ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
<ZirconiumX> I feel like I need to read up on how to do QAM because that kind of math confuses me greatly
<whitequark> same here
<ZirconiumX> s_s(t) = sin(2*pi*f_c*t)*I(t) + sin(2*pi*f_c*t + pi/2)*Q(t)
<ZirconiumX> Clear as fucking mud, Wikipedia
_whitelogger has joined #nmigen
<whitequark> ok well that's not bad
<whitequark> it would be more clear if they wrote it as s_s(t) = sin(2π*fc*t)I(t) + cos(2π*fc*t)Q(t)
<whitequark> what they wrote looks more like the sum of two carrier waves, and what i wrote looks more like the constellation diagram
proteus-guy has quit [Remote host closed the connection]
<_whitenotifier-3> [nmigen-boards] jeanthom opened pull request #47: Add Fomu PVT support -
<_whitenotifier-3> [nmigen-boards] whitequark reviewed pull request #47 commit -
<awygle> god python makes me nervous. does "not counter.any()" do what i think it does?
<whitequark> what's "counter" in this case?
<whitequark> nmigen value?
<awygle> signal
<awygle> 4 bits
<awygle> for slightly more context, the code is basically `m.d.sync += is_zero.eq(not counter.any())`
<awygle> (yes i can just do a compare against 0 and probably will but this is how i wrote it first)
<whitequark> try it
<whitequark> migen used to silently do the wrong thing, nmigen does:
<whitequark> TypeError: Attempted to convert nMigen value to boolean
<whitequark> you have to use ~counter.any(), and then yes, it work
<awygle> interesting. it elaborates for me
<whitequark> hm
<awygle> ... i'm not actually elaborating.
<awygle> never mind.
<whitequark> right.
<whitequark> `not`, `and` and `or` won't ever work with nmigen values, but you also won't use them by accident
<_whitenotifier-3> [nmigen-boards] jeanthom synchronize pull request #47: Add Fomu PVT support -
<awygle> okay there we go, now it correctly fails
<awygle> thanks wq
<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....
<_whitenotifier-3> [nmigen-boards] jeanthom reviewed pull request #47 commit -
<whitequark> hehe
<_whitenotifier-3> [nmigen-boards] whitequark closed pull request #47: Add Fomu PVT support -
<_whitenotifier-3> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0]
<_whitenotifier-3> [nmigen/nmigen-boards] jeanthom 9117a6a - Add Fomu PVT support.
proteus-guy has joined #nmigen
<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> 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
<whitequark> ooh
<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