ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
mwk has joined #nmigen
<_whitenotifier-3> [nmigen] whitequark labeled issue #307: AssertionError not in -
<awygle> nmigen's simulator is not _integrated_ with gtkwave or anything, correct? one still must produce a vcd output and open it?
<awygle> also, cxxsim is still WIP?
<whitequark> pysim is not integrated with gtkwave, although it can produce gtkwave savefiles
<whitequark> i'm not sure if i could integrate it if i wanted, even?
<whitequark> cxxsim is still WIP for a bunch of reasons, expect it to progress soon
<awygle> copy. cxxsim looks _awesome_, i am psyched about it
<whitequark> nice!
<whitequark> mostly what's not done yet is hierarchy (easy) and deciding on how to integrate it with simulated peripherals (bit harder)
<awygle> hopefully by the time it's ready for primetime i'll.... understand how to use the python simulator :p
<whitequark> do you have any particular issues with it?
<awygle> na, just getting started
<awygle> i'll let you know
<awygle> working through robert baruch's tutorial now
<whitequark> there's unfortunately a bunch of race conditions in it that have existed since migen times
<whitequark> they exist in verilog and vhdl too
<whitequark> i have some ideas on how to tackle them but it's a bit of a research problem
<awygle> all i remember about my one experience with migen's simulator is "sprinkle yield around until it 'works'"
<whitequark> yes
<whitequark> the reason you have to do so is actually to *avoid* some race conditions
<whitequark> once i'm a bit less swamped i will write a detailed explanation of the issues with simulating logic
<awygle> sure :)
<awygle> is there a wawy to give a signal in the simulator a random value on each clock tick? i tried simply doing a `for i in range(...) yield signal.eq(random.getrandbits(1))` but that seems to assign a single random value for all of time
<whitequark> the verilog equivalent for that would be something like `initial for(i=0;i<n;i++) signal <= $random()`
<whitequark> i mean, for the code you wrote
<awygle> right
<awygle> that makes sense
<awygle> i need to yield Tick
<awygle> of course
<whitequark> and do it in another process
<whitequark> i feel kind of bad teaching you this simulator design because it's so bad
<whitequark> like, a bit more background
<awygle> wait, yield tick in another process?
<whitequark> the fundamental reason for this design where you have to add yield at random is because this way, it does not matter in which order processes are run
<whitequark> which is a good thing to have
<whitequark> unfortunately it's also extremely non-intuitive
<whitequark> basically, think of a sync process (in a sync process, every `yield` with no argument is just `yield Tick(domain)`) as a DFF
<whitequark> if you do `yield y.eq(a)`, then that assignment happens at the next tick, and conversely, `yield y` gives you the value before the current tick
<whitequark> this means that you can replace any synchronous part of a circuit with a sync process and the rest would work exactly as before
<whitequark> the problem is that "replacing synchronous logic with synchronous simulator processes" is something that is quite rare
<whitequark> and "writing testbenches" is something that is very common
<whitequark> in particular, this design makes it *impossible* to read from a FIFO on every cycle
<whitequark> you have to check ready signal, activate the strobe, yield, deactivate the strobe, yield again
<whitequark> in other words you can't write a testbench that tests a pipelined circuit
<whitequark> does this make sense?
<whitequark> well, the explanation, not the design
<awygle> yes, it does
<whitequark> the plan i have is to separate testbench and logic processes
<awygle> what i'm confused by currently is, do i want to yield Tick() on only one process? or every process in the simulator?
<whitequark> logic processes (comb or sync) would only have the exact kind of capability that the corresponding kind of logic does
<whitequark> and testbench processes could ask for comb settling to happen
<whitequark> so you can actually act on combinatorial feedback in a sync circuit you just triggered
<whitequark> oh
<whitequark> to answer your specific question
<whitequark> `yield Tick("x")` is similar to `@(posedge clk_x)` in Verilog
<whitequark> so if you have two processes, then each would do `yield Tick`
<whitequark> in your case, one would be just setting that signal on every cycle, and another is the testbench you're writing
<awygle> right, ok
<awygle> i only got confused because i fucked up the mitigation for the "inputs don't show up in trace" thing, apparently
<whitequark> oh, ugh, i really should fix that; i forgot
<awygle> eyy i found my first bug in my code using nmigen's simulator, happy day
<whitequark> :D
<awygle> i like the fifo interfaces being built in so i don't have to write them every time lol
<whitequark> it amazes me that people accept verilog just... not having a standard library
<awygle> would you consider adding 'gearbox' fifos? write 8 bits, read 1 bit?
<awygle> (obviously parameterizing 8 and 1)
<whitequark> yeah absolutely that is within scope
<whitequark> i'm a bit worried about the implementation correctness, but that can be handled