01:51 <xobs> mithro: Okay! I do think I'll adopt the suggestion of _florent_ and subclass it from CSRStorage/CSRStatus, and place all fields under an `f` property.

02:02 <xobs> By the way, does anyone use an ECP5 board and have the ability to test my toolchain?

02:03 <xobs> It's basically an ECP5-equivalent of the Fomu toolchain, built for the Hackaday badge that uses an ECP5: https://github.com/xobs/ecp5-toolchain

02:03 <xobs> ...I've been busy with Fomu lately so I haven't had a chance to get set up, but if anyone has an ECP5 handy that'd be really useful to know if it's working!

02:03 <John_K> I just got an ULX3S, should be able to give it a shot

02:09 <xobs> John_K: thanks! Let me know how it goes. Everything should be statically built for linux and windows. Just set your PATH and go.

02:10 <xobs> ...whoops. Forgot to push the branch that filed nameplates. Fixed, so now it doesn't say "Fomu" anymore.

02:23 <John_K> so I just run build.sh? documents are unclear

02:24 <John_K> or is this repo just telling me to download a prebuilt toolchain?

02:41 <John_K> trying to build spispy with it and ecppll is missing from ProjectTrellis

02:43 <John_K> @xobs: looks like you need to include some things from ProjectTrellis and it would be nice if there was a script to download the prebuilt for you (it seems you have most of the needed logic in build.sh anyway)

02:44 <xobs> John_K: It's missing? I thought I included it... Thanks for the report.

02:44 <John_K> at least not in the 1.4 version

02:46 <xobs> Are any of the other ecp tools installed? I might've just gotten the paths wrong.

02:48 <John_K> find returns no binaries starting with "ecp"

02:49 <xobs> John_K: I'm sorry, I think the page wasn't updated yet, so maybe you downloaded the fomu toolchain that's ice40-only. Did you get it from https://github.com/xobs/ecp5-toolchain/releases?

02:49 <tpb> Title: Releases · xobs/ecp5-toolchain · GitHub (at github.com)

02:49 <xobs> The latest version is 1.3.

02:49 <John_K> ah, no

02:49 <John_K> the readme linked to ice40

02:50 <John_K> I see you've updated it

02:51 <xobs> Yeah, git is weird. Especially when it comes to tags and branches. I messed up and only pushed the tag, not the branch.

02:51 <John_K> ahh yep, been bitten by that before

02:54 <John_K> xobs: ERROR: Unable to read chipdb /usr/share/nextpnr/ecp5/chipdb-25k.bin

02:54 <John_K> checking to make sure this isn't something weird with spispy build system

02:55 <John_K> looks like an error in nextpnr-ecp5 in your toolchain

02:57 <John_K> chipdb-25k.bin doesn't appear to exist either

03:01 <xobs> John_K: Okay, that's definitely an error. Apparently when you use an external chipdb, it doesn't include it in the binary.

08:54 <xobs> _florent_: I redid it so now it's subclassed from csrstatus and csrstorage.

08:54 <xobs> https://github.com/xobs/dreg/blob/master/dcsr.py

08:54 <tpb> Title: dreg/dcsr.py at master · xobs/dreg · GitHub (at github.com)

08:55 <xobs> And here's a working example that uses it for all accesses: https://github.com/xobs/valentyusb/blob/8731739397e13d41a94b6dba428be9f854a28072/valentyusb/usbcore/cpu/eptri.py#L699

08:55 <tpb> Title: valentyusb/eptri.py at 8731739397e13d41a94b6dba428be9f854a28072 · xobs/valentyusb · GitHub (at github.com)

09:34 <keesj> https://theamphour.com/456-3-discussing-fomu-with-tim-ansell-and-sean-cross/ had some talk on the whole ecosystem (including litex)

09:35 <keesj> I know some stuff was discussed here (usb->withbone) but it was also nice to hear the "use case" typeish idea

14:20 <_florent_> xobs: that seems fine, i'll have a closer look later, just regarding the API:

14:21 <_florent_> Field should probably be renamed to DCSRField (to avoid ambiguity when others Field objects are used)

14:22 <_florent_> also to access field, could it be: status.have instead of status.w.have and ctrl.advance instead of ctrl.r.advance?

15:55 <xobs> _florent_: I'm about to go to bed right now, sorry. But I wanted a short name for Fields since they get used often.

15:56 <xobs> Also, to access a field depends on whether you're writing it or reading it. CSRStorage objects that have writr_from_dev support both reading and writing, so that syntax wouldn't work.

15:57 <xobs> Maybe we could prefix them with w_ and r_ if they're readable and writable?

17:29 <_florent_> xobs: maybe only CSRStorage with write_from_dev should have a .w: status.have (written by the logic, read by the CPU), ctrl.advance ( written by the CPU, read by the logic) ctrl.advance.w (for write_from_dev)