<tpb>
Title: xc7: Use the common_slice definition when LUTRAM used as a LUT. by mithro · Pull Request #779 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
kraiskil has quit [Ping timeout: 248 seconds]
<sf-slack2>
<mkurc> Morning !
<mithro>
Is anyone awaiting reviews from me?
kraiskil has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
Bertl_oO is now known as Bertl
<sf-slack2>
<acomodi> mithro: not yet in detail, was traveling today. I will get to it first thing tomorrow so that the PR can be merged ASAP
<tpb>
Title: Create a test design using LiteX, LiteEth and LiteDRAM and figure out what bits are still needed · Issue #867 · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack2>
<mkurc> @mithro @litghost. Some time ago I did looking what bits we are missing in the 7-series. These are tiles that have pips and we do not have segbits for them: HCLK_IOI3, CMT_TOP_R_LOWER_B, CMT_TOP_R_LOWER_T, CMT_TOP_R_UPPER_B, CMT_TOP_R_UPPER_T, CMT_FIFO_R, CMT_TOP_L_LOWER_B, CMT_TOP_L_LOWER_T, CMT_TOP_L_UPPER_B, CMT_TOP_L_UPPER_T, CMT_FIFO_L
<litghost>
mkurc: Maybe file an issue with details?
<mithro>
mkurc: how did you do that?
<sf-slack2>
<mkurc> I manually looked up `ppips_*.db` files to see which tiles that I am not familiar with have non-pseudo pips. Then I looked into corresponding `segbits_*.db`files and checked whether there are bits for those pips.
<sf-slack2>
<mkurc> I focused mainly on the clock tree.
kraiskil has quit [Ping timeout: 258 seconds]
<sf-slack2>
<mkurc> Now when I think of that, I can write a script which does the same to double check my findings.
<mithro>
mkurc: But how did you figure out which bits are *needed* ?
<sf-slack2>
<mkurc> @mithro Well, each non-pseudo pip should have at least some (I guess)
<sf-slack2>
<mkurc> I identified which pips do not have bits
<mithro>
mkurc: But if a design never uses these pips, then we don't care all that much?
<sf-slack2>
<mkurc> Oh, I didn't check which bits would be required for a particular design
<hackerfoo>
litghost: I sketched an idea about compressing and sampling the cost matrix for lookahead:
<hackerfoo>
Let me know if that makes sense, or you'd like me to write up something more detailed.
<hackerfoo>
From my work on simulated annealing, most connections will be near the diagonal, but I didn't use a space filling curve, because I didn't care about compression.
<hackerfoo>
So this should focus the diagonal better.
<tpb>
Title: Notes122.pdf - Google Drive (at drive.google.com)
<litghost>
Ya, 1-10 GB for 1 million nodes is still a loser
<litghost>
1 million nodes is a small FPGA
<hackerfoo>
Really? Why?
<litghost>
Because we need to scale to 10 - 100 million nodes
<litghost>
The current a7 graph is 1/5 of a 50k part
<litghost>
even in artix 7-series, there is s 300k part
<hackerfoo>
Oh. The width of the diagonal is likely much less than sqrt(N), but I don't know.
<litghost>
once you get to uS+, you have 1 M parts
<litghost>
So we are still working on toy sized graphs
<litghost>
We have +1-2 order of magnitude to go to reach the big parts
<hackerfoo>
So this is the number of pins? Can pins be grouped together?
<litghost>
Nodes, which can be either pin or interconnect
<hackerfoo>
I would guess the lower bound to be O(N log^2 N), which could scale to 100 million. But that's probably too optimistic.
<hackerfoo>
Maybe this coupled with some symmetry tricks could do it. At least it's a start.
<litghost>
To be clear, N in this case is number of nodes?
<hackerfoo>
Yeah.
<hackerfoo>
We could keep improving the compression without affecting the results, since its just a way to store the true data, although sampling all of that data would take forever, hence random sampling.
<hackerfoo>
There's probably good ways to accelerate that, though, since you shouldn't have to route every src -> dst individually.
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 257 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 258 seconds]
Bertl is now known as Bertl_zZ
bjorkintosh has quit [Remote host closed the connection]