vpr segfaults if you have a tile which is not connected to fabric.

[mithro]

If you provide vpr with a tile description were a tile does not have any pins connected to the fabric, vpr segfaults with the following;

Device Utilization: 0.06 (target 1.00)

Placement

Starting placement delay look-up...
Starting build routing resource graph...

Program received signal SIGFPE, Arithmetic exception.
0x0000555555b3991a in vtr::NdMatrixProxy<int, 2ul>::operator[] (this=0x7fffffff2a40, index=0) at /home/tansell/work/catx/vtr-verilog-to-routing/libs/libvtrutil/src/vtr_ndmatrix.h:64
64              size_t next_dim_stride = dim_stride_ / dim_ranges_[idim_ + 1].size();
(gdb) bt
#0  0x0000555555b3991a in vtr::NdMatrixProxy<int, 2ul>::operator[] (this=0x7fffffff2a40, index=0) at /home/tansell/work/catx/vtr-verilog-to-routing/libs/libvtrutil/src/vtr_ndmatrix.h:64
#1  0x0000555555b377cf in vtr::NdMatrixProxy<int, 2ul>::operator[] (this=0x7fffffff2a40, index=0) at /home/tansell/work/catx/vtr-verilog-to-routing/libs/libvtrutil/src/vtr_ndmatrix.h:75
#2  0x0000555555b32a9a in alloc_and_load_track_to_pin_lookup (pin_to_track_map=..., Fc=..., type_width=1, type_height=1, num_pins=90, max_chan_width=8, num_seg_types=3)
    at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/route/rr_graph.cpp:2181
#3  0x0000555555b2b69b in build_rr_graph (graph_type=GRAPH_BIDIR, L_num_types=10, types=0x5555561a65e8, grid=..., nodes_per_chan=0x55555617b968 <g_vpr_ctx+168>, sb_type=WILTON, Fs=3, 
    switchblocks=std::vector of length 0, capacity 0, num_seg_types=3, num_arch_switches=3, segment_inf=0x5555561a9f40, global_route_switch=2, wire_to_arch_ipin_switch=1, delayless_switch=2, 
    R_minW_nmos=6065.52002, R_minW_pmos=18138.5, base_cost_type=DELAY_NORMALIZED, trim_empty_channels=false, trim_obs_channels=false, directs=0x55555629ba30, num_directs=9, 
    wire_to_rr_ipin_switch=0x7fffffffc224, num_rr_switches=0x55555617b9c8 <g_vpr_ctx+264>, Warnings=0x7fffffff343c) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/route/rr_graph.cpp:544
#4  0x0000555555b2a5f8 in create_rr_graph (graph_type=GRAPH_BIDIR, num_block_types=10, block_types=0x5555561a65e8, grid=..., nodes_per_chan=0x55555617b968 <g_vpr_ctx+168>, num_arch_switches=3, 
    det_routing_arch=0x7fffffffc1f0, segment_inf=0x5555561a9f40, base_cost_type=DELAY_NORMALIZED, trim_empty_channels=false, trim_obs_channels=false, directs=0x55555629ba30, num_directs=9, 
    num_rr_switches=0x55555617b9c8 <g_vpr_ctx+264>, Warnings=0x7fffffff343c) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/route/rr_graph.cpp:297
#5  0x0000555555ad66b5 in alloc_routing_structs (router_opts=..., det_routing_arch=0x7fffffffc1f0, segment_inf=0x5555561a9f40, directs=0x55555629ba30, num_directs=9)
    at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/place/timing_place_lookup.cpp:242
#6  0x0000555555ad62a7 in compute_delay_lookup_tables (router_opts=..., det_routing_arch=0x7fffffffc1f0, segment_inf=0x5555561a9f40, chan_width_dist=..., directs=0x55555629ba30, num_directs=9)
    at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/place/timing_place_lookup.cpp:111
#7  0x0000555555ad60e6 in alloc_lookups_and_criticalities (chan_width_dist=..., router_opts=..., det_routing_arch=0x7fffffffc1f0, segment_inf=0x5555561a9f40, directs=0x55555629ba30, num_directs=9)
    at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/place/timing_place.cpp:89
#8  0x0000555555abd029 in try_place (placer_opts=..., annealing_sched=..., chan_width_dist=..., router_opts=..., det_routing_arch=0x7fffffffc1f0, segment_inf=0x5555561a9f40, directs=0x55555629ba30, 
    num_directs=9) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/place/place.cpp:371
#9  0x0000555555a38621 in vpr_place (vpr_setup=..., arch=...) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/base/vpr_api.cpp:512
#10 0x0000555555a3840b in vpr_place_flow (vpr_setup=..., arch=...) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/base/vpr_api.cpp:483
#11 0x0000555555a377e6 in vpr_flow (vpr_setup=..., arch=...) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/base/vpr_api.cpp:284
#12 0x0000555555a28885 in main (argc=9, argv=0x7fffffffdd48) at /home/tansell/work/catx/vtr-verilog-to-routing/vpr/src/main.cpp:69
(gdb) 

While it might feel silly at first to have a tile which has no fabric connection, a couple of use cases are;

• (a) A tile which is connected only using <direct> connections to other tiles.
• (b) You want to specify the "fabric" in terms of <direct> connections between tiles rather then using channels / segments structure. (This is would be useful were tiles are only connected to other tiles next to each other.)

My current work around is to add a dummy pin which is connected to the fabric but not to anything inside the block.

So I think a bigger question is;

• Can vpr work on an architecture without channels.
• Does vpr care about the difference between internal to a block an external to a block routing? It looks like the complete graph (internal and external) is just dumped into the rr_graph.xml

[kmurray]

I agree the use-cases for no routing fabric connections are reasonable. Can you provide the example architecture which causes the error?

Can vpr work on an architecture without channels

The RR graph builder (and probably graphics) make assumptions about the routing being organized in channels. So if you are trying to specify a non-channel architecture description you'll likely run into issues.

The router operates on the RR graph and shouldn't make any assumptions about the architecture being channel-based. This means that if you build an rr_graph.xml appropriately, VPR should be able to route it -- even if it is not channel-based.

That being said, all the commercial FPGA architectures I'm aware of have channel-based routing architectures.

Does vpr care about the difference between internal to a block an external to a block routing?

Yes, VPR treats them separately

Currently the packer handles all block-internal routing. While the router performs global routing of all block-external routing (e.g. routes between block pins).

This distinction is somewhat artificial and currently limits some potential optimizations that VPR could perform otherwise (e.g. pin equivalence, LUT rotation). In the long term we would like to make the router able to route inside clustered blocks; however it would require more substantial code changes.

The rr_graph.xml only describe the global routing network between block pins.