Custom pin assignment results in unroutability errors.

[cloudcalvin]

Expected Behaviour

When I change the setting in the architecture file from 'spread' pin locations (which produces only left output pins for my test architecture) to custom pin location set to left output, I expect the same routing result.

Current Behaviour

Using <pinlocations pattern="spread"/>, my design routes perfectly, with all of the outputs from basic BLE going out from the left pin.

When I comment out the above line and instead say the following,

 <pinlocations pattern="custom">
        <loc side="left">clb.O</loc>
  </pinlocations>

I get VPR errors such as the following

WARNING(2): in check_rr_graph: fringe node 53 has no fanin.
This is possible on a fringe node based on low Fc_out, N, and certain lengths.
ERROR(1): in check_rr_graph: node 145 has no fanin.
ERROR(2): in check_rr_graph: node 146 has no fanin.
ERROR(3): in check_rr_graph: node 147 has no fanin.
ERROR(4): in check_rr_graph: node 155 has no fanin.
ERROR(5): in check_rr_graph: node 156 has no fanin.
ERROR(6): in check_rr_graph: node 157 has no fanin.
ERROR(7): in check_rr_graph: node 165 has no fanin.
ERROR(8): in check_rr_graph: node 166 has no fanin.
ERROR(9): in check_rr_graph: node 167 has no fanin.
.
.
.
.
Build rr_graph took 0.006289 seconds.
Confirming router algorithm: TIMING_DRIVEN.
WARNING(3): Empty heap occurred in get_heap_head.
WARNING(4): Some blocks are impossible to connect in this architecture.
Cannot route net #11 (top^a~3) to sink #1 -- no possible path. //NOTE: this is actually the nets from my own circuit.
Routing failed.

Using low: 6, high: -1, current: 12
WARNING(5): in check_rr_graph: fringe node 53 has no fanin.
This is possible on a fringe node based on low Fc_out, N, and certain lengths.
ERROR(76): in check_rr_graph: node 145 has no fanin.
ERROR(77): in check_rr_graph: node 146 has no fanin.
ERROR(78): in check_rr_graph: node 147 has no fanin.
.
.
.

.
.
.
Using low: 768, high: -1, current: 1536
ERROR(601):
Type: Routing
File: SRC/base/place_and_route.c
Line: 343
Message: This circuit requires a channel width above 1000, probably is not going to route.
Aborting routing procedure.
<<<

One observation I have made is that it says 'routing algorithm used : TIMING_DRIVEN' yet the options '--timing_analysis off --timing_driven_clustering off' have been supplied..

Reproducing Error

I am using the latest master version.
I have only tested reproducibility with the K4_90_nm.xml architecture with the edits made as stated above.
(Spread changed to Custom).
The verilog file I have tested was the ch_intrinsics.v and was run with the following :

vpr k4_N4_90nm.xml ch_intrinsics.pre-vpr.blif --timing_analysis off
which results in the following output :
ch_intrinsics.k4_N4_90nm.tar.gz

Please let me know if any other Context or System specs are needed.

Regards
Calvin

[kmurray]

Thanks for the detailed error report!

'spread' pin locations (which produces only left output pins for my test architecture)

This doesn't appear to be the case, my run shows pins spread on all sides:

Running the architecture with:

<pinlocations pattern="custom">
      <loc side="left">clb.O</loc>
</pinlocations>

Shows that only the output O pins are connected to global routing:

However, since neither the I nor clk ports are specified they are left disconnected; as a result the architecture is un-routable (no inputs can enter the CLBs).

If you do want to put all ports on the left side you would specify:

<pinlocations pattern="custom">
      <loc side="left">clb.O clb.I clb.clk</loc>
</pinlocations>

Which is yielding this (routable) routing architecture:

One observation I have made is that it says 'routing algorithm used : TIMING_DRIVEN' yet the options '--timing_analysis off --timing_driven_clustering off' have been supplied..

This is OK, TIMING_DRIVEN refers to the routing algorithm used (which can be run with or without timing analysis enabled).

Hope this helps!

[kmurray]

b568631 adds extra error checking to detect pins missing pin locations.

Your original architecture now produces the following error message:

Error 1: k4_N4_90nm.fail.xml:179 Pin 'clb.I[0]' has no pin location specificed with pin location pattern="custom"