ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting TBD
<_whitenotifier> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier> [YoWASP/nextpnr] whitequark 366e8a0 - Update dependencies.
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #nmigen
<awygle> good evening
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
bsmt has quit [Quit: Ping timeout (120 seconds)]
bsmt has joined #nmigen
_whitelogger has joined #nmigen
cjearls has joined #nmigen
cjearls has quit [Quit: Leaving]
emeb_mac has quit [Ping timeout: 256 seconds]
_whitelogger has joined #nmigen
Bertl_oO is now known as Bertl_zZ
chipmuenk has joined #nmigen
m4ssi has joined #nmigen
<phire> What should I do when nmigen starts taking 3 min to generate verilog, and generating 26mb .v files?
<phire> is it a sign I should be writing certain inner parts directly in verilog?
<phire> or is it a bug/deficiency in the implemenation of nmigen
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
<whitequark> phire: it could be an inefficiency in your design as well
<whitequark> hard to say without context
<whitequark> are you using a lot of Arrays?
<phire> arrays and loops
<phire> I'm building a 64x64 bit matrix
<phire> and I build custom set logic for each bit
<whitequark> right
<whitequark> so, if you know how to implement this more efficiently in verilog, you should be able to do the same thing in nmigen
<phire> well in verilog, I'd use a for loop. I've used a for loop in nmigen too
<phire> but nmigen seems to choke processing the results of expanding the for loop
<whitequark> each array access is essentially a for loop on its own
<whitequark> so if you access an array in a loop, you're building a *lot* of logic
<daveshah> I think a synthesis tool is ultimately going to do similar transforms to Verilog, though
<phire> it seems to synthisize reasonably fine
<phire> quartus has no problems injecting the 26mb of verilog
<whitequark> yep, if you use SV arrays, the results would be similar
<daveshah> That strongly suggests it can be simplified, and that synthesis is optimising things
<whitequark> can you perhaps hoist some array accesses out of the loop using a temporary signal?
<phire> so this is my inner loop (one row of the matrix)
<whitequark> ouch
<phire> num_values = 64, num_sets = 4, num_sets_per_row = 2
<whitequark> wait, in self.addr, do you even need the outer Array?
<phire> there are 4 "set ports" to the matrix, each set port can set two bits of a row
<whitequark> it could be a list, I think?
<phire> yeah, could probally be a list
<phire> I only statically index into it
<whitequark> same for row_set
<whitequark> this shouldn't actually affect the size of the verilog
<whitequark> but it makes intent more clear
<phire> yeah
sakirious has joined #nmigen
<phire> whoops, now I'm crashing quartus_fit
<phire> (i fixed a bug in my code so quartus_map wasn't removing almost all the registers)
ronyrus has quit [Quit: %me%]
ronyrus has joined #nmigen
<phire> For all that crazyness, It synthesizes down to a pretty reasonable 2.03 ALUTs per register.
futarisIRCcloud has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<phire> Ok, I optimised the code to be more nmigen friendly (I took inspration from the optimisations that synthesis did)
<phire> nmigen now generations 1.5mb of verilog in 8 seconds
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 272 seconds]
Bertl_zZ is now known as Bertl
m4ssi has quit [Remote host closed the connection]
m4ssi has joined #nmigen
Bertl is now known as Bertl_oO
<agg> would it be possible in pysim to measure 'coverage' of things like FSM states, if conditions true/false, etc, over a test/series of tests?
m4ssi has quit [Remote host closed the connection]
<whitequark> not at the moment, but it would be a reasonable extension
<whitequark> that said, sensibly expressing results is difficult
<whitequark> we could probably produce an SC/CC coverage file for ingestion to some standard tools...
<agg> maybe even write pycov-compatible outputs, then you could use pycov reporting and xml generation and everything else
<agg> huh,, rather
<agg> not sure if you can use directly (via either its api or its plugin interface) to add different coverage information, rather than just trying to write coverage-compatible outputs, which might be a bit cursed
<whitequark> coverage explicitly tells you to not write coverage-compatible outputs
<whitequark> idk, might be worth writing our own, then cxxrtl could use it as well
<agg> it looks like coverage file tracing plugins can 'claim' a python-or-otherwise file and report coverage for it, which could work for cxxsim, but wouldn't help cxxrtl I guess
<whitequark> cxxrtl can export coverage information via an API
<whitequark> so that's not an issue
<whitequark> awygle: poke?
<awygle> whitequark: peek
<whitequark> awygle: up for discussing cxxsim later today?
<awygle> sure
<awygle> just ping me whenever
<awygle> (well whenever within the next approx 12 hours)
<whitequark> ack
electronic_eel has joined #nmigen
electronic_eel_ has quit [Ping timeout: 256 seconds]
<whitequark> awygle: mkay, so i'd like to talk about simulation phases & triggering
<awygle> mk
emeb has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
<whitequark> awygle: sorry, got distracted
<whitequark> i think we actually discussed this earlier
<whitequark> do you recall if that was public or private?
emeb_mac has joined #nmigen
jeanthom has joined #nmigen
<awygle> uhh
<awygle> i don't recall
<awygle> probably public? we don't talk privately that often
<awygle> whitequark: also sorry, was lunch
<awygle> oh yeah i remember that
<whitequark> ... i can't believe that was just 3 months ago, i thought it was in 2019
<awygle> i can't believe it was 3 entire months ago, i thought it was like, last week
<whitequark> time, huh
<awygle> yep
<awygle> so have your thoughts evolved since then?
<whitequark> they did, and so did the problems i'm facing
<whitequark> here's my current view of cxxrtl
<whitequark> cxxrtl generates a eval and commit function, but really it's generating two significantly distinct kinds of code that happen to be squished into the same boxes
<whitequark> first, it generates code that evaluates combinatorial cells. on a well-behaved netlist (i.e. without combinatorial loops) this code can be fully statically scheduled. we go to great lengths to turn not-quite-well-behaved netlists into entirely well-behaving ones, but if worst comes to worst, this code can be called in a loop until it settles.
<whitequark> but really, its intended purpose is to be executed once per simulation instant, and the current approach is actually a global performance optimum. nothing to do here.
<awygle> yep, makes sense
jeanthom has quit [Ping timeout: 246 seconds]
<whitequark> (this is basically my answer to your earlier "process per cell" suggestion)
<awygle> mhm
<whitequark> (there's an interesting detail here where the behavior of fully asynchronous logic / combinatorial loops is essentially undefined beyond "it's fully deterministic", but i digress)
<whitequark> second, it generates code that evaluates synchronous cells. this is a lot more tricky. scheduling-wise, this code can run at pretty much any order as long as it happens after all the combinatorial cells are evaluated. the trickiness is in the guarding condition.
<whitequark> the purpose of the guarding condition is pretty much to evaluate synchronous cells when (e.g.) there is a posedge on clk. that doesn't sound very complex. but the exact form of the condition has major ergonomics and performance implications in cxxrtl alone, and cxxsim makes all that twice as complex
jeanthom has joined #nmigen
<whitequark> let's look at cxxrtl alone first
<whitequark> how do we detect a posedge on clk? well, an obvious way to do so is during commit: we know the clock just changed, if it's 1 now, we have a posedge.
<whitequark> however, this requires the clock to be a wire<>.
<whitequark> so if you have code in a testbench like `top.p_clk.set(true); top.step();` then this will run eval/commit twice: first eval does nothing, first commit detects the edge, second eval/commit is actually useful.
<whitequark> that's a 2x performance hit which obviously sucks.
jeanthom has quit [Ping timeout: 264 seconds]
emeb has quit [Quit: Leaving.]
<whitequark> so what i do instead is one of two things:
<whitequark> - if p_clk is a wire<> after all, i compare p_clk.curr and to see if it's about to be committed, and if it is, i consider that a posedge has happened.
<whitequark> this is strictly speaking illegal according to my own rules, and unsurprisingly, it causes issues i'll go into later
<whitequark> - if p_clk is a value<>, i create another value<> prev_p_clk, do `prev_p_clk = p_clk` in commit, and compare them to determine if a posedge has happened.
jeanthom has joined #nmigen
<whitequark> so, what goes wrong here?
<awygle> got distracted oops
<awygle> the former sounds like it could cause issues if the combinatorial logic isn't settled, for one thing
electronic_eel has quit [Ping timeout: 256 seconds]
jeanthom has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
<whitequark> awygle: sorry, got distracted
<whitequark> oh, you too
<whitequark> ok, so you're right, that is one issue
<whitequark> another issue is... actually hang on i found a bug
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
* whitequark sighs
<whitequark> awygle: ok, so other than the issue you pointed out, i'm not aware of how this plan breaks. it's just gross.
<whitequark> (i thought it would break, but it turned out to be a simple miscompilation that i fixed in #2485)
sakirious has quit [Quit: The Lounge -]
sakirious has joined #nmigen
sakirious has quit [Client Quit]
<whitequark> awygle: still here?
peteut has joined #nmigen