VPR handling of unconnected .names from blif

[kmurray]

Originally reported on Google Code with ID 20

Sometimes blif files are produced where circuit nodes are not connected. An example
is the ch_intrinsics blif file (lines 997-1043), attached.

The lines in the blif file look like this:
.names top^memory_controller_out~8
 0
.names top^memory_controller_out~9
 0

These end up getting mapped to LUTs in VPR.  I believe this is incorrect, since they
don't actually drive any nodes.


Secondly, entries that are essentially just wires also get LUTs.  This may be the intended
behavior - I'm not sure, but it seems unnecessary.

.names top^FF_NODE~161 top^return_val~0
1 1
.names top^FF_NODE~162 top^return_val~1
1 1

Reported by jeffrey.goeders on 2012-04-30 04:50:10

---

- _Attachment: [ch_intrinsics.pre-vpr.blif](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-20/comment-0/ch_intrinsics.pre-vpr.blif)_

[kmurray]

Thanks for reporting this issue Jeff. 

Can you please try again with the latest SVN version of Odin II? The Odin II trunk
should be stable, and I believe this bug has already been corrected. 

Reported by andy16666 on 2012-04-30 12:53:25

[kmurray]

Reported by jeffrey.goeders on 2012-04-30 15:09:48

• Labels added: Module-ODIN

[kmurray]

I have updated to the latest versions of ODIN and VPR. 

The bug still exists.

Reported by jeffrey.goeders on 2012-05-07 23:04:57

[kmurray]

On closer examination, I believe this is correct, strictly speaking. But bear with me
for a moment while I explain and then I'll ask for your recommendation. For example:


.names top^memory_controller_out~8
 0
.names top^memory_controller_out~9
 0

Depending, these are probably added during padding, and *should* be unconnected. The
new version probably names them more descriptively. Knowing that, what do you suggest
it outputs instead? I would be just as happy to output nothing for unconnected output
pins, if that's legal. 

The second case is correct as well. We can output something else in the BLIF if you
want, but this seems like something ABC would easily catch. 

What do you think? 

Reported by andy16666 on 2012-05-07 23:22:52

[kmurray]

OK.  I guess what ODIN is doing is fine.  I had originally flagged this as a VPR issue,
and I think that still holds true.

I don't think VPR should be mapping unconnected signals to LUTs.  

The second case, where signals are merely a name change, also seems like it should
not be using LUTs.  

Reported by jeffrey.goeders on 2012-05-07 23:27:00

[kmurray]

The 1st case (unconnected) needs to be fixed in VPR.

The 2nd case (wire, name change) is already handled in VPR.

Reported by jeffrey.goeders on 2012-05-10 16:17:52

• Status changed: Accepted

[kmurray]

I also came across the following lines in diffeq1.pre-vpr.blif:

.names vcc
 1

Is this something that we are automatically inserting to specify a constant '1'?  

Currently VPR is mapping this to a LUT, which should be fixed.

Reported by jeffrey.goeders on 2012-05-18 19:02:19

[kmurray]

I'm going to merge in Jeff Rudolphs fixes for constant output pads.  He gives the user
the option of whether or not to remove constants.  This choice is actually quite important.
 How often have we, as digital designers, set a particular output pad to a constant
gnd or vcc (to turn on an LED on a development board, for example) for testing on small
projects?  I'm sure pretty often.  At the same time, we also rely on the CAD tools
to warn us when an output is constant when it is not supposed to be.  So giving the
same choice to the user is pretty useful.

Constants such as vcc and gnd are not so easy to handle.  They can only be removed
if the architecture can programmably set pins to gnd or vcc.  If not, then a LUT will
need to get consumed to act as a constant 0 or constant 1.  VPR already has code in
place that will handle constants with LUTs (ie. timing analyzer does not treat delays
from constants as part of the timing path).  Furthermore, what if some blocks in your
architecture support gnd/vcc and others do not?  

For these reasons, I'm actually changing this to a VPR enhancement and taking over
ownership for it. 

Reported by JasonKaiLuu on 2012-06-05 20:01:04

• Labels added: Type-Enhancement
• Labels removed: Type-Defect, Module-ODIN

[kmurray]

With the new atom netlist support has been added for more advanced netlist cleaning as documented here, including support for sweeping outputs driven by constants.

I've filed #163 to track enhanced support for constant nets.