<zyp[m]>
I made a workaround for hooking up a 32-bit CSR bus to a wishbone bus with granularity 8: https://paste.jvnv.net/view/g35PB
<zyp[m]>
well, it's not CSR specific, it goes between a WishboneCSRBridge and a wishbone.Decoder
mabl[m] has joined #amaranth-lang
<mabl[m]>
Nice! The problem is clearly the `target.sel.eq(initiator.sel.all()), # With .all(), smaller writes will be silently ignored.` line.
<mabl[m]>
How common are partial writes? I am planning to attach the CSR to an Axi-Lite bus driven by a Zynq with a hard-CPU core. Not sure if that only issues full width writes?
<zyp[m]>
a CPU typically has 8b, 16b, 32b and so on wide store instructions, so it depends on the code
<zyp[m]>
C and higher level languages will emit the store instructions that fit the datatype
<zyp[m]>
so registers on a 32-bit CSR bus should be modelled as volatile uint32_t or similar and the compiler will tell the CPU to do the right thing
<whitequark[cis]>
I prefer using inline assembly to do explicit loads and stores
<whitequark[cis]>
as volatile is not well-defined and should probably not be used
<whitequark[cis]>
(yes, many people use it, but it's also fragile and it's not too difficult to run into issues with it because of how it's specified)
pbsds3 has quit [Server closed connection]
<zyp[m]>
that's a separate discussion I'm not inclined to engage in :)
pbsds3 has joined #amaranth-lang
<zyp[m]>
anyway, the ugly part of my solution is the MemoryMap workaround; it'd be nice to be able to just add the downstream bus as a window and have it handle the granularity translation internally
urja has quit [Server closed connection]
urja has joined #amaranth-lang
<mabl[m]>
Good points, thank you all
<whitequark[cis]>
the Amaranth SoC BSP generator will not provide the volatile method of reading/writing registers
<whitequark[cis]>
other than that everyone is free to do whatever is to their liking
<mabl[m]>
> Amaranth SoC BSP generator
<mabl[m]>
That one doesn't exist yet, right? There is no premade way to export the register (and field) layout.
Chips4MakersakaS has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
not yet
<whitequark[cis]>
given my and JF's current plans we may start working on it in late Sep / early Oct
<whitequark[cis]>
however you can export interface metadata, which includes all of the register and field layout, IIRC
<jfng[m]>
i got bitten by this recently, clang would serialize the access as four 8-bit stores, in the wrong order, unless the `aligned(4)` attribute was also used
<jfng[m]>
generating assembly would avoid having to deal with this kind of language/toolchain specific things
<whitequark[cis]>
yes
<zyp[m]>
FWIW an inline assembly store counts under «or similar»
<jfng[m]>
(in the above example, the CSRs were accessed over an 8-bit bus)
<whitequark[cis]>
zyp: I wasn't intending to argue with you
<whitequark[cis]>
rather I was describing what I see as the appropriate way to handle CSRs that will be used in Amaranth once we have BSP generation
<whitequark[cis]>
since I don't think it was explicitly stated before anywhere here
<zyp[m]>
> i got bitten by this recently, clang would serialize the access as four 8-bit stores, in the wrong order, unless the `aligned(4)` attribute was also used
<zyp[m]>
with `packed` you've effectively turned off the alignment guarantee, and riscv-clang by default assumes the cpu doesn't support unaligned accesses, so it resorts to byte accesses
<jfng[m]>
yep
<zyp[m]>
<jfng[m]> "(in the above example, the..." <- how can that struct be correct then? mode and setclr is twice as wide as input and output
<jfng[m]>
i was experimenting with adding a configurable `alignment` parameter to `csr.Builder`
<jfng[m]>
zyp[m]: i want it too, the current situation (natural alignment of each register) is overly restrictive
<zyp[m]>
I think it'd be good to have every register be 32b aligned, that way the address map would be more or less identical regardless of whether the actual CSR bus is 8b or 32b
<jfng[m]>
zyp[m]: yes, this is what i think too; the example i showed only works because this CSR bus is 8-bit wide
<zyp[m]>
did anyone do any benchmarks of what is most efficient (resource wise) of a 32b wide or an 8b wide CSR bus?
<jfng[m]>
@mabl:matrix.org yeah, that would be the idea
<zyp[m]>
AIUI in cr1901 's sentinel example, having peripherals hanging right on wishbone ends up with a smaller gateware than having them on an 8b CSR bus
<zyp[m]>
which I assume is due do the added width conversion logic
<jfng[m]>
<jfng[m]> "@mabl:matrix.org yeah, that..." <- sorry i misread; no it wouldn't. it would work similarly to the `alignment` parameter in `MemoryMap.add_resource`, so the size of the register would be affected
<jfng[m]>
from the perspective of a firmware driver, the register would be 32b
<jfng[m]>
@mabl:matrix.org do you have a use case for aligning a CSR register address without rounding up its size ? `.align_to()` could also be added to `csr.Builder`, but i don't have a motivational use-case atm
<zyp[m]>
IMO it'd be preferrable to have the size rounded up, so the generated code ends up exactly identical to having the registers on a 32b bus
<mabl[m]>
jfng[m]: Because the write strobe to the register is not triggered if only the register is accessed and not the upper end of the (larger sized) window.
<zyp[m]>
the only disadvantage I imagine is that if you didn't round it up, WishboneCSRBridge could be optimized to skip writes and save a few cycles on smaller registers
<jfng[m]>
yeah, what zyp said
<zyp[m]>
assuming that's worth the increased logic
<mabl[m]>
<jfng[m]> "from the perspective of a..." <- Right, I guess i can live with that.
Wolfvak has quit [Server closed connection]
Wolfvak has joined #amaranth-lang
FFY00_ has quit [Server closed connection]
FFY00_ has joined #amaranth-lang
cr1901 has quit [Server closed connection]
cr1901 has joined #amaranth-lang
bob_twinkles has quit [Server closed connection]
bob_twinkles has joined #amaranth-lang
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #amaranth-lang
cr1901 has quit [Read error: Connection reset by peer]
Wanda[cis] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has joined #amaranth-lang
mcc111[m] has quit [Quit: Idle timeout reached: 172800s]