VPR handling of unconnected .names from blif

[GoogleCodeExporter]

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

Original issue reported on code.google.com by jeffrey....@gmail.com on 30 Apr 2012 at 4:50

Attachments:

• ch_intrinsics.pre-vpr.blif

[GoogleCodeExporter]

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. 

Original comment by andy16...@gmail.com on 30 Apr 2012 at 12:53

[GoogleCodeExporter]

Original comment by jeffrey....@gmail.com on 30 Apr 2012 at 3:09

• Added labels: Module-ODIN

[GoogleCodeExporter]

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

The bug still exists.

Original comment by jeffrey....@gmail.com on 7 May 2012 at 11:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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? 

Original comment by andy16...@gmail.com on 7 May 2012 at 11:22

[GoogleCodeExporter]

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.  

Original comment by jeffrey....@gmail.com on 7 May 2012 at 11:27

[GoogleCodeExporter]

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

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

Original comment by jeffrey....@gmail.com on 10 May 2012 at 4:17

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by jeffrey....@gmail.com on 18 May 2012 at 7:02

[GoogleCodeExporter]

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. 

Original comment by JasonKai...@gmail.com on 5 Jun 2012 at 8:01

• Added labels: Type-Enhancement
• Removed labels: Type-Defect, Module-ODIN