verilog-to-routing / vtr-verilog-to-routing

Verilog to Routing -- Open Source CAD Flow for FPGA Research

Verilog to Routing (VTR)

Introduction

The Verilog-to-Routing (VTR) project is a world-wide collaborative effort to provide an open-source framework for conducting FPGA architecture and CAD research and development. The VTR design flow takes as input a Verilog description of a digital circuit, and a description of the target FPGA architecture. It then performs:

• Elaboration, Synthesis & Partial Mapping (PARMYS)
• Logic Optimization & Technology Mapping (ABC)
• Packing, Placement, Routing & Timing Analysis (VPR)

to generate FPGA speed and area results. VTR includes a set of benchmark designs known to work with the design flow.

VTR can also produce FASM to program some commercial FPGAs (via Symbiflow)

Placement (carry-chains highlighted)	Critical Path

Logical Connections	Routing Utilziation

Documentation

VTR's full documentation includes tutorials, descriptions of the VTR design flow, and tool options.

Also check out our additional support resources.

License

Generally most code is under MIT license, with the exception of ABC which is distributed under its own (permissive) terms. See the full license for details.

How to Cite

The following paper may be used as a general citation for VTR:

K. E. Murray, O. Petelin, S. Zhong, J. M. Wang, M. ElDafrawy, J.-P. Legault, E. Sha, A. G. Graham, J. Wu, M. J. P. Walker, H. Zeng, P. Patros, J. Luu, K. B. Kent and V. Betz "VTR 8: High Performance CAD and Customizable FPGA Architecture Modelling", ACM TRETS, 2020.

Bibtex:

@article{vtr8,
  title={VTR 8: High Performance CAD and Customizable FPGA Architecture Modelling},
  author={Murray, Kevin E. and Petelin, Oleg and Zhong, Sheng and Wang, Jai Min and ElDafrawy, Mohamed and Legault, Jean-Philippe and Sha, Eugene and Graham, Aaron G. and Wu, Jean and Walker, Matthew J. P. and Zeng, Hanqing and Patros, Panagiotis and Luu, Jason and Kent, Kenneth B. and Betz, Vaughn},
  journal={ACM Trans. Reconfigurable Technol. Syst.},
  year={2020}
}

Download

For most users of VTR (rather than active developers) you should download the latest official VTR release, which has been fully regression tested.

Building

On unix-like systems run make from the root VTR directory.

For more details see the building instructions.

Docker

We provide a Dockerfile that sets up all the necessary packages for VTR to run. For more details see here.

Mailing Lists

If you have questions, or want to keep up-to-date with VTR, consider joining our mailing lists:

VTR-Announce: VTR release announcements (low traffic)

VTR-Users: Discussions about using VTR

VTR-Devel: Discussions about VTR development

VTR-Commits: VTR revision control commits

Development

This is the development trunk for the Verilog-to-Routing project. Unlike the nicely packaged releases that we create, you are working with code in a constant state of flux. You should expect that the tools are not always stable and that more work is needed to get the flow to run.

For new developers, please follow the quickstart guide.

We follow a feature branch flow, where you create a new branch for new code, test it, measure its Quality of Results, and eventually produce a pull request for review by other developers. Pull requests that meet all the quality and review criteria are then merged into the master branch by a developer with the authority to do so.

In addition to measuring QoR and functionality automatically on pull requests, we do periodic automated testing of the master using BuildBot, and the results can be viewed below to track QoR and stability.

• Trunk Status
• QoR Tracking

IMPORTANT: A broken build must be fixed at top priority. You break the build if your commit breaks any of the automated regression tests.

For additional information see the developer README.

Contributing to VTR

If you'd like to contribute to VTR see our Contribution Guidelines.

Contributors

Please keep this up-to-date

Professors: Kenneth Kent, Vaughn Betz, Jonathan Rose, Jason Anderson, Peter Jamieson

Research Assistants: Aaron Graham

Graduate Students: Kevin Murray, Jason Luu, Oleg Petelin, Xifian Tang, Mohamed Elgammal, Mohamed Eldafrawy, Jeffrey Goeders, Chi Wai Yu, Andrew Somerville, Ian Kuon, Alexander Marquardt, Andy Ye, Wei Mark Fang, Tim Liu, Charles Chiasson, Panagiotis (Panos) Patros, Jean-Philippe Legault, Aaron Graham, Nasrin Eshraghi Ivari, Maria Patrou, Scott Young, Sarah Khalid, Seyed Alireza Damghani, Harpreet Kaur, Daniel Khadivi, Alireza Azadi

Summer Students: Opal Densmore, Ted Campbell, Cong Wang, Peter Milankov, Scott Whitty, Michael Wainberg, Suya Liu, Miad Nasr, Nooruddin Ahmed, Thien Yu, Long Yu Wang, Matthew J.P. Walker, Amer Hesson, Sheng Zhong, Hanqing Zeng, Vidya Sankaranarayanan, Jia Min Wang, Eugene Sha, Jean-Philippe Legault, Richard Ren, Dingyu Yang, Alexandrea Demmings, Hillary Soontiens, Julie Brown, Bill Hu, David Baines, Mahshad Farahani, Helen Dai, Daniel Zhai

Companies: Intel, Huawei, Lattice, Altera Corporation, Texas Instruments, Google, Antmicro

Funding Agencies: NSERC, Semiconductor Research Corporation

vtr-verilog-to-routing's Issues

Need better error checking for repeat pins

Originally reported on Google Code with ID 39

What steps will reproduce the problem?
1. Compiled attached architecture file
2. VPR crashes
3. Fix line 1224 and 1228 alm[5:4] to alm[5:5], rerun and the architecture is fine

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Reported by JasonKaiLuu on 2012-08-14 20:12:37

---

- _Attachment: [stratixiv_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-39/comment-0/stratixiv_arch.xml)_

Random number generation: Linux vs Mac vs Windows

Originally reported on Google Code with ID 35

As we have discussed, the VTR flow produces different results in Linux, Max or Windows.

I've tracked the problem down to ABC.  ODIN produces identical blifs; however, when
ABC optimized the blif, the results vary.

I believe this is due to different random number generators in the different platforms,
and I think we should use a platform-independent solution. 

One possible random number generator is here: http://www-cs-faculty.stanford.edu/~knuth/programs/rng.c

However, I'm not sure how to tell the gcc linker to use a different function instead
of srand/rand.  Could someone explain the process so that I can see if this fixes the
variation problem?  I think we have briefly discussed it when talking about using a
new malloc implementation.

Reported by jeffrey.goeders on 2012-06-08 22:26:24

run_vtr_task script

Originally reported on Google Code with ID 50

What steps will reproduce the problem?
1. Use a multi verilog file benchmark that employs "include"


What is the expected output? What do you see instead?
The script copies the verilog benchmark to perform the vtr flow. This results in losing
the include files for the benchmark

Any simple benchmark that has an include will trigger the issue.

Reported by JanetChina.V on 2012-11-12 20:11:53

.net file and .blif file do not match

Originally reported on Google Code with ID 57

What steps will reproduce the problem?
k6_N10_I33_Fi6_L4_frac1_ff1_45nm.xml bgm --blif_file bgm.pre-vpr.blif --timing_analysis
on --timing_driven_clustering on --cluster_seed_type timing --seed 1 --nodisp

What is the expected output? What do you see instead?
ERROR(1): .net file and .blif file do not match, encountered unknown primitive in .net
file.

This is a custom architecture file I am using - but it works for all other circuits,
so I don't think it is the problem.

Reported by jeffrey.goeders on 2013-02-28 23:49:11

---

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

VTR Sparse Crossbar Error

Originally reported on Google Code with ID 55

What steps will reproduce the problem?
1. Run VPR with attached architecture file (sparse crossbar)

The architecture file should be the same as k6_N10_memDepth16384_memData64_40nm_timing.xml,
except with a sparse crossbar and power properties.

I used ch_intrinsics as the test circuit, but other circuits have the same problem.

Output:
Routing iteration: 11
Successfully routed after 11 routing iterations.
ERROR(1): in timing_driven_check_net_delays: net 10 pin 14.
ERROR(2):   Incremental calc. net_delay is 2.0921e-10, but from scratch net delay is
2.7758e-10.

Reported by jeffrey.goeders on 2013-01-23 22:19:21

---

- _Attachment: [k6_N10_I33_Fi6_L4_frac1_ff2_C9_45nm.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-55/comment-0/k6_N10_I33_Fi6_L4_frac1_ff2_C9_45nm.xml)_

ODIN-II generates more LUTs with adder

Originally reported on Google Code with ID 53

What steps will reproduce the problem?

I have attached three xml files with the following run commands:

1. This xml run is directly from the nightly build version# 1342 (Dec.28, 2012).
   Other recent nightly builds have the same issue, described below
   in the "Expected Output" section. 
perl scripts/run_vtr_flow.pl benchmarks/verilog/sha.v arch/timing/k4_N1_no_cluster.xml

2. This run has the xml arch file in 1 above with the adder model added in.
perl scripts/run_vtr_flow.pl benchmarks/verilog/sha.v arch/timing/k4_N1_no_cluster_with_adder.xml

3. With this run, the xml is copied from 1 above, but modified slightly
   to make it run in the previous official release (Feb 2012).
perl scripts/run_vtr_flow.pl benchmarks/verilog/sha.v arch/timing/k4_N1_no_cluster_rel1_0.xml


What is the expected output? What do you see instead?

With the adder inference in the current nightly build, we expect 
the number of LUTs goes down, but instead it goes up by 32% 
(plus the adders) in the case of "sha", compared to the previous 
official release.
Other designs have similar behaviour.

What version of the product are you using? On what operating system?
1. VTR nightly release versions 1294 (Nov 28, 2012) and 1342 (Dec 28, 2012).
2. VTR official release in Feb 2012. 
OS = Ubuntu Linux.

Please provide any additional information below.

Outputs from vpr.out:

1. Run design "sha" with arch/timing/k4_N1_no_cluster.xml in 2012-11-28 nightly build,
I got:
        1 LUTs of size 0
        3 LUTs of size 1
        147 LUTs of size 2
        494 LUTs of size 3
        2459 LUTs of size 4
        38 of type input
        36 of type output
        911 of type latch
        3104 of type names
Total LUT#=3104

2. Run design "sha" with arch/timing/k4_N1_no_cluster.xml plus adder in 2012-11-28
nightly build, I got:
        10 LUTs of size 0
        3 LUTs of size 1
        134 LUTs of size 2
        674 LUTs of size 3
        3073 LUTs of size 4
        38 of type input
        36 of type output
        911 of type latch
        3894 of type names
        329 of type adder
     Total LUT# = 3894 plus 329 adders, 25% more LUTs than without adder (3894 vs 3104);
32% more than Feb 2012 release (3894 vs 2951).

3. Modify k4_N1_no_cluster.xml a bit for Feb 2012 release, the same run I got
       1 LUTs of size 0
       3 LUTs of size 1
       74 LUTs of size 2
       639 LUTs of size 3
       2234 LUTs of size 4
       2951 LUTs in input netlist
       911 FFs in input netlist
    Total LUT# = 2951

Please take a look.
Thanks.
Jianshe 

Reported by [email protected] on 2012-12-28 21:58:57

---

- _Attachment: [k4_N1_no_cluster.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-53/comment-0/k4_N1_no_cluster.xml)_ - _Attachment: [k4_N1_no_cluster_rel1_0.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-53/comment-0/k4_N1_no_cluster_rel1_0.xml)_ - _Attachment: [k4_N1_no_cluster_with_adder.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-53/comment-0/k4_N1_no_cluster_with_adder.xml)_

VPR: "subset"/"universal" SBs unrouteable at greater than min W

Originally reported on Google Code with ID 14

What steps will reproduce the problem?
1. ./vpr N4K4L1Fci0.1Fco0.3SBuniversal.xml or1200_K4 -route -route_chan_width 64
2.
3.

What is the expected output? What do you see instead?
Binary search place and route finds the minimum channel width to be 54, via:
low, high, current -1 -1 182
low, high, current -1 182 92
low, high, current -1 92 46
low, high, current 46 92 70
low, high, current 46 70 58
low, high, current 46 58 52
low, high, current 52 58 56
low, high, current 52 56 54

Strangely, the circuit is unrouteable at W=64 (a point I'm interested in because it's
minimum +20%) but is routeable at the other even-widths I tested in the range 54-70.
This non-monotonic behaviour is a little bit unsettling considering the minimum channel
width is found via binary search?

What version of the product are you using? On what operating system?
VTR 1.0 final, Linux 64-bit.

Please provide any additional information below.
.xml, .blif, .net, .place attached.

I've been doing a big architecture sweep across the typical FPGA parameters (N,K,I,L,SB,etc.)
and I've found several more cases of this behaviour where it is unrouteable at minimum
W + 20%, and this is but one example.

Reported by eddie.hung on 2012-02-16 08:49:47

---

- _Attachment: [N4K4L1Fci0.1Fco0.3SBuniversal.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-14/comment-0/N4K4L1Fci0.1Fco0.3SBuniversal.xml)_ - _Attachment: [or1200_K4.blif](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-14/comment-0/or1200_K4.blif)_ - _Attachment: [or1200_K4.net](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-14/comment-0/or1200_K4.net)_ - _Attachment: [or1200_K4.place](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-14/comment-0/or1200_K4.place)_

Error in delay when LUT operates as wire

Originally reported on Google Code with ID 25

What steps will reproduce the problem?
1. Create a shift register
2. Observe delays between shift registers
3. LUT delay missing

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Reported by JasonKaiLuu on 2012-05-11 15:14:49

VPR clustering - asserts with certain architecture

Originally reported on Google Code with ID 23

What steps will reproduce the problem?
1. Run vpr with attached arch & circuit.

What is the expected output? What do you see instead?

The code asserts in cluster_legality.c:198:

        if (curr_ext_input > ext_output_rr_node_index
                || curr_ext_output > ext_clock_rr_node_index
                || curr_ext_clock > max_ext_index) {
            /* failed, not enough pins of proper type, overran index */
            assert(0);
        }


This could be an issue with the architecture file; however, it is fine as far as I
can tell.

Reported by jeffrey.goeders on 2012-05-08 19:15:08

---

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

VPR fails with "Error: in check_node: node XX has no edges."

Originally reported on Google Code with ID 56

What steps will reproduce the problem?
1. I used the architecture arch/timing/soft_fpu_arch_timing.xml, that comes with the
package. Benchmark is my own test circuit, which is a 4bit counter using only soft
logic.

2. Since the run_vtr_flow script seems to fail with architectures that do not have
any memory blocks, I added the memory definition from arch/timing/k6_N10_memDepth16384_memData64_40nm.xml
(copy&paste)

3. Flow scripts were not changed.

What is the expected output? What do you see instead?
Flow fails. vpr prints this message:
"Error: in check_node: node 87 has no edges."
Please find attached the task folder including the run.

What version of the product are you using? On what operating system?
VTR release 1.0 (compiled for graphic output)
Ubuntu 12.04 32-bit

Please provide any additional information below.
I'm currently evaluating vtr for possible use within my company's research division.
It would be great, if you could look into this issue, because the framework is actually
pretty cool. However, error messages should be more verbose to enable users to fix
problems in their architecture.

Regards,
Daniel Drescher

Reported by [email protected] on 2013-01-24 08:01:10

---

- _Attachment: [rb_eval_flow.zip](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-56/comment-0/rb_eval_flow.zip)_

vpr Makefile can't compile

Originally reported on Google Code with ID 18

What steps will reproduce the problem?
1.
make
2.
3.

What is the expected output? What do you see instead?
make: *** No rule to make target `$(dir)', needed by `OBJ/main.o'.  Stop.

What version of the product are you using? On what operating system?


Please provide any additional information below.

Reported by yujian777777 on 2012-04-20 08:33:55

Packer Timing Analyzer

Originally reported on Google Code with ID 36

Packer needs to understand the timing edges within a combinational primitive.  

Suppose for example we have product = (A * B) * C using monolithic multipliers.  Clearly
there is no combinational path from the MSB of A to the LSB of C.  However, the packer
currently assumes timing edges from all inputs to all outputs of a combinational block
so it sees a timing edge from the MSB of A to the LSB of C.  This messes up cost functions
as well as occasionally flagging spurious combinational cycles when none exists.  The
timing analyzer in placement-and-routing has already been enhanced (recently) to handle
this case correctly, it's just packing that needs to follow suit.

This is a major re-write of the timing engine used pre-packing so I'm going to specify
this as an enhancement.

Reported by JasonKaiLuu on 2012-07-05 18:49:43

Carry-chain bug

Originally reported on Google Code with ID 48

This circuit has a cout -> a[0] and the same cout -> cin.  Placement code thinks that
all 3 output adders belong to the same carry-chain when in fact the adder connected
at a[0] does not belong.  Results in the swap code messing up and swapping the adder
with a[0] being fed by a carry-out to bad locations.

Search for net "top^ADD~5542-1[0]" in blif

Reported by JasonKaiLuu on 2012-11-08 00:01:10

---

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

Odin II Adder Bug

Originally reported on Google Code with ID 38

What steps will reproduce the problem?
1. odin_II.exe -a sample_arch.xml -V adder_test.v -o adder.blif
2. notice the "-1" indices in output pins of adder.  BLIF expects unique net names
for unused outputs.
3.

What is the expected output? What do you see instead?

Should provide unique stub names for unused outputs.  Sen, you can talk to Ken or me
about this if you would like more information about the BLIF format.

Please use labels and text to provide additional information.

Reported by JasonKaiLuu on 2012-08-13 22:08:04

---

- _Attachment: [sample_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-38/comment-0/sample_arch.xml)_ - _Attachment: [adder_test.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-38/comment-0/adder_test.v)_

vpr Makefile can't compile

Originally reported on Google Code with ID 19

What steps will reproduce the problem?
1.
make
2.
3.

What is the expected output? What do you see instead?
make[1]: Entering directory `/net/leo/export/home1/jyu/VTR/vtr_release/vpr'
make[1]: *** No rule to make target `$(dir)', needed by `OBJ/main.o'.  Stop.

What version of the product are you using? On what operating system?
vtr final
linux 64


Please provide any additional information below.

Reported by yujian777777 on 2012-04-20 10:00:19

ODIN_II does not compile

Originally reported on Google Code with ID 12

What steps will reproduce the problem?
1. make
2.
3.

What is the expected output? What do you see instead?

eddieh@daiyu:~/vtr_final/ODIN_II$ make
bison --verbose -d -t -o SRC/verilog_bison.c SRC/verilog_bison.y
SRC/verilog_bison.y: conflicts: 1 shift/reduce
flex  -o SRC/verilog_flex.c SRC/verilog_flex.l
flex: can't open SRC/verilog_flex.c
make: *** [SRC/verilog_flex.c] Error 1

What version of the product are you using? On what operating system?
VTR final on 64-bit Linux.

eddieh@daiyu:~/vtr_final/ODIN_II$ flex --version
flex version 2.5.4

Please provide any additional information below.
An extra space between "-o" and the output filename for the flex command seemed to
have caused this. Patch attached. It worked fine in RC3.

Reported by eddie.hung on 2012-02-16 03:31:34

---

- _Attachment: [ODIN_make.patch](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-12/comment-0/ODIN_make.patch)_

Cluster-hopping

Originally reported on Google Code with ID 40

In VPR, is there an estimated check for the number of clusters on the critical path
right after packing (or a cluster-hopping estimation based on packing only?)

Reported by alshahna.jamal on 2012-09-25 21:44:38

VPR segfaults when given BLIF with LUT bigger than architecture

Originally reported on Google Code with ID 13

What steps will reproduce the problem?
1. ./vpr sample_arch.xml ../vtr_flow/benchmarks/blif/7/5xp1
(sample_arch.xml is K6)
2.
3.

What is the expected output? What do you see instead?
Expect it to fail gracefully. Like a swan.
Instead, segfaults because it writes past the size of the saved_names array.

What version of the product are you using? On what operating system?
VTR final, 64-bit Linux.

Please provide any additional information below.
Patch attached, which duplicates the check from a few lines below.

Reported by eddie.hung on 2012-02-16 04:00:47

---

- _Attachment: [vpr_lut.patch](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-13/comment-0/vpr_lut.patch)_

Bug in ezxml

Originally reported on Google Code with ID 21

We are not currently using the latest version of ezxml.  There is a bug in the version
we are using when adding tags out of order.  The code segfaults.

I tested with the latest version of ezxml and it corrected the problem.  

I encountered it using the following architecture snippet:

                <interconnect>
                    <direct name="direct1" input="ble.in" output="soft_logic.in"/>
                    <mux name="mux1" input="soft_logic.out[1:1] soft_logic.out[0:0]" output="ff[0:0].D"/>
                    <mux name="mux2" input="soft_logic.out[0:0] ff[0:0].Q" output="ble.out[0:0]"/>
                    <mux name="mux3" input="soft_logic.out[1:1] ff[0:0].Q" output="ble.out[1:1]"/>
                    <direct name="direct4" input="ble.clk" output="ff[0:0].clk"/>                                       
                </interconnect>

Reported by jeffrey.goeders on 2012-05-08 00:46:51

The same molecules with the same logical blocks being packed up to three times

Originally reported on Google Code with ID 32

What steps will reproduce the problem?
1. Trunk version from May 28th
2. In pack.c line 86 after lis_of_pack_molecules is assigned: use the following to
print the molecules and their respective logical_blocks:

#if 1   /*Alshahna -- sanity check of molecule blocks */
        cur_molecule = list_of_pack_molecules;
        while(cur_molecule != NULL) {
            printf("IN PACK: This molecule has the following number of logic blocks: '%d' \n",

                    cur_molecule->num_blocks);
            for (i=0; i < cur_molecule->num_blocks; i++) {
                printf("logical blocks '%s'\n", cur_molecule->logical_block_ptrs[i]->name);

            }
            cur_molecule = cur_molecule->next;
        }
#endif  /*endAlshahna*/


3.

What is the expected output? What do you see instead?

I expected each logical block to be packed into a molecule once...instead I'm seeing
all blocks packed into molecules 3 times. As in the exact same packed molecule three
times. 

What version of the product are you using? On what operating system?

Trunk version from May 28th, Debian.

Please provide any additional information below.

Have included the output file which shows a printout of the molecules -- start at the
molecule that has n1231, the list of molecules after this is repeated three times I
believe.

Reported by alshahna.jamal on 2012-06-04 18:46:20

---

- _Attachment: [4.06.2012_molecule_packed_more_than_once](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-32/comment-0/4.06.2012_molecule_packed_more_than_once)_

odin doesn't make

Originally reported on Google Code with ID 28

What steps will reproduce the problem?
1.cd into either the vtr_release directory or the odin directory
2.enter make

What is the expected output? What do you see instead?
~/Documents/vtr_release/ODIN_II$ make
/bin/sh: 1: ctags: not found
make: *** [CTAGS] Error 127


What version of the product are you using? On what operating system?
VTR 1.0 running on ubuntu 12.04 LTS

Please provide any additional information below.

Reported by the.afrojoe on 2012-05-21 21:28:31

VPR segfaults when given circuit but no architecture file

Originally reported on Google Code with ID 22

VPR segfaults when given a circuit parameter but no architecture file

What steps will reproduce the problem?
./vpr.exe my_circuit

What is the expected output? What do you see instead?
Should print error message.  Instead it crashes.

Reported by jeffrey.goeders on 2012-05-08 17:55:09

Need better error reporting for pin count mismatches in the .arch file

Originally reported on Google Code with ID 30

What steps will reproduce the problem?
1. vpr k4_N1_no_cluster.xml <any_file> 

What is the expected output? What do you see instead?

I get:
Building complex block graph 
vpr: SRC/pack/pb_type_graph.c:761: alloc_and_load_mux_interc_edges: Assertion `num_output_ptrs[0]
== num_input_ptrs[i_inset]' failed.
Aborted

Would like an error message saying what is wrong with the arch file (ideal, with a
line number), or at least specifying what the likely problem is and which complex block
and which pin / pb / mode are being built when this error occurs.

Error is due to specifying two output pins on a BLE, but later hooking up only one
output from the FF or a LUT (muxed) the BLE outputs.

      <pb_type name="ble">
          <input name="in" num_pins="4" equivalent = "true"/>
          <output name="out" num_pins="2" equivalent = "false"/>
          <clock name="clk" num_pins="1"/>


... later in <interconnect>

                <mux name="mux1" input="ff.Q lut4.out" output="ble.out"/>



Please use labels and text to provide additional information.

Reported by vaughnbetz on 2012-05-30 22:26:07

---

- _Attachment: [k4_N1_no_cluster.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-30/comment-0/k4_N1_no_cluster.xml)_

Odin makefile: libvpr_6 vs libvpr

Originally reported on Google Code with ID 29

Currently the ODIN makefile looks for either ../libvpr_6 or ../libvpr_5.  In my opinion
it would be much more convenient to use ../libvpr.  

Currently I check-out Odin into the vtr directory.  In this directory is the 'libvpr'
folder, which is now part of the VTR trunk.  However, ODIN expects a libvpr_6 folder,
and in order to make this work, I need to install ODIN elsewhere and symlink it.  Symlinking
is a pain as I work in VMs, where the symlinks aren't valid. 

If we could change the ODIN makefile to use ../libvpr we wouldn't need to symlink anymore.


Of course, if we move ODIN into the VTR trunk, this change will need to be many anyway.

Reported by jeffrey.goeders on 2012-05-22 21:18:43

ODIN II: not support the parameter expression

Originally reported on Google Code with ID 43

What steps will reproduce the problem?
1. gdb ./odin.exe
2. r -V a25_icache.v
3.

What is the expected output? What do you see instead?
Parameters are defined by the expression using other parameters, it doesn't support
the expression.

Instead error in parsing: syntax error, unexpected '(', expecting ';' or ',' 


What version of the product are you using? On what operating system?
 ODIN II version 1.0 (from vtr for fpga) 64-bit Linux

Please provide any additional information below.

Reported by JanetChina.V on 2012-10-22 15:16:30

---

- _Attachment: [a25_icache.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-43/comment-0/a25_icache.v)_ - _Attachment: [a25_config_defines.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-43/comment-0/a25_config_defines.v)_ - _Attachment: [a25_localparams.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-43/comment-0/a25_localparams.v)_ - _Attachment: [sample_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-43/comment-0/sample_arch.xml)_

VPR crash undetected by run_vtr_flow.pl

Originally reported on Google Code with ID 27

If VPR crashes late in execution, it is possible that run_vtr_flow.pl believes that
it completed successfully, and will not report an error.

run_vtr_flow.pl should be modified to check the return code of the program.  I thought
this was already in place, so I'll have to investigate.  Alternatively, VPR could print
a success message to the log immediately before completion, and the script could check
for this message.

I can fix this next week.

Reported by jeffrey.goeders on 2012-05-18 18:27:29

ODIN II: dual_port_ram memory depth not bounded

Originally reported on Google Code with ID 10

What steps will reproduce the problem?
1. ./odin_II.exe -V test3.v -a sample_arch.xml 
2.
3.

What is the expected output? What do you see instead?
addr input width to dual_port_ram should be bounded.
Instead, overflow occurs:

Hard Logical Memory Distribution
============================
DPRAM: 32 width 26 depth

Total Logical Memory Blocks = 1 
Total Logical Memory bits = -2147483648 
Max Memory Width = 32 
Max Memory Depth = 26

and ODIN II eats up lots of memory during the "Performing Optimizations of the Netlist"
stage.


What version of the product are you using? On what operating system?
ODIN II version 0.1 (from VTR1.0rc1) under 64-bit Linux

Please provide any additional information below.

Reported by eddie.hung on 2012-01-20 01:08:30

---

- _Attachment: [test3.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-10/comment-0/test3.v)_ - _Attachment: [sample_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-10/comment-0/sample_arch.xml)_

run_vtr_flow.pl error reporting is vague

Originally reported on Google Code with ID 26

run_vtr_flow.pl gives essentially no information about why a circuit fails.  If there
is an error, an error message appears of the form:
circuitname/circuitname...failed: stage
which gives no information about the actual cause of the error, even though more detailed
information is available in the log files.  
Is there some way to get the perl script to return the same terminal output as the
individual stages would return if they were run manually?

Reported by mikewainberg on 2012-05-11 21:18:51

VPR handling of unconnected .names from blif

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)_

Area calculation error in routing_stats()

Originally reported on Google Code with ID 11

for(i = 1; i <= nx; i++) {
 for(j = 1; j <= ny; j++) {
  if(grid[i][j].offset == 0) {
   if(grid[i][j].type->area == UNDEFINED) {
    area += grid_logic_tile_area * block[i].type->height;
   } else {
    area += grid[i][j].type->area;
   }
  }
 }
}

The code above indexes block using the variable i.  This variable is a loop through
the rows.  I believe this should be grid[i][j] instead of block[i].

What steps will reproduce the problem?
1. Run a very sparse design rows > blocks

What is the expected output? What do you see instead?
Segfault

Please use labels and text to provide additional information.

Reported by jeffrey.goeders on 2012-02-06 22:27:31

Do not support the constant shift

Originally reported on Google Code with ID 45

What steps will reproduce the problem?
1. gdb ./odin_II.exe
2.r -V a25/a25_decode.v
3.

What is the expected output? What do you see instead?
When using the right shift operator, it should work. but it doesn't support it with
localparam or arrays.

error:(Line number: 1430) Odin only supports constant shifts at present

Line: 1239(a25_decode.v  (1'd1 << instruction[19:16]))

What version of the product are you using? On what operating system?


Please provide any additional information below.

Reported by JanetChina.V on 2012-10-25 19:03:39

---

- _Attachment: [a25_decode.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-45/comment-0/a25_decode.v)_ - _Attachment: [a25_decompile.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-45/comment-0/a25_decompile.v)_ - _Attachment: [debug_functions.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-45/comment-0/debug_functions.v)_

ODIN constant string to long error

Originally reported on Google Code with ID 34

The following code from odin_util.c:192 contains a problem:
    #ifdef LLONG_MAX
    long long number = strtoll(orig_string, NULL, 10);
    if (number == LLONG_MAX || number == LLONG_MIN)
        error_message(PARSE_ERROR, -1, -1, "This suspected decimal number (%s) is too long
for Odin\n", orig_string);
    #else
    long long number = strtol(orig_string, NULL, 10);
    if (number == LONG_MAX || number == LONG_MIN)
        error_message(PARSE_ERROR, -1, -1, "This suspected decimal number (%s) is too long
for Odin\n", orig_string);
    #endif

This checks if LLONG_MAX is defined, and if so uses strtoll, otherwise it uses strtol.
 Unfortunately mcnc.v contains a very large constant (32'd3447127471), which is a 32
bit number.  It is too large for a 32-bit signed long, thus strtol will error.

In the system I was using, a long long is 8 bytes and a long is 4 bytes; however, LLONG_MAX
is not defined.  So, the above code uses strtol which returns a signed long, and will
error with the mentioned constant.  Instead, strtoll could be used, even though LLONG_MAX
is not defined.  However, without LLONG_MAX being defined, you cannot use the same
method to check for an error.  Instead, you need to check the errno.

I propose the above lines be replaced by the following code:
errno = 0;
    long long number = strtoll(orig_string, NULL, 10);
    if (errno == ERANGE) {
        error_message(PARSE_ERROR, -1, -1, "This suspected decimal number (%s) is too long
for Odin\n", orig_string);
    }

You need to include <errno.h> as well.

Reported by jeffrey.goeders on 2012-06-05 18:07:38

Bad annealing selection code fixed

Originally reported on Google Code with ID 37

What steps will reproduce the problem?
1. Compile any circuit
2.
3.

What is the expected output? What do you see instead?

Observe that empty blocks all appear on the top row.  If the circuit has multipliers/memories,
then those get pushed to the bottom.

This was a scary bug in VPR 5.0 lasting to just last week.  The find_to function in
place.c had a natural bias down 1.  In fact, when rlim == 1, it always returns Y -
1 from the "from" position.  This has huge consequences on QoR for cases where the
circuit has fixed I/O pins and has any degree of sparsity (ie. real FPGAs).  

Fortunately, from reviewing our loads of regression tests, this bug generally did not
empirically affect QoR in prior experimental results for two reasons:
1. We always let the FPGA resize so for a densely packed FPGA, the from function still
allows blocks to get swapped from the top positions
2. Since I/Os are free floating in almost all academic research, blocks that gravitate
to the bottom that are connected to I/Os will naturally drag the I/Os down to the bottom.

The re-done find_to function I put in is slower than the original but it is correct
and a lot more generic.  The assumptions that I/Os are at the perimeter as well as
all columns in the core must contain the same block type have been removed.

Reported by JasonKaiLuu on 2012-08-04 14:35:45

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

Originally reported on Google Code with ID 15

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.

Reported by jeffrey.goeders on 2012-03-21 17:31:57

VPR crash during execution of a flow

Originally reported on Google Code with ID 16

VPR crashes running a flow with: 
k4_N10_memSize65536_memData64_nomem/LU32PEEng...*** glibc detected *** /home/andrew/vtr_release/vtr_flow/../vpr/vpr:
corrupted double-linked list: 0x000000000680bfd0 ***

VPR command was: 

/home/andrew/vtr_release/vtr_flow/../vpr/vpr k4_N10_memSize65536_memData64_nomem.xml
LU32PEEng --blif_file LU32PEEng.pre-vpr.blif --timing_analysis off --timing_driven_clustering
off --cluster_seed_type max_inputs --pack --nodisp

VPR output and input files are attached. Blif file is compressed with gzip to meet
upload size limit. 

Reported by andy16666 on 2012-03-27 15:26:42

---

- _Attachment: [k4_N10_memSize65536_memData64_nomem.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-16/comment-0/k4_N10_memSize65536_memData64_nomem.xml)_ - _Attachment: [LU32PEEng.pre-vpr.blif.gz](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-16/comment-0/LU32PEEng.pre-vpr.blif.gz)_ - _Attachment: [vpr.out](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-16/comment-0/vpr.out)_

ODIN II: can not calculate the parameter which locate in the array

Originally reported on Google Code with ID 41

What steps will reproduce the problem?
1. ./odin_II.exe
2. r -V a25_fetch.v
3.

What is the expected output? What do you see instead?

when assign the address_cachable value, (i_iaddress[31:(BOOT_MSB+1)] == (HIBOOT_BASE>>(BOOT_MSB+1))
should be true.


Instead, the two values are different. ODIN II errors out with"if(first_node->children[1]->types.number.value
< first_node->children[2]->types.number.value)"

What version of the product are you using? On what operating system?

64-bit Linux

Please provide any additional information below.

Reported by JanetChina.V on 2012-10-22 14:31:30

---

- _Attachment: [a25_fetch.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-41/comment-0/a25_fetch.v)_ - _Attachment: [memory_configuration.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-41/comment-0/memory_configuration.v)_ - _Attachment: [sample_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-41/comment-0/sample_arch.xml)_

[ODIN] Incorrect BLIF for asymmetric multipliers

Originally reported on Google Code with ID 46

What steps will reproduce the problem?
1. ./run_vtr_flow.pl with the attached arch (which has a 36x35 mult)
2. Observe that fails at ABC stage, because ODIN instantiates .subckt with a 35 bit
'a' input (and a 36 bit 'b' input) -- but the .model specifies 36/35 bit order.

What is the expected output? What do you see instead?
Expect that 'a' input is 36 bit and 'b' input is 35 bits instead.


What version of the product are you using? On what operating system?
Trunk r1267 on Ubuntu 12.04 x86_64


Please provide any additional information below.

Bug is caused by the architecture reader reading input 'b' as 
Arch.models->inputs and input 'a' as Arch.models->inputs->next

This is used as is by pad_multiplier(), which should be more sensitive to this possibility.
A quick fix is to check the size of each swap if necessary before padding. Attached
patch seems to fix this.
It's not enough to just swap when writing out the .subckt in define_mult_function().

Reported by eddie.hung on 2012-10-31 10:24:28

---

- _Attachment: [k6_N10_memDepth16384_memData64_40nm_nofrac_timing_36x35.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-46/comment-0/k6_N10_memDepth16384_memData64_40nm_nofrac_timing_36x35.xml)_ - _Attachment: [odin_asym_mult.patch](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-46/comment-0/odin_asym_mult.patch)_

ODIN II: modeling sequential logic using always can not work

Originally reported on Google Code with ID 42

What steps will reproduce the problem?
1. gdb ./odin.exe
2. r -V a25_wishbone_buf.v
3.

What is the expected output? What do you see instead?

Sequential models using always should be working

Instead,error: (File: a25/a25_wishbone_buf.v) (Line number: 81) ODIN doesn't handle
blocking statements in Sequential blocks


What version of the product are you using? On what operating system?
 ODIN II version 1.0 (from vtr for fpga) 64-bit Linux

Please provide any additional information below.

Reported by JanetChina.V on 2012-10-22 14:42:26

---

- _Attachment: [sample_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-42/comment-0/sample_arch.xml)_ - _Attachment: [a25_wishbone_buf.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-42/comment-0/a25_wishbone_buf.v)_

ODIN Usage line is incorrect

Originally reported on Google Code with ID 52

What steps will reproduce the problem?
1. run odin with no arguments
2.
3.

What is the expected output? What do you see instead?

I expect a correct usage, statement, but instead it says:

USAGE: odin_II.exe [-c <Configuration> | -b <BLIF> | -V <Verilog HDL>]

and it should be 

USAGE: odin_II.exe [-c <Configuration> | -b <BLIF> | ] verilogfile.v

Please use labels and text to provide additional information.

Reported by JonathanScottRose on 2012-11-26 19:16:07

VPR Placement has a bias down to the bottom

Originally reported on Google Code with ID 51

Symptom:
   The problem happens with many benchmarks.
It is more visible when given a fixed number of tracks with lower utilization.
One can see that close to the end of placement, the placed design always
consolidates (or sinks) to the bottom of the arrays, even the IO pads are 
locked to the top.

To reproduce the problem, 
1. Take a benchmark, for example, sha.
2. Specify a larger array size to make the utilization, say, around 30%.
3. Lock the pins to the top (optional).
Then run VPR placement. One can see that it always sinks to the
bottom at the end of placement.  

Possible Solution:
   I think the issue comes from vpr/SRC/place/place.c function "find_to()"
and line "y_rel = my_irand(max (0, ((max_y - min_y) / type->height) - 1));".
The "-1" causes the drifting down and should be removed.
Please take a look and verify it. 

Thanks.
Jianshe
Efinix Inc.

Reported by [email protected] on 2012-11-16 21:01:05

VPR Windows release

Originally reported on Google Code with ID 54

Need help to run VPR on Windows. Is there a binary release for Windows users? If not,
is the current release build-able for Windows?

JL

Reported by jleung1102 on 2013-01-23 07:35:47

read_blif() does not complain on garbage lines in blif files

Originally reported on Google Code with ID 33

Attached is a blif file with a garbage line in Ln 3, but the program does not complain
about it. (Apparently does not affect how it works)

Reported by thienyuguang on 2012-06-04 22:43:01

---

- _Attachment: [or1200.latren.blif](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-33/comment-0/or1200.latren.blif)_

Parsing Architecture SB/CB depopulation doesn't handle newlines

Originally reported on Google Code with ID 24

This is a very minor bug.

The architecture parser is very picky when parsing the SB/CB depopulation lists.

The following sample from architecture file will cause an error because the parser
has been coded to reject newlines:

<sb type="pattern">
    1 1 1 1 1
</sb>
<cb type="pattern">
    1 1 1 1
</cb>

The problem exists in read_xml_arch_file.c:2330.

Reported by jeffrey.goeders on 2012-05-10 16:14:50

Wire-with-no-driver causes segfault in if-statements

Originally reported on Google Code with ID 8

What steps will reproduce the problem?
1. ./odin_II.exe -V test.v
2.
3.

What is the expected output? What do you see instead?
Error message stating that signal 'd' is undriven.
(In any case, generated BLIF file is incorrect)

What version of the product are you using? On what operating system?
ODIN II version 0.1 (from VTR1.0rc1) under 64-bit Linux 

Please provide any additional information below.

Reported by eddie.hung on 2012-01-20 00:36:26

---

- _Attachment: [test.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-8/comment-0/test.v)_

Post-packing error

Originally reported on Google Code with ID 31

What steps will reproduce the problem?
1. Post packing error, after netlist is generated

What is the expected output? What do you see instead?
Placement is not initiated

What version of the product are you using? On what operating system?
The latest version of VPR on linux

Please provide any additional information below.
Error is as follows:

Begin parsing packed FPGA netlist file
Finished parsing packed FPGA netlist file
Netlist generated from file ../my_arch/aeMB_v3/mux23/aeMB_core.odin.pre-vpr.net
ERROR:  [LINE 900] Element 'port' found twice within element 'outputs'.

Reported by madhurap on 2012-06-02 07:42:02

---

- _Attachment: [aeMB_core.odin.pre-vpr.blif](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-31/comment-0/aeMB_core.odin.pre-vpr.blif)_ - _Attachment: [arch_with_CLB_V6_mux23_v4.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-31/comment-0/arch_with_CLB_V6_mux23_v4.xml)_

Area numbers for k6_N10 logic tile area incorrect

Originally reported on Google Code with ID 17

Area is normalized to nmwt so the grid area across technology nodes should be approximately
the same.  The number seems scaled. 

Reported by JasonKaiLuu on 2012-03-29 17:26:06

ODIN II: can not have two same include statements

Originally reported on Google Code with ID 44

What steps will reproduce the problem?
1. gdb ./odin.exe
2. r -V a25_barrel_shift.v
3.

What is the expected output? What do you see instead?
In one module, when I include two different modules which has a same include statement,
it should work.

Instead, it shows error:Missing declaration of this symbol LSL


What version of the product are you using? On what operating system?
ODIN II version 1.0 (from vtr for fpga) 64-bit Linux

Please provide any additional information below.

Reported by JanetChina.V on 2012-10-22 17:42:18

---

- _Attachment: [sample_arch.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-44/comment-0/sample_arch.xml)_ - _Attachment: [a25_barrel_shift.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-44/comment-0/a25_barrel_shift.v)_ - _Attachment: [a25_shifter_quick.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-44/comment-0/a25_shifter_quick.v)_ - _Attachment: [a25_shifter_full.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-44/comment-0/a25_shifter_full.v)_ - _Attachment: [a25_localparams.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-44/comment-0/a25_localparams.v)_

ODIN II: Instantiating more than one module with dual_port_ram inside fails

Originally reported on Google Code with ID 9

What steps will reproduce the problem?
1. ./odin_II.exe -V test2.v -a sample_arch.xml
2.
3.

What is the expected output? What do you see instead?
Instantiating more than one instance of a module, which contains a dual_port_ram inside,
should work.
Instead, ODIN II errors out with "Missing declaration of this symbol dual_port_ram"

Workaround is to copy-and-paste the module in question with another name. See attached
for example.

What version of the product are you using? On what operating system?
ODIN II version 0.1 (from VTR1.0rc1) under 64-bit Linux


Please provide any additional information below.

Reported by eddie.hung on 2012-01-20 01:01:23

---

- _Attachment: [test2.v](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-9/comment-0/test2.v)_

double semi-colon causing empty child node in AST

Originally reported on Google Code with ID 47

What steps will reproduce the problem?
1. Any verilog code that contains an extra semi-colon at the end of a line.

This will create a NULL child to an AST node that later in AST to netlist conversion
results in a NULL pointer exception.

Reported by kenneth.b.kent on 2012-10-31 22:34:24

LUT size 2 has problems

Originally reported on Google Code with ID 49

What steps will reproduce the problem?
1. change the original architecture file with the release to support LUT size 2
2. the changed file is attached

Output:
3. abc reports errors "Incorrect LUT SIZE (2)"
4. we have changed the file to support lut size 3-7, and they are working.

Reported by qiang.liu205 on 2012-11-12 02:15:55

---

- _Attachment: [k2_N1_soft_logic_only.xml](https://storage.googleapis.com/google-code-attachments/vtr-verilog-to-routing/issue-49/comment-0/k2_N1_soft_logic_only.xml)_