Alessandro Comodi

@litghost @mithro @HackerFoo FYI

I have resumed the work on getting the lookahead in a mergeable state with upstream. First I successfully reproduced the results I have obtained a couple of weeks ago, than...

By analyzing the routing debug information when running some of the symbiflow-arch-defs tests, I could see that the `Worst connections` are relative to four kinds of categories: - Constant nets:...

After some debugging of the router behaviour, I have applied some fixes to the new lookahead map code. The fixes I have added are: 1. In `add_paths` remove the `site_pin_delay`...

> To be clear, the new lookahead is based on an extension of the upstream map lookahead, comparing against the downstream connection box lookahead? Indeed. Actually the new lookahead uses...

> Okay, so the sampling method and Dijkstra expansion (for place delay) should be both go upstream, yes? Djikstra expansion is actually related to the lookahead generation, when expanding the...

PR upstream open here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/1449 Additional note: the fixes resulted in an increase of the `lookahead.bin` size from 15M to 55M for the 50T device.

Update: I am trying to get the upstream lookahead and the downstream new lookahead as similar as possible. I have updated https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/1449 to get towards the goal of having less...

**Results differences** I was able to identify the issue related to the differences in the results obtained recently with the one reported in the [above comment](https://github.com/SymbiFlow/vtr-verilog-to-routing/issues/517#issuecomment-662573720) The difference is due...

@litghost I think that, with the new information I got and summarized above, there are still issues to be solved with the lookahead if we want to stop using the...