<pepijndevos_>
I'm currently writing a nextpnr target, which will replace the generic stuff.
<pepijndevos_>
Okay hold on, actually I'll just update the readme and make sure master works.
<pepijndevos_>
Glad to hear blinkygw1n1 still works with the changes
<pepijndevos_>
daveshah, you're thinking of making a commercial pnr effort? (re not open source)
<daveshah>
no, I'm thinking about working on pnr just for fun
<pepijndevos_>
Ah like... just the fun without all the expectations and users and everything hehe
<pepijndevos_>
Something I'm wondering about: why is nextpnr "generic" at the build level, rather than say, at the language level with inheritance? Does that offer a certain speed or flexibility advantage?
<daveshah>
It was for inlining
<daveshah>
It's one of the things that I am growing less keen on, tbh
<daveshah>
If C++ templates weren't such a PITA, they would have probably been a better option
<pepijndevos_>
One thing I found is where functions only need to return something that vaguely resembles an iterator, which might be tricky to express at the language level.
<daveshah>
Well, that should work with templates but it's still not super clean
<daveshah>
C++20 concepts would be a nicer solution for that kind of thing
<pepijndevos_>
I'm currently just taking the sledgehammer to a copy of the nexus target to get a "dummy" target that builds. Was just dreaming about an imaginary baseclass that I could inherit to take care of the boilerplate stuff.
<daveshah>
Yeah and that's what I'd like to do too
<daveshah>
although the amount of changes I have planned, just doing an rm -rf * and starting again becomes increasingly tempting
<pepijndevos_>
As omnitechnomancer likes to say: RIIR XD
<daveshah>
said baseclass would also provide a standardised deduplicated database and generator for it that you could extend with arch-specific data to your heart's content
<daveshah>
not entirely a joke lol
<pepijndevos_>
I wonder how much work it'd get to get back to the current state of things
<daveshah>
O(18 months)
<daveshah>
The GUI would be a pain. That would probably stay in C++/Qt for now and use some kind of client/server interface
<pepijndevos_>
I forget nexprn has a GUI all the time hehe
<daveshah>
Yeah it's a bit lacklustre
<daveshah>
I kind of feel like that about a lot of nextpnr, that's why I'm a bit burnt out and dreaming of a greenfield start...
<pepijndevos_>
Have you seen vgtk? Looking for an excuse to use it sometime..
<pepijndevos_>
Hmm :/
<daveshah>
The big question is whether it can easily include an OpenGL (or equivalent) widget
<daveshah>
That is a non-negotiable requirement for whatever toolkit we use
<pepijndevos_>
Rust/C++ interop is a bit of a pain, but possible. So I imagine some sort of gradual refactor/port is possible. But the more important problem seems not burning out.
<daveshah>
I'm not sure if a gradual refactor is really worth the pain
<daveshah>
I think a total clean slate API etc wise would be better anyway
<daveshah>
My experience of prjtrellis -> prjoxide was the porting process was a lot easier than expected really
<pepijndevos_>
Yea as a whole it's probably fine. There is just a high up-front cost to understanding and getting a MVP, after that implementing the rest of the API is probably fine.
<daveshah>
The problem with nextpnr is that we all rushed to a MVP due to external constraints :/
<daveshah>
and then as is so often the case I never really put enough energy into tidying things up
<pepijndevos_>
Basically my entire progress yesterday was understanding the build system and hooking up Apicula to make the bba and put it in the right place
<daveshah>
not rushing towards an MVP would be more of an incentive for good unit tests, too...
<pepijndevos_>
"the bba" is a grandiose overstatement at the moment. Just the machinery to write a hardcoded u32 basically haha
<pepijndevos_>
Makes sense.
<pepijndevos_>
rvalles_, master is now functioning again, sorry about that.
<omnitechnomancer>
There is a DearIMGUI wrapper for Rust I believe
<pepijndevos_>
The reason that vgtk is based on gtk is that there is a whole lot of not so trivial things that naive UI libs miss out on, like accessibility for example.
<pepijndevos_>
that and the rust bindings being good. iirc bodil mentioned she would have chosen qt if the bindings were as good as gtk-rs
<Lofty>
daveshah: are you going to call it nextnextpnr?
<daveshah>
I kind of want a place and route tool called planar
<Lofty>
Heh, not bad, though maybe a little ungoogleable
<Lofty>
On the other hand if the community can get away with a vital part being called *ABC*, that should be okay :P
<daveshah>
The GUI could be called coplanar too
<Lofty>
daveshah: it sounds increasingly like the new year's fresh start is going to be on something new, rather than nextpnr
<daveshah>
I honestly have no idea
<Lofty>
No point rushing to anything though
<daveshah>
Indeed
<Lofty>
mignite feels maybe a little rushed, but also kinda solid
<daveshah>
I don't plan on dropping basic support for nextpnr any time soon
<daveshah>
it's just I might put the time I would spend on newer/more experimental stuff into a new codebase or parts thereof instead
<daveshah>
or even something non-FPGA instead, idk
<pepijndevos_>
ASIC Pnr :))
<Lofty>
pepijndevos_: TritonRoute.
<pepijndevos_>
bleh
<daveshah>
I wonder whether several framework components could be reused for both (second system problem going on here I know)
<daveshah>
like the netlist, timing, and some solver components at least
<pepijndevos_>
Niels is working on an ASIC PnR thing...
<daveshah>
oh nice
<Lofty>
daveshah: what would you say are the "good" parts of nextpnr?
<daveshah>
The actual placer and router aren't that bad; and the overall approach of virtually-zero-startup time is great
<daveshah>
The ability of arches to implement arbitrarily complex constraints in code is also something that absolutely must stay
<Lofty>
I often feel like one of the biggest success stories of nextpnr is that it asked "what would VPR do?" and then did the opposite
<daveshah>
Yeah. I think a few things went too far in the other direction
<pepijndevos_>
lol
<daveshah>
which makes getting started with an arch (particularly if you want to do deduplication, which VPR doesn't do at all fwiw...) a bit harder than it needs to be, and limits the visibility of pnr algorithms into the details of the arch
* pepijndevos_
cries in compiler errors
<Lofty>
The nextpnr architecture API is a bit daunting, yes
<Lofty>
Since there's a *lot* that needs to be implemented to even get off the ground
* pepijndevos_
feels like a mile underground (sorry david, I'm just whining, don't take it as a critique)
<daveshah>
I _want_ the critique to feed into the planar design
<pepijndevos_>
Is planar the official name now? Cool. I was literally thinking about nextnextpnr when I came back and read loftys message
<daveshah>
at least for now
<pepijndevos_>
Can I contribute to planar instead... it sounds more fun than these compiler errors... I'm sure this is more a feeling than a rational thing, but... yea
<pepijndevos_>
I was thinking nextpnr-ng XD
<pepijndevos_>
ororor cdrpnr
<pepijndevos_>
cddrpnr
<daveshah>
It's probably a long way off even mvp...
<pepijndevos_>
I knoooow, but greenfields dev is so alluring compared to compiler errors, hence... more of a feeling than a rational option
<daveshah>
ditto
<pepijndevos_>
hmmm, how would you sad cdrpnr? I think most people say cdr as cadur, but pnr as pee and ar. But cadur pee and ar sounds meh... cadurpeenur would be more consistent, but.... weird
<pepijndevos_>
or just cee dee ar pee en ar
<rvalles_>
pepijndevos_ | Okay hold on, actually I'll just update the readme and make sure master works. --> yes, that sounds the better path :-)
<rvalles_>
I'm currently writing a nextpnr target, which will replace the generic stuff. --> but that will likely take a while :P
<rvalles_>
I'll give it another go in a while.
<pepijndevos_>
I basically just did what you did: add "from apycula"
<pepijndevos_>
I probably did something silly with copy-pasting... Nexus seems to load chipdb form a binary file while my makefile generates a c string hehe
<pepijndevos_>
This appears to be based on BBASM_MODE which is set via EXTERNAL_CHIPDB in the toplevel file
<pepijndevos_>
ohhh I see... maybe...
<daveshah>
There are different modes for different contexts
<daveshah>
It can be an embedded C++ string, a mmap'd bin file or a Windows resource
<pepijndevos_>
And get_chipdb just kinda takes care of that transparently I guess
<daveshah>
Yeah, wq helped clean that side things up a lot for yowasp
<pepijndevos_>
ah sweet
<pepijndevos_>
heh, looking forward to pip install apycula[yowasp] and that just gets you instant ready to go toolchain.
<daveshah>
:)
<pepijndevos_>
huh, nexus includes constids, but also has ids that are added from the chipdb.
daveshah has quit [*.net *.split]
omnitechnomancer has quit [*.net *.split]
daveshah has joined #apicula
omnitechnomancer has joined #apicula
notafile has quit [Ping timeout: 270 seconds]
omnitechnomancer has quit [Ping timeout: 246 seconds]
wiizzard has quit [Ping timeout: 246 seconds]
notafile has joined #apicula
wiizzard has joined #apicula
omnitechnomancer has joined #apicula
notafile has quit [Quit: Bridge terminating on SIGTERM]
omnitechnomancer has quit [Client Quit]
wiizzard has quit [Quit: Bridge terminating on SIGTERM]
omnitechnomancer has joined #apicula
<pepijndevos_>
confusion...
<pepijndevos_>
getPackagePinBel is in ice40 and ecp5 but not in nexus, but arch_pybindings_shared seems to need it
notafile has joined #apicula
wiizzard has joined #apicula
kprasadvnsi[m] has joined #apicula
<daveshah>
Thats an error, its not part of the standard API