16:30 <mithro> https://github.com/Blinkinlabs/QL-EOS-S3-breakout

16:30 <tpb> Title: GitHub - Blinkinlabs/QL-EOS-S3-breakout (at github.com)

16:42 <litghost> nelson: What are your questions around tileconn? The code for generating it is located https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/074-dump_all/generate_grid.py

16:42 <tpb> Title: prjxray/generate_grid.py at master · SymbiFlow/prjxray · GitHub (at github.com)

16:42 <litghost> nelson: The code in prjuray for generating tileconn is a little more general, and I think better, but they both handle the same kind of processing.

17:31 <sf-slack> <nelson> I did see that previously, just trying to make sense of what I am seeing. In xc7a100tcsg324-1/tileconn.json, the combination [0,1] (CLBLL_L, CLBLL_L) (line 100215 in the latest version I checked out), is confusing me. The source wire is called “CLBLL_LL_CIN” and the dest wire is called “CLBLL_LL_COUT_N”. That seems backwards to me. I assume the source wire would be who is driving the wire and dest would be

17:31 <sf-slack> who is sinking the value. Am I looking at it wrong? Thanks!

17:33 <litghost> nelson: tileconn has no directions

17:33 <litghost> nelson: The pairs are undirected

17:35 <sf-slack> <nelson> Thanks - I was wondering that (it was the only plausible explanation). So, the terms source and dest in the documentation could just be tile1, tile2?

17:35 <litghost> nelson: Ya

19:12 <_whitenotifier-f> [symbiflow-arch-defs] andrewb1999 opened issue #1684: Support BRAM_Rs - https://git.io/JUyOT

19:18 <_whitenotifier-f> [symbiflow-arch-defs] andrewb1999 opened issue #1685: Reduce lookahead creation time for partition regions - https://git.io/JUyOD

20:50 <sf-slack> <nelson> Thanks. So, if the connections are directionless should I expect the same number of entries to show up in these two sets: INT_R,INT_R with offset [0, -1] and INT_R, INT_R with offset [0,1]? But they are different. Can you explain this?

20:59 <litghost> nelson: Not at all

21:00 <litghost> nelson: tileconn is simply one of many possible folded representations of the graph. A normalization pass over tileconn might produce what you are expecting, but in the end it has little meaning

21:01 <litghost> nelson: tileconn can only be considered in its totality when applied to a particular grid

21:01 <litghost> nelson: Individual patterns or rules don't have particular mean

22:03 <sf-slack> <nelson> What I decided to do to learn about the data structures was to see if I could come up with a list of all the wires connecting two adjacent INT_R tiles. Seems pretty basic. So, I grabbed all the INT_R,INT_R [0, -1] wire pairs and thought that was the list of all wires between them. But I see that the set of wires in INT_R,INT_R [0, 1] is different, suggesting neither set of wires is the entire set of connections. It

22:03 <sf-slack> would seem that there must be additional information that tells what connections *actually* exist between any 2 adjacent INT_R tiles. My question is what is that information and how is it derived? Thanks.

22:06 <litghost> nelson: The answer to your question is possible, but it requires converting tileconn into the full node map

22:06 <litghost> nelson: So in your specific example, there are many tiles between two INT_R's, and tileconn may form the node 1 tile at a time

22:07 <litghost> nelson: I guess you are focused on the +/-1 y case

22:07 <sf-slack> <nelson> I am, I figured just trying to understand how to interpret adjacent tiles…

22:08 <litghost> nelson: Anyways, the answer to you question can be easily solved using the connection database formed by symbiflow-arch-defs or xc-fasm2bels

22:08 <litghost> nelson: Because what you are asking for is the set of nodes that contain wires for INT_R dx,dy and INT_R dx,dy+1

22:09 <litghost> nelson: I don't believe you can do that by examining tileconn directly

22:09 <litghost> nelson: Also it varies depending on where you are in the grid

22:09 <litghost> nelson: But you could limit yourself to the examples that exist between all north/south adcent INT_R tiles

22:13 <sf-slack> <nelson> OK, make a bit more sense. Can you point me to that other database and the code that generates it? Just trying to understand how the pieces fit together, what combination of things gives information once could traverse to combine wires in the device into nodes, etc.

22:14 <litghost> https://github.com/SymbiFlow/symbiflow-xc-fasm2bels/blob/3b72e6f5beb09d85d2ba2957282ef2cf13933b0c/fasm2bels/database/create_channels.py#L309-L354

22:14 <tpb> Title: symbiflow-xc-fasm2bels/create_channels.py at 3b72e6f5beb09d85d2ba2957282ef2cf13933b0c · SymbiFlow/symbiflow-xc-fasm2bels · GitHub (at github.com)