Attempting to read them in both orders yields different results:
#!/usr/bin/env -S sta -exit
set bad_list "./bad.v ./good.v"
set good_list "./good.v ./bad.v"
foreach el $good_list {
if { [catch {read_verilog $el} err]} {
puts "Netlist $el failed parsing:"
puts "$err"
puts "Skipping..."
}
}
link_design valid_module
If bad.v is read first, good.v fails to read and no design is linked eventually. If good.v is read first, bad.v fails, but the design is still linked.
2. Modules appear to be associated with the wrong file
This isn't as big of a problem but, when reading them in the good order, this happens:
OpenSTA 2.3.3 2f330b3bf4 Copyright (c) 2021, Parallax Software, Inc.
License GPLv3: GNU GPL version 3 <http://gnu.org/licenses/gpl.html>
This is free software, and you are free to change and redistribute it
under certain conditions; type `show_copying' for details.
This program comes with ABSOLUTELY NO WARRANTY; for details type `show_warranty'.
Netlist ./bad.v failed parsing:
Error: ./bad.v line 1, syntax error
Skipping...
Warning: ./bad.v line 4, module blackbox_module not found. Creating black box for inst.
As you can see, the warning was printed for the wrong file. blackbox_module is part of good.v, but it seems to have been overwritten by the last file read.
There are a number of issues with reading netlists in OpenSTA:
1. Reading a bad netlist causes all further files read to fail parsing:
Let's presume we have two netlists, one valid and one invalid:
bad.v
good.v
Attempting to read them in both orders yields different results:
If
bad.v
is read first,good.v
fails to read and no design is linked eventually. Ifgood.v
is read first,bad.v
fails, but the design is still linked.2. Modules appear to be associated with the wrong file
This isn't as big of a problem but, when reading them in the good order, this happens:
As you can see, the warning was printed for the wrong file.
blackbox_module
is part ofgood.v
, but it seems to have been overwritten by the last file read.