<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] https://git.io/JTLQF
<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 - www.ntalk.de]
<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)
<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 - https://git.io/JTq55
<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 nmigen.lib.io 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 - https://git.io/JTqFN
<_whitenotifier-f>
[nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JTqbI
<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 - https://git.io/JTqx5
<_whitenotifier-f>
[nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JTqp2
<_whitenotifier-f>
[nmigen] pbsds commented on issue #425: Support for PLL primitives - https://git.io/JTmvl
<_whitenotifier-f>
[nmigen] alanvgreen commented on issue #425: Support for PLL primitives - https://git.io/JTmfU
<_whitenotifier-f>
[nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JTmft
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]
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/lattice_ice40.py, 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