-
Notifications
You must be signed in to change notification settings - Fork 415
Inconsistency between post synthesis BLIF and Verilog netlists #1721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Discussed in meeting; agreed that we can copy the blif behaviour so long as it doesn't confuse downstream verilog simulators.
|
This issue has been inactive for a year and has been marked as stale. It will be closed in 15 days if it continues to be stale. If you believe this is still an issue, please add a comment. |
This issue has been marked stale for 15 days and has been automatically closed. |
This was fixed long ago and should have been closed; leaving it closed. |
VPR can write post synthesis netlist (it is more of a post-pnr netlist IMO) as BLIF and Verilog. In the BLIF file unconnected input and output ports are tied to special nets named
__vpr__unconnXX
which is fine. However, in the Verilog file they are not represented correctly.Expected Behaviour
In post synthesis netlist in Verilog format:
1'bX
or tied to a special net named__vpr__unconnXX
.__vpr__unconnXX
.Current Behaviour
In post synthesis netlist in Verilog format:
1'b0
which is clearly incorrectDummyOut
which is even more incorrect as it results in multi-source nets.Possible Solution
Fix this part of the code
vtr-verilog-to-routing/vpr/src/base/netlist_writer.cpp
Lines 2188 to 2196 in a71ca6d
Steps to Reproduce
For any architecture and design run the full VPR flow (pack, place and route) with
--analysis
and--gen_post_synthesis_netlist on
options.Context
I want the output post-synthesis netlist in Verilog format to be usable for design simulation.
Your Environment
8.0.0-3452-ge7d45e013
(same issue would occur with the current master)GNU 7.3.0 on Linux-4.15.0-1109-azure x86_64
The text was updated successfully, but these errors were encountered: