Icestorm Inter-operability

[mithro]

Hi!

I'm still playing with getting vtr working with iCE40 like architectures. The iCE40 has the idea that you have span4 and span12 lines which are not directly connected to the logic slices, I've described as follows (using cb == '0');

  <!-- Span 12 vertical   tracks -->
  <!-- Span 12 horizontal tracks -->
  <segment name="span12" length="12" freq="1.000000" type="bidir" Rmetal="101" Cmetal="22.5e-15">
   <sb type="pattern">1 1 1 1 1 1 1 1 1 1 1 1 1</sb>
   <cb type="pattern">0 0 0 0 0 0 0 0 0 0 0 0</cb>
   <wire_switch name="1"/>
   <opin_switch name="0"/>
   <mux name="2"/>
  </segment>
  <!-- Span 4 vertical   tracks -->
  <!-- Span 4 horizontal tracks -->
  <segment name="span4" length="4" freq="1.000000" type="bidir" Rmetal="101" Cmetal="22.5e-15">
   <sb type="pattern">1 1 1 1 1</sb>
   <cb type="pattern">0 0 0 0</cb>
   <wire_switch name="1"/>
   <opin_switch name="0"/>
   <mux name="2"/>
  </segment>

These lines are then routed "onto" the local tracks, I've describe the local tracks as follows;

  <!-- Local tracks -->
  <segment name="local" length="1" freq="1.000000" type="bidir" Rmetal="101" Cmetal="22.5e-15">
   <sb type="pattern">0 1</sb>
   <cb type="pattern">1</cb>
   <wire_switch name="1"/>
   <opin_switch name="0"/>
   <mux name="2"/>
  </segment>

I'm then forcing the pins to be only connected to the local wires using the following;

   <fc default_in_type="frac" default_in_val="0.0" default_out_type="frac" default_out_val="0.0">
    <!-- Connect all the ports to 2 local tracks -->
    <fc_override fc_type="abs" fc_val="2" port_name="I0" segment_name="local"/>
    <fc_override fc_type="abs" fc_val="2" port_name="I1" segment_name="local"/>
    <fc_override fc_type="abs" fc_val="2" port_name="I2" segment_name="local"/>
      ...

I then define switch box which connects the local wires to the span wires using the following;

   <wireconn num_conns_type="max">
    <from type="span4" switchpoint="0,1,2,3"/>
    <from type="span12" switchpoint="0,1,2,3,4,5,6,7,8,9,10,11"/>
    <to type="local" switchpoint="0"/>
   </wireconn>

The full description can be found at https://gist.github.com/mithro/4def2abc8d20841d872ea3ca0dbf775c#file-ice40-virt-xml

However, I'm now getting the following error;

Placement took 0.26 seconds                          
Error 1:                                             
Type: Routing                                        
File: /usr/local/google/home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/route/check_rr_graph.cpp    
Line: 530                                            
Message: in check_pass_transistors:                  
connection from node 26019 to node 26636 uses a pass transistor (switch type 0)                           
but there is no corresponding pass transistor edge in the other direction.                                

However there doesn't seem to be enough information in this message for me to debug where the issue is occuring.

I'm also getting the following warnings;

Warning 79: in check_rr_node: rr_node 12977 OPIN at (10,12) side=RIGHT, block_type=PLB ptc=38 has no out-going edges.                                                                                               
Warning 80: in check_rr_node: rr_node 12978 OPIN at (10,12) side=RIGHT, block_type=PLB ptc=39 has no out-going edges.                                                                                               
Warning 81: in check_rr_node: rr_node 12979 OPIN at (10,12) side=RIGHT, block_type=PLB ptc=40 has no out-going edges.                                                                                               
Warning 82: in check_rr_node: rr_node 12980 OPIN at (10,12) side=RIGHT, block_type=PLB ptc=41 has no out-going edges.                                                                                               
Warning 83: in check_rr_node: rr_node 14283 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=34 has no out-going edges.                                                                                               
Warning 84: in check_rr_node: rr_node 14284 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=35 has no out-going edges.                                                                                               
Warning 85: in check_rr_node: rr_node 14285 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=36 has no out-going edges.                                                                                               
Warning 86: in check_rr_node: rr_node 14286 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=37 has no out-going edges.                                                                                               
Warning 87: in check_rr_node: rr_node 14287 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=38 has no out-going edges.                                                                                               
Warning 88: in check_rr_node: rr_node 14288 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=39 has no out-going edges.                                                                                               
Warning 89: in check_rr_node: rr_node 14289 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=40 has no out-going edges.                                                                                               
Warning 90: in check_rr_node: rr_node 14290 OPIN at (11,12) side=RIGHT, block_type=PLB ptc=41 has no out-going edges.                                                                                               
Warning 91: in check_rr_node: rr_node 14679 OPIN at (12,12) side=LEFT, block_type=PIO ptc=1 has no out-going edges.     

Any advice on how to debug this issue?

Thanks!

[kmurray]

connection from node 26019 to node 26636 uses a pass transistor (switch type 0) but there is no corresponding pass transistor edge in the other direction.

VPR assumes that pass transistors can be used as bi-directional switches (allowing segments to be driven in either direction).

However the RR graph uses uni-directional edges to represent switches. This requires bi-directional switches to be specified as a pair of backward and forward edges.

The error is reporting that the expected backward edge is missing.

Since you are using the built-in RR Graph generator I'm not sure why this error is occurring. I'll take a look.

Warning 91: in check_rr_node: rr_node 14679 OPIN at (12,12) side=LEFT, block_type=PIO ptc=1 has no out-going edges.

This indicates there are node with no out-going edges. The best way to debug this is to look at the architecture with VPR's interactive graphics (--disp on). You can then find the relevant block, and (if you zoom far enough) the pins and their pin numbers will show up.

Since these are all output pins (OPINs), it likely means the Fc of these pins is set to zero (no outgoing edges) for some pins.

Sometimes these warnings are expected. For example if you have a carry-chain between blocks you may get a dangling carry-out pin at the edge of the device (since there is no next block of the correct type to make the direct connection).

[kmurray]

I was able to get past the RR graph error by setting all <wire_switch> and <opin_switch> tags to use switch 0 (tristate) instead of switch 1 (pass_gate).

However VPR later fails since some connections are not routable -- indicating an issue with the routing pattern (custom switchblock) you have specified. You might want to start with one of the default routing patterns (e.g. wilton) at least initially so you can get all the way through VPR, and then refine the exact pattern later.

It looks like there is a problem in the RR graph generator with pass_gates. I'm not sure what the issue is (we currently don't test any architectures which use pass_gate routing switches). Most modern FPGA architectures use mux (uni-directional) or tristate (bi-directional) style switches since this buffers the routing segments (better for delay).

Do you know whether you want to model pass gates for tristates for your switches?

[mithro]

I started with wilton patterns and now moving on to doing something closer to the real world example.

Couple of things I've noticed;

1. vpr doesn't have channels around the perimeter of the IC. I've ended up padding the IC with EMPTY tiles around the perimeter to allow the IO tiles to have routing.
2. I don't really understand how "channels" actually map to things? It just seems to mean a gap in-between the tiles. Is there any extra meaning?
3. I don't quite understand how wire segments with length longer than 1 work at the edges? The two possible modes could be;
   • only generate wire segments of the given length (thus less wires as you get to the edge),
   • generate "short" segments
4. There doesn't seem to be a way to have segments which just run horizontal or vertical?
5. There doesn't seem to be a way to say how many wire segments of each type should be in a channel? It seems like something with fc_type="abs" fc_val="2" could work?
6. How does one do diagonal wire segments? Are they not supported?
7. I don't really understand how the type attribute in <switchfuncs> works. It seems to be 'SOURCE EDGE DEST EDGE'. So tl means from the top edge to the left edge. However, which wire segments are considered to be on the "top edge"?
8. It doesn't seem to be possible to mix unidir and bidir segments in the same architecture. I do think it should work if we manually generate rr_graph.xml however?

I do think we want to use an architecture with pass_gate routing switches.

I almost have a script which generates a real rr_graph.xml for the ice40 (from the icestorm description), but would be nice to have the "virtual" ice40 as close to real description. It would let us see what happens if we changed the size of the IC and such.

BTW Thanks for all your quick responses! Do you have an IRC or Slack channel where people hang out and discuss things like this?

[kmurray]

I've filed #246 to track the pass gate issue, but since no one seems to be using them it'll be low priority. I've also renamed this issue to track general IceStorm inter-operatiblity issues.

Glad to about progress on the icestorm -> rr_graph.xml script. I'd be very interested to hear how it goes!

Currently we don't have an IRC/Slack setup, although if we get more interest it is may be worth considering.

The other questions:

1) Padding with EMPTY around the perimeter is the 'correct' way we support architectures with routing on the sides of all blocks. Some architectures do have perimeter blocks which connect only to the adjacent channel which we still want to support.

2) Yes, a 'channel' is just the space between blocks. The only extra meaning is that conceptually when generating/drawing the RR graph VPR associates routing wires/segments with a particular channel. However this is not an assumption held by the router (which just operates on the RR graph).

3) VPR's RR graph generator tries to stagger the wire start points of length > 1 wires (it improves routability). The long wires are clipped at the edges producing shorter wires.

4) Yes, this is a known limitation of VPR's RR graph generator, it assumes the same segment/channel width distribution for both vertical and horizontal channels. However via rr_graph.xml you should be able to describe such an architecture.

5) This is controlled by the freq attribute of the <segment> tag, which specifies the relative frequency of the different segment types. You can then specify --route_chan_width at the command-line to fix the absolute number.

6) This is another feature not supported by VPR's RR graph generator, but should be do-able with an rr_graph.xml (although it may not draw correctly in interactive graphics).

7) You are correct about the SRC -> DEST convention. Conceptually a switch block is constructed whenever an x-directed and y-directed channel intersect. The edges correspond to the 'sides' of the switch block (e.g. lr and rl correspond to straight-through connections in the x-direction, trcorresponds to a down-ward going y-directed track connecting to a right-ward going x-directed track).

8) Yes, the RR graph generator assumes the entire graph is either unidir or bidir. Using an rr_graph.xml it should be possible to use segments of both types.

[qaarah]

Hi, I am trying to palce and route using VPR the blif generated by yosys (synth_ice40). I face the following error. Architecture file: sample_arch.xml Circuit name: Example_LUT

Warning 1: Model 'multiply' input port 'b' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 2: Model 'multiply' input port 'a' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 3: Model 'multiply' output port 'out' has no timing specification (no clock specified to create a sequential output port, not combinationally connected to any inputs, not a clock output) Warning 4: Model 'single_port_ram' input port 'data' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 5: Model 'single_port_ram' input port 'addr' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 6: Model 'single_port_ram' input port 'we' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 7: Model 'single_port_ram' output port 'out' has no timing specification (no clock specified to create a sequential output port, not combinationally connected to any inputs, not a clock output) Warning 8: Model 'dual_port_ram' input port 'data2' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 9: Model 'dual_port_ram' input port 'data1' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 10: Model 'dual_port_ram' input port 'addr2' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 11: Model 'dual_port_ram' input port 'addr1' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 12: Model 'dual_port_ram' input port 'we2' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 13: Model 'dual_port_ram' input port 'we1' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input) Warning 14: Model 'dual_port_ram' output port 'out2' has no timing specification (no clock specified to create a sequential output port, not combinationally connected to any inputs, not a clock output) Warning 15: Model 'dual_port_ram' output port 'out1' has no timing specification (no clock specified to create a sequential output port, not combinationally connected to any inputs, not a clock output) Error 1: sample_arch.xml:129 Unexpected attribute 'auto' found on node 'layout'. When I do solve this issue by giving specific layout i.e. width and length, then I face the error, Error 1: Arch_VPR8.xml:94 Found 1 'timing' child node(s) of 'device' (expected 0). has been replaced with the tag. Please upgrade your architecture file. I also tried to play with switch_block but I do not know, what up-gradation is required. Thanks