ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting TBD
nfbraun has quit [Quit: leaving]
FFY00 has joined #nmigen
jjeanthom has joined #nmigen
lf_ has quit [Ping timeout: 264 seconds]
lf has joined #nmigen
jjeanthom has quit [Ping timeout: 260 seconds]
pftbest has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 246 seconds]
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
Bertl_oO is now known as Bertl_zZ
PyroPeter_ has joined #nmigen
PyroPeter_ is now known as PyroPeter
PyroPeter has quit [Ping timeout: 264 seconds]
Lord_Nightmare has quit [Ping timeout: 265 seconds]
slan has quit [Quit: Lost terminal]
Lord_Nightmare has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
pftbest has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
jjeanthom has joined #nmigen
jjeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
bvernoux has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
nfbraun has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Bertl_zZ is now known as Bertl
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
chipmuenk has joined #nmigen
emeb_mac has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
Chips4Makers has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
jeanthom has joined #nmigen
<agg> with a very slight variant nextpnr installed, i can now go from nmigen ALU54/MULT18 instances to a working MAC on the ECP5 with no manual tweaking, yay
<whitequark> very nice
<whitequark> though I kinda assumed that already worked
<agg> yes, me too, some days ago
<whitequark> hahah
<Sarayan> reality happened?
<agg> i was expecting to plop down the instances and once i'd figured out which BELs to assign to (the hard part, since npnr doesn't have anything to pack them yet), it would work after that :p
<agg> obviously this expectation was tempered by repeated warning that it probably wouldn't
GenTooMan has quit [Quit: Leaving]
jeanthom has quit [Ping timeout: 256 seconds]
GenTooMan has joined #nmigen
jeanthom has joined #nmigen
<agg> anyone have any guesses why assigning a signal in a comb block leads leads to yosys-generated verilog containing "1'hx = 1'hx;" (which upsets e.g. diamond)? https://dpaste.com/4YVW862YL
<agg> I'm sort of gathering that the verilog_initial_trigger should maybe have somehow been deleted before it made it to the verilog
<whitequark> no, it's uhm
<whitequark> it's called verilog_initial_trigger because it needs to be present in verilog.
<whitequark> or rather, it *used* to need to be present
<whitequark> it no longer does because write_verilog handles that
<whitequark> please file a bug, there's a condition in back.verilog to handle this but I guess some case slipped through?
<_whitenotifier> [nmigen] adamgreig opened issue #581: $verilog_initial_trigger leading to `1'hx = 1'hx;` in generated Verilog - https://git.io/JtZsW
<agg> hmm, updating yosys just in case, it's gotten a bit older than I thought
<_whitenotifier> [nmigen] adamgreig commented on issue #581: $verilog_initial_trigger leading to `1'hx = 1'hx;` in generated Verilog - https://git.io/JtZsP
<_whitenotifier> [nmigen] adamgreig closed issue #581: $verilog_initial_trigger leading to `1'hx = 1'hx;` in generated Verilog - https://git.io/JtZsW
<agg> yep, nevermind
<awygle> has anyone written a draft of like, "here's best practices for distributing an nmigen module"?
<awygle> I am not aware of one but just wanna check if I missed something
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<agg> i should talk to my boss about maybe releasing some, i certainly have thoughts on the matter anyway
<agg> not aware of any such draft though
<_whitenotifier> [nmigen] whitequark commented on issue #581: $verilog_initial_trigger leading to `1'hx = 1'hx;` in generated Verilog - https://git.io/JtZG2
<awygle> I'd be interested in hearing your thoughts, if you've got a second to lay them our
chipmuenk has quit [Quit: chipmuenk]
<agg> trying to pick apart which thoughts might be interesting. a lot is basically normal python packaging stuff (which of course is its own book), and a lot is module design style (naming of signals, using attributes for signals and function parameters for module parameters, documentation conventions, handshaking signals/bus interfaces)
<agg> sphinx can be compelled to make reasonable documentation including describing signals, I use poetry for managing the package metadata/dependencies/virtualenv
<agg> i guess once you have a style guide for writing the modules, and follow the latest python packaging best practices, the actual modules are not that different to distributing other python objects
<awygle> ok cool, thanks
<awygle> taht basically matches my thoughts, except the bit about sphinx and poetry, i'm not familiar with those at all
<agg> A style guide for nmigen modules is a related thing that could be really useful, independent of whether they're being distributed
<agg> Poetry is the latest trendy competitor in the "manage python packaging" space; I like that it can replace setup.py for most cases and works for both binaries and libraries
<agg> Somewhat further down my to-do list is packaging and distributing my nmigen rmii and rgmii interfaces, which would also be a nice example of the docs and poetry and testing and so forth
<agg> But... time etc
<modwizcode> ooo rmii and rgmii interfaces in nmigen would be nice :)
<whitequark> agg: opinion on having those in nmigen-soc, eventually?
<whitequark> we need streams first, but you already know that
<agg> Would be delighted for them to end up in nmigen-*
<whitequark> sweet
<whitequark> I really need to onboard more contributors and work on some (more) formal processes
<agg> I also have a cool crc module that might be useful somewhere but it's technically works'
<agg> Parameterized by the standard Rockwell/Williams model params so does basically any crc in existence
<whitequark> nice
<whitequark> that *probably* goes to nmigen.lib?
<whitequark> using a Rust analogy, it's not essential but it's something you'd find in libcore
<agg> Yea, that's what I was thinking
<agg> Or even like nmigen-contrib, idk
<agg> Just helpful things that it makes sense to implement once and make available
jeanthom has quit [Ping timeout: 264 seconds]
<whitequark> -contrib implies that it's unsupported
<whitequark> sometimes you just feel like haing a dumping ground for random stuff, but CRC is everywhere
<whitequark> you wouldn't have a string library in -contrib would you
<agg> Yep, fair
<modwizcode> I tried to understand the streams abstraction but I couldn't understand how it worked/what it was supposed to do
<awygle> we actually discussed CRC at one point
<awygle> i think i might have said i was going to submit it
<awygle> >_>
<agg> awygle: the one from Harmon Instruments?
<awygle> yes
GenTooMan has quit [Quit: Leaving]
<agg> Mine's a very similar design mathematically, just also wraps the crap you have to do like bit reversing in/out, xor in/out, etc
<awygle> i'd be perhaps slightly troubled if your crc module used novel mathematics :)
<awygle> but yeah i have no particular horse in the race, just adding another tally to "things i said i'd do and then didn't because *gestures broadly*"
<agg> Hmm, there's a lot of ways to skin this cat when you want a word-parallel crc
<agg> But yes it's nothing extremely exciting. Though I did also make a bram table based version which uses fewer luts if you have bram(s) spare... not sure it really works out much better though
<lkcl> agg: ah you're doing RGMII? or you've already done them? where, where!
<lkcl> agg: you'll like this - i'm just putting in an NLnet grant request for a Gigabit router in nmigen
<lkcl> HA! cool!
futarisIRCcloud has joined #nmigen
<lkcl> would you be interested to like, y'know, receive some $ donations for working on that?
<lkcl> we also need a DMA engine, so that packets can be routed between network interfaces without the main CPU having to do it
<lkcl> there's a litex DMA engine been recently added to litepcie
<agg> lkcl: I'd have to think about it... sadly they can't grant time instead of money :p I don't expect the rgmii interface would be the hard part in any event!
<futarisIRCcloud> A gigabit router would be useful in a few other contexts...
<lkcl> agg: true. time-stretching/compaction machines would truly be valuable lol
<lkcl> futarisIRCcloud, indeed. it was staf verhaegen's idea. we'd like to include USB-ULPI as well, and some crytpo-primitives. all in nmigen.
<awygle> i am generically open to contract work, assuming things line up properly
<agg> You found the RMII, though the first version predates nmigen iirc and I'd probably do it a bit differently today, not sure if I've put the rgmii online anywhere yet but it's very simple
<awygle> to anybody who might have such opportunities
<lkcl> awygle: nice. we can't do contracts per se, we can do "oh look this work got completed here's a no-obligation payment from NLnet"
<lkcl> which amounts to the same thing :)
<lkcl> agg: good to hear - if you do make it available do let me know, i keep a curated list here https://libre-soc.org/shakti/m_class/RGMII/
<agg> Will do
<lkcl> it would save having to replicate your work, which is always appreciated, saving time
<lkcl> awygle: if you're up for not-a-contract-but-still-being-paid-as-if-you-were? :)
<awygle> i'd want to discuss details pretty carefully in such an arrangement
<agg> I think you'll be a bit underwhelmed, it's basically just feeding a byte at a time to/from four ddr registers with an attached state machine for preamble/add/frame/FCS and the CRC engine hanging off the side
<lkcl> awygle: sure. i wrote an FAQ about it - https://libre-soc.org/nlnet/#faq - if you've any questions after that, do ask.
<agg> If anything it was much simpler than RMII since you don't need to do the dibit serialisation or crs_dv deser
<awygle> oh, nice
<lkcl> agg: sounds great to me. i know not a lot about RMII / RGMII other than when i had to design a PHY in to a PCB with GbE on it
<lkcl> did you add a wishbone interface to it as well?
<agg> No, in this case it streamed to/from a bram
<lkcl> ahh. oh. that's interesting. and also,,,
* lkcl thinks
<lkcl> actually that's extremely good and pretty much what i'd expect an ethernet router-thing to do anyway
<lkcl> take in packets into an SRAM, send them out again...
<agg> Handy if you want to cross clock domains asap after the rgmii too
<lkcl> and then there could be a wishbone interface on the SRAM
<lkcl> nice
<agg> I usually have a fifo carrying lengths and start addresses and some way of ensuring you don't overflow the memory
<agg> Seems to work fairly well
<lkcl> ohh going to need a linux kernel driver. musn't forget that
* lkcl just reminding myself of the task list for the grant request :)
nengel has joined #nmigen