[Libre-soc-dev] microwatt / libresoc dcache
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri May 7 05:17:44 BST 2021
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
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.
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the Libre-soc-dev