<Evidlo>
I somehow missed -all when installing the package
<whitequark>
yeah it's not entirely obvious and the way the error is printed is not helpful
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
revolve has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
<d1b2>
<4o> how do i assign Array(Signal() for _ in range(n)) value to a Signal(n)
Bertl_zZ is now known as Bertl
<d1b2>
<4o> side note: only found this channel (and irc from this channel description) from people on digital design hq server. failed to find any ways to get help with nmigen on the web
<miek>
sig.eq(Cat(array))
<d1b2>
<4o> ok, thanks. another question. can i generate an inferred ram without using the memory instance?
jeanthom has joined #nmigen
<agg>
Depends on your synthesis tool's inference I guess, why do you need to?
<d1b2>
<4o> i want altera's and xilinx's block ram inferred for high capacity memory blocks
<agg>
Oh, I may have misunderstood what you meant by using the memory instance, have you seen nmigen.Memory?
<d1b2>
<4o> yeah. wonder if i can avoid nmigen.Memory
<agg>
Why do you want to avoid it? It should emit verilog which is inferred to the relevant block ram, or you can also add synthesis attributes to request it always be block ram
<d1b2>
<dub_dub_11> if you use more or less the same structure as you would in eg Verilog, you should infer RAM
<agg>
Yea, you could just write out your own memory the same way you would in verilog and the synthesis tool should hopefully infer it, but why not use Memory which is designed for this and should also be inferred?
<gatecat>
I don't think the pattern Array creates is at all likely to reliably infer memory
<gatecat>
if you want blockram you should definitely be using Memory
<d1b2>
<4o> tried to use Array for memory, got a 400-KB verilog, which was mapped to logic by ise
<agg>
Oh yea don't use Array
<gatecat>
that's exactly what I'd expect
<agg>
If you're going to use an nmigen primitive for memory you should be using Memory not Array
<agg>
I expect you could use some Signals to write something that looked like a memory and was inferred the right way? I've not tried though...
<gatecat>
maybe for a 1-bit wide memory; but wider memories require a Verilog array like `reg [x:0]mem[0:y]` and a Memory is the only way to create that
<d1b2>
<4o> ok, sad
<gatecat>
what is the reason here for not wanting to use Memory?
<agg>
Doesn't Memory create yosys-specific mem cells (which then get turned into that when emitting verilog)?
<gatecat>
yes, exactly
<agg>
got it
<d1b2>
<4o> i'm building a thing above nmigen. and i don't see a way to check if instance port is input or output
<d1b2>
<4o> can i do it?
<d1b2>
<4o> well also i hate mixing structural and behavioral code:)
<whitequark[m]>
nmigen does not have behavioral code, at least with the definition I consider useful (it does not "infer" anything in the base language)
<whitequark[m]>
re instance ports: check in which context? you can interrogate the Fragment which has this info
<d1b2>
<4o> i need to know ports direction on arbitrary instance. checking Fragment
<d1b2>
<4o> python for i in inst.ports: print(i, "dir = ", inst.ports[i]) ?
<d1b2>
<4o> or rather inst.iter_ports(None) as long as it yields?
<whitequark[m]>
something like that. note that Fragment is not guaranteed to be a stable API, though for the time being there are no planned breaking changes
<d1b2>
<4o> ok
<d1b2>
<4o> as for nMigen definition for "behavioral code" i suggest "it generates behavioral code"
<whitequark[m]>
nMigen always generates netlists
<whitequark[m]>
legacy toolchains do require an intermediate Verilog step but it is specific to those targets which use them
<d1b2>
<4o> yep. i'm trying to use nmigen to generated pieces of verilog to fit into hdl structural code. well that only matters for marginal people forcing strict quarantine for behavioral hdl
<whitequark[m]>
I'm not sure if I would recommend that but it is of course up to you
<d1b2>
<4o> ok, just to be sure. "intermediate verilog" souunds like you are mainly targeting yosys il?
jeanthom has quit [Ping timeout: 246 seconds]
nelgau has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
<whitequark[m]>
not exclusively yosys il, rtl formats in general
<whitequark[m]>
LoFIRRTL is one option for a future backend
jeanthom has joined #nmigen
Bertl is now known as Bertl_oO
<d1b2>
<4o> ok, noted
peepsalot has quit [Ping timeout: 264 seconds]
jeanthom has quit [Remote host closed the connection]
peepsalot has joined #nmigen
jeanthom has joined #nmigen
<d1b2>
<4o> is this python m.d.comb += next_channel[0].eq(iValid[0]) for i in range(1, port_num): with m.If((iValid[0:(i - 1)] == 0)): m.d.comb += next_channel[i].eq(iValid[i]) with m.Else(): m.d.comb += next_channel[i].eq(0) code for next_channel[0] = iValid[0] next_channel[1] = iValid[1] and not iValid[0] next_channel[2] = iValid[2] and not iValid[1] and not iValid[0] ... ?
emeb has joined #nmigen
<whitequark>
please use pastebin, your message is unreadable on the IRC side of the bridge
<d1b2>
<4o> ok
<whitequark[m]>
http:/paste.debian.net for example
<whitequark[m]>
we should just have that primitive in stdlib, it's been requested quite a bit
<whitequark[m]>
awygle: do you feel like taking a stab at implementing it?
<whitequark[m]>
then we can stop having everyone reinvent it from scratch
<whitequark[m]>
you can use back-to-back PriorityEncoder+PriorityDecoder but that tends to synthesize into something unpleasant, so a dedicated primitive works better
<d1b2>
<4o> the question is not in the encoder. is iValid slicing done right?
<whitequark[m]>
it looks right to me, but it's confusingly written
<d1b2>
<4o> looks like i'm getting assign \$2 = "" == 1'h0 for iValid[0:0] == 0 and assign \$5 = iValid[0] == 1'h0; for iValid[0:1] == 0. am i doing sometthing wrong in python? full code: https://paste.debian.net/1187683/
<whitequark[m]>
iValid[0:0] is an empty slice
<whitequark[m]>
i.e. a 0-bit value
<whitequark[m]>
the Verilog backend represents it as `""` which although unconventional is legal
<whitequark[m]>
(not actually sure why, I'd expect it to use `{0{1'b0}}` instead)
<d1b2>
<4o> true. python slicing differs from verilog one. thanks
<d1b2>
<4o> i did found it. btw in what way bit_select(offset, width) is different from [offset:width] slicing?
<whitequark[m]>
in bit_select, offset can be a (dynamic) value. in [], offset can only be a constant
<whitequark[m]>
also it's not [offset:width]
<whitequark[m]>
it's [start:stop]
<whitequark[m]>
which is why bit_select is also necessary: if `start` were dynamic, for exampe, the width, too, would have to be. but that's not representable as RTL
<d1b2>
<4o> ok. so bit_select is a barrel shifter of a kind?
<whitequark[m]>
sorta, yes
<whitequark[m]>
it can also be used on left-hand side of assignment
<whitequark[m]>
unlike a simple shift operation
<d1b2>
<4o> ok, good to know. thanks
<whitequark[m]>
in the backend, bit_select and word_select expand into case statements for every possible offset
bvernoux has joined #nmigen
<_whitenotifier-5>
[nmigen-boards] nono2357 opened issue #145: Add support for Nandland Go Board - https://git.io/Jqvtm
<_whitenotifier-5>
[nmigen-boards] whitequark commented on issue #145: Add support for Nandland Go Board - https://git.io/Jqvtz
pftbest has quit [Read error: Connection reset by peer]
<lkcl>
revolve_, whitequark[m] : we're doing a 180nm tape-out, with help from Staf Verhaegen (Chips4Makers,io) and coriolis2 by Sorbonne University (Jean-Paul Chaput)
<lkcl>
for expediency we're using litex (really wish there was something better)
<lkcl>
and i've created a suite of replacement Litex IO classes which expose the IO pads properly
<lkcl>
use of litex GPIOTristate is replaced by GPIOTristateASIC for example