whitequark changed the topic of #nmigen to: nMigen hardware description language · code https://github.com/nmigen · logs https://libera.irclog.whitequark.org/nmigen
lf has quit [Ping timeout: 252 seconds]
lf has joined #nmigen
lf has quit [Ping timeout: 258 seconds]
lf has joined #nmigen
cr1901 has quit [Read error: Connection reset by peer]
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
cr1901 has joined #nmigen
pho has quit [*.net *.split]
RobTaylor[m] has quit [*.net *.split]
Niklas[m] has quit [*.net *.split]
CarlFK has quit [*.net *.split]
pie__ has quit [*.net *.split]
mindw0rk has quit [*.net *.split]
Ekho has quit [*.net *.split]
pie_ has joined #nmigen
mindw0rk has joined #nmigen
Niklas[m] has joined #nmigen
RobTaylor[m] has joined #nmigen
pho has joined #nmigen
Ekho has joined #nmigen
CarlFK has joined #nmigen
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinXW
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMY
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMO
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinM3
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMs
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMG
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMZ
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMn
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMZ
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JinMZ
<_whitenotifier-1> [nmigen] codecov[bot] commented on pull request #644: vendor.openlane: OpenLANE ASIC Platform - https://git.io/JinMo
<_whitenotifier-1> [nmigen] codecov[bot] edited a comment on pull request #644: vendor.openlane: OpenLANE ASIC Platform - https://git.io/JinMo
<_whitenotifier-1> [nmigen] lethalbit reviewed pull request #644 commit - https://git.io/Jicmt
<_whitenotifier-1> [nmigen] lethalbit reviewed pull request #644 commit - https://git.io/Jicm8
<_whitenotifier-1> [nmigen] lethalbit reviewed pull request #644 commit - https://git.io/Jicmi
<_whitenotifier-1> [nmigen] lethalbit reviewed pull request #644 commit - https://git.io/JicYI
<_whitenotifier-1> [nmigen] whitequark reviewed pull request #644 commit - https://git.io/JicsN
Guest8057 has joined #nmigen
bvernoux has joined #nmigen
Guest8057 has quit [Quit: Client closed]
balrog has quit [Quit: Bye]
balrog has joined #nmigen
<_whitenotifier-1> [nmigen] olofk reviewed pull request #644 commit - https://git.io/JiCRe
<FL4SHK> How can I do an OR reduce in nMigen?
<FL4SHK> Also, does an OR reduce translate into an OR tree?
<vup> FL4SHK: do you just want `.any()`
<FL4SHK> vup: `.any()`?
<vup> some statement `.any()`
<vup> (a + b).any()
<FL4SHK> I need to do vector ORs
<vup> ah
<FL4SHK> I suppose it's still possible to use this
<FL4SHK> No, I guess not.
<FL4SHK> a `variable` would be helpful to have.
<FL4SHK> As it stands, it looks like I have to use a Python `list` that I add `Signal`s representing subsequent values of the "variable" to
<FL4SHK> then I can simply use `my_list[-1]` for the most recent value.
<d1b2> <zyp> what are you trying to do? my_list[0] | my_list[1] | …?
<FL4SHK> Okay so I was making two separate points.
<FL4SHK> a value representing `my_list[0] | my_list[1] | my_list[2]` would need to use a `for` loop if I don't know how many elements are in `my_list`
<d1b2> <zyp> I believe you can just treat it as a regular python expression and do functools.reduce(operator.or_, my_list)
<FL4SHK> Ah, I see.
<FL4SHK> Does it become something efficient when optimized by yosys?
<d1b2> <zyp> I don't know, but I would expect it to be equivalent to typing out the expression for a known length of the list
<d1b2> <zyp> I mean, functools.reduce(operator.or_, [a, b, c]) creates exactly the same expression as a | b | c as far as nmigen is concerned, they'll both invoke the OR-operator twice
<FL4SHK> I'd prefer it generate an `or` tree
<FL4SHK> I'm going to test it.
<d1b2> <zyp> I figure that's an optimization yosys should do, not nmigen
<FL4SHK> I agree.
<FL4SHK> If yosys doesn't make that optimization, I have to do it myself.
<dragonmux> also, if you have a list, you can pass it to Array to turn it into a nMigen object where you can then do .any() as suggested before to automate the generation of the | without having to map-reduce
<dragonmux> this assumes a list/tuple of Signal/Array/etc but givne what you're asking, that seems like a reasonable assumption to make
<FL4SHK> `Array` doesn't have an `any()` function.
<mwk> what is it that you actually want?
<dragonmux> Array() is a Value, and Value has .any()
<FL4SHK> Array() is not a Value
<mwk> a | b | c | d already has the right semantics, and after being put through synthesis, it will go through abc which will make it into a tree and rebalance it
<mwk> so I don't see any actual problem here
<FL4SHK> mwk: then that's what I need
<d1b2> <zyp> then what I suggested should work
<mwk> yosys itself has no pass for it, but abc is pretty good at this stuff
<dragonmux> ohh, Array is an abc MutableSequence.. our bad
<FL4SHK> When does it go through abc?
<mwk> yosys calls abc as a subprocess in later stages of the synth flow
<FL4SHK> Does it go through abc when I use Vivado for pnr?
<mwk> if you're using the plain nmigen platform? no
<mwk> but vivado also does its own optimizations, which should be able to optimize that stuff
<d1b2> <zyp> in that case I'd expect vivado to do the right thing
<FL4SHK> Okay.
<FL4SHK> I'll just do a reduce, then.
<d1b2> <zyp> I figure tree balancing would be among the lowest hanging fruits of optimizations
<dragonmux> ah, if all your operands have the same shape, you can use `Operator('r|', my_list)`!!
<dragonmux> it's equivilent to the .any() or reduce
<dragonmux> (think you're not technically supposed to instance this yourself, but that's not made clear)
<mwk> uh, there's a problem here
<mwk> nMigen lowers to yosys RTLIL, and yosys only supports multi-input OR for single-bit width
<mwk> (which is actually a unary operation on a bit vector, like in Verilog)
<dragonmux> that'd be the "you're not supposed to directly make that"
<dragonmux> mmm
<dragonmux> okie
<mwk> so if you have multi-bit width signals, you *cannot* compress a | b | c into a single operator
<dragonmux> it'd be `Operator('r|', (sig.any() for sig in my_list))` then right?
<dragonmux> assuming you want to fold all available bits into a single output bit
<mwk> no, Operator r| is always unary
<mwk> you'd have to Concat the signals into a single signal
<FL4SHK> My goal isn't to do a `Cat(signals)`
<mwk> you *cannot* have a r| with more than one operand
<dragonmux> ahhh, okie
<mwk> like... you'll just hit an assert failure if you manually construct such Operator anyway and attempt to use it
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #nmigen
lf has quit [Ping timeout: 258 seconds]
lf has joined #nmigen