rvalles_ has quit [Read error: Connection reset by peer]
rvalles_ has joined #apicula
FabM has joined #apicula
<pepijndevos_>
kbeckmann, hurray, PR is merged. Didn't notice it before until mmicko asked for a review
<pepijndevos_>
Kinda confusing that Gowin has a PLL and rPLL thing... have not looked into that in detail, but this one matches the rPLL so should be fine either way.
<pepijndevos_>
bleeeeeegh... feel like I should either make my db look EXACTLY like Nexus or throw out all remnants of Nexus code.
<pepijndevos_>
I have so much half commented out stuff that I'm not really sure what it does or how it maps to my stuff.
<pepijndevos_>
Or... start from nextpnr generic but "inline" setup with my bba and expand from there. I mean... I have working nextpnr generic stuff...
<pepijndevos_>
Only problem is that doesn't do deduplication at all. Which is kinda fine for gw1n, but might become a problem for gw2a.
<pepijndevos_>
Feels like it would be a lot more manageable to refactor working code than wade through broken code.
<omnitechnomancer>
generic also likes to store many hundreds of strings to consume all memory
<pepijndevos_>
You'll just need 16GB of RAM to PnR for gw2a, no problem, right?
<pepijndevos_>
Well, maybe "inlining" the setup with proper constids will help with that. I think deduplication is the bigger problem.
<pepijndevos_>
Maybe I'm actually doing okay with the nexus-inspired mess I'm in. I just don't see any light at the end of the tunnel.
<pepijndevos_>
daveshah, any input?
<daveshah>
I don't know
<daveshah>
if you don't want to mess with a deduplicated db, looking at how the iCE40 db works is probably best
<pepijndevos_>
The odd thing is my db is already deduplicated, except I deal with the edgecases in a different way.
<pepijndevos_>
The only reason to do nextpnr-generic is so I can literally port the python code and take it from there. I don't think ice40 will be very beneficial.
<pepijndevos_>
I only have one chip per db, so I need to get rid of the chipinfo part. And routing is completely homogeneous except it wraps around the edges, so I don't have "neighbourhoods" but the function that looks up a wire just handles the wrapping
<daveshah>
You could always keep the chipinfo part?
<daveshah>
more than one chip per db can save space if a lot of the tiles are the same
<daveshah>
stick with one chipinfo per db and keep the structure
<omnitechnomancer>
I remember my not very good one doing PnR for an Anlogic Eagle would consume several GB just to build the routing db
<pepijndevos_>
Yea okay so basically go with the "make my db look exactly like Nexus" option.
<omnitechnomancer>
The neighboourhoods are to deal with the edge reflections? or was there something else in nexus that required them?
<daveshah>
no, edge reflections aren't even handled yet
<daveshah>
they are used for all the connectivity, they aren't for any particular special case
<omnitechnomancer>
What makes the connectivity not homogenous?
<daveshah>
anything other than logic tiles
<daveshah>
global networks as well
<pepijndevos_>
Gowin is basically completely homogeneous except the first 32 or so wires map to different things, which I basically ignore and have a portmap on the bel to connect it up.
<omnitechnomancer>
ah so you include the global trees in the same DB I guess?
<daveshah>
yeah
<pepijndevos_>
And yea global stuff, which I handle seperately.
<daveshah>
and all kinds of other things like special interconnect between DSP cores, edge clocks, DQS groups, etc
<omnitechnomancer>
But does the PnR want it separately?
<omnitechnomancer>
ripple carry connections?
<daveshah>
compared to ecp5 where it was a bit separate, it's much easier in nexus where it is all one db
<daveshah>
well those are pretty homogeneous
<omnitechnomancer>
those just go up and down in one grid direciton generally right?
<daveshah>
yeah
<daveshah>
not really different to the x1 general interconnect
<omnitechnomancer>
indeed
<pepijndevos_>
fk im going nextpnr_yolo
<Lofty>
Mmm, pepijndevos_?
<pepijndevos_>
Rather than jumping in at the deep end and drowning, going to try a more incremental approach. It wont be much better than what I have currently but... it will be better for my wellbeing.
<Lofty>
I feel like nextpnr kinda *requires* a deep end approach
<pepijndevos_>
yea... but I have a working nextpnr-generic setup, so by making that un-generic... it will be bad in startup time and resource usage, but with incremental steps I think I can improve ergonomy and fpga utilisaiton a lot.
<pepijndevos_>
I don't enjoy drowning so much you see...