You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the corner case where VPR's --sweep_dangling_primary_ios is set to off, --sweep_dangling_nets is set to on, and an SDC file is provided for timing analysis, the dangling primary IOs that remain in the netlist cause the assertion on line 1291 of read_sdc.cpp to trigger
VTR_ASSERT(netlist.block_pins(blk).size() == 1);
Inspecting with GDB reveals that the size value for the dangling pin is 0, which I understand from tracing the code means that block pin list for the dangling I/O is empty instead of containing an entry for the pin.
After digging through some source code and finding that adding --sweep_dangling_nets off to my command line caused SDC parsing to succeed, it appears that also not sweeping the dangling net allows the block_pins() call to work as intended. My takeaway from this at a high level is that the pin information and related net information need to be swept consistently in order for the netlist data to be constructed correctly.
Expected Behaviour
The documentation for --sweep_dangling_primary_ios and --sweep_dangling_nets does not give any hints that these need to be used in concert to avoid issues of inconsistency in the AtomNetlist data structure content. I would therefore expect that they could be used independently of one another, but these results suggest that either they should always be used together or that there is a need to resolve a consistency issue in the sweeping functions.
Current Behaviour
Since the assertion triggers, VPR aborts.
Possible Solution
It would appear that either the net sweeping pass needs to be modified so that it does not sweep nets related to unswept primary IOs, or the documentation needs an update to reflect that these options should be used in concert, or the options should somehow be merged so that sweeping behavior is self-consistent.
For the corner case where VPR's
--sweep_dangling_primary_ios
is set tooff
,--sweep_dangling_nets
is set toon
, and an SDC file is provided for timing analysis, the dangling primary IOs that remain in the netlist cause the assertion on line 1291 of read_sdc.cpp to triggerVTR_ASSERT(netlist.block_pins(blk).size() == 1);
Inspecting with GDB reveals that the size value for the dangling pin is 0, which I understand from tracing the code means that block pin list for the dangling I/O is empty instead of containing an entry for the pin.
After digging through some source code and finding that adding
--sweep_dangling_nets off
to my command line caused SDC parsing to succeed, it appears that also not sweeping the dangling net allows theblock_pins()
call to work as intended. My takeaway from this at a high level is that the pin information and related net information need to be swept consistently in order for the netlist data to be constructed correctly.Expected Behaviour
The documentation for
--sweep_dangling_primary_ios
and--sweep_dangling_nets
does not give any hints that these need to be used in concert to avoid issues of inconsistency in the AtomNetlist data structure content. I would therefore expect that they could be used independently of one another, but these results suggest that either they should always be used together or that there is a need to resolve a consistency issue in the sweeping functions.Current Behaviour
Since the assertion triggers, VPR aborts.
Possible Solution
It would appear that either the net sweeping pass needs to be modified so that it does not sweep nets related to unswept primary IOs, or the documentation needs an update to reflect that these options should be used in concert, or the options should somehow be merged so that sweeping behavior is self-consistent.
Steps to Reproduce
Download:
sweep_example.tar.gz
untar to directory of your choosing
run
vpr logik_demo_core.xml dbg_bridge.blif --sweep_dangling_primary_ios off
to see the crashrun
vpr logik_demo_core.xml dbg_bridge.blif --sweep_dangling_primary_ios off --sweep_dangling_nets off
to see successful place and route.Context
Your Environment
The text was updated successfully, but these errors were encountered: