05:48 <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.

05:51 <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

05:51 <a314> 's infrastructure if I want to use LiteX cores

05:58 <lsneff> Oh, looks like I have to build it myself

06:23 <a314> Well, never mind, didn't realize liteX was oMigen

06:23 <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?

06:23 <a314> (other than converting to verilog and doing the integration as an external module/Instance)

06:59 <whitequark> a314: no, you have to use nmigen.compat at the moment

06:59 <whitequark> lsneff: what platform are you on?

07:09 <lsneff> whitequark: macos. I got it working eventually, but the process could've been streamlined

07:15 <a314> hmm okay thanks, that makes things tricky

07:32 <whitequark> lsneff: hmm that should work with the wasm port, did it break for you? if yes we should fix it

07:32 <whitequark> https://pypi.org/project/wasmtime/#files has macos x86_64 wheels

07:33 <whitequark> a314: iirc the last time we discussed this with litex maintainers, the conclusion was to not use the compat layer

07:37 <a314> whitequark: yep saw that on GH, was mostly just wondering if there was a workaround

10:43 <_whitenotifier-f> [nmigen] kowalewskijan reviewed pull request #518 commit - https://git.io/JTSfS

10:43 <_whitenotifier-f> [nmigen] kowalewskijan reviewed pull request #518 commit - https://git.io/JTSfS

12:19 <_whitenotifier-f> [nmigen-boards] kowalewskijan reviewed pull request #117 commit - https://git.io/JTSOY

14:54 <lsneff> whitequark: I think that worked, but maybe not for the published one and only for the one from git?

14:54 <lsneff> Also, I had to install nmigen_boards from github, the published home brew one is out of date

15:40 <lsneff> Is there anyway to use an existing core/library that's defined in verilog without porting it to nmigen?

15:41 <tpw_rules> yeah, use an Instance

15:41 <tpw_rules> you can use it to instantiate an arbitrary verilog module

15:42 <tpw_rules> not sure where good docs are

15:42 <lsneff> Awesome thanks. I'll use that to access a PLL, which I believe nmigen doesn't support yet

15:43 <tpw_rules> lsneff: https://github.com/tpwrules/tasha_and_friends/blob/eventuator/tasha/gateware/icebreaker/pll.py

15:45 <lsneff> tpw_rules: That's fantastic, exactly what I needed, thank you

15:48 <Lofty> Well, the "support" bit is basically just nmigen using Instance itself

15:53 <whitequark> lsneff: oh yeah, it only works with git. the published version is fairly out of date; the next release is almost done though

15:54 <lsneff> When nmigen becomes more mature, is there a plan to expand the number of built-in primitives/modules?

15:54 <awygle> there are plans to expand nmigen-stdio and nmigen-soc

15:55 <awygle> nmigen.lib is going to have a higher bar but I'd assume would probably be expanded as well

15:56 <lsneff> Ah, I see.

15:57 <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.

16:03 <lkcl> lsneff: we've started on CORDIC (and all sorts of stuff) :)

16:04 <lkcl> https://git.libre-soc.org/?p=ieee754fpu.git;a=tree;f=src/ieee754/cordic;hb=HEAD

16:05 <lkcl> i recall whitequark mentioning that she hoped that more complex libraries / systems would build up on top of nmigen

16:05 <lkcl> for example, a system which has strong type checking could be developed

16:06 <lkcl> but it would not be part *of* nmigen, it would *use* nmigen

16:07 <lkcl> fascinating article by dan gisselquist (zipcpu)

16:08 <lkcl> https://zipcpu.com/formal/2018/05/31/clkswitch.html

16:16 <lsneff> Oh, that's interesting, a soc implemented in nmigen?

16:19 <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.

16:36 <lkcl> well the ieee754fp library is designed to be independent

16:36 <lkcl> (useable by anyone)

16:37 <lkcl> yes it's one of many nmigen socs, the first significant one was minerva.

16:37 <lkcl> https://github.com/lambdaconcept/minerva

16:38 <lkcl> that's integrated into litex btw

16:39 <lkcl> then also, i don't know if you're familiar with chisel3's "io" library?

16:39 <lkcl> we created nmutil as a sort-of-similar concept to that

16:39 <lkcl> https://git.libre-soc.org/?p=nmutil.git;a=tree;f=src/nmutil;hb=HEAD

16:40 <lkcl> so there's things like "pipeline building blocks" for doing different types of pipeline synchronisation (buffered, unbuffered)

16:40 <lkcl> and also an actual port of chisel3 io "queue" class

16:41 <lkcl> there i actually dropped it on top of the nmigen FIFOInterface so it has exactly the same API and behaviour

16:41 <_whitenotifier-f> [nmigen-boards] kowalewskijan synchronize pull request #117: Add quickfeather board - https://git.io/JTYG0

16:42 <_whitenotifier-f> [nmigen-boards] kowalewskijan reviewed pull request #117 commit - https://git.io/JTSSP

17:04 <lsneff> lkcl: Awesome, I'll browse through all the source for that.

17:04 <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.

17:46 <awygle> also critical features.

17:46 <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

17:48 <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.

17:49 <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

17:50 <whitequark> yup

17:59 <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)

18:00 <lkcl> that's entirely tax-deductible so is equivalent to earning 2x that as "salary"

18:00 <whitequark> that last part is a serious problem

18:00 <whitequark> (address in EEC)

18:01 <lkcl> or a home address. i have some spare people that might be able to be part of the team, to help with that

18:02 <lkcl> it's a silly thing because NLnet's original grant was from EU Horizon 2020

18:02 <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)

18:02 <lkcl> but i was in... mmm... Den Haag at the time, then moved to Taiwan etc. etc.

18:04 <lkcl> so jeanthom or any of the other EU contributors to nmigen could apply, *even if* they are physically outside of the EU

18:11 <_whitenotifier-f> [nmigen] whitequark reviewed pull request #518 commit - https://git.io/JTSAU

18:11 <_whitenotifier-f> [nmigen] whitequark closed pull request #518: Quicklogic Quickfeather integration - https://git.io/JTMS4

18:11 <_whitenotifier-f> [nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JTSAk

18:11 <_whitenotifier-f> [nmigen/nmigen] kowalewskijan b88009b - vendor.quicklogic: fix toolchain nomenclature

18:11 <_whitenotifier-f> [nmigen/nmigen] kowalewskijan 8fe319f - vendor.quicklogic: utilize internal SoC clock in EOS-S3

18:11 <_whitenotifier-f> [nmigen] whitequark commented on pull request #518: Quicklogic Quickfeather integration - https://git.io/JTSAI

18:12 <_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±14] https://git.io/JTSAm

18:12 <_whitenotifier-f> [nmigen/nmigen] whitequark 9ffc2e2 - Deploying to gh-pages from @ 8fe319f065807f421b092e7ffb8b90748512bf8c 🚀

18:37 <awygle> whitequark: i never connected with you when you pinged me the other day btw

18:37 <awygle> did you still want to talk about whatever it was?

18:38 <whitequark> awygle: yes

18:38 <whitequark> ValueCastable PR and I2CResource

18:38 <awygle> saw the requests on VC PR

18:39 <awygle> I2CResource is on the list for this weekend

18:40 <whitequark> cool, thanks!

20:53 <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