rr_graph: avoide div-by-zero issues while getting the delay norm fac

[acomodi]

Signed-off-by: Alessandro Comodi [email protected]

Description

This PR solves a coverty issue on the delay normalization factor calculation function for which, in corner cases, there might be a division by zero.

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

[vaughnbetz]

Would returning 0 result in 0 base costs? If so, I think it's better to return 1 or 1e-9 (1 ns) if this happens. Since we're issuing a warning and continuing we should make sure the returned value will let routing complete.

[acomodi]

I think it's better to return 1 or 1e-9 (1 ns) if this happens

@vaughnbetz Sure, makes sense. Fixed

[vaughnbetz]

LGTM. Whenever CI goes green this can be merged.

[vaughnbetz]

Not sure what is going on in Travis (looks like one test hung) but this is clearly safe and passed the more extensive tests. Merging.

[acomodi]

@vaughnbetz Travis is currently having some troubles for what I understood, and this is happening pretty much everywhere. I think we might need to consider to move towards using GH actions instead.

[vaughnbetz]

Hmmm ... won't let me merge unless I change permissions. @acomodi if you can't merge either can you relaunch the hung travis CI build?

[vaughnbetz]

That would be fine with me. Good topic for Thursday.

[vaughnbetz]

OK, changed permissions temporarily to let me merge this.