Games / Log forensics / Sign-off checks

Sign-off checks

Each case shows the tail of a real run, ending where the tool stopped or warned. Say what caused it, or what to do about it. A case you miss returns later in the round and starts its schedule over; one you get right returns after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. Progress is stored in this browser.

SourceEach case is the tail of a real run of the gcd design on Nangate45 in the openroad/orfs container, with one thing wrong. The same failures happen on commercial tools in different words: what carries across is the reasoning from the last few lines back to the cause. Reference: the OpenROAD documentation (OpenROAD-flow-scripts on GitHub).

All 3 cases in this stage, with answers

The design-rule count is zero. What has that proved?
6_drc log
```
$ cat reports/sky130hd/gcd/6_drc_count.rpt
0

$ head reports/sky130hd/gcd/6_drc.lyrdb
<report-database>
 <description>SKY130 DRC runset</description>
 <original-file/>
 <generator>drc: script='/OpenROAD-flow-scripts/flow/platforms/sky130hd/drc/sky130hd.lydrc'</generator>
 <top-cell>gcd</top-cell>
 <tags>
 </tags>
 <categories>
  <category>
   <name>li.1</name>
   <description>li.1 : min. li width : 0.17um</description>
   <categories>
   </categories>
```
That this deck's rules found nothing, which is narrower than clean.

Hint: Read what the report says about itself before reading its result.

The report names the deck it came from and lists the rules it knows, each with its own description. An open deck implements a subset of what a foundry's sign-off deck checks, so a zero means only that the subset passed. The number itself is counted by matching markers in the report database, which is why the count file and the database must be read together.
```
# know which rules your deck implements before trusting the count
grep -c "<category>" 6_drc.lyrdb
```
Did layout versus schematic find a mismatch?
6_lvs log
```
KLayout 0.30.7
ERROR: In /OpenROAD-flow-scripts/flow/platforms/sky130hd/lvs/sky130hd.lylvs: Can't find a value for a R, C or L device in /OpenROAD-flow-scripts/flow/objects/sky130hd/gcd/sky_signoff/6_final_concat.cdl, line 5740 in Netlist::read
ERROR: RuntimeError: Can't find a value for a R, C or L device in /OpenROAD-flow-scripts/flow/objects/sky130hd/gcd/sky_signoff/6_final_concat.cdl, line 5740 in Netlist::read in Executable::execute
```
No: it stopped while reading the netlist, before comparing.

Hint: Ask what stage of the check this message comes from.

The comparison never started. The reader hit a passive device with no value on it and gave up, which usually means the netlist handed to the check was assembled wrongly rather than that the design is wrong. A check that did not run is not a check that passed, and it is worth being strict about the difference: the line to look at is the one the error names.
```
sed -n '5740p' 6_final_concat.cdl
```
The same design on the default grid drops 0.38 percent. What does this run tell you?
6_report log
```
[INFO PSM-0040] All shapes on net VDD are connected.
########## IR report #################
Net              : VDD
Corner           : default
Total power      : 2.61e-03 W
Supply voltage   : 1.10e+00 V
Worstcase voltage: 1.09e+00 V
Average voltage  : 1.09e+00 V
Average IR drop  : 8.77e-03 V
Worstcase IR drop: 1.25e-02 V
Percentage drop  : 1.14 %
######################################
```
The grid is carrying the same current through less metal.

Hint: The power is the same in both runs. Only one thing changed.

Total power is 2.61 milliwatts here against 2.62 in the default run, so the design is doing the same work. The straps were narrowed and spread out, and the drop tripled. A percentage of a percent is still healthy, since limits are usually a few percent, but the trend is what a grid review watches: the number means nothing without the grid and the activity that produced it.
```
# widen or tighten the straps until the drop fits the budget
add_pdn_stripe -layer metal4 -width 1.4 -pitch 6.5 -offset 0
```