maliberty
commented
1 year ago I think this is more of an spef generation issue. If you have:
*27610 soc\/gpio\/gen_filter\[14\]\.filter\/_14_then it annotates fine. Please package your setup to extract the spef.
Describe the bug
For the special case where synthesis netlists preserve hierarchy and OpenROAD flattens them, the resulting naming convention in the netlist and that of the SPEF file do not appear to align. This results in SPEF parasitic annotation failures.
As an example, we use a particular hierarchical name from an open source design implemented with hierarchy preserved during synthesis. The netlist name for a particular instance is:
sky130_fd_sc_hd__xor2_2 \soc/gpio/gen_filter[14].filter/_14_ (.A(ea_din[0]),The corresponding instance name mapping in the SPEF file is:
*27610 soc/gpio/gen_filter\[14\]\.filter/_14_For the example above, the expected behavior is that the slight differences in name syntax used between the two files are resolved internally to OpenROAD and that annotation succeeds without causing warnings. Instead, the following warning is generated:
[WARNING STA-0172] ./asic_core.minimum.spef line 263475, instance soc/gpio/gen_filter\[14\].filter/_14_ not found.Note that thousands of similar examples are present in the open source design used, and that they result in delay modeling errors posted in Issue #3211.
To investigate, the above example was modified in the netlist AND SPEF file with matching names that lack special characters that are treated as corner cases by many EDA software products when managing ASIC netlist names (notably '\', '[', ']', and '.'). The diff of the netlists is as follows:
28564c28564< sky130_fd_sc_hd__xor2_2 \soc/gpio/gen_filter[14].filter/_14_ (.A(ea_din[0]),---> sky130_fd_sc_hd__xor2_2 soc_gpio_gen_filter_14_filter_14_ (.A(ea_din[0]),Similarly, the SPEF file is modified to produce a matching name:
< *27610 soc_gpio_gen_filter_14_filter_14_---> *27610 soc/gpio/gen_filter\[14\]\.filter/_14_Expected Behavior
The expected outcome of this experiment is elimination of the warning noted above. The intended outcome is obtained, along with some additional side effects, yielding the following overall diff in warning messages from readback of the netlist and SPEF:
Right facing diffs (">") indicate warnings present in the unmodified netlist and not in the modified netlist. Left facing diffs ("<") indicate warnings in the modified netlist that didn't line up with warnings found in the unmodified netlist. Inspection via tkdiff suggests that these new warnings in the modified netlist arise because the warning count limit is being reached, and eliminating the three warnings via modification allows previously unprinted warnings to appear in the log file.
Environment
To Reproduce
Download this tarball:
Example netlist modification to eliminate SPEF annotation warnings
cd testcase./run.shExecution of run.sh executes readback of the design database and loading of the verilog netlist and SPEF file to generate above warnings and redirect them to a log file. A provided perl script eliminates filename differences in the warning messages to simplify the analysis of the logfile diff. The diff is then executed and printed to STDOUT. When run successfully the resulting diff should match that posted to this issue thread.
Relevant log output
No response
Screenshots
No response
Additional Context
No response