11:19 <sf-slack2> <acomodi> litghost: done, opened a PR upstream with the required changes. https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/713

11:19 <tpb> Title: vpr: changed some VPR_THROW to VPR_ERROR by acomodi · Pull Request #713 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

17:38 <sf-slack2> <acomodi> litghost, @tmichalak, mithro: I am confident I have found a great amount of unknown bits. I need to create a minitest to prove it, but I believe that IN_FIFO and OUT_FIFO in the CMT_FIFO column is responsible for those bits

17:38 <litghost> acomodi: Great

17:40 <sf-slack2> <tmichalak> Do we know the base address of this tile?

17:42 <sf-slack2> <tmichalak> Do you mean large number of unknown bits in general or from Litex on Arty perspective?

17:45 <sf-slack2> <acomodi> from the Litex on Arty perspective, but I still need to verify my theories actually

17:46 <sf-slack2> <acomodi> Anyway no, we do not have the base address

17:55 <sf-slack2> <tmichalak> Make sure to create an issue once you are certain

17:59 <sf-slack2> <acomodi> Sure

18:14 <sf-slack2> <butta> We are consistently having an issue where routing gets stuck and isn't able to resolve congestion around FAN_ALT5 resources. Is this something anyone has insight on or is there something we should try to diagnose this?

18:43 <sf-slack2> <acomodi> @butta try to set the `--congested_routing_iteration_threshold 0.8` vpr option. It sets the router to solve highly congested nets after the number of iterations is above the treshold

18:44 <sf-slack2> <acomodi> if you set your `max iteration number` to 500, with a treshold of 0.8 the highly-congested algorithm should be enabled at iteration 400

18:53 <sf-slack2> <butta> That didn't change anything

18:53 <sf-slack2> <butta> It's still having the same congestion and doesn't seem to be spending a long time trying to resolve the congestion

20:31 <litghost> butta: Can you file an issue with the relevant replication information?

20:34 <mithro> I have pushed an updated database + harness

20:35 <mithro> Lots of new bits! -> https://github.com/SymbiFlow/prjxray-db/commit/8bb6b84629659db128ee9364e9df121c3c7c3411

20:59 <sf-slack2> <butta> @litghost I'm not sure this would be particularly helpful because we have diverged quite a bit from the symbiflow ROI. These tests route when we allow the placer to choose IO locations, but refuse to route (because of congestion) when we fix the IO locations.

21:00 <litghost> Butta: if you help, please create a replicating test case

21:00 <litghost> *If you want help

21:28 <litghost> butta: Which symbiflow fork are you based off of?

21:28 <litghost> butta: E.g. last upstream commit

21:29 <sf-slack2> <butta> @litghost 619a4356de8b11b83664826e8e9b78e9154d220b

21:30 <litghost> butta: Do try https://github.com/SymbiFlow/symbiflow-arch-defs/pull/849 , which improves the lookahead in the router a somewhat

21:30 <tpb> Title: Add segment and connection box annotations to routing graph. by litghost · Pull Request #849 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

23:38 <hackerfoo> The import scripts have a lot of problems with duplicate site types, so I've decided to work on splitting the IO tiles vertically before proceeding further.

23:50 <hackerfoo> https://github.com/SymbiFlow/symbiflow-arch-defs/issues/881

23:50 <tpb> Title: [xc7] add architecture definitions for IO tiles · Issue #881 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)