ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 12th
<carlomaragno> Good night kid people, thanks for your help
<lkcl> carlomaragno: cool!
<lkcl> night carlomaragno
<awygle> whitequark: nice code goes a long way tbh. i've learned a ton just from poking around the nmigen codebase.
<awygle> although a lot of that is that we don't have a terribly high overlap in our most comfortable domains, i think.
<awygle> the high clarity of your style makes it easy to pick things up
<awygle> it's extra interesting too because of the dual meta levels - the nmigen codebase is clean but it's also to allow others to write clean code _in_ nmigen
<_whitenotifier-f> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±2]
<_whitenotifier-f> [YoWASP/yosys] whitequark db12c68 - Update dependencies.
<cr1901_modern> whitequark: Pedantic q, but is the Fragment.get() here required (because rtlil convert will call it internally) or not?
<cr1901_modern> Not that it harms anything to keep it
<cr1901_modern> Asking b/c I just spent 20 minutes looking over the formal code and thought "I don't remember having to pass a fragment to .convert".
<awygle> oh no, FHDLTestCase :P
<cr1901_modern> Non-FHDLTestCase example (pysim.Simulator also calls Fragment.get())
<d1b2> <dub_dub_11> Heartwarming conversation :D I will now tell myself to write better comments and then maintain it for about two days
emeb has quit [Quit: Leaving.]
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
<d1b2> <Qyriad> Yeah it's probably a bit easier to get yourself to do that when the codebase you're contributing to is already like that and you want to match the existing style
hitomi2509 has joined #nmigen
chipmuenk has joined #nmigen
djr has joined #nmigen
djr has quit [Remote host closed the connection]
emeb_mac has quit [Quit: Leaving.]
oab9e2 has joined #nmigen
oab9e2 has quit []
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
chipmuenk has quit [Quit: chipmuenk]
Asu has joined #nmigen
Asu has quit [Remote host closed the connection]
<whitequark> cr1901_modern: that's necessary to inject platform="formal"
hitomi2509 has quit [Read error: Connection reset by peer]
hitomi2509 has joined #nmigen
chipmuenk has joined #nmigen
emeb_mac has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
chipmuenk has quit [Quit: chipmuenk]
Asu has joined #nmigen
hitomi2509 has quit [Quit: Nettalk6 -]
<FL4SHK> Hm. It seems that my test code doesn't work in pysim.
<FL4SHK> I added a clock like (I think) vup said
<FL4SHK> m.d.sync += bus.busy.eq(0b1)
<FL4SHK> doesn't seem to work
<vup> what does not work?
<FL4SHK> seeing `bus.busy` being set to 1
<FL4SHK> it only seems to stay at 0
<vup> I think this needs way more context
<FL4SHK> just a bit
<FL4SHK> brb
<tpw_rules> is something else setting bus.busy?
<miek> the last code you posted had a bunch of `yield Delay()` statements, but you probably want `yield Tick()` (or just `yield` for short)
chipmuenk has joined #nmigen
<cr1901_modern> whitequark: Cool, what about in pysim.Simulator?
<cr1901_modern> I'm trying to figure out "when is it appropriate to call Fragment.get()" _before_ passing an nmigen design to a function that simulates/generates output/does formal/etc.
aa has joined #nmigen
aa is now known as Guest54668
<Guest54668> has nmigen ever been used in any ASIC tapeouts?
<whitequark> not to my knowledge
<whitequark> lkcl is working on it, i think
<whitequark> cr1901_modern: oh
<whitequark> cr1901_modern: Fragment.get() calls elaborate(). that's about it. it's a different function because it does a few more checks but fundamentally Fragment.get(x, platform=y) is just x.elaborate(platform=y)
<cr1901_modern> ack... thanks
<cr1901_modern> afaict,Fragment.get() calls elaborate in a loop; I think if I were to write docs on that alluding to internals I would say "Fragment.get() is fundamentally doing repeated calls to elaborate until certain conditions are met."
<whitequark> well, it ensures you get a fragment from an elaboratable
<whitequark> but yes, it's a part of the public API that you can return an elaboratable from elaborate()
emeb has joined #nmigen
emeb_mac has joined #nmigen
Guest54668 has quit [Remote host closed the connection]
<lkcl> whitequark: yes, using litex by defining a platform that has its bi-directional pins come out with a completely different type of IO configuration from FPGAs.
<lkcl> where normally you just connect to the FPGA pad and it's a single pin, we have to bring out the xxx_i, xxx_o and xxx_oe triplet
<lkcl> then in coriolis2 wire each of those up to the actual GPIO pads which have their own cell library, pxlib
<lkcl> which does remind me that it would be nice - helpful - to have nmigen-boards (and peripherals in general) "recognise" this difference
<lkcl> right now i've had to duplicate quite a lot of peripheral code in litex because the pin-mappings (with the assumption that it'll be for an FPGA platform) are usually tightly integrated into the actual peripheral
<lkcl> there's no rush on that though, because we had to pick litex rather than nmigen-boards, because it's a lot less work
<lkcl> i would like to see nmigen-boards grow to the point where we don't have to use litex though.
<whitequark> uh, what?
<whitequark> i have no idea what you're talking about
<whitequark> it seems like you're referring to some previous discussion, which i have not seen
<_whitenotifier-f> [nmigen] alanvgreen commented on issue #425: Support for PLL primitives -
<lkcl> <Guest54668> has nmigen ever been used in any ASIC tapeouts
<lkcl> sorry, didn't refer back to that
<lkcl> that was the context. and we had to use litex to create the peripherals and the Pins.
<FL4SHK> miek: so I had `yield Tick()`
<FL4SHK> tpw_rules: no, nothing else is setting `bus.busy`
<lkcl> Pin in has "i/o/oe" (and many more capabilities which is fantastic)
<FL4SHK> oh
<FL4SHK> here's the problem
chipmuenk has quit [Quit: chipmuenk]
<FL4SHK> I had old debug stuff left
<lkcl> however one of the things that distinguishes an ASIC from an FPGA platform is: you *must* bring those triplets all the way out to the actual pads.
<_whitenotifier-f> [nmigen] whitequark commented on issue #425: Support for PLL primitives -
<_whitenotifier-f> [nmigen] whitequark commented on issue #425: Support for PLL primitives -
<whitequark> lkcl: i don't see why you'd *have* to use lite
<whitequark> *litex
<whitequark> in the context of nmigen, it seems like you would want to define a new platform that instantiates pxlib cells
<whitequark> if that's not possible you should explain why on the ASIC support tracking issue
<whitequark> so we can improve the platform interface
<lkcl> yes, that's what we'd need (pxlib platform). pxlib is what has to have the triplet i/o/oe Pins. also from looking at Staf's code, i've learned that there's a 4th type "Tristate-Out" which is "o/oe"
<lkcl> ok willdo.
<whitequark> the platform interface isn't 100% stable yet but feel free to use it, with existing vendor/ files as reference
<_whitenotifier-f> [nmigen] alanvgreen commented on issue #425: Support for PLL primitives -
<_whitenotifier-f> [nmigen] whitequark commented on issue #425: Support for PLL primitives -
<_whitenotifier-f> [nmigen] pbsds commented on issue #425: Support for PLL primitives -
<_whitenotifier-f> [nmigen] alanvgreen commented on issue #425: Support for PLL primitives -
<_whitenotifier-f> [nmigen] whitequark commented on issue #425: Support for PLL primitives -
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 -]
feldim2425 has joined #nmigen
<ktemkin> incidentally, it looks like I'm implicitly going to be drafted to create a "getting started with FPGAs using nMigen" workshop sometime in the next year or so
<whitequark> ooh, hopefully the tutorial i'm writing for the official docs would be ready ther
<whitequark> *by then
<ktemkin> considering Lattice is sponsoring making 5000 FPGA badges for a forthcoming hackercamp; and the Python-heavy badge team is leaning towards favoring nMigen
<ktemkin> it sounds like there's going to be a good chunk of people taking FPGA workshops
<ktemkin> assuming it's ever safe to have people outside in the same space again
<whitequark> it seems clear that eventually we'll get a vaccine
Asu has quit [Ping timeout: 260 seconds]
Ultrasauce has quit [Remote host closed the connection]
Ultrasauce has joined #nmigen
mixedmedia has joined #nmigen
vup has quit [Ping timeout: 260 seconds]
vup has joined #nmigen
<ktemkin> and hopefully I'll actually get around to producing all the educational resources I owe everyone
<whitequark> oof
mixedmedia has quit [Client Quit]
<whitequark> i find these resources to be like 50x harder to make than code
<ktemkin> I find them fairly easy to make; I just find there's always a more pressing technical objective that prevents me from really sitting down and getting to make them
<whitequark> ah
<ktemkin> theoretically, I'm an educator first, and an engineer second; but every time I go to produce good educational materials, I find there aren't enough good tools to teach the way I want to
<ktemkin> so then I wind up building the tools I need
<ktemkin> which would work well if there was time left over to actually produce the damned materials
<d1b2> <edbordin> you seem pretty expert at both things fwiw 🙂
<ktemkin> thanks
<gkelly> If I want to instantiate an open-drain pin on ice40 should I be trying to instance SB_IO myself and configure the output directly? I see there's configuration happening in vendor/, but not yet clear to me if it gives me enough power to configure o_type myself...
<whitequark> what do you mean by an open-drain pin exactly?
<whitequark> and what o_type?
<Lofty> I'm assuming they mean tristate
<Lofty> gkelly: ^
<whitequark> so, you can use dir="oe" with platform.request() to get an open-drain pin
<gkelly> I meant a pin that either goes tristate when driven as 1 or pulls down when driven as 0. Like you'd use for i2c. Looking at SB_IO definitions now it actually looks like you can't get that from SB_IO, but SB_GB_IO maybe can do this.
<d1b2> <TiltMeSenpai> what's the difference between oe and io
<gkelly> Ah okay, so a dedicated oe would definitely be sufficient, thanks!
<gkelly> I'm interpreting this as oe=output enable. Drive oe high, get a push-pull drive. Drive oe low, get tristate...
<whitequark> yep
<d1b2> <dub_dub_11> > what's the difference between oe and io @TiltMeSenpai I think oe doesn't have a .i subsignal?
<whitequark> correct
<whitequark> this is necessary in some cases to satisfy placement constraints
<d1b2> <dub_dub_11> Oh huh
<d1b2> <TiltMeSenpai> oh, yeah, some fpga's might not have pins that have io, but do have oe?
<whitequark> you generally always have oe
<whitequark> i've never seen pins that are always output only
<whitequark> well not on FPGAs
<whitequark> you get them on some PLDs
emeb has quit [Quit: Leaving.]
<d1b2> <dub_dub_11> So if you don't need the input it would generally be better to use oe ig. Doesn't i2c require Io though, at least on sda
<whitequark> sure
<whitequark> 99% of time, io/oe distinction is just to show your intent
<whitequark> it doesn't actually matter
<d1b2> <dub_dub_11> Actually iirc scl should be io too
<whitequark> but that 1% of time you'll be glad oe is also an option
<whitequark> scl needs to be io if you support clock generation or stretching
<d1b2> <dub_dub_11> Because the slave can hold them clock low
<d1b2> <dub_dub_11> Yeah
<whitequark> if you only respond to i2c transactions and don't stretch clock then it can be an input
<d1b2> <dub_dub_11> Ah yeah. I was assuming it was an i2c master in this case but I don't actually know which gkelly is doing
<gkelly> Yes, i2c host in my case.