rasmusto / vtr-verilog-to-routing

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

.route file pin sequence #90

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Sinthesize any Verilog file to a target architecture.

What is the expected output? What do you see instead?
It's not quite an issue but more a understanding matter.
Whenever a .route file is generated, the node sequence within a net will 
eventually have a series of IPIN and OPIN elements, each in turn having a Pin: 
# attribute that reportedly informs which pin of a given CLB a net is tied to. 
My CLB block has an input with four pins, an output and a clock pin, evenly 
spreaded through the sides (using the pinlocation's pattern attribute). I'm 
trying to figure what do this numbers actually means. I mean, do Pin #0 is the 
first pin of the input of my CLB? By analyzing the files generated by VTR I can 
almost surely assert that the last pin (pin 4) is my solely output. That also 
made me believe that pin 0 is the first pin of my input I[0:0], pin 1 is I[1:1] 
and so forth. And where do the clock pins come to play? Am I right? Thank you 
very much!!

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

Original issue reported on code.google.com by ky.s.oli...@gmail.com on 5 Jul 2014 at 7:03

GoogleCodeExporter commented 9 years ago

Original comment by JasonKai...@gmail.com on 7 Jul 2014 at 2:01

GoogleCodeExporter commented 9 years ago
Agreed.  The final route stats showed internal pin numbers which are 
nonsensical to a user.  I now output the block.port[pin_number] so that it 
makes more sense where nets connect to.

Original comment by JasonKai...@gmail.com on 14 Jul 2014 at 5:36