<cr1901>
(Actually I know it's not a glitch; I assume it's a transition that lasts for 0 time, but for e.g. the red circle, it's not clear to me _from visual inspection alone_ whether PutX2 or PutX1 is the command latched in during that 0-time-elapsed cycle.)
<whitequark[cis]>
<cr1901> "(Actually I know it's not a..." <- a 0-time transition is what I would call a glitch
<whitequark[cis]>
<cr1901> "http://gopher.wdj-consulting.com..." <- at the last cycle where PutX1 is active, there is ready+valid; therefore the transfer is concluded at that point. since the next cycle (which has valid) the command processor performs PutX2
<cr1901>
Is the "mode" stream from the POV of the sink/receiver in that waveform viewer screenshot?
<whitequark[cis]>
"mode" is from the controller pov
<whitequark[cis]>
so "putx1" sends a command to the flash for example
<cr1901>
> since the next cycle (which has valid) the command processor performs PutX2. That makes sense. It's just that immediate when PutX2 is put on the bus, bus.mode__ready starts being ready twice as fast (even though for one of those transactions where PutX2 is on the payload the processer is still processing a PutX1)
<whitequark[cis]>
the processor keeps ready low until it's done processing a transaction, actually
<cr1901>
So why is the last PutX1 transaction (the transaction clocked into the command processor in the red circle, after which PutX2 is immediately put on the payload, _unless I'm misunderstanding which is likely_) finished twice as fast as the preceding ones?
<whitequark[cis]>
the processor does not have its own buffer for commands
<whitequark[cis]>
it relies on the fact that until it asserts ready, payload must not change
<whitequark[cis]>
so the output register of whatever's driving the processor is the command buffer
<cr1901>
Ahh, so valid goes low for "that infinitesimal amount of time that the processor driver is changing commands", which is 0 time elapsed in the case of sim and just before the leading edge of top.clk for convenience of testbench/processes?
<whitequark[cis]>
yes; it's an artifact of how the stream_put function is written
<whitequark[cis]>
two back-to-back calls to it lower valid and then raise it immediately after
<cr1901>
>the processor does not have its own buffer for commands <-- I'm not used to this, as I've never written streams like this (w/o an internal command buffer). I'll keep that in mind from now on.
<whitequark[cis]>
it saves you a cycle in many cases
<whitequark[cis]>
also the QSPI processor doesn't have any FSMs inside
<cr1901>
What causes the glitch in the blue circle? Is it also process/testbench-stimulus-related?
<whitequark[cis]>
I think that one might be comb propagation
<whitequark[cis]>
do note that sck_buffer__o is an input to FFBuffer; it is not intended to drive the device directly
<cr1901>
So none of the artifacts "matter" (for want of better term) in this waveform.
<whitequark[cis]>
yes
<cr1901>
I never saw these in the pre-testbench/process split simulator (that I can recall), and whenever I saw artifacts like these in iverilog, they typically indicated that I made a coding mistake (floating point precision issue w/ clock period vs how much to delay my testbench stimuli). So they throw me off here.
<whitequark[cis]>
this is with fs_per_delta=1
<whitequark[cis]>
which is an undocumented parameter whose purpose is to show comb settling in the VCD
<cr1901>
oh ffs, why didn't you tell me that from the beginning :P
<cr1901>
ALL of what I'm seeing makes sense now
<cr1901>
Disregard all of the above. I don't understand 100% how pysim works, but I've looked at it enough to grok the fs_per_delta stuff. I thought all of this was fs_per_delta = 0, and GTKWave was _still_ (somehow) deciding to show 0 length pulses without time having elapsed.
<whitequark[cis]>
there is an open issue to make that happen
<whitequark[cis]>
because otherwise debugging certain races makes you feel insane