Relax when router lookahead issues warnings for failure to find sample locations

[petergrossmann21]

The generation of the wire lookahead map appears to check that each segment type defined in the architecture file has a sample node for both CHANX and CHANY routing node types. If one wishes to model the segment types of vertical and horizontal routing channels with different segment types, this will produce a warning for each segment type. If one also wishes to uniquify segment types at different (X,Y) locations (for example, so that the delay parameters at those locations can be uniquified), the warning count explodes.

Proposed Behaviour

Additional work is required to finalize the details of how this solution should be implemented, but in essence I'm proposing that the checking described above be relaxed such that warnings are issued only if a sample location cannot be found across all node types, rather than warnings issued for each node type. In the event that the router lookahead calculations need sample locations defined for all types in order to function correctly, I would appreciate feedback on what drives such requirements. If it turned out that resolving the issue also required functional changes to the lookahead (rather than just warnings management) that would be understandable.

Is it possible that what I'm seeing related to this open issue from several years ago?

https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/1117

Current Behaviour

See above

Possible Solution

Context

For context, I encountered this behavior when attempting to perform a delay parameter capture for a chip I am developing. The delay parameter capture executes on each unique tile in my architecture, and determines unique delay parameters for each switch box and each connection box in each tile. While my unique tile count is small (4), this still puts the number of required segment types to uniquify delay parameters well into the thousands. Since each segment type is defined only for CHANX or for CHANY, each segment type produces a warning.

[amin1377]

You can specify the axis of a segment type. If no axis is specified, it is assumed that the segment type is on both CHANX and CHANY (Link). Based on what you said, specifying the axis of those segments should resolve the warnings.

[petergrossmann21]

@amin1377 Thanks for this. Your solution resolves the issue for switch box muxes. The question then remains how to handle connection box muxes. Since I want to uniquify their delay parameters, separate segment definitions are required for these as well. Is it possible to specify multiple tags in the device section? If so I could use that capability in my architecture file and this issue could be closed.

[amin1377]

Could you please send me the warning you are getting regarding connection block connections? This way, I can trace it back in the code and see what is causing it. Thanks!

[petergrossmann21]

@amin1377 It is the identical warning to what I see with switch box that don't have axis properties set correctly, for example:

Warning 40: Unable to find any sample location for segment CHANY type 'cb_1_0_0/to_a_south_out_south_mux_0_cbox_mux_1_size_8_a_to_y_0' (length 1)

One observation is that I might actually just need to eliminate the segment types for the connection boxes altogether. I will still need uniquified switch types so that I can annotate their delays individually, but because my delay model does not require an RC model for unique connection box wires (I set them all to zero because the RC delay of the wire in the actual chip will be lumped in the Tdel parameter), I don't strictly speaking need the CB segments unless they are required by VPR to help keep all the switch types in order.

[petergrossmann21]

A quick update with the CB segments removed has the desired effect on warning reduction. This leaves one two-part question to tackle: do I need all be CB switch types defined with tags in the section, and is having multiple tags supported?

[amin1377]

I think you can only define one <connection_block> tag. I also looked at some architecture files that are supposed to model commercial architectures, such as S10, SIV, and 7-series, and they all have only one <connection_block> defined. One thing you can do is, when defining the switch you assign to the connection block, you can assign different delays to the switch based on the number of inputs, as explained here.