<_whitenotifier-b>
[nmigen] whitequark commented on issue #418: Simulation of Verilog output doesn't match nMigen simulation - https://git.io/JJkOa
<_whitenotifier-b>
[nmigen-boards] whitequark commented on pull request #73: Update SPI definition in interface.py to match new terminology - https://git.io/JJkOw
<_whitenotifier-b>
[nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJkOP
<_whitenotifier-b>
[nmigen/nmigen-boards] fl4shk 3d0f159 - de0_cv: fix ba and cs pins of the SDRAM resource.
<_whitenotifier-b>
[nmigen-boards] whitequark commented on pull request #72: fix DE0-CV (bank and cs) - https://git.io/JJkOX
<awygle>
whitequark: was the decision "no" or "not now"?
<whitequark>
awygle: "no" for multiple reasons
<whitequark>
the main one is that clock domains don't have frequencies, clocks do, and they're not always constant
<awygle>
thats basically what i assumed would be the case
<whitequark>
both clocks and clock domains are also lazily bound, so even during/after you elaborate, you don't necessarily know which clock you'll end up using
<whitequark>
which makes it not techincally very viable either
<awygle>
mhm
<whitequark>
maybe we can address the issues you are having in some other way though
<awygle>
idk that it's an _issue_ exactly. my DDR2 controller needs to be able to e.g. wait 400 ns after enabling the clock before issuing the Precharge All command. the timer that handles that wait needs to know how fast it's running.
<awygle>
so i pass in a frequency. which is exactly how i'd do it in e.g. verilog, it just feels a bit sketchy that it's repeating information that also exists in e.g. the clock constraints
<whitequark>
ah I see
<whitequark>
so the way I think of this is that the clock constraints aren't the *source* of truth for frequencies
<whitequark>
rather they are derived information stripped of its original context
<whitequark>
you're saying "the frequency of this domain would not be higher than this", right?
<whitequark>
but the actual source of truth could be something like "this domain can run at 100 and 125 MHz" and there's no way for nMigen to abstract all of that
<awygle>
that's a reasonable POV
<awygle>
and you're right that variable frequency clocks can exist
<awygle>
it's just a bummer that the _overwhelmingly_ common case needs this boilerplate
<awygle>
so i figured i'd ask the question
<whitequark>
i'm not sure if it's actually boilerplate
<awygle>
boilerplate is the wrong word
<whitequark>
like, it's not meaningless; what it's doing is semi-explicitly saying "this component *has* to know a frequency to work, and it also can only work at exactly one frequency"
<awygle>
it's actually the duplication that bothers me
<awygle>
it opens the door to "i passed in a frequency for a clock domain i don't actually belong to" kinds of errors
<awygle>
which seem more common/likely than "my module expected a constant frequency and i put it in a variable-frequency clock domain" errors
<whitequark>
hrm
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
<awygle>
oh lol i just hit #355. can't make something that's both a UserValue and an Enum due to metaclass conflict. fortunately that's not actually what i want anyway but still
withig has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
nengel has quit [Ping timeout: 244 seconds]
peepsalot has joined #nmigen
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to master [+1/-0/±3] https://git.io/JJks5
<_whitenotifier-b>
[nmigen/nmigen] whitequark f115335 - docs: link to community tutorials until we have an official one.
jaseg has quit [Ping timeout: 256 seconds]
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+3/-0/±19] https://git.io/JJksx
<_whitenotifier-b>
[nmigen/nmigen] whitequark b763208 - Deploying to gh-pages from @ f1153352c0e0d6c1e5ff345e5fbab5653bb8f24c 🚀
<whitequark>
hm, so pysim currently can express "wake up this process iff this signal goes from 0 to 1" as well as "wake up this process iff this signal changes"
<whitequark>
the latter is required to get any sort of decent performance from it (i checked) but the former doesn't necessarily, and if i got rid of it in pysim (instead adding some conditionals) it'd maybe get easier to integrate things with cxxsim
<cr1901_modern>
The latter isn't a superset of the former?
_whitelogger has joined #nmigen
<d1b2>
<edbordin> hmm, is there a small nmigen example targeting ecp5 that anyone recommends as a smoke test for nmigen master + nightly toolchain?
<d1b2>
<edbordin> I'm planning to use icebreaker-nmigen-examples for ice40
<d1b2>
<edbordin> I mean...I guess I could build luna but that's probably a little larger than I was thinking
_whitelogger has joined #nmigen
<whitequark>
edbordin: smoke test?
<whitequark>
python3 -m nmigen_boards.versa_ecp5
<whitequark>
should do it
<d1b2>
<edbordin> idk how common that term "smoke test" is, perhaps I should adjust my usage accordingly 😛
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
<MadHacker>
re https://github.com/nmigen/nmigen/issues/356 : about Rose, Fell, etc. and exporting them. I've a situation where I have an FPGA running at a related-but-faster clock to an old 8 bit micro, and I want to do something only once when a condition is met and I see a rising edge of my 2MHz clock (when I'm running off 16MHz the 2MHz is derived from). Rose() works nicely for me here.
<MadHacker>
e.g. trigger something when I see a write to a register in 2MHz land. I don't want to run *everything* in a 2MHz domain, not least because it uses both edges of the clock.
<whitequark>
isn't EnableInserter more appropriate here?
<MadHacker>
Possibly. Rose() is what I went looking for though.
<MadHacker>
As in, that was the path of least resistance.
<MadHacker>
Looking into EnableInserter now to compare.
<MadHacker>
OK, no, I don't think so, but I could be wrong. So, I have some registers in fast-land, and I want to trigger effects beyond updating them - say, pushing into a FIFO, or clearing a flag - when slow-land does a thing. That's not about gating the clock on a module or similar; I'm not gating lots of logic, I'm setting or resetting a flag, for example. I'm not, however, doing something like taking a whole
<MadHacker>
module and running it off a sliced-up clock.
<MadHacker>
Practical example: Read from register clears interrupt flag.
<MadHacker>
Don't want it double-clearing.
<whitequark>
hrm
<whitequark>
oh, the micro is actually separate to the FPGA?
<MadHacker>
Oh yes.
<MadHacker>
Entirely.
<whitequark>
isn't there a CDC then?
<whitequark>
since the micro's timing paths are not taken into account by the nextpnr analyzer
<whitequark>
well, let me rephrase
<MadHacker>
No. The micro exports its fast graphics clock as well as the slow main clock, and that's feeding the FPGA.
<whitequark>
ohhhh
<whitequark>
mk, can you describe that use case in the issue?
<MadHacker>
So I basically have 16MHZ + 2MHz outputs from the micro, both of which the FPGA can see. Even if there were a CDC though, one clock is guaranteed much faster than the other.
<MadHacker>
As in, guaranteed to have multiple edges of one between edges of the other.
<agg>
and the register containing a bit you'd like to clear is in the 16MHz domain?
<MadHacker>
Yes agg, because everything I can possibly put in 16MHz is in 16MHz.
<MadHacker>
The 2MHz domain is a weird double-edged world of pain.
<MadHacker>
Since I'm running much faster than it, I don't need to deal with that.
<agg>
for something similar i put some fpga logic in the slow domain to talk to that bus, and use some sort of cdc (a fifo in a bram in this case) to communicate back to the fast domain
<MadHacker>
whitequark: Specific example use case: FPGA implementation of a UART, has a buffer + IRQ, when the micro reads from the buffer it should clear IRQ.
<agg>
but maybe that's overkill for this
<MadHacker>
I *know* I could redesign it to not work like that, but for the sake of argument I'm not going to.
<agg>
how do you handle the micro reading the buffer?
<MadHacker>
agg: with m.If(bufferdecoded): m.d.comb += [ self.databus.o.eq(buffer_head) ]
<MadHacker>
In context comb or sync wouldn't actually matter because that sync is guaranteed to come before the next edge the micro reads anything from because 16MHZ >> 2MHz.
<whitequark>
this could be handled by building one edge detector and then using its output everywhere you need to touch the 2 MHz domain, right?
<MadHacker>
Well, I could put self.2mhz_rose = Rose(self.2mhz_in) if that's what you're suggesting?
<MadHacker>
I mean, that's what Rose() does anyway, it's an edge detector.
<whitequark>
it's an edge detector with weird consequences
<MadHacker>
Well, what are those here? I'm not sure I see anything except "it might not be zero on reset".
<whitequark>
basically the reset behavior
<agg>
isn't there a cdc hazard when you e.g. read the address line from the 2MHz mcu at your 16MHz clock?
<whitequark>
i'm very uncomfortable promoting Rose() to be used everywhere without tackling that
<MadHacker>
agg: Basically no, my clock is referenced to the 2MHz one plus the hold times are long enough anyway.
<MadHacker>
To be clear, *this is running just now*, I'm not suggesting hypotheticals.
<MadHacker>
whitequark: The reset behaviour, although I get your point, applies for one cycle on reset. In real platforms, that's not normally a huge deal, although I agree it's a thing worth knowing about.
<MadHacker>
e.g. this machine is never, ever, going to try and write to that register within one 16MHz cycle of coming out of reset.
<MadHacker>
The place I can see needing to know about it being important is if you do something daft like Rose(reset).
<MadHacker>
There, yes, you're embracing the footgun.
<agg>
are you using the registers in the fpga io cells to register the lines from the mcu on its 2MHz clock or your 16MHz clock (or not using them and just straight into logic)?
<MadHacker>
agg: Varies. Some are into logic, some are into 16MHz. Nothing runs at 2MHz, because, again, it uses both edges and I couldn't if I wanted to.
<whitequark>
MadHacker: not one cycle, you can go arbitrarily in the past
<whitequark>
but anyway, "embracing the footgun" is something i'd like to avoid in first place
<whitequark>
so you're making an argument against the feature moreso than for the feature
<whitequark>
anyway, i'm not against it as long as something is done about the reset
<whitequark>
so far no one actually suggested what to do with the reset
<MadHacker>
Well, sensible suggestions: i) Nothing, ignore it, put a warning on it, ii) Fill the Sample() on first clock after reset with the current value?
<MadHacker>
(i.e. "time starts at reset" sort of answer)
<MadHacker>
I suppose that misbehaves with Stable().
<lkcl_>
MadHacker, "something daft like Rose(reset)" is entirely avoided in BSV because of the strong typing. reset has a strongly-type context associated with it, which will propagate through any functions that use it (e.g. Rose)
<lkcl_>
at the point where assignment is attempted to anything that is *not* in that exact same strongly-typed context, you get a compile-time error
<lkcl_>
the only way to convert between two entirely separate reset domains is to use a reset domain converter.
<whitequark>
MadHacker: yeah there's a lot of subtleties there, all of which are avoided if we simply not do this
<whitequark>
in general, i like solving problems by not having the features that cause these problems
<lkcl_>
that converter *will* DoTheRightThingOnYourBehalf - detecting the 16mhz reset and holding it for 2mhz for example
<lkcl_>
whitequark: i'm describing how it's done in BSV (bluespec) because i would kinda expect / like nmigen to be able to do the same thing
<MadHacker>
whitequark: I understand, but I have a real use for the feature and I haven't seen a real example of the problem. I can go reimplement it, but it seems needless.
<MadHacker>
lkcl_: I understand what you're saying but the potential badness around Rose(reset) has nothing to do with CDC in context.
<MadHacker>
lkcl_: I think you're conflating two points.
<lkcl_>
MadHacker: quite possibly :)
<whitequark>
MadHacker: the cost of implementing it in your code is one-time; the cost of adding it to the language is borne by everyone forever
<whitequark>
(unless we plan to deprecate it, in which case why add it in first place)
<MadHacker>
Yeah, I absolutely accept that point; I'm just arguing for its inclusion, but it's your language and your call.
<whitequark>
right, makes sense
<whitequark>
just to reiterate, i'm fine with including it as long as there is a good way to handle the reset behavior
<whitequark>
that problem isn't theoretical
<whitequark>
it actually caused issues when writing formal testbenches
<lkcl_>
whitequark: the ASIC that we are doing will also need edge-detection and so on for EINTs (external ints)
<whitequark>
lkcl_: an edge detector is literally 2 or 3 lines of nmigen
<whitequark>
i'm sure you can write that yourself
<whitequark>
MadHacker: so with formal, you want reset_less sample registers, but with synthesizable code, you probably want non-reset_less sample registers
<whitequark>
so far this looks like an intractable conflict to me
<MadHacker>
I mean, you can just steal the code from Sample() and Rose(); it's not like it's hard to implement. It's more about being idiomatic in the language.
<MadHacker>
whitequark: RoseAfterReset() vs Rose()?
<whitequark>
:/
<whitequark>
that's actually worse than just writing them out
<MadHacker>
with m.SafeSamples(): with m.If(Rose(blah): ?
<whitequark>
Rose() is pretty much necessary because SVA is a reasonably good API and it's a part of SVA
<whitequark>
wtf
<whitequark>
this is the very definition of bad design
<MadHacker>
Heh. OK.
<MadHacker>
Thinking out loud. :D
<MadHacker>
I'll shut up and ponder harder.
<whitequark>
if you have some feature that starts working properly if you sprinkle "safe" something in your code you shouldn't have that feature in the first place!
<whitequark>
it's like uh
<MadHacker>
I get you.
<whitequark>
that C extension with strcpy_s
<MadHacker>
Yep.
<MadHacker>
Calling it Safe is sort of the mistake though, SamplesClearedOnReset(): is the same thing.
<whitequark>
sure but that's still a footgun
<whitequark>
if a feature has a built-in footgun you have to disable you can't call it idiomatic!
<MadHacker>
From my side, the biggest issue I have is just that if I implement my own, the obvious name is Rose() and having a Rose() that does almost but not quite the same thing as the language one is even footgunnier.
<whitequark>
you probably can't implement your own as a function
<whitequark>
since it needs a register and a sync statement
<MadHacker>
If I can't, that's an argument for the inclusion.
<MadHacker>
I think I've said as much as I think I have in the way of valuable contribution, so I'm going to bow out for now and get on with the rest of my code. I'll say if I come up with a more convincing argument.
<whitequark>
you can implement it as a submodule
<whitequark>
oh, also
<whitequark>
you can't use Rose() with arbitrary expressions, at least at the moment
<whitequark>
only with signals
<whitequark>
it's really just a bit of SVA magic (it's magic because it knows which clock domain it's in, whereas other expressions don't) that looks general purpose but isn't
<whitequark>
oh
<whitequark>
if you want to have some inspiration, see if people are using SVA $rose in synthesizable code and how they are handling this issue
<FL4SHK>
well, looks like I'm going to be unable to use nMigen with my actual FPGA dev board for a while
<FL4SHK>
my x86 laptop's keyboard is busted
<FL4SHK>
I really hate how I'm stuck using closed source synthesis software
<whitequark>
what are you using right now?
<FL4SHK>
an RPi 4
<whitequark>
AArch64 kernel?
<FL4SHK>
no...
<FL4SHK>
I can switch tha
<FL4SHK>
t
<FL4SHK>
been meaning to try Dolphin on the thing anyway
<whitequark>
if you can get an AArch64 kernel to run you can just use yowasp
<whitequark>
if you can't, you can build nextpnr yourself or use packages
<FL4SHK>
will nextpnr work with an Intel board?
<whitequark>
hang on
<whitequark>
oh, i see, i misunderstood your problem
<whitequark>
could probably run quartus in qemu-user-x86_64
<FL4SHK>
that's an idea
<whitequark>
it will need fiddling with ld_library_path
<whitequark>
but it's probably doable
<FL4SHK>
this thing is beefy enough to run my normal DE, so hopefully that'd work
<whitequark>
yes
<whitequark>
wouldn't suggest on pi3
<whitequark>
that device's CPU is kind of a joke
<FL4SHK>
Honestly, I'd love to make something like a Pi but with a custom SoC
<whitequark>
i think i once compiled nextpnr for something like 30 hours
<FL4SHK>
I don't know enough about ASIC dev nor have enough money for it atm though
<FL4SHK>
I'm probably best off just getting a fancy FPGA dev board
<MadHacker>
Talk to Sifive maybe if you're serious and have something you want on there?
<miek>
would your laptop work with a usb keyboard?
<FL4SHK>
miek: yes, but it's still under warranty
<miek>
ah right, so you're having to send it off for repair?
<FL4SHK>
Yes
<FL4SHK>
I have this RPi4 though
chipmuenk has joined #nmigen
<lkcl_>
FL4SHK: well, funnily enough, that's what libre-soc is for. roadmap: 18 months, quad-core dual-issue 800 mhz POWER9 with hybrid CPU/VPU/GPU instructions
<lkcl_>
all in nmigen :)
<sorear>
reminds me of lowRISC's roadmap ten years ago
<lkcl_>
sorear: yes, and they're progressing nicely. the power budget we're aiming for is 2.5 watts.
<Lofty>
I think you missed the point, lkcl_
<lkcl_>
once we've got that done (which will need around USD $5 million in 45nm) we can move to higher geometries
<lkcl_>
Lofty: i was coming to that :)
<lkcl_>
the absolute last thing we want is to ask investors to take a chance on putting USD $20 million into a 7nm ASIC as our very first chip.
<lkcl_>
that would just be... well... stupidly risky
<lkcl_>
so by going up the geometries we can get the core done and proven with less money in smaller geometries - iteratively - and work our way up.
<lkcl_>
1st one: 180nm and only costing around USD 18k, sponsored by NLNet.
<lkcl_>
if that fails, so what, big deal, USD 18k is 3 orders of magnitude less money thrown away than if we'd tried to go straight to 7nm
<sorear>
6 years later, AFAICT there is no test chip, because it turns out you can't do much with 3 people and 0 funding
<Lofty>
Remember the J4 core?
<sorear>
I'm not complaining, they DID give us the llvm port
<FL4SHK>
lkcl_: I am uninterested in running a machine I didn't design
<lkcl_>
sorear: sigh, i really want to see them succeed.
<sorear>
J4/J32/I think it's called something else now because there's a trademark on the letter "J" is a different animal, it's been allegedly been done for > a year but unreleased due to corporate bureaucracy
<lkcl_>
FL4SHK: good for you, to have pride and a feeling of accomplishment when you succeed at that
chipmuenk has quit [Quit: chipmuenk]
<lkcl_>
FL4SHK: on a practical note, processor design is so insanely hard that it means that you'd be able to fix it if something went wrong. if someone else designed it, you'd almost certainly not be able to
<sorear>
lkcl_: so do I
cr1901_modern has left #nmigen [#nmigen]
cr1901_modern has joined #nmigen
<tpw_rules>
lkcl_: why did you decide POWER9?
<FL4SHK>
lkcl_: processor design is hard?
<FL4SHK>
since when?
<FL4SHK>
I designed a giant-arse processor for my master's degree
<FL4SHK>
...also I know how to port GCC to work with a new processor
<FL4SHK>
I've done that before, too.
<FL4SHK>
I expect the software side to be tougher than the hardware side, though.
<FL4SHK>
whitequark: so what's it take to run a program in qemu?
<FL4SHK>
I've used qemu for running an OS
<sorear>
I tried to join a local public transit advocacy org recently and they had a NDA that was much worse than the risc-v foundation NDA
<whitequark>
FL4SHK: run `qemu-x86_64-static`, specify the x86_64 dynamic linker with -L, specify LD_LIBRARY_PATH, should work?
<sorear>
if you're using -L I think you don't need to statically link qemu
<whitequark>
the -static one is just the one in debian that i've used before
<FL4SHK>
whitequark: so where do I get qemu-x86_64 from?
<FL4SHK>
wait, let me double check the package manager
<FL4SHK>
maybe it's in the AUR
<FL4SHK>
nope
<whitequark>
hrm
<whitequark>
no idea about arch, it's in debian tho
<FL4SHK>
I might just build it from source
<sorear>
if it comes to that, ./configure --target-list=x86_64-linux-user
<FL4SHK>
That's helpful, thanks
<sorear>
if you need subprocesses, --enable-static and set up binfmt_misc
<ktemkin>
FL4SHK: try `qemu-arch-extra`
<lkcl_>
tpw_rules: we need "official endorsement" for some extensive modifications to the ISA.
<ktemkin>
"pacman -Ql qemu-arch-extra" has "qemu-arch-extra /usr/bin/qemu-x86_64" on x86_64, I assume it does on alarm
<tpw_rules>
oh hey i just found out where the nmigen discord bot is attached
<lkcl_>
the Open Power Foundation was amenable to that.
<lkcl_>
FL4SHK: interesting! what ISA, and what type of architecture?
<d1b2>
<tpw_rules> hi
<sorear>
I'm sure whatever you're doing is less "extensive" than CHERI
<lkcl_>
FL4SHK: yes on the software side, we deliberately picked a pre-existing ISA. we witnessed OpenRISC go through the bootstrap process.
<lkcl>
tpw_rules: there were some competitions to see how few LUTs people could create a RISC-V core in, a while back. maybe worth looking into, to see what people did?
<tpw_rules>
eh, i don't need something anywhere near that complex
<tpw_rules>
just single cycle and crazy small
<tpw_rules>
so. is there any way to tell discord to not even make a red notification?
<lkcl>
tpw_rules: :)
<tpw_rules>
apparently not. this isn't necessarily the place but god i hate discord so much
<d1b2>
<TiltMeSenpai> I just wish discord allowed custom clients
<d1b2>
<TiltMeSenpai> so many problems could be fixed with a better discord client
<d1b2>
<Qyriad> There do exist other clients for Discord, though I haven't found one that I like
<ktemkin>
tpw_rules: I can probably just add a role that removes access to that channel
<ktemkin>
if you'd rather use IRC for the bridged channels
<tpw_rules>
almost certainly i would
<d1b2>
<Qyriad> If you don't want an unread notification you can just mute the channel.
<tpw_rules>
that doesn't work. i still get unread notifications if someone nickpings me on irc, which turns into an @ over the bridge
<tpw_rules>
they don't show up, but i have to clear them out to avoid the claim that i have unread notifications
<d1b2>
<Qyriad> that should suppress mentions
<tpw_rules>
nope
<d1b2>
<Qyriad> I think
<d1b2>
<Qyriad> really?
<d1b2>
<Qyriad> damn
<d1b2>
<TiltMeSenpai> that unfortunately only mutes desktop notifications
<tpw_rules>
like i said they don't show up as an OS notification
<d1b2>
<TiltMeSenpai> you still get the red badge
<tpw_rules>
but there's still the little unread thing
<d1b2>
<Qyriad> TIL
<d1b2>
<TiltMeSenpai> also I'm glad I'm not the only person who's slightly obsessive about notification badges
<d1b2>
<TiltMeSenpai> I've pretty much never met anyone else that cares, but having unread notifications really bothers me
<awygle>
Dang that was a lot of backlog. Guess that's what I get for sleeping til noon.
<ktemkin>
tpw_rules: okay, I brought it up to esden, and assuming he's cool with the role being set up I'll stick it on you
<tpw_rules>
is it something i can switch or will i have to ask you?
<ktemkin>
a mod will have to do it for now; but theoretically one of the bots in there can be configured to let you take the roles on and off
<tpw_rules>
i don't mind either way
<FL4SHK>
woohoo, my laptop's keyboard is magically working again!
<FL4SHK>
I am super happy
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
<sorear>
yay
<esden>
tpw_rules: ok, you have the irc-only role now. You should not see the glasgow and nmigen channels on the discord server any more.
<ktemkin>
oh, cool, and I can toggle it on and off of myself to hide and show the channel for me
<d1b2>
<Qyriad> esden can't though, since admin/owner overrides everything
<ktemkin>
yep
<ktemkin>
but he can tweak the bot settings to never translate his Discord tags~
<d1b2>
<Qyriad> but that would require him to do something in node.js
<d1b2>
<Qyriad> that seems unlikely~
<d1b2>
<esden> Ohh I can, exclude specific users from being bridged from irc to discord and vice versa.
<d1b2>
<esden> You just have to list them in the config file.
<d1b2>
<esden> But that is more useful for bots I guess or annoying users 😉
<d1b2>
<esden> I don't mind though, I just have disabled notifications in IRCCloud client for the glasgow and nmigen channels. So I solved it for myself that way.
Asu has quit [Remote host closed the connection]
FFY00 has quit [Remote host closed the connection]