<_whitenotifier-3>
[nmigen] whitequark labeled issue #307: AssertionError domain.name not in self.domains - https://git.io/JvYiL
<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