00:13 <litghost> mithro: I can confirm that in the short case, the route chooses to expand node 3102 (on column 3) but the node 3103 (on column 4) is "right" node to expand

00:13 <litghost> mithro: So I think we are looking at a straight up bug in the short case

00:15 <mithro> litghost: I would suggest this should be to bugs so the vtr devs don't get confused...

00:16 <litghost> mithro: Most of the contents of https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/520 would be the same between the two issues

00:16 <tpb> Title: Routing failure on global channel structure · Issue #520 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

00:30 <mithro> litghost: Does vbrk tiles actually have anything in them?

00:31 <litghost> mithro: Yes/no. We put the synthetic IO tiles there because nothing is there :)

00:31 <mithro> Yeah - but they don't have any pips or anything?

00:31 <litghost> mithro: No configurable pips

00:31 <litghost> mithro: There are pips, but we believe them to be ppips

00:39 <mithro> litghost: I'm warming up to the idea of having one tool which takes a tilegrid + tileconn files and generates the vtr side and then a separate tool which translates prjxray's tilegrid + tileconn into a more suitable form for the original...

01:10 <litghost> mithro: I don't believe there is a technical justification to modifying tileconn. Tileconn is simply a compressed node (e.g. collection of wires) format. Changing the grid doesn't actually change the nodes at all. In fact reforming the grid doesn't need to worry about wires or nodes at all. The only thing changing the grid does is move the sources and sinks (e.g. pips and site pins). The actually connectivity between

01:10 <litghost> pips and sites pins remains exactly the same, no matter how the grid is defined

01:11 <litghost> mithro: Given that, what technical justification exists to modifying tileconn based on the VPR grid at all? The only thing that must be preserved is connectivity. There does need to a way to locate pips and site pins in the new grid, but the nodes/wires themselves? That should be completely transparent to routing import process

02:06 <duck2> hello

02:10 <duck2> i got vpr to run with the sax reader. now it peaks at 2G instead of 5.8G(i upgraded to 8G ram so i could run it :D) and produces the same top.net(checked md5sums) with the conda vpr. however it takes 58s as opposed to conda vpr's 24s and sometimes a destructor fails to free something at the end.

02:12 <litghost> duck2: That's a partial win :/ Any idea why it is slower?

02:16 <duck2> i did not optimize for time yet but let me run callgrind to see

02:23 <duck2> i'm not very hopeful about surpassing the pugixml version though, i could tweak my first reader only down to 42 seconds. maybe it's just that pugixml is faster than libxml2 or navigating an in-memory tree is faster etc. or i'm missing something obvious

04:01 <duck2> i thought of some improvements. opening a wip pr for now: https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/34

04:01 <tpb> Title: [WIP] Read rr_graph.xml using libxml2 SAX by duck2 · Pull Request #34 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

13:10 <sf-slack> <acomodi> litghost, mithro: I have given some though on the equivalent tile implementation and expanded the initial doc. Could you give it a look? feel free to edit/comment if something does not sound right

13:10 <sf-slack> <acomodi> litghost, mithro: here's the doc https://docs.google.com/document/d/1lWLgZ5fCwKUgPh1MaOoAHwKBBr1ZAQLDzPkJtzTjLvQ/edit#heading=h.ndgjwhvitt1

13:10 <tpb> Title: Google Docs - create and edit documents online, for free. (at docs.google.com)

13:13 <sf-slack> <tmichalak> @litghost: on the prjxray stabilization front, I ran the CI after reverting your commit that affects the 054-fan-alt (https://github.com/SymbiFlow/prjxray/commit/3c764a65e14d34aca0821a75d64ef401fe5e8f71) and the conflict for the BYP_ALT.GFAN seems to be gone. However, the run always fails for Kintex as it seems the current prjxray-db database still has the incorrect bits for kintex. There are also some diffs in

13:13 <sf-slack> segbits_hclk_cmt.db and segbits_clk_hrow_top_r.db for kintex.

13:13 <tpb> Title: Revert 054 fuzzer. · SymbiFlow/prjxray@3c764a6 · GitHub (at github.com)

13:15 <sf-slack> <tmichalak> @litghost: I recall you saying at some point that there is an issue related to the unstability of 057-pip-bi. Does the point still stand? What is the issue number?

14:44 <litghost> tmichalak: https://github.com/SymbiFlow/prjxray/issues/661

14:44 <tpb> Title: INT fuzzers randomly failing on CI · Issue #661 · SymbiFlow/prjxray · GitHub (at github.com)

15:09 <sf-slack> <mkurc> Good time of day! I've been looking into the tile grid and routing channels in the VPR GUI. It seems that tiles are imported only for the ROI (which is expected) but channels are present for the whole device (even outside the ROI) Is that a correct situation ?

15:20 <litghost> mkurc: I was looking at this again yesterday. Channels are current longer than they have to be such that they are correct over the optimum. In theory they can be of limit extent, but that requires some additional unwritten code, and it is unclear the value of the change.

15:22 <sf-slack> <mkurc> @litghost: They are not only longer, there are CHANX present north of the ROI.

15:24 <sf-slack> <mkurc> My concern is what if the VPR chooses to route something using such channels.

15:36 <litghost> mkurc: But no *edges* exists outside of the ROI, so it doesn't matter

15:37 <litghost> mkurc: Channels are only vehicles for edges, so we filter edges out based on whether the tile that contains the edges is in the ROI

15:37 <sf-slack> <mkurc> Ok, I understand

15:38 <litghost> mkurc: Relevant logic https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_create_edges.py#L830

15:38 <tpb> Title: symbiflow-arch-defs/prjxray_create_edges.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

15:39 <sf-slack> <mkurc> Mhm

16:19 <litghost> mithro: kem_ was able to identify both router issues https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/520#issuecomment-478057904

16:19 <tpb> Title: Routing failure on global channel structure · Issue #520 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

20:56 <mithro> litghost: Great!

23:08 <mithro> duck2: ping?