<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 02ef3f0 - Deploying to main from @ amaranth-lang/amaranth@7f00f4b99d74c56272e4cb1d085fb01ba6610dfb 🚀
jjsuperpower_ has quit [Ping timeout: 250 seconds]
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 2dd0525 - Deploying to main from @ amaranth-lang/amaranth@a127167c533aaa9f917f16c2df8b60191f6a2c4e 🚀
<galibert[m]1>
I don't understand it. What's write last?
<jfng[m]1>
writes preserve the current value
<jfng[m]1>
*must
<galibert[m]1>
and what if they don't?
<galibert[m]1>
you segfault?
<galibert[m]1>
or it's just informative?
<jfng[m]1>
its a "contract" between the silicon and the BSP
<jfng[m]1>
so you'd loose backward or forward compatibility, depending on the context
<galibert[m]1>
what's the bsp?
<cr1901>
Board Support Package
<jfng[m]1>
board support package, which contains headers etc. for firmware
<galibert[m]1>
ok, so informative
<jfng[m]1>
yep
<jfng[m]1>
if it was a fuse, it's more than just informative
<galibert[m]1>
if it's a fuse it's not a reserved field
<jfng[m]1>
it is, from the point of view of software
<galibert[m]1>
hard disagree
<jfng[m]1>
the ideas is that some fields may be voluntarily left undocumented by a vendor, and exposed as reserved fields
<galibert[m]1>
you don't hide stuff behind pretending it's reserved, tyvm
<jfng[m]1>
i mean, as a vendor, i wouldn't
<galibert[m]1>
and you want to promote that?
<jfng[m]1>
well, its a use case
<galibert[m]1>
or, well, I guess there are two types of reserved
<galibert[m]1>
there's "those bits don't exist"
<galibert[m]1>
and there's "those bits exist, don't touch them, they're for me only"
<jfng[m]1>
yep
<galibert[m]1>
it would be nice to actually say which if which
<galibert[m]1>
s/if/is/
<zyp[m]1>
and then there's two kinds of «don't touch them»
<whitequark[cis]>
jfng: yes
<whitequark[cis]>
sorry, was very tired and didn't notice 20 minutes coming by
<galibert[m]1>
"don't touch them" and "really don't touch them"?
<jfng[m]1>
Catherine: np!
<whitequark[cis]>
it was 17:58 just a few minutes before... etc
<zyp[m]1>
«write 0» and «write last»
<galibert[m]1>
Catherine: you just blinked?
<whitequark[cis]>
yes, I just blinked
<cr1901>
We thought you were taking a catnap and didn't want to disturb you
<jfng[m]1>
zyp[m]1: yep! i think that's a good distinction between "lose bwd/fwd compat" and "brick your chip"
<galibert[m]1>
It was a cathnap
<jfng[m]1>
(in the reverse order)
<whitequark[cis]>
galibert[m]1: there are plenty of times when this is unavoidable, e.g. "a patent troll has sued you"
<whitequark[cis]>
in any case, compatibility (for good and for bad) with vendor CSP peripherals and practices is something I explicitly see as desirable
<galibert[m]1>
Catherine: didn't think of that case indeed
<whitequark[cis]>
galibert: re bits: there's also "this bit could exist or not exist depending on which die gets shipped"
<whitequark[cis]>
i think it is basically okay for a vendor to ship an untested peripheral in secret, test it, determine that it doesn't actually work, and never admit to anyone that it existed
<whitequark[cis]>
(this happens very often)
<galibert[m]1>
jfng: if think it would be nice to be explicit between "don't use that, it may exist but we won't document what it does, write 0/1/read value" and "this is known to not being implemented, write 0/1/read value for compatibility"
<whitequark[cis]>
getting people to admit something they don't want to admit for one reason or another is futile
<galibert[m]1>
it's also different for the glue, because in the first case the bit should exist, and not in the second
<galibert[m]1>
in fact in the first case it's a register like the others
<Chips4Makersaka4>
I'm wondering if the one time programmable fuse as reserved can't be left out ? Maybe the vendor who wants that need provide other interface or other mean to do the actual write and let not the user blow the fuse by just writing to the register.
<whitequark[cis]>
i think there's a good amount of unintentional 'one time programmable fuses' in silicon around
<jfng[m]1>
in the RFC, these are "read-zero/write-last", in contrast to "read-any/write-last" for "harmless" fields
<jfng[m]1>
galibert[m]1: hmm i think zyp's point holds: the reserved fields which are likely to brick your chip have a defined "write 0" policy
<whitequark[cis]>
remember how intel shipped FPGAs with transceivers that died if you stopped clock to them for a few hours?
<whitequark[cis]>
that is almost identical to jf's example
<Wanda[cis]>
... not just intel
<galibert[m]1>
died as in never worked again, or as in need to power cycle?
<Wanda[cis]>
permanently
<whitequark[cis]>
as in never worked again
<whitequark[cis]>
Just Don't Stop The Clock
<galibert[m]1>
that's insane
<whitequark[cis]>
that is completely normal
<whitequark[cis]>
vendors do this all the time completely unintentionally and this is a huge part of the reason why they are hiding so much from you instead of exposing the registers to everyone
<whitequark[cis]>
it's because they're chock full of stuff like this, and the less severe ones even more so
<galibert[m]1>
that's called an hidden defect in my book
<Chips4Makersaka4>
So you want the CSR definition also used as documenting hardware bugs after the fact ? New silicon should not retain such features.
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): I think this is inevitable if we are to make real silicon
<Wanda[cis]>
galibert[m]1: there's a reason chicken bits are a thing
<Wanda[cis]>
if you can poke the expensive hardware you just made into working with a software workaround, why would you not do that?
<whitequark[cis]>
respins cost a lot!
<Chips4Makersaka4>
I don't how you can accidently introduce a writable fuse on a cihp defined in Amaranth code.
<galibert[m]1>
the transciever thing sounds like perfectly normal usage
<Chips4Makersaka4>
* I don't see how you
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): well it wouldn't be in the standard cells
<whitequark[cis]>
it would be in something connected to the register
<whitequark[cis]>
we are heavily encouraging restricting registers to either "read only for the user" or "flop for the user" which would mitigate that somewhat
<galibert[m]1>
"don't connect a bit to the nuke detonator" should be in the manual somewhere
<Chips4Makersaka4>
external IP you mean, mmh, still...
<whitequark[cis]>
have you ever looked at luminary micro devices?
<cr1901>
jfng[m]1: Can we have ResR0WL for fields to represent "reserved, but I've already decided 0 is a safe, noop value in the future"?
<cr1901>
(to opt-out of RMW cycle for reserved fields)
<galibert[m]1>
R0WL = R0W0?
<whitequark[cis]>
Stellaris/Tiva
<whitequark[cis]>
their erratasheets are fantastic reading
<jfng[m]1>
cr1901: you mean, for values and not flags ?
<jfng[m]1>
like, these are more like a collection of use cases rather than hard guidelines
<whitequark[cis]>
highly recommended, some of the best non-fiction i know
<cr1901>
Ohhhh, R0WL isn't hardcoded to flags
<galibert[m]1>
In which way R0WL/R1WL make sense, rather than R0W0/R1W1? Do it mean you have to read the register before writing it?
<galibert[m]1>
s/Do/Does/
<galibert[m]1>
RAWL sure
<zyp[m]1>
Can you expand on what R0WL means? I might be reading it wrong, but it doesn't seem to make a lot of sense
<cr1901>
I don't think the compiler can "know" R0WL, but I think the assembly-snippet writer can take advantage of when they know that the last value written was nonzero.
<jfng[m]1>
galibert: if you can assume the read value, you don't need an RMW transaction to write it
<zyp[m]1>
IMO the useful ones would be RAWL, RAW0 and R0WA
<jfng[m]1>
zyp: read 0, write last
<jfng[m]1>
reads are defined to return 0, so the software driver must write 0 too
<cr1901>
What's the intended use of RAW0?
<cr1901>
(It's not in the RFC)
<galibert[m]1>
jfng: which is where, as a software dude, I ask "why don't you say I have to write 0 rather than saying I have to write the last read value which is going to be 0? Whyyyyyyyyyyyyyyyyyyyyy?"
<galibert[m]1>
(add 'y' to taste)
<jfng[m]1>
i have a preference for R0/WL over RA/W0, as it retains a storage-like property
<Chips4Makersaka4>
<whitequark[cis]> "highly recommended, some of..." <- Likely for every complex digital or analog ASIC you will have errata sheet but I'm still not convinced this is reason to have the one time programmable fuse.
<zyp[m]1>
RAW0 would be «you can't assume what this bit will read, but it's always safe to write it to 0»
<Chips4Makersaka4>
* have the reserved one time
<zyp[m]1>
maybe R0W0 is more useful
<galibert[m]1>
and in particular I'm going to ask "does it mean I have to read the register before I'm allowed to write to it?"
<cr1901>
zyp[m]1: I think R0WL for values serves that purpose
<cr1901>
it's intended for flags, but jfng[m]1 says it can be used for fields
<jfng[m]1>
R0/W0 is equivalent to R0/WL, no ?
<cr1901>
so I say "no problem"
<zyp[m]1>
R0WL is effectively R0W0
<whitequark[cis]>
Chips4Makersaka4: i once connected a ground of my logic analyzer connected to my laptop to the stellaris devboard connected to my laptop and the stellaris board instantly died to latchup
<zyp[m]1>
WL implies RMW, so I'd prefer calling it R0W0
<whitequark[cis]>
not signal. ground. to a laptop that was isolated from power
<galibert[m]1>
jfng: for me "write last" means "you have to read the value, even if you know what the result is going to be"
<whitequark[cis]>
this is a known issue, you just buy a new one when that happens
<jfng[m]1>
the underlying idea is that RMWs are only needed for RA/WL
<Chips4Makersaka4>
whitequark[cis]: OK but you dont want to document that then in the CSR definition afterwards do you ?
<Chips4Makersaka4>
I mean the vendor
<whitequark[cis]>
no i'm just giving you a link to the stellaris erratasheet because it's incredibly funny
<whitequark[cis]>
it's not really an argument of any kind
<cr1901>
RAWL implies RMW, none of the others imply RMW because the read value is known ahead-of-time. 1/2
<Chips4Makersaka4>
+1
<cr1901>
Although your next silicon revision better return 0 at any place an older version of software expects a 0
<galibert[m]1>
Catherine: the workaround parts are the really fun part
<jfng[m]1>
zyp[m]1: i should think about it, i may just be missing a good reason to add this
<cr1901>
your next silicon revision with implements the undefined bits*
<whitequark[cis]>
galibert: the part i like the most is how that's revision b. i wanna know how revision a was
<whitequark[cis]>
do you know why it dies if you so much as breathe near it? they didn't want to pay tsmc for the esd diodes and designed their own
<whitequark[cis]>
the part that is objectively the funniest is that TI still manufactures them, with identical masks, and identical errata
<whitequark[cis]>
they renamed them from tm4c to msp432e a while ago, same die, 2x the price
<galibert[m]1>
cr1901: write last implies RMW because if you don't read there is no last
<zyp[m]1>
jfng[m]1: effectively it means that as a designer you can say «I promise that any functionality I add to these bits will have no impact as long as they are set to 0»
<cr1901>
jfng[m]1: Yea, so re: "Software drivers need to be aware of such fields, to ensure forward compatibility of software binaries with future silicon versions." 1/2
<zyp[m]1>
although R0W0 is probably more appropriate, since you can then also assume they'll read 0
<galibert[m]1>
In fact it means "it's going to read 0 in this version, but for future compatibility do a rmw and don't change them" now that I really think about it
<cr1901>
I take this to mean: If you implement a currently ResR0WL field in a new silicon version, it's up to the current revision BSP to correctly handle the case where "oh God, a read didn't return 0"
<jfng[m]1>
zyp[m]1: zyp: R0/WL says the same thing *and* provides a defined read value
<zyp[m]1>
true
<cr1901>
(which basically means "ignore the read value/pretend it's 0"?)
<zyp[m]1>
okay, better reason: «I promise that any bit I'll add here will be readonly»
<cr1901>
B/c this is my current understanding
<galibert[m]1>
jfng: No, it means "for now it's zero, it may change in the future, be careful not to change it". What you say is RAW0
<zyp[m]1>
IMO it should be okay to declare a bit R0W0 if it has a reset value of 0 and it's gonna stay 0 if software doesn't touch it
* cr1901
will wait his turn as to not overload /jfng
<zyp[m]1>
if software breaks the W0 contract, gateware can't guarantee the R0 contract
<jfng[m]1>
cr1901: ok, i think this is actually a good argument for ResRAW0
<galibert[m]1>
*W0 and *W1 should mean "the underlying module is not even going to see the bit in question"
<jfng[m]1>
if the flag is implemented in a future revision, and returns 1, an old software driver could still write 0 (which would be a no-op, the field would either be RW1C or RW1S)
<jfng[m]1>
so yeah, zyp, ResRAW0 is going in
<galibert[m]1>
"Boundary scan is not functional" wow
<cr1901>
Is my understanding of R0WL and the "software drivers..." line correct?
<zyp[m]1>
also let me restate what I said earlier; the only *WL that makes sense to have is RAWL, because the other options would have a defined write value, and would thus have better readability if it just explicitly states W0 or W1
<jfng[m]1>
cr1901: this would be a silicon bug if it did, but now that i think of it, R0WL doesn't make sense
<jfng[m]1>
this should really be ResRAW0
<cr1901>
It's not a silicon bug if it's a future revision of silicon paired w/ an earlier version of the BSP
<galibert[m]1>
yay we're converging
<cr1901>
I don't think
<cr1901>
I think RAW0 is better intent (don't assume anything about the read value), but R0WL could work too
<galibert[m]1>
WL implies you have to do a read to find the value of L. Nothing else makes sense
ChanServ has quit [shutting down]
<zyp[m]1>
exactly
<cr1901>
For some reason I'm not hung up on the "WL" terminology, but I can understand why others are
<jfng[m]1>
zyp[m]1: so i now think we should go with 3 reserved fields: ResRAW0, ResRAWL, ResR0WA
<jfng[m]1>
so there aren't other WL types besides RAWL
<Chips4Makersaka4>
Wouldn't it be better called write-same than write-last ? E.g. you have to write same value than what you read ? Or is that not the meaning ?
<zyp[m]1>
> <@jfng:matrix.org> so i now think we should go with 3 reserved fields: ResRAW0, ResRAWL, ResR0WA
<zyp[m]1>
> so there aren't other WL types besides RAWL
<zyp[m]1>
Sounds good, also ResR0W0 seems useful
<galibert[m]1>
R1WA?
<jfng[m]1>
Chips4Makersaka4: i borrowed it from the SVD spec, which specifies a "write-last-read" policy for CSR writes
<zyp[m]1>
any 0 could naturally have a 1 counterpart, but those seem less useful in practice
<jfng[m]1>
riscv uses "write preserves"
<galibert[m]1>
I have cases in the h8 dma for instance
<galibert[m]1>
or sci, not sure anymore
<galibert[m]1>
in any case, a channel that doesn't have a given mode switch and the value read reflects the fixed mode
<whitequark[cis]>
we can always add 1 counterparts at a later point if someone asks
<galibert[m]1>
the other channels have the mode switch, and that way all registers look identical
<jfng[m]1>
galibert[m]1: are these really common ? users can still subclass GenericField for unconventional definitions
<galibert[m]1>
h8 ports direction registers also show the direction for bits that are only one way
<galibert[m]1>
ah they're not readable
<jfng[m]1>
<jfng[m]1> "i borrowed it from the SVD spec,..." <- ... indeed, write-last is ambiguous
<jfng[m]1>
like, it could mean the last time the register was read... a long time ago ?
<jfng[m]1>
... write-retains, so get a RAWR policy
<jfng[m]1>
but that's ambigous again
<galibert[m]1>
og.kervella.org/h8s-2655.pdf pdf page 582
<Chips4Makersaka4>
I think needing real RMW cycle or not or two valid cases.
<galibert[m]1>
you have an example of R1W1/R1WA
<Chips4Makersaka4>
* think needing a real RMW
<Chips4Makersaka4>
* I think needing a real RMW cycle or not are two valid cases.
<galibert[m]1>
the non-existing ADTE on TCSR1
<galibert[m]1>
which is always active on that channel
<jfng[m]1>
i'll keep write-last for now, but this is open to bikeshedding
<jfng[m]1>
i guess time is up, thanks everyone
<jfng[m]1>
the feedback was productive
ChanServ has joined #amaranth-lang
<Chips4Makersaka4>
K, heading off then, CU.
<jfng[m]1>
Chips4Makersaka4: how can you write a read-any/write-last without an RMW cycle ?
<jfng[m]1>
i think the current consensus is that this is the only field that requires one
<whitequark[cis]>
fwiw I was really tired and not fit to participate anyway, but I'll make sure to catch up when Im less tired