-
Notifications
You must be signed in to change notification settings - Fork 416
Relax when router lookahead issues warnings for failure to find sample locations #2636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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. |
@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 <connection_block> tags in the device section? If so I could use that capability in my architecture file and this issue could be closed. |
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! |
@amin1377 It is the identical warning to what I see with switch box that don't have axis properties set correctly, for example:
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. |
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 <connection_block> tags in the section, and is having multiple <connection_block> tags supported? |
I think you can only define one |
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?
#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.
The text was updated successfully, but these errors were encountered: