[Libre-soc-dev] microwatt / libresoc dcache

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri May 7 03:02:36 BST 2021

assuming my assessment that there is an unnecessary sync/clock state
introduced, i believe that this extra clock delay may be removed on load
output *and* store acknowledgment may be achieved as follows:


* all reg_stage_1_t forwarding and the block marked "signals to complete"
to be moved to a new struct, call it (for lack of a better name)

* note in passing that the majority of the new struct is pretty much the
same as dout and that it is the focus of attention of writeback_control
*except* for cache_out row.

* make a reg_stage_1_out_t a member of reg_stage_1_t called r1.out and
adjust all references of r1 in dcache.vhdl to use the new r1.out

* run all unit tests to make sure nothing got "damaged"

* create a new variable, r1_out, which is combinatorially copied from r1.out

* in a rising edge block, copy r1_out into r1.out

* in all cases where members of r1.out were set in a *rising* edge, now set
them *combinatorially* in r1_out instead.

* remove the ADD_BUF=true argument from all cache_ram instances

* in the entirety of writeback_control, where any use of r1.out is
specified (read), use r1_out instead.

this basically shifts the entirety of writeback_control output early by an
entire clock cycle, necessitating the removal of the ADD_BUF=true because
the cache hit data output need no longer be delayed by that one extra cycle.

note that even the acknowledgement of stores is moved one cycle early.

i cannot say if this is "wise" inasmuch that there may be good reasons
(gate latency) why the extra cycle is there: i have not done the analysis.

however i believe it should be possible, with a small amount of extra work
(similar to ADD_BUF itself back in cache_ram.vhdl) to make a compile-time
choice to make r1_out either combinatorial or rising edge set.

this would allow the old behaviour to be preserved at the choice of the



crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

More information about the Libre-soc-dev mailing list