<cr1901>
TypeError: Only signals may be added as ports, not <ufm_reader.sequencer.Operands object at 0x0000025f42a27d50> <-- If Operands is a union, whose largets variant is 24 bits how do I convert it to "a 24 bit signal that is compatible with the ports= argument to verilog.convert()"?
* cr1901
is going to sleep, be back in a few hours
<galibert[m]>
another 24-bits signal you comb.eq to your union.as_value() ?
<galibert[m]>
unwraps the view at zero cost that way
<whitequark[cis]>
cr1901: we could probably extend `ports=` to also accept `ValueCastable` things whose `as_value` returns a `Signal`
<whitequark[cis]>
but considering interfaces can contain value-castables it doesn't seem worth it
jess has joined #amaranth-lang
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #amaranth-lang
nak has quit [Ping timeout: 255 seconds]
mwk_ is now known as mwk
<cr1901>
whitequark[cis]: >but considering interfaces can contain value-castables it doesn't seem worth it <-- could you elaborate on this? Is this about #883 and making the ports= arg redundant?
<whitequark[cis]>
yes
<cr1901>
whitequark[cis]: When deciding how to map aggregate data structures to ports, what are your thoughts on "struct fields get split into their own ports", as opposed to "struct becomes one big signal"?
<whitequark[cis]>
a struct is a single signal
<whitequark[cis]>
this is clearly described in the manual
<cr1901>
struct becomes one big port*
<whitequark[cis]>
if you're uncertain about this, consider what a union or a flexible view would become
<cr1901>
I see what you mean.
<galibert[m]>
Catherine: lots of signals? :-)
<whitequark[cis]>
how do you have two overlapping input ports?
<galibert[m]>
well, for vcd it works, for verilog it explodes beautifully
<whitequark[cis]>
yes, it works for output ports
<whitequark[cis]>
but not for input
<whitequark[cis]>
this is the reason lib.data is designed the way it is
<whitequark[cis]>
cr1901: if you want separate ports you probably want fields in an interface, usually
<whitequark[cis]>
structs would ideally become SV structs
<whitequark[cis]>
but that won't happen until we ship the new IR
<cr1901>
whitequark[cis]: Yes, this is what I'm doing now. I almost was able to get away w/o using a separate wrapper object, but sometimes accessing a struct field returns "Slice", and "(slice (sig ctl__cmd) 0:8)" isn't value-castable to Signal :P
<whitequark[cis]>
this is how lib.wiring and lib.data are intended to be used
<whitequark[cis]>
having an Interface consisting only of Out members is probably what you're looking for
<cr1901>
Btw, unrelated to anything, why do Signature __init__()s have a return value?
FFY00 has quit [Remote host closed the connection]
<whitequark[cis]>
they do? I think that's illegal in Python
<cr1901>
Oh, in StreamSignature.__init__(self, payload_shape)
<cr1901>
it has a lone statement: "return super().__init__({..})"
<cr1901>
which probably works b/c super().__init__() returns None?
<whitequark[cis]>
that return shouldn't be a thing
<cr1901>
I just copied it thinking "I'll ask about it later, wq has her reasons"
<whitequark[cis]>
no it's a bug
<whitequark[cis]>
this is not correct python, period
<whitequark[cis]>
it happens to not error out because super().__init__ returns None
<cr1901>
I'll make a pull w/ corrections later today.
<whitequark[cis]>
please don't treat me like some sort of programming deity, i hate that. i make a ton of mistakes; the RFC process quite literally exists to make sure others don't pay for my mistakes
<cr1901>
I don't think you're a deity. I would've done the same thing for anyone else, b/c 90% of the time I think something looks off, it's because I don't understand something
<cr1901>
_I_ in emphasis
<cr1901>
This happens to be the 10%
FFY00 has quit [Remote host closed the connection]
<whitequark[cis]>
yeah that was a bit of a non-sequitur, this is a frustration i have in general. especially in cases where people decide to treat me like that and then they decide to hate me because i don't live up to their expectations or some other insane conclusion they make from it
<whitequark[cis]>
shouldn't that be just Out(RandSignature)?
<whitequark[cis]>
* shouldn't that be just Out(RandSignature())?
<cr1901>
Yes, it was a typo I fixed before bed last night but haven't pushed yet :P
<whitequark[cis]>
ah, makes sense
<cr1901>
It happens to compile b/c I don't really use the PageBuffer anything that depends on checking the flow right now (it is turned into Verilog), but it was a mistake nonetheless
<cr1901>
it is turned straight into Verilog*
FFY00 has joined #amaranth-lang
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #amaranth-lang
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #amaranth-lang
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #amaranth-lang
FFY00 has quit [Remote host closed the connection]
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] whitequark 0e2f90e - Deploying to main from @ amaranth-lang/rfcs@13279cc9685af79cef06c99f0dc49be2fc244081 🚀
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] whitequark f207b91 - Deploying to main from @ amaranth-lang/rfcs@1e81be54446a4592e07e9168273a093075bed840 🚀
<_whitenotifier>
[amaranth-lang/rfcs] cr1901 fef9c46 - Remove return value from StreamSignature __init__ in Signature inheritance example (Python constructors don't return anything).
<_whitenotifier>
[amaranth-lang/rfcs] whitequark 1e81be5 - Fix a typo in RFC #2.