This is a very simple example of a tiny Verilog design which will hopefully be made into part of an ASIC (i.e. a real silicon chip) through the Tiny Tapeout program.
It implements what could be considered a primitive state machine that takes in two 8-bit numbers (clocked in one nibble at a time), and then gives the 16-bit product (clocked out one byte at a time), before then repeating this process.
The waveform above shows two operands being clocked in: 0xAE
, then 0xCD
. Then starting at 800µs it starts clocking out the result: 0x8B56
.
Building this is normally done automatically via GitHub Actions, but more info about this is provided below.
The main things are:
.github/workflows
: contains workflow scripts, for running automated tasks via GitHub Actions, on push.src/
:product.v
: Main Verilog source code implementing this design (a module calledalgofoogle_product
).tb.v
: Verilog testbench that is used by cocotb tests, basically as an adapter to interface with the design and capture signal waveforms intb.vcd
.test.py
: Python script used by cocotb to run our tests.Makefile
: Used bymake
ormake GATES=yes
to run tests.tb2.gtkw
: "Save File" for GTKWave; config for how to displaytb.vcd
.config.tcl
: Generic config for OpenLane (TT standard; should not be modified).cells.v
: Ignore this one; only used for Wokwi-based designs (which this isn't).
info.yaml
: Tiny Tapeout standard project information about this repo, inc. source files and basic documentation.
The src
directory contains not only the main Verilog source code, but also a Makefile
.
If you run make
while the correct tools are installed, it should put the verilog through a few simple
tests that sequentially load and retrieve data from the design, to exercise a few multiplications.
Running this will also create a tb.vcd
file of the signal waveforms, that can be viewed with GTKWave:
gtkwave tb.vcd tb2.gtkw
Note that running tests requires that Python is installed, along with cocotb
and iverilog
.
The GitHub Actions (see below) can provide more tips on what you need to install for running tests.
They also reveal how you could set up a run of make GATES=yes
to run a GL (Gate-Level) test.
If you can't run things locally, you could just rely on the GitHub Actions to run your tests,
generate your GDS, and show you what the final layout looks like.
NOTE: TT designs can be made using an HDL (e.g. Verilog, as this design is) or through schematic capture using Wokwi.
There is a specific guide for using Wokwi to make Tiny Tapeout designs,
but this design is a fork of tt03-verilog-demo
.
There are GitHub Actions we can look to which run the build process for us, via GitHub, each time there is a push to the repo.
Note that you might want to read the following two articles:
Artifacts produced by these Actions include:
- Test results: Both cocotb result text (see here for an example; expand the
test
step) andtest-vcd.zip
file containing the.vcd
file of signals simulated during the test. - Documentation: PDF of the "datasheet" for this design, built from information in
info.yaml
. - GDS: The main affair. Actual GDS (blueprint) to be included in the overall TT chip for manufacturing, with both 2D and 3D previews. Also, GL (Gate-Level) test results built from the GDS.
All 3 must succeed before the design is eligible to submit to TT. Once you've confirmed that, if a TT round is open, you should be able to go to the submission page and paste in the URL of your GitHub repo, and it will verify that everything is good. I won't provide too much detail on this because it might change in TT04.
Being able to build locally is a great way to quickly identify synthesis or fit issues, instead of having to wait for the GitHub Actions to complete.
I'm using the "MPW8 VM" supplied by Matt Venn via the Zero to ASIC course, which is an Ubuntu 20.04 LTS VM that comes with most of the necessary tools installed, but you can potentially figure out what you need to set up by looking at the GitHub Actions.
Here's what I specifically needed to do, when using the MPW8 VM:
-
Clone this repo.
-
Go into it, then clone the tt-support-tools repo into a subdirectory called
tt
:git clone git@github.com:tinytapeout/tt-support-tools tt
-
I already have these environment variables defined:
var value OPENLANE_IMAGE_NAME
efabless/openlane:cb59d1f84deb5cedbb5b0a3e3f3b4129a967c988-amd64
OPENLANE_ROOT
/home/zerotoasic/asic_tools/openlane
PDK_ROOT
/home/zerotoasic/asic_tools/pdk
PDK
sky130A
...if you're setting up from scratch, though, see the top of the
gds
workflow for values, and note that references torunner
is specific to the environment of the GitHub Action itself. -
Install Python stuff needed by TT:
pip install -r tt/requirements.txt
-
Run:
./tt/tt_tool.py --create-user-config
- Outputs:
2023-04-26 06:08:07,817 - project - INFO - creating include file
- Contents of
src/user_config.tcl
:set ::env(DESIGN_NAME) algofoogle_product set ::env(VERILOG_FILES) "\ $::env(DESIGN_DIR)/product.v"
- Outputs:
-
Run:
./tt/tt_tool.py --harden
-
Results are in
runs/wokwi/
, with these warnings:[WARNING]: Current core area is too small for the power grid settings chosen. The power grid will be scaled down. [WARNING]: There are max fanout violations in the design at the typical corner. Please refer to '../work/runs/wokwi/reports/signoff/25-rcx_sta.slew.rpt'.
Generally these can be ignored: The core area warning is to be expected, and in the case of this repo the fanout is just a clock buffer going 1 over, which from what others have advised is still OK.
-
Summaries:
./tt/tt_tool.py --print-warnings
-- No output./tt/tt_tool.py --print-stats
-- 18.35% utilisation (just for routing?) with wire length of 13563um../tt/tt_tool.py --print-cell-category
-- Hard to read because it's a Markdown table with URLs, but it appears to be the same numbers as what the official build did in GHA../tt/tt_tool.py --create-png
-- Creates a PNG of the GDS.
- Include the proper license in all source files.
- Support more bits, i.e. larger operand and hence larger result. Make this selective based on another input pin?
- The design could probably already start clocking out the first output byte while receiving the last input nibble; 1 fewer cycles needed.
- There is an SHL-8 (shift-left by 8 bits, i.e.
<<8
) that might synthesise to slightly fewer standard cells if we accept that we don't actually need to set the lower 8 bits to 0. - Would some sort of progressive multi-step multiply mean smaller multiply logic and hence could support more bits?
- If we're really space-constrained, we could drop
product <= 0
during reset. - Try targeting an FPGA.
TinyTapeout is an educational project that aims to make it easier and cheaper than ever to get your digital designs manufactured on a real chip!
Go to https://tinytapeout.com for instructions!
General constraints of this 3rd TT round are that the design must fit in 150µm × 170µm (which allows for ~1000 standard cells using sky130A), and can use up to 8 distinct inputs, 8 distinct outputs. Clock and reset signals (if required) must be a part of the 8 inputs. Additionally, because of the "scan chain" of the whole Tiny Tapeout chip (i.e. how 250 separate designs must share the available chip area and IOs), the maximum IO speed is limited to somewhere between 6kHz and 70kHz (to be proven).
NOTE: For TT04 it is expected that clock/IO speeds, available design area, and number of IOs will be notably higher.