[Libre-soc-dev] microwatt / libresoc dcache

[Luke Kenneth Casson Leighton]

On Friday, May 7, 2021, Paul Mackerras <paulus at ozlabs.org> wrote:

>
> When you talk about a two clock delay, I don't know whether you are
> rounding up or rounding down.  In other words, do you mean 2 cycles
> plus setup plus clock-to-output, or are you considering 1 cycle plus
> setup plus clock-to-output to be two cycles?


clk             rise  fall  rise fall  rise  fall
rd_in:          1      0      0     0     0      0
rd0_data:   00  00     NN  00  00  00
rd_data:     00  00    00    00  NN 00

the 1st process i understand to be a 1 clock delay from rd_in to rd_data0
being set.

the 2nd process, by also being a rising edge and by taking its output from
rd_data0 and placing it into rd_data, introduces a 2nd clock delay.

thus the total time taken is 2 clock cycles from when rd_in went high to
when rd_data is valid.

essentially, i am questioning why ADD_BUF was added.

of output signals from
> > dcache.vhdl is clear?
>
> No, I think I would need to see a patch to understand what you're
> driving at;


i can do a couple of partial ones, as you've probably gathered i am not a
VHDL "writer" expert yet.  another 6-8 months and i may be.  what i send
you will need checking and completing is what i mean.


>  but from what I gather, you're worried about the path
> through the cache data RAM - but that's not the critical path.


not "worried", just questioning why ADD_BUF has been added to the code.

to see what i am getting at, try setting ADD_BUF=false then cascading
through the code changes needed to get the rd_data to be valid within
dcache.vhdl itself - on the *real* path, not the virt path.

l.



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