shenpeifu / vtr-verilog-to-routing

Automatically exported from code.google.com/p/vtr-verilog-to-routing
0 stars 0 forks source link

VPR stores truth table for UNCONN, overwriting data for previous LUT #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Read in a blif with a '.names unconn'

In read_blif.c, get_tok() makes a call to add_lut(), which indicates that the 
next line of the blif is truth table data.  However, add_lut() will not create 
a new LUT for '.names unconn' so the truth table data ends up overwriting the 
truth table data of the previous LUT.

This is probably low priority as I'm not sure if anything is even using the 
truth table data.  I can fix this later; currently I don't have an environment 
set up to use the new repository.

Original issue reported on code.google.com by jeffrey....@gmail.com on 21 Mar 2012 at 5:31

GoogleCodeExporter commented 9 years ago
Good catch, how did you manage to discover this?  Fixed in the trunk.

I currently use the truth tables to verify the packer for pure soft logic 
designs.  I was planning on extending that code so that we can do equivalence 
checking post place-and-route for general circuits.  That way, we can use tools 
independant of VPR (ABC for example) to check that VPR produces logically 
correct circuits post place-and-route.  This would be much stronger 
verification than verification within VPR because if, for example, VPR has a 
messed up netlist reader, the missed logic will get caught by the third party 
tool.

Original comment by JasonKai...@gmail.com on 21 Mar 2012 at 10:16

GoogleCodeExporter commented 9 years ago

Original comment by JasonKai...@gmail.com on 21 Mar 2012 at 10:17

GoogleCodeExporter commented 9 years ago
Thanks for making the fix.

I use the truth table to generate the SRAM values in a LUT for power analysis.  
My code was crashing when trying to parse ' 0' as it is not in the normal 
.names format.

Original comment by jeffrey....@gmail.com on 21 Mar 2012 at 11:09