Fix inconsistent buffering

[acomodi]

Description

This PR fixes an issue related to buffered nodes.
During the rr_graph_indexed_data calculation, the state of the switches of different segment type nodes are being checked and, currently, if two different computation of the buffering state of two nodes belonging to the same cost_index (e.g. same segment type), VTR throws an error.

The changes in this PR prevent VTR to throw the error, but instead, as the buffered switches "win" against the non-buffered ones, if a conflict is found when checking the buffering state of the switches of two nodes of the same segment type.
In case of conflict then, the buffered state of a node is set to one as there is no other possibility (e.g. the conflict can only be between zero and one).

Related Issue

#1564 (comment)

Motivation and Context

Complex RR graph structure fail due to this too restrict check on the buffering state of some segments.

How Has This Been Tested?

Strong reg tests

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[acomodi]

@litghost @vaughnbetz FYI

[litghost]

@acomodi What is the impact on arch-defs with this change? Do things seem okay?

[acomodi]

@litghost I am running several tests to assess the impact on arch-defs.

From preliminary results, I can tell with confidence that the bug reported yesterday at the meeting impacts on the overall routing run-time, reaching ~2x w.r.t. to baseline.

As reported yesterday, in the symbiflow arch defs we are not averaging the delay values when calculating the indexed data (relevant code).
I have wrongly determined what was the base cost difference due to this bug, and I need to correct that:

• with the bug (no averaging) we have higher base costs.
• without the bug (averaging) we have lower base costs.

I am assessing whether this happens as well when using the connection box map lookahead, to check whether it is a generic problem.

I have also notices that, during the calculation of the lookahead itself, the base cost type is left to the default value, while at run-time, the base cost type is delay_normalized_length_bounded. I am unsure whether this is a bug as well, or it was intended, but I am running tests to verify whether using the same base cost type both at lookahead generation time and routing time have an impact.

[vaughnbetz]

Having different base costs during lookahead creation and at route time sounds bad to me; that will create a misalignment between the lookahead's base cost/cong cost prediction and reality. So it creates and inaccuracy in the lookahead that will impact non-timing-critical nets; likely to lead to bad behaviour and certainly hard to reason about. So I think that's important to fix / align.

[acomodi]

@vaughnbetz Sure, initial tests seem to actually be in favour on the current behaviour (different base_cost_types during lookahead and run-time).

Apart from this, which is more a symbiflow-related issue rather than a VPR one, there are two issues still pending:

1. Correctly calculating the average delays of switches results in an increase in run-time
2. Unroutable connection on SymbiFlow tests #1571

Given that both these issues are not-related to the fixes in this PR, would it be good to go ahead and merge this one, so that the hard failure on the buffering state is fixed? @litghost thoughts?

[vaughnbetz]

The fix looks fine to me. I suspect we shouldn't even print a warning; this isn't really a problem, just an rr-node topology that mixes buffered and unbuffered switches.

[acomodi]

@vaughnbetz Ok, I have removed the warnings related to the buffering state.

[acomodi]

@vaughnbetz All CIs went green, is this good to merge?