[libre-riscv-dev] buffered pipeline

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Mar 13 04:21:44 GMT 2019


dan, hi,

where this code occurs, strictly speaking i believe it may be placed into
the "else" block, above it.  the reason is: r_stb is already 0, therefore
it need not be set to a value that it is already set to.

however... i appreciate that that would potentially result in loss of
clarity in illustrating that o_busy is synonymous with r_stb.





		// We can also clear any stall condition		o_busy  <= 1'b0;

		// And declare the register to be empty.		r_stb   <= 1'b0;

also, a minor weirdness, see attached gtkwave

i've put several values into the pipeline: 0x5, 0x7, 0x2, 0x9, 0xC and
0x20.  the input strobe *stops* at 0x09, so only 0x05, 0x7, 0x2 and 0x9
should be on the output.  the output stage adds 1 to its input.

at the 6th clock pulse i set i_n_busy HIGH in order to create a stall (and
release it 2 clocks later) this was done deliberately one clock earlier
than when the input strobe goes LOW.  that results in o_p_busy going HIGH
for 2 clocks, matching i_n_busy but with a one-clock delay.

therefore, o_n_stb is two clocks *longer* than i_p_stb.  i_p_stb was valid
for 4 clocks (input values 0x5, 0x7, 0x2, 0x9), and the output can be seen:

* 0x6 (1 cycle),
* 0x8 (1 cycle),
* 0x3 (held for 3 cycles because of i_n_busy HIGH for 2)
* then 0xa for 1 cycle (after i_n_busy goes LOW)

the value 0xD (generated from the input 0xC when the input strobe was LOW)
does not appear on the output (even though the intermediary combinatorial
"result" shows it was computed (0xD).

the "weirdness" is that the value 0x21 appears on the output, even though
the input strobe is LOW.  this suggests that unnecessary processing is
occurring, and that the condition of assigning r_data on o_busy is
insufficient to stop that from happening.

yes we don't care what the output is: i can see that o_n_stb has gone LOW,
so the output 0x21 is known to be invalid: i'd just prefer that the output
not be computed at all if the input's not valid, to save power.

would it be as simple as setting the combinatorial result computation on
the condition that i_p_stb is HIGH?

l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019-03-13_04-00.png
Type: image/png
Size: 41318 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190313/322ac719/attachment-0001.png>


More information about the libre-riscv-dev mailing list