<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 3fafc7a - Deploying to main from @ amaranth-lang/amaranth@7e3e10e7333630999c5b51440f0e5f0daef0358c 🚀
<tannewt>
I was approaching it as `elaborate()` was the only hardware generation specific function
<whitequark>
so I think defining register banks this way is fine and might even end up being the way to do it in -soc
<tannewt>
everything else was "just" driver code
<whitequark>
right
<tannewt>
that's mostly what I deal with
<whitequark>
I definitely see the intent and, hm
<tannewt>
(register code)
<whitequark>
the only concern I have against this design is that the use case of generating a design, immediately turning it into a bitstream, and then interacting with it, is actually fairly special
<whitequark>
this isn't a very realistic flow for Xilinx devices for example
<tannewt>
one other reason I liked this approach is that it is documented like standard python
<whitequark>
if you have a very long bitstream generation step, you end up wanting to cache either the bitstream or the Python design hierarchy
<tannewt>
its not a separate custom generation process
<tannewt>
totally. I've been experimenting with this with arm code loaded over i2c
<whitequark>
so there are two separate things here: defining registers as class members (entirely reasonable idea, we'll definitely explore it; I'm already using something like that in lib.data and lib.intf)
<whitequark>
and having those class members be able to run code that talks to hardware
<whitequark>
the whole thing with MemoryMap, etc, is about taking the design hierarchy as it's created when you are generating the bitstream, and turning it into something serializable
<whitequark>
I think there might be a compromise solution that makes your use case feasible, but I'd have to think deeper about the way -soc is doing things, which we can do a bit later
<whitequark>
after interfaces land
<whitequark>
to summarize: mostly something I already want, to a lesser extent something we can explore with likely success
<whitequark>
it's something that might be usable in Glasgow too
<tannewt>
the python class is actually generated from C
<whitequark>
interesting
<whitequark>
how does that work?
<tannewt>
this is for the espressif chips with a ultra low power processor
<tannewt>
you build the c file for it and the generator reads the global variables and their address
<tannewt>
then makes them available on the python class
<tannewt>
I was thinking of something similar for an external stm32g0 which can have code loaded over i2c
<tannewt>
my hope would be that you don't need to manage a memorymap object separately from defining the register class members
<whitequark>
the idea is that there would be a register bank class that'd have that functionality built in
<whitequark>
the design for that was riiiight about the time i stopped working with m-labs
<josuah>
this would allow declaring registers in RTL, and this would also generate a register map by the same occasion?
<whitequark>
yeah
<whitequark>
most likely, like with lib.data, there would be a lower-level interface with more flexibility, and high-level interface that lets you go tx_fifo: Register(unsigned(16)) or something in a class