pepijndevos changed the topic of #apicula to: Project Apicula: bitstream documentation and tooling for Gowin FPGAs -- logs
rvalles_ has joined #apicula
rvalles has quit [Ping timeout: 260 seconds]
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...
<pepijndevos_> ah...typedef IdString BelId;
Claude has quit [Disconnected by services]
Claude has joined #apicula
FabM has quit [Quit: Leaving]