<cr1901>
jfng: If you do wishbone.Decoder.add() with an addr parameter, and it's less than the specified alignment to the Decoder constructor, which address wins? The next alignment up, or the manually-specified addr in add()?
<jfng[m]>
<cr1901> "jfng: If you do wishbone.Decoder..." <- alignment is only used for implicit address assignments (i.e. when `addr` isn't provided), so you'd either get the exact address or an error
<cr1901>
ahh okay, cool
<cr1901>
I was playing around w/ it yesterday... starting to get the hang of it after looking at the tests/. I did at least get a working SoC out of the wishbone decoder :)
<jfng[m]>
nice!
<cr1901>
And the error messages are good when I made mistakes (tho I don't remember the exact error I got, it told me how to correct it)
galibert[m] has joined #amaranth-lang
<galibert[m]>
jfng: now that interfaces are a thing, should add on arbiter and decoder take an interface or return one to connect to?
<jfng[m]>
they already take interfaces as parameters
<galibert[m]>
I know
<jfng[m]>
as for returning an interface instead of having the caller provide one, i'm not sure what would be the benefit
<galibert[m]>
Two things, maybe minor, more isolation from other modules and delegating compatibility checks to the generic connect, with an automatic upgrade path if eventually things are done to make a connect-like thing with automatic adapter capabilities
<whitequark[cis]>
we can't currently assign the memory map in connect() since connect() is not extensible and there's no plan to make it so
<whitequark[cis]>
(though it doesn't seem outright impossible)
<jfng[m]>
also, a replacement for .add() that would return an interface would become some sort of interface constructor, that would still require parameters (e.g. you can add an initiator with a granularity of 32 bits to an arbiter with a granularity of 8 bits)
<galibert[m]>
You can? Ewwwwww
<jfng[m]>
why not ? it is actually straightforward in terms of interoperability
<jfng[m]>
as long as they have the same address and data widths
<galibert[m]>
I’m not sure I like that vs. using an explicit adapter just because the adapter would in that case be simple
<galibert[m]>
I personally (but that’s just my personal opinion) would require strict structural identity
<jfng[m]>
it's just a `.replicate()` for the sel lines
<whitequark[cis]>
it's something we could easily deprecate later, anyway
<galibert[m]>
My problem with transparent automatic adapters is when to stop. What about 8-bit wide initiator with 16-bits wide 8-bits granularity target? What about the other way around?
<jfng[m]>
yeah, there is a line to draw in terms of ease of implementation
<jfng[m]>
i don't have anything against different granularities because it can indeed be done transparently
<galibert[m]>
Only going towards smaller, but yeah
<jfng[m]>
i don't have strong opinions on this specific feature (i don't even think i ever needed to use it), but it hasn't bothered me to maintain it either
<galibert[m]>
It’s now a good time to choose how you want the api to be since with interfaces all the other code is going to change anyway
<galibert[m]>
Of course being happy with the status quo is perfectly sane
<jfng[m]>
one use-case is an RV32I cpu, where the instruction bus has a 32-bit granularity, and the data bus has 8-bit
<jfng[m]>
both connected to the same arbiter
<galibert[m]>
Personally I’d have an explicit adapter in front of the ibus
<galibert[m]>
A trivial one for sure
<galibert[m]>
Just explicitly showing what’s going on
<jfng[m]>
yeah, though the question becomes what kind of interface adapters do we provide in amaranth-soc, where do we draw the line, etc
<jfng[m]>
btw, there is totally a place for up/down converters in amaranth-soc
<jfng[m]>
hopefully soon(tm)
<galibert[m]>
Well where it comes to adapters you can go quite far since the costs are explicit
<galibert[m]>
You know you’re putting one in, no surprises
<galibert[m]>
You know that one is going to generate rmw cycles, etc
<galibert[m]>
You could even have one that’s a cache
<galibert[m]>
Over a slow external sdram for instance
<jfng[m]>
litex has such a cache that it uses as L2, but iirc it can't be easily flushed
<jfng[m]>
so you'd have to trigger a collision on every line to flush it :')
<galibert[m]>
Huhu fun
<whitequark[cis]>
terrible design
<whitequark[cis]>
we won't have something so awful
<galibert[m]>
Yeah, sanity requires csrs
lf has quit [Ping timeout: 258 seconds]
lf has joined #amaranth-lang
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #amaranth-lang
Raito_Bezarius has quit [Read error: Connection reset by peer]