whitequark[m] changed the topic of #nmigen to: nMigen hardware description language · code https://github.com/nmigen · logs https://freenode.irclog.whitequark.org/nmigen
<_whitenotifier-5> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JtjhE
<_whitenotifier-5> [YoWASP/nextpnr] whitequark ba83221 - Update dependencies.
whitequark[m] has quit [Ping timeout: 240 seconds]
whitequark[m] has joined #nmigen
<_whitenotifier-5> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JqeeX
<_whitenotifier-5> [YoWASP/yosys] whitequark 9a530f4 - Update dependencies.
aquijoule__ has joined #nmigen
aquijoule_ has quit [Ping timeout: 264 seconds]
lf has quit [Ping timeout: 264 seconds]
lf has joined #nmigen
oter has joined #nmigen
pftbest has quit [Remote host closed the connection]
oter has quit [Quit: Textual IRC Client: www.textualapp.com]
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 240 seconds]
<GenTooMan> is there a suggested method from within nmigen to find the version of nmigen and yosys?
lkcl has quit [Ping timeout: 240 seconds]
Degi_ has joined #nmigen
lkcl has joined #nmigen
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #nmigen
balrog has quit [Ping timeout: 264 seconds]
nelgau_ has quit [Ping timeout: 240 seconds]
pftbest has joined #nmigen
balrog has joined #nmigen
pftbest has quit [Ping timeout: 260 seconds]
Bertl_oO is now known as Bertl_zZ
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 245 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
slan has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
pftbest has joined #nmigen
smkz has quit [Quit: smkz]
smkz has joined #nmigen
jeanthom has joined #nmigen
<Evidlo> GenTooMan: nmigen is a python package, so you can get its version with 'pip freeze'
<Evidlo> I tried testing the ECP5 toolchain, but I'm getting an error: https://termbin.com/geln
<Evidlo> Is this maybe because I'm using the yowasp toolchain? I'm currently building nextpnr myself, but it will take a while
<gatecat> Try using yowasp yosys too, it looks like your native Yosys version is too old
<Evidlo> It seems to have gotten a bit further, but a new error: https://termbin.com/tv45
<Evidlo> anything I should try?
<gatecat> It looks like a possible issue in the wasm build but I don't know what
<whitequark[m]> I'll look into it soon
jeanthom has quit [Ping timeout: 265 seconds]
<whitequark> Evidlo: unfortunately I cannot reproduce, try `pip list | grep yowasp`
<whitequark> and post the results
<Evidlo> yowasp-nextpnr-ecp5 0.0.post3192.dev91
<Evidlo> yowasp-yosys 0.9.post5278.dev116
<whitequark> try `pip install -U yowasp-nextpnr-ecp5-all`
<Evidlo> it's working now! thanks
<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]> * http://paste.debian.net for example
<d1b2> <4o> https://pastebin.com/DCctNg4t question is inside for convenience
<whitequark[m]> is this a priority encoder?
<d1b2> <4o> yep, with onehot input
<whitequark[m]> oh right, so more of a priority picker
<whitequark[m]> back-to-back nmigen.lib.coding.PriorityEncoder+PriorityDecoder
<d1b2> <4o> huh, with parallel input
<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
<whitequark[m]> check out the https://nmigen.info/nmigen/latest/lang.html#operators section for more useful notes on the differences
<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]
pftbest has joined #nmigen
Degi has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
Degi has joined #nmigen
lkcl has quit [*.net *.split]
zignig has quit [*.net *.split]
MadHacker has quit [*.net *.split]
zignig has joined #nmigen
MadHacker has joined #nmigen
lkcl has joined #nmigen
oter has joined #nmigen
slan has quit [Quit: Connection closed]
aquijoule__ has quit [Ping timeout: 256 seconds]
<revolve> whitequark[m]: what's the best way to learn chip design?
<whitequark[m]> what is "chip design" here? ASIC design?
<revolve> Multicore CPU/SoC design
<whitequark[m]> no idea, I haven't done any multicore CPUs
revolve_ has joined #nmigen
<revolve_> sry, whitequark, I disconnected
<revolve_> Thanks
emeb_mac has joined #nmigen
<revolve_> nmigen outputs Verilog amirite?
<whitequark[m]> it currently outputs RTLIL (Yosys' IR), which can be converted to Verilog among other options
revolve has quit [Read error: Connection reset by peer]
<revolve_> Thanks.
<whitequark[m]> FOSS toolchain based synthesis flows don't use intermediate Verilog
<revolve_> Right
<revolve_> Have you ever had a design taped out?
<whitequark[m]> no
<revolve_> OK NP
<revolve_> Thanks whitequark[m]
chipmuenk has quit [Quit: chipmuenk]
richbridger has joined #nmigen
phire has quit [*.net *.split]
phire has joined #nmigen
bvernoux has quit [Read error: Connection reset by peer]
bvernoux has joined #nmigen
revolve_ has quit [*.net *.split]
ronyrus has quit [*.net *.split]
gekh has quit [*.net *.split]
trabucayre has quit [*.net *.split]
revolve_ has joined #nmigen
trabucayre has joined #nmigen
gekh has joined #nmigen
ronyrus has joined #nmigen
<d1b2> <dub_dub_11> someone is currently taping out an nmigen design on 180nm iirc
<lkcl> agg: daveshah posted something about how to override the default yosys-specific mem cell behaviour
<lkcl> agg ^ gatecat ^
emeb has quit [Quit: Leaving.]
<lkcl> hey that's funny, you've already commented on the stackoverflow find, gatecat :)
<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
<lkcl> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=3224f6d1b1ceb3a441561f726352d44c9f8395c2;hb=c9f3eb6eca6ef3e7de44e8cb9dd01a84ec3d55b7#l101
<lkcl> everything has to bring out a triplet "i, o, oe" where normally for FPGA you'd not have to do that
<lkcl> Staf's C4M-JTAG nmigen module allows us to do boundary scanning entirely in nmigen
<lkcl> https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;h=fe6e26b7285125d71fde0e5f9c5e033c6881011f;hb=c71b674a067a52a26e96242c148c09999f237826#l308
jeanthom has quit [Ping timeout: 264 seconds]
Raito_Bezarius has joined #nmigen