ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting November 2nd
esden has quit [Read error: Connection reset by peer]
esden has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
GenTooMan has quit [Ping timeout: 260 seconds]
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
alexhw has quit [Ping timeout: 264 seconds]
peeps has quit [Ping timeout: 264 seconds]
alexhw has joined #nmigen
peepsalot has joined #nmigen
DaKnig has joined #nmigen
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
lsneff has joined #nmigen
<lsneff> I'm having issues getting nmigen to find yosys. Should `pip3 install --upgrade nmigen[builtin-yosys]` be enough? I also tried `pip3 install nmigen-yosys` to install the wasm port.
<a314> what's the difference between nmigen-soc and litex for things like wishbone Records? are they designed to be cross-compatible or should I use LiteX
<a314> 's infrastructure if I want to use LiteX cores
<lsneff> Oh, looks like I have to build it myself
<a314> Well, never mind, didn't realize liteX was oMigen
<a314> in that case, is there any clean way to integrate Migen code into nMigen code without having to convert the Migen code to use nmigen.compat?
<a314> (other than converting to verilog and doing the integration as an external module/Instance)
_whitelogger has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<whitequark> a314: no, you have to use nmigen.compat at the moment
<whitequark> lsneff: what platform are you on?
<lsneff> whitequark: macos. I got it working eventually, but the process could've been streamlined
<a314> hmm okay thanks, that makes things tricky
<whitequark> lsneff: hmm that should work with the wasm port, did it break for you? if yes we should fix it
<whitequark> has macos x86_64 wheels
<whitequark> a314: iirc the last time we discussed this with litex maintainers, the conclusion was to not use the compat layer
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
<a314> whitequark: yep saw that on GH, was mostly just wondering if there was a workaround
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
Asu has joined #nmigen
<_whitenotifier-f> [nmigen] kowalewskijan reviewed pull request #518 commit -
<_whitenotifier-f> [nmigen] kowalewskijan reviewed pull request #518 commit -
_whitelogger has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #nmigen
<_whitenotifier-f> [nmigen-boards] kowalewskijan reviewed pull request #117 commit -
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
lambda has quit [Quit: WeeChat 2.9]
Asuu has joined #nmigen
Asu has quit [Ping timeout: 264 seconds]
lambda has joined #nmigen
GenTooMan has joined #nmigen
<lsneff> whitequark: I think that worked, but maybe not for the published one and only for the one from git?
<lsneff> Also, I had to install nmigen_boards from github, the published home brew one is out of date
Asu has joined #nmigen
Asuu has quit [Ping timeout: 268 seconds]
<lsneff> Is there anyway to use an existing core/library that's defined in verilog without porting it to nmigen?
<tpw_rules> yeah, use an Instance
<tpw_rules> you can use it to instantiate an arbitrary verilog module
<tpw_rules> not sure where good docs are
<lsneff> Awesome thanks. I'll use that to access a PLL, which I believe nmigen doesn't support yet
<lsneff> tpw_rules: That's fantastic, exactly what I needed, thank you
<Lofty> Well, the "support" bit is basically just nmigen using Instance itself
<whitequark> lsneff: oh yeah, it only works with git. the published version is fairly out of date; the next release is almost done though
<lsneff> When nmigen becomes more mature, is there a plan to expand the number of built-in primitives/modules?
<awygle> there are plans to expand nmigen-stdio and nmigen-soc
<awygle> nmigen.lib is going to have a higher bar but I'd assume would probably be expanded as well
<lsneff> Ah, I see.
emeb has joined #nmigen
<lsneff> Having built in modules for cordic and all sorts of stuff would be great, but that's more a responsibility of the larger ecosystem, I suppose.
<lkcl> lsneff: we've started on CORDIC (and all sorts of stuff) :)
<lkcl> i recall whitequark mentioning that she hoped that more complex libraries / systems would build up on top of nmigen
<lkcl> for example, a system which has strong type checking could be developed
<lkcl> but it would not be part *of* nmigen, it would *use* nmigen
<lkcl> fascinating article by dan gisselquist (zipcpu)
jeanthom has joined #nmigen
<lsneff> Oh, that's interesting, a soc implemented in nmigen?
<lsneff> I understand that's part of a much larger system, but a library of composable nmigen models that do things like that would be fantastic.
alexhw has quit [Remote host closed the connection]
alexhw has joined #nmigen
<lkcl> well the ieee754fp library is designed to be independent
<lkcl> (useable by anyone)
<lkcl> yes it's one of many nmigen socs, the first significant one was minerva.
<lkcl> that's integrated into litex btw
<lkcl> then also, i don't know if you're familiar with chisel3's "io" library?
<lkcl> we created nmutil as a sort-of-similar concept to that
<lkcl> so there's things like "pipeline building blocks" for doing different types of pipeline synchronisation (buffered, unbuffered)
<lkcl> and also an actual port of chisel3 io "queue" class
<lkcl> there i actually dropped it on top of the nmigen FIFOInterface so it has exactly the same API and behaviour
<_whitenotifier-f> [nmigen-boards] kowalewskijan synchronize pull request #117: Add quickfeather board -
<_whitenotifier-f> [nmigen-boards] kowalewskijan reviewed pull request #117 commit -
jeanthom has quit [Ping timeout: 260 seconds]
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 -]
feldim2425 has joined #nmigen
<lsneff> lkcl: Awesome, I'll browse through all the source for that.
<lsneff> I'll need to eventually work on a lock-in amplifier that runs on my fpga, so I'd be happy to donate that to whatever nmigen standard library shows up that fits that kind of thing.
<awygle> also critical features.
<awygle> as usual the limiting factor is time/hands. nmigen-stdio needs a standard interface for data flow. it's easy for everybody to whip up their own that fits their specific use case (and i have done that myself), but anything that goes into an "official" nmigen repository becomes a maintenance burden, so we need to make sure it's designed properly for everybody's use cases. meanwhile we also have a lot of requests for things like cxxsim, which are
<awygle> hands becomes difficult too because if not careful it's just more work for the maintainers (which is just wq right now, at least on nmigen-core). i personally am probably just barely in the black on that front, if at all.
<awygle> all of which is to say - definitely a priority, not the #1 priority right now, but that's not out of a lack of interest just practicality
<whitequark> yup
<lkcl> awygle: NLnet is very interested to receive a proposal to fund nmigen development work up to EUR 50,000, if that would help at all. anyone can be part of it (it just requires one person to have an address in the EEC)
<lkcl> that's entirely tax-deductible so is equivalent to earning 2x that as "salary"
<whitequark> that last part is a serious problem
<whitequark> (address in EEC)
<lkcl> or a home address. i have some spare people that might be able to be part of the team, to help with that
<lkcl> it's a silly thing because NLnet's original grant was from EU Horizon 2020
<lkcl> they don't have to *actively* live there. for example my home address i list as being in scotland (it's where all my letters are sent)
<lkcl> but i was in... mmm... Den Haag at the time, then moved to Taiwan etc. etc.
<lkcl> so jeanthom or any of the other EU contributors to nmigen could apply, *even if* they are physically outside of the EU
<_whitenotifier-f> [nmigen] whitequark reviewed pull request #518 commit -
<_whitenotifier-f> [nmigen] whitequark closed pull request #518: Quicklogic Quickfeather integration -
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-f> [nmigen/nmigen] kowalewskijan b88009b - vendor.quicklogic: fix toolchain nomenclature
<_whitenotifier-f> [nmigen/nmigen] kowalewskijan 8fe319f - vendor.quicklogic: utilize internal SoC clock in EOS-S3
<_whitenotifier-f> [nmigen] whitequark commented on pull request #518: Quicklogic Quickfeather integration -
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±14]
<_whitenotifier-f> [nmigen/nmigen] whitequark 9ffc2e2 - Deploying to gh-pages from @ 8fe319f065807f421b092e7ffb8b90748512bf8c 🚀
jeanthom has joined #nmigen
<awygle> whitequark: i never connected with you when you pinged me the other day btw
<awygle> did you still want to talk about whatever it was?
<whitequark> awygle: yes
<whitequark> ValueCastable PR and I2CResource
<awygle> saw the requests on VC PR
<awygle> I2CResource is on the list for this weekend
<whitequark> cool, thanks!
shizoor has joined #nmigen
shizoor has quit [Quit: Going offline, see ya! (]
emeb_mac has joined #nmigen
korken89 has joined #nmigen
<bsmt> dumb question: is there something special i have to do to get the default_rst pin to reset all of my logic? I was assuming it would just automagically reset my signals but my design does not appear to be doing that
korken89 has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 258 seconds]
electronic_eel has quit [Ping timeout: 268 seconds]
electronic_eel has joined #nmigen
jeanthom has joined #nmigen
moony has quit [Remote host closed the connection]
moony has joined #nmigen
jeanthom has quit [Ping timeout: 268 seconds]