pepijndevos changed the topic of #apicula to: Project Apicula: bitstream documentation and tooling for Gowin FPGAs -- logs
<rvalles_> Followed readme, yet ModuleNotFoundError: No module named 'wirenames'. Same deal for other modules.
<rvalles_> I've managed to make it work by editing the generic/ .py stuff to import from apycula.
<rvalles_> But... what's in the readme should really just work.
<rvalles_> Blinkygw1n1 seems to work, so that's something :-)
_whitelogger has joined #apicula
_whitelogger has joined #apicula
Conny40 has quit [Ping timeout: 260 seconds]
Conny40 has joined #apicula
<omnitechnomancer> Were you supposed to have PYTHON_PATH set to something for the README commands and it never told you I wonder
FabM has joined #apicula
FabM has quit [Ping timeout: 260 seconds]
FabM has joined #apicula
<pepijndevos_> rvalles_, I'm in the middle of some major changes at the moment, so documentation is a bit out of sync
<pepijndevos_> This is probably the best point if you want to use it right now:
<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_> No idea tbh
<daveshah> looks possibly promising
<pepijndevos_> oh sweet
<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"
<daveshah> :D
<Lofty> I think planar is nice as a name
<pepijndevos_> Yea agree
<pepijndevos_> I think this one is pretty funny though
<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
<pepijndevos_> So what is the correct thing to do?
<daveshah> It should be removed from pybindings_shared and added back to the ice40 and ecp5 specific pybindings
<pepijndevos_> alright
FabM has quit [Ping timeout: 256 seconds]
<omnitechnomancer> Clearly to save hassle the naming should be abstracted so the next pnr tool is just succ(currentpnr)