[Libre-soc-dev] microwatt / libresoc dcache

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri May 7 04:57:09 BST 2021


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

> On Fri, May 07, 2021 at 12:27:38AM +0100, Luke Kenneth Casson Leighton
> wrote:
>
> > 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?
>
> That block is combinatorial, since it's process(all) and has no if
> rising_edge(clk) then ... statement.  So it's the current r1.


ok whew.  so i am reading VHDL correctly.  same thing repeated below in
different ways, reinforcing the understanding.


> If you mean you're seeing valid data two cycles after presenting the
> address, that's how it's meant to work.


i believe it possible to remove one of those on real mode LDs.

now, it may be useful to introduce a pipeline stage elsewhere, it just
seems anomalous design.

i think what i am saying is that cache_ram.vhdl having the ADD_BUF delay
inside *cache_ram.vhfl itself* is completely unclear.

i would expect that rd_data0 to be in *dcache.vhdl*, placed into a data
structure that is explicitly marked and documented, "this is part of a read
pipeline"

whereas right now there's one pipeline path in dcache.vhdl for control
signals... oh and a totally separate pipeline which happens to be the exact
same length except it's in cache_ram.vhdl involving rd_data and rd_data0.

this does not seem sensible from a code maintenance and clarity perspective.



>  The constraint is really the
> TLB and cache tag matching and consequent hit/miss detection and cache
> way determination, which takes up essentially the whole of cycle 1.


ah additional context (sorry) i am tacking the phys path at the moment.


> Of course, you can always cram more into a cycle if you're willing to
> increase the cycle time, but in fact I want to take Microwatt in the
> other direction, towards more pipelining and shorter cycle times,
> given that registers are close to free on FPGAs.
>
>
understood.

l.



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


More information about the Libre-soc-dev mailing list