whitequark changed the topic of #nmigen to: nMigen hardware description language · code https://github.com/nmigen · logs https://libera.irclog.whitequark.org/nmigen
Lilian_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
Lilian has joined #nmigen
lf has quit [Ping timeout: 260 seconds]
lf has joined #nmigen
k-haze has quit [Ping timeout: 264 seconds]
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 264 seconds]
<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
bvernoux has quit [Quit: Leaving]