The-OpenROAD-Project-Attic/FastRoute

fastroute should print information about congestion (high fanout)

tajayi opened this issue · 8 comments

Priority: Medium

Details:
fastroute should print information about congestion (high fanout). This is especially important for nets that have extremely high fanouts and are problematic to work with. These are issues with tools or processes upstream but affect the ability to perform routing.
This was affecting several testcases before we eventually added a method to counter this.

Also, fastroute should print information about any net that doesn't have complete coverage

Steps to reproduce
Try to route a design with thousands (eg 4000) of fanouts. Ideally this should be added as a unit test that is expected to fail

There's a unit-test with 10000 pins in alpha-release/flow/designs/src/tiny-tests.

Info:

  1. Would you like fastroute to die or to print a warning when encountering a net with a high fanout? What would be the maximum net degree allowed?
  2. FlexRoute already provides information about nets that do not have complete coverage. Do you think it would be worth to implement in our tool given that FlexRoute already provides this information?

Would you like fastroute to die or to print a warning when encountering a net with a high fanout?

If fastroute encounters a net that is not globally routable (due to high fanout nets), then it should print the net in question (and any other debug information) and die (with an error code). In the past, fastroute would simply do nothing, generate invalid route guides, and then TritonRoute would complain about coverage. The idea is to detect the error as early as possible within the flow and provide the user this information. A lot of time may be spent by the user debugging TritonRoute only to find out that a bad guide was generated by fastroute

What would be the maximum net degree allowed?

This is probably not a static number that can be defined. It will be dependent on fastroute's ability to perform routing and also on the kit/platform. Essentially, if fastroute is having difficulties (or knows it will have difficulty) routing a high fanout net, then it should print the information and die

Do you think it would be worth to implement in our tool given that FlexRoute already provides this information?

FlexRoute performs some due diligence to ensure that it's input's are valid and that it will be able to complete the task with a fair degree of certainty on the output's correctness. The request here is for fastroute to do the same (i.e. check its inputs, check if it's routable,etc )

I would like to replace "die" with something more specific:

  1. Print out "Error: some human readable string"
  2. Exit with exit code != 0

The second point is very important w.r.t. writing tests and automation. The nonzero exit code is part of the interface to the tool: it is guaranteed to be zero only if the tool succeeded and produced valid output that is usable by downstream tools.

Agree with @oharboe

  1. About dying when encountering a net with high fanout, we changed fastroute4-lefdef to support nets with any degree.

  2. We now check if the nets have complete coverage and print out an error when it doesn't.

@isadorasop Does the appliaction stop with a non-zero exit code in the case the nest do not have complete coverage? If not, then I assume the tool flow will continue and the error message will be buried and obscured bysome followon error in the tool flow.

FastRoute exits with non-zero code when an error occurs.
Also, high fanout nets is not a problem anymore