00:32 <hackerfoo> litghost: Using the locations with the most samples slows down lookahead calculation a lot for the full 50T. I'm trying tuning the cache and turning on BREAK_ON_MISS.

00:33 <litghost> hackerfoo: What is "a lot"?

00:33 <litghost> hackerfoo: And are certain segments causing a lot more work than others?

00:33 <hackerfoo> I got tired of waiting, but it has to be at least 3x slower.

00:39 <litghost> hackerfoo: I think we should let the full version complete and be compared against the current sampling strategy

00:39 <litghost> hackerfoo: If the quality of routing (e.g. critical path and runtime) are the same between the two strategies, that points us to avoid the most expensive option

00:40 <litghost> hackerfoo: There does then come the question, what prevents the previous algorithm from behaving like the new algorithm, and I believe the answer is luck

00:40 <litghost> hackerfoo: So we probably want the idea of effort tuning in this case

00:40 <hackerfoo> Okay, I'll let it run.

00:40 <litghost> hackerfoo: Where maybe we don't pick the location with the most elements, but the one with a median amount?

00:41 <litghost> hackerfoo: Also something to watch out for is over sampling rrnodes that belong to the same non-configurable node set

00:44 <litghost> hackerfoo: How many jobs were you running with?

00:44 <hackerfoo> 8 jobs. BREAK_ON_MISS does seem to be running faster.

00:49 <hackerfoo> BREAK_ON_MISS is pretty safe, since it just discards the intermediate samples when the delay of the full route is higher (the "free" samples from the Dijkstra expansion.)

00:50 <litghost> hackerfoo: Given that we have variants of the router lookahead working well, I'm only really interested in data

00:50 <litghost> hackerfoo: E.g. how long does the variant take, how long do our circuits take to route, what is the quality of those routes (CPD, wirelength, etc)

00:53 <hackerfoo> We could generate a perfect lookup given a month or so to process every route.

00:54 <litghost> hackerfoo: Sure, but if one variant takes 10 minutes and is 90% of the quality one that takes a month, that is more than good enough

00:54 <litghost> hackerfoo: So let's compare the values. How long does it take to compute, how long does router take to route our circuits, and is the quality good enough

00:55 <litghost> hackerfoo: If the variant that takes 10 minutes is the same quality as one that takes 1 hr, that is also valuable data

00:55 <litghost> hackerfoo: There is definitely a knee in the curve somewhere

01:35 <hackerfoo> I added a paths/sec stat to the "Expanded..." log message. It's running at 70-100k paths per second, counting each path routed from a segment to a connection box. Each sample point is around a million paths.

01:36 <hackerfoo> (on average)

01:58 <litghost> hackerfoo: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1134 is one of the variants I was describing. The CI runtime with the new lookahead went from 1 hr 40 min to 53 minutes, with improvement in the runtime and QoR of picosoc and murax

01:58 <litghost> That variant is your sampling combined with the site pin delay fix, the base cost fix and the expansion of the base cost in addition to the delay matrix

01:58 <tpb> Title: Update VTR that contains latest sampling logic and reverts clock prop. by litghost · Pull Request #1134 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

21:27 <_whitenotifier-f> [vtr-verilog-to-routing] litghost opened issue #321: Branch: fix_check_route_tree - https://git.io/JeahR

23:08 <litghost> hackerfoo: VTR+symbiflow CI is up and running

23:08 <litghost> hackerfoo: If you push an integrated master+wip PR on https://github.com/SymbiFlow/vtr-verilog-to-routing it will get tested against symbiflow-arch-defs

23:08 <tpb> Title: GitHub - SymbiFlow/vtr-verilog-to-routing: SymbiFlow WIP changes for Verilog to Routing -- Open Source CAD Flow for FPGA Research (at github.com)

23:09 <hackerfoo> litghost: Nice. Thanks.