[Libre-soc-dev] microwatt / libresoc dcache

[Luke Kenneth Casson Leighton]

On Thursday, May 6, 2021, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
> a normal SRAM you would expect a 1 clock cycle delay, all good.  except
> here, an *extra* cycle of delay is added.  after assertion of the read it
> is *two* cycles before the data appears on the read data output.
>
> i have no idea why, and i'm not skilled enough at VHDL to work out how to
> remove it.
>

illustration, control_writeback:

https://github.com/antonblanchard/microwatt/blob/master/dcache.vhdl#L990

the logic there is reading all its decisions from r1.  dout.valid etc, the
data itself, all comes from r1.

r1 was set up with a single clock delay from r0, r0 was set up
combinatorially.

the question i have is: is control_writeback making its decisions from the
*current* r1 or is it making its decisions from the *future* r1?

i have seen VHDL set values that get used in the same cycle, like variables
in normal software programs.  very odd to have that in an HDL.

how does dout.valid get set? it is equal to r1.ls_valid.  for LOADs, how
does r1.ls_valid get set? in NC_LOAD_ACK and RELOAD_WAIT_ACK.

all good... except... does that setting of r1.ls_valid get picked up *in
the same cycle* by control_writeback? or does control_writeback react to
the values in r1 on the *next* cycle?

this is an aspect of VHDL that has me confused.  also, if it is the *next*
cycle it would explain why we are seeing a 2 cycle delay on LD cache reads.

l.



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