<awygle>
i forget to _do_ something with the module every time i write a new one, and then i'm like "wow this is working quite smoothly, i must be getting the hang of things" and then....
<awygle>
i _am_ picked nmigen up, by the way. slowly but surely. the thing i just wrote probably only took me like, 1.5 times as long as it would have in verilog? and i don't feel close to asymptoting
<whitequark>
nice!
<awygle>
i think the thing my brain hiccups on most at the moment is that the clock domain comes before the signal, but i think of the signal first. so i always write the assignment and then prepend the clock domain afterwards
<awygle>
definitely the nicest thing about nmigen so far is the tooling, that's choice
<whitequark>
yeah, the control logic is inverted compared to verilog; it's as if `always` is nested in `if`
<awygle>
yes, exactly
<whitequark>
this decision still feels odd even to me, but i think it was crucially right
<whitequark>
for one, it matches the actual logic a bit more closely
<whitequark>
and then of course it makes FSMs truly first-class
<awygle>
i like the idea of first class FSMs but i am not totally sold on the implementation (but then i know you share this view)
<awygle>
still trying to noodle out exactly why
<whitequark>
the implementation is definitely oversimplified compared to what it should be
<whitequark>
m.next is awkward
<awygle>
i think i'll need to do something multiclock before i have a real handle on whether the control inversion w.r.t. verilog feels like a good decision to me
<awygle>
right now i'm sitting in the easy case feeling like it's boilerplate i don't need, but ... it's the easy case lol
<awygle>
i think what i really want is something closer to statecharts in terms of capability
<whitequark>
i'm not sure if multiclock will prove very insightful; i designed it with the assumption that CDCs are relatively rare and confined to dedicated modules
<awygle>
which i think would require being able to point at a state machine object. which maybe you can? but the `with` pattern pushes you away from
<whitequark>
almost all code will use m.d.comb/m.d.sync, and then have those renamed
<whitequark>
(well, just the sync)
<awygle>
anyway, just thinking out loud
<whitequark>
the core reason here is to avoid duplicating the If conditions between comb and sync assigns
<whitequark>
(and a similar issue with FSMs that required NextValue)
<whitequark>
what are statecharts?
<awygle>
also called hierarchical state machines (there are differences but they are of interest only to pedants)
<whitequark>
that sounds very much something i'm interested in
<awygle>
i _love_ statecharts. when i was at planetary resources substantially all of our software was modeled by, and in many cases generated from, statecharts
<whitequark>
will investigate
<awygle>
i basically think of them as higher-order statecharts lol
<awygle>
err, higher-order FSMs rather
<awygle>
i am going to go to sleep now, goodnight
<whitequark>
night
<ZirconiumX>
Morning
<ZirconiumX>
Slightly annoyed that I missed awygle but ah well
<ZirconiumX>
So, I saw a Twitter post on a Rust proc-macro called `bitmatch` which had a small DSL to describe bit-level pattern matching
<ZirconiumX>
And I've been daydreaming about whether it would be possible/feasible to do something similar in nMigen
<ZirconiumX>
e.g. with m.Match("0101aaaabbccdddd") as match
<ZirconiumX>
And then using match.a or whatever.
* Sarayan
waves
<Sarayan>
whitequark, if you're around, I could use even more recoomendations :-)
* ZirconiumX
waves to Sarayan
<whitequark>
ZirconiumX: it's possible, certainly, but better prototyped outside of core
<whitequark>
that'd require being able to extend Module with custom operators, which is something that's on roadmap, I think
<whitequark>
(for now you could use a branch)
<whitequark>
my biggest concern is that such case statements are (a) mostly useful for instruction decoders and (b) don't work well in instruction decoders
<Sarayan>
whitequark:do you have some free time?
<Sarayan>
no being a perfectly acceptable answer, as always :-)
<ZirconiumX>
Something alike it would be useful for decoding chip register writes
<whitequark>
Sarayan: sure
<whitequark>
ZirconiumX: have you seen nmigen-soc CSR?
<Sarayan>
The pcb has essentially two clocks, derived from on xtal, one at 12MHz and one at 6, which are synchronized
<ZirconiumX>
I have not, no
<Sarayan>
chips tend to use both, because the 6MHz clock is the pixel clock, and that makes phase important
<Sarayan>
how should I go about it? For instance the chip I want ot implement now accesses an internal ram at 12MHz, but from a different source depending on the 6MHz clock staate
<Sarayan>
e.g. one phase is rendering, the other is cpu ram access
<Sarayan>
readability is by #1 aim, performance of secondary since I don't expect to run it on hardware in practice
<Sarayan>
s/by/my/
proteus-guy has quit [Ping timeout: 265 seconds]
<whitequark>
Sarayan: hmm
<whitequark>
use a single clock, and have a register with the phase of the 6 MHz clock
<Sarayan>
whitequark: ok
<awygle>
ZirconiumX: you can always leave a message at the beep (beep) :-P good morning
<ZirconiumX>
Morning
<Sarayan>
whitequark: I have a bug report report on the C++ gen in nmigen. Do you want it here on as an issue in your tree?
<Sarayan>
ok cute, it's a nmigen bug
<Sarayan>
whitequark: nmigen loses the reset values of signals which are never written to
<Sarayan>
specifically, when outputting to yosys. Sim works
<whitequark>
Sarayan: hmm
<whitequark>
are you sure it's an nmigen bug?
<whitequark>
and not a bug in the nmigen cxxsim converter?
<Sarayan>
whitequark: as far as I can tell, the default value is missing from the code generated for yosys
<Sarayan>
you can try with the k053252, because I typoed the Case(0xb) where it should be vbp, with the side effect of nothing writing to it
<Sarayan>
and that lost its reset value
<whitequark>
let me see
<whitequark>
oh
<whitequark>
that happens because it assumes vbp is an input
<whitequark>
drop the `expose w:o_* w:*$next %d` line and explicitly specify every port
<Sarayan>
it's an internal register
<whitequark>
yes
<Sarayan>
I don't really want it eposed
<whitequark>
unless you specify ports=[...] and *not* put it in there, it'll become an input
<whitequark>
this should probably be changed, it was done for some compatibility reason