<galibert[m]>
Is there a way to express in Amaranth (and, I guess, in verilog/rtlil) that "this set of signals is one-hot, so don't bother checking if the others are zero, that will be less wires to route"
<galibert[m]>
s/less/fewer/
<whitequark[cis]>
hm, you could control downstream logic with the individual bits rather than the entire word?
cr1901_ has joined #amaranth-lang
cr1901 has quit [Ping timeout: 248 seconds]
<galibert[m]>
amaranth will still want to manage the priorities between the possibilities
<galibert[m]>
with m.If(hot1): [...] with m.If(hot2): [...], both blocks hitting the same registers it's going to explicitely prioritize
<whitequark[cis]>
yes
<whitequark[cis]>
this is intentional
<whitequark[cis]>
there's no way to turn it off nor is a way to turn it off planned
<galibert[m]>
Yeah, I'm not sure if it should be at the amaranth level or at the yosys level, noticing/proving that it is one-hot and that some freedom is gained in synthesis thanks to that
<galibert[m]>
Optimization but without relying on undefined stuff, only with proof that it's not going to happen
<galibert[m]>
but seeing that it's one-hot at the yosys level may be difficult, too low level
<whitequark[cis]>
Oh, no, that's something that I think yosys actually does
<whitequark[cis]>
it uses SAT
<galibert[m]>
It's not an entirely well-formed concept in my head :-)
<galibert[m]>
Ah nice
<whitequark[cis]>
this is mainly useful for merging memory ports where enables are mutually exclusive
<whitequark[cis]>
but I think it might be applying the same logic in other cases
<galibert[m]>
here it's instruction register -> one-hot behaviour-to-do register -> switch on the behaviour
<galibert[m]>
It would be nice to have the concept of one-hot even for the debugging and proof aspects. I'd love amaranth to tell me when I fuck up in a 1-hot set
<whitequark[cis]>
oh, you should be able to do that soon with an Assert
<whitequark[cis]>
they're going to become simulatable
<galibert[m]>
"compile" time would be nicer
<galibert[m]>
as always
<whitequark[cis]>
you can use formal verification for that
<galibert[m]>
An idea just sprang to mind: a variant of Signal(Enum) that is underneath encoded as one-hot
<whitequark[cis]>
hm, there is an open issue for Enum type safety which I'm going to write an RFC for, probably, today
<whitequark[cis]>
you could simply define an enum with one-hot representation then?
<galibert[m]>
That would lose auto() though
<whitequark[cis]>
assigning something other than the values of this enum would be a compile time error
<whitequark[cis]>
so?
<whitequark[cis]>
actually I'm not even sure of that