TinyTapeout/tt-support-tools
1
0
Fork 0
mirror of https://github.com/TinyTapeout/tt-support-tools.git synced 2026-11-03 04:36:09 +01:00
Code Issues Packages Projects Releases Wiki Activity

fix(datasheet): remove outdated STA / Verification sections

Browse Source
This commit is contained in:
Uri Shaked
2023-09-07 20:53:56 +03:00
parent af58bde8be
commit 010cebe7d6
3 changed files with 0 additions and 270 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/STA.md
-115
View File
@@ -1,115 +0,0 @@
# Toplevel STA and Spice analysis for TinyTapeout-02 and 03.
Contributed by J. Birch 22 March 2023
## Introduction
TinyTapeout is built using the OpenLane flow and consists of three major components:
1) up to 250 user designs with a common interface, each of which has been composed using the OpenLane flow,
2) a scanchain block that is instanced for each user design to provide input data and to sink output data,
3) a scan chain controller.
The OpenLane flow allows for timing analysis of each of these individual blocks but does not provide for
analysis of the assembly of them, which leaves potential holes in timing that could cause failures.
This work allows a single design to be assembled out of the sub-blocks and this can then be submitted to
STA for analysis.
In addition, an example critical path (for the clock that is passed along the scanchain) is created using
a Python script so that it can be run through SPICE.
## GitHub action
The [STA github action](.github/workflows/sta.yaml) automatically runs the STA when the repository is updated.
## Prerequisites
To run STA, the following files need to be available:
1) a gate level verilog netlist of the top level design (verilog/rtl/user_project_wrapper.v)
2) a gate level verilog netlist for each sub-block (verilog/rtl/)
3) a SPEF format parasitics file for the top level wiring (spef/)
4) a SPEF format parasitics file for each sub-block (spef/)
5) the relevant SkyWater libraries for STA analysis - installed with the PDK
6) OpenSTA 2.4.0 (or later) needs to be on the PATH. rundocker.sh shows how to use STA included in the OpenLane docker
7) python3.9 or later
8) verilog parser (pip3 install verilog-parser)
9) a constraints file (sta_top/top.sdc)
## Assumptions
* all of the Verilog files are in a single directory
* all of the SPEF files are in a single directory
## Issues
The Verilog parser has two bugs: it does not recognise 'inout' and it does not cope
with escaped names (starting with a '\'). Locally this has been fixed but to use the
off-the-shelf parser we preprocess the file to change inout to input and remove the escapes and
substitute the [nnn] with _nnn_ in the names
## Invoking STA analysis
sta_top/toplevel_sta.py <path to verilog> <path to spef> <sdc>
eg:
sta_top/toplevel_sta.py ./verilog/gl/user_project_wrapper.v
./spef/user_project_wrapper.spef ./sta_top/top.sdc > sta.log
Alternatively you can enter interactive mode after analysis:
sta_top/toplevel_sta.py ./verilog/gl/user_project_wrapper.v
./spef/user_project_wrapper.spef ./sta_top/top.sdc -i
## How it works
* preprocesses the main Verilog
* parses the main Verilog to find which modules are used
* creates a new merged Verilog containing all the module netlists and the main netlist
* creates a tcl script in the spef directory to load the relevant spefs for each instanced module in the main verilog
* creates all_sta.tcl in the verilog/gl directory that does the main STA steps (loading design, loading constraints,
running analyses) - this mimics what OpenLane does
* creates a script sta.sh in the verilog/gl directory which sets up the environment and invokes STA to run all_sta.tcl
* runs sta.sh
## Invoking Spice simulation:
### Important notes
* This uses at least ngspice-34, tested on ngspice-39, which has features to increase speed
and reduce memory image when running with the SkyWater spice models. In addition the following
needs to be set in ~/spice.rc and/or ~/.spiceinit:
set ngbehavior=hs
* Note the spelling of ngbehavior (no u). If this is not set then the simulation will run out of memory]
* If the critical path changes then the spice_path.py script will need to be adapted to follow suit
### Instructions
* go to where the included spice files will be found
cd $PDK_ROOT/sky130A/libs.tech/ngspice
* run the script to get the critical path spice circuit - 250 stages of the clock
<repo directory>/sta_top/spice_path.py path.spice
* invoke spice (takes about 2 minutes)
ngspice path.spice
* run the sim (takes about 2 minutes)
tran 1n 70n
* show the results
plot i0 i250
This chart shows the input clock and how it changes after 250 blocks. It was simulated for 200n to capture a clean pair of clock pulses.
![clock_spice.png](pics/clock_spice.png)
docs/VERIFICATION.md
-149
View File
@@ -1,149 +0,0 @@
# Verification
We are not trying to verify every single design. That is up to the person who makes it. What we want is to ensure that every design is accessible, even if some designs are broken.
We can split the verification effort into functional testing (simulation), static tests (formal verification), timing tests (STA) and physical tests (LVS & DRC).
See the sections below for details on each type of verification.
## Setup
You will need the GitHub tokens setup as described in [INFO](INFO.md#instructions-to-build-gds).
The default of 250 projects takes a very long time to simulate, so I advise overriding the configuration:
# fetch the test projects
./configure.py --test --clone-all
# rebuild config with only 20 projects
./configure.py --test --update-caravel --limit 20
You will also need iVerilog & cocotb. The easist way to install these are to download and install the [oss-cad-suite](https://github.com/YosysHQ/oss-cad-suite-build).
## Simulations
* Simulation of some test projects at RTL and GL level.
* Simulation of the whole chip with scan controller, external controller, logic analyser.
* Check wait state setting.
* Check clock divider setting.
### Scan controller
This test only instantiates user_project_wrapper (which contains all the small projects). It doesn't simulate the rest of the ASIC.
cd verilog/dv/scan_controller
make test_scan_controller
The Gate Level simulation requires scan_controller and user_project_wrapper to be re-hardened to get the correct gate level netlists:
* Edit openlane/scan_controller/config.tcl and change NUM_DESIGNS=250 to NUM_DESIGNS=20.
* Then from the top level directory:
make scan_controller
make user_project_wrapper
* Then run the GL test
cd verilog/dv/scan_controller
make test_scan_controller_gl
#### single
Just check one inverter module. Mainly for easy understanding of the traces.
make test_single
#### custom wait state
Just check one inverter module. Set a custom wait state value.
make test_wait_state
#### clock divider
Test one inverter module with an automatically generated clock on input 0. Sets the clock rate to 1/2 of the scan refresh rate.
make test_clock_div
## Top level tests setup
For all the top level tests, you will also need a [RISCV compiler to build the firmware](https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2020.04.1-x86_64-linux-ubuntu14.tar.gz).
You will also need to install the 'management core' for the Caravel ASIC submission wrapper. This is done automatically by following the [PDK install instructions](INFO.md#build-the-gds).
### Top level test: internal control
Uses the scan controller, instantiated inside the whole chip.
cd verilog/dv/scan_controller_int
make coco_test
### Top level test: external control
Uses external signals to control the scan chain. Simulates the whole chip.
cd verilog/dv/scan_controller_ext
make coco_test
### Top level test: logic analyser control
Uses the RISCV co-processor to drive the scanchain with firmware. Simulates the whole chip.
cd verilog/dv/scan_controller_la
make coco_test
## Formal Verification
* Formal verification that each small project's scan chain is correct.
* Formal verification that the correct signals are passed through for the 3 different scan chain control modes.
### Scan chain
Each GL netlist for each small project is proven to be equivalent to the reference scan chain implementation.
The verification is done on the GL netlist, so an RTL version of the cells used needed to be created.
See [here for more info](tinytapeout_scan/README.md).
### Scan controller MUX
In case the internal scan controller doesn't work, we also have ability to control the chain from external pins or the Caravel Logic Analyser.
We implement a simple MUX to achieve this and [formally prove it is correct](verilog/rtl/scan_controller/properties.v).
## Timing constraints
Due to limitations in OpenLane - a top level timing analyis is not possible. This would allow us to detect setup and hold violations in the scan chain.
Instead, we design the chain and the timing constraints for each project and the scan controller with this in mind.
* [Each small project has a negedge flop flop at the end of the shift register to reclock the data](https://github.com/mattvenn/wokwi-verilog-gds-test/blob/17f106db36f022536d013b960316bcc7f02c572c/template/scan_wrapper.v#L67). This gives more hold margin.
* [Each small project has SDC timing constraints](https://github.com/mattvenn/wokwi-verilog-gds-test/blob/main/src/base.sdc)
* [Scan controller](https://github.com/mattvenn/tinytapeout-mpw7/blob/aacae16304f4a4878943a49fd479d8a284736e32/verilog/rtl/scan_controller/scan_controller.v#L334) uses a shift register clocked with the end of the chain to ensure correct data is captured.
* [Scan controller has its own SDC timing constraints](openlane/scan_controller/base.sdc)
* Scan controller can be configured to wait for a programmable time at latching data into the design and capturing it from the design.
* External pins (by default) control the scan chain.
## Physical tests
* LVS
* DRC
* CVC
### LVS
Each project is built with OpenLane, which will check LVS for each small project.
Then when we combine all the projects together we run a top level LVS & DRC for routing, power supply and macro placement.
The extracted netlist from the GDS is what is used in the formal scan chain proof.
### DRC
DRC is checked by OpenLane for each small project, and then again at the top level when we combine all the projects.
### CVC
Mitch Bailey' CVC checker is a device level static verification system for quickly and easily detecting common circuit errors in CDL (Circuit Definition Language) netlists. We ran the test on the final design and found no errors.
* See [the paper here](https://woset-workshop.github.io/PDFs/2020/a05-slides.pdf).
* Github repo for the tool: https://github.com/d-m-bailey/cvc
documentation.py
-6
View File
@@ -66,8 +66,6 @@ class Docs():
doc_header = self.load_doc_template('doc_header.md')
doc_template = self.load_doc_template('doc_template.md')
doc_info = self.load_doc_template("../../tt-multiplexer/docs/INFO.md")
doc_verification = self.load_doc_template('VERIFICATION.md')
doc_sta = self.load_doc_template('STA.md')
doc_credits = self.load_doc_template('CREDITS.md')
with open(self.args.dump_markdown, 'w') as fh:
@@ -117,10 +115,6 @@ class Docs():
# ending
fh.write(doc_info)
fh.write("\n\clearpage\n")
fh.write(doc_verification)
fh.write("\n\clearpage\n")
fh.write(doc_sta)
fh.write("\n\clearpage\n")
fh.write(doc_credits)
logging.info(f'wrote markdown to {self.args.dump_markdown}')