<d1b2>
<dbosky> Did you mean nMigen in general or just Record?
<mwk>
Record in particular
bvernoux has joined #nmigen
k-haze has joined #nmigen
<_whitenotifier-1>
[yosys] whitequark commented on issue #24: Error when used with VSCode and Teroshdl - https://git.io/JPV9r
<FL4SHK>
cr1901: I have implemented a couple record classes derived from `ValueCastable` that can be used instead of `Record`.
<FL4SHK>
The classes I've written scale well.
<FL4SHK>
As well as a packed array class
<FL4SHK>
which can be combined with packed recrods
<whitequark>
that's a different use case though
<FL4SHK>
Well, I also wrote a class derived from `ValueCastable` that is made to be used for interfaces
<FL4SHK>
I have two record classes
<FL4SHK>
My `Splitrec` class is meant to be filled up with members that are `Signal`s, `Packrec`s, `Packarr`s, and other `Splitrec`s.
<FL4SHK>
I also wrote a class that's basically a wrapper around Python `list`s that is derived from `ValueCastable`
<FL4SHK>
It also stores `Signal`s, `Packrec`s, etc.
<FL4SHK>
This stuff together allows you to do essentially any kind of interface you want for a module
<FL4SHK>
I don't have something like an SV `interface` that you can have both inputs and outputs in one `ValueCastable` if your goal is also to connect all the ports together in one go
<FL4SHK>
I've been using two `Splitrec`s per module interface, one for inputs, and one for outputs.
<whitequark>
I'd say that an interface shouldn't be ValueCastable at all
<FL4SHK>
Why?
<whitequark>
because it doesn't make sense?
<whitequark>
you've just described it yourself: if you're using a ValueCastable to connect things up, you can't have both inputs and outputs there
<whitequark>
and interfaces (module interfaces, but also things like streams) very much are composed from both inputs and outputs
<FL4SHK>
Well, I've been using a Python class per module representing the full interface
<FL4SHK>
storing two `Splitrec`s, one ofr inputs, one for outputs, in that Python class
<whitequark>
yes, that would be a workaround for being able to use your design for interfaces
<FL4SHK>
It's the same thing I'd do in VHDL 2008.
<whitequark>
the existing `Record.connect` method doesn't have this limitation
<FL4SHK>
I see.
<FL4SHK>
The existing `Record` class doesn't support arrays as members
<whitequark>
sure
<FL4SHK>
I need that
<whitequark>
I'm not suggesting you use it
<FL4SHK>
Okay
<FL4SHK>
I would like to include a `connect()` member
<FL4SHK>
method
<FL4SHK>
I didn't even realize that was possible with what I have written
<FL4SHK>
Er
<FL4SHK>
With nMigen*
<whitequark>
one of the major issues with Record is that you can do both `.connect` and `.eq` on them, and the latter is subtly wrong if you have directions
<whitequark>
which is why it needs to be split into a `ValueCastable` part (that you can assign to), and a non-`ValueCastable` part (that you can only connect)
<FL4SHK>
Would you be interested in using the modules I have written?
<whitequark>
as-is? unlikely
<FL4SHK>
What kinds of changes would you want?
<whitequark>
an RFC will need to be written first
<FL4SHK>
Okay. I'm willing to contribute my code.
<FL4SHK>
I can change it.
<whitequark>
code is secondary to design, really
<whitequark>
I'm not worried about the effort of writing code at all; I'm worried about getting things wrong in a way that would cause backwards compat issues later
<FL4SHK>
That makes sense.
<FL4SHK>
What would be a cause of backwards incompat?
<whitequark>
look at what happened with the existing `Record`
<whitequark>
it was designed by somewhat blindly following what Migen did, and now we have to split it in two and deprecate
<whitequark>
it also doesn't support things like packed arrays
<whitequark>
so for its replacement, rather than just iteratively adding code that seems to make sense for someone's use case (which is how Migen's `Record` was built, and which is, necessarily, how your code was built), I'll start with a design document and ask for feedback on it
<FL4SHK>
I understand.
gdd has quit [Ping timeout: 260 seconds]
gdd has joined #nmigen
peeps[zen] has quit [Ping timeout: 260 seconds]
peepsalot has joined #nmigen
lambda has quit [Quit: WeeChat 3.2]
lambda has joined #nmigen
bvernoux has quit [Ping timeout: 246 seconds]
bvernoux has joined #nmigen
kaucasus has joined #nmigen
<key2>
+1
kaucasus has quit [Quit: Client closed]
<d1b2>
<Uwe> Subject: Mein ELSTER: Informationen zu Ihrem Zertifikat Subject: Mein ELSTER: Informationen zu Ihrem Zertifikat