|
Message
From: Matjaz Breskvar<phoenix@o...>
Date: Sun May 15 19:11:39 CEST 2005
Subject: [openrisc] [or1ksim #85] [RFC] Overhoul memory code
* Gy?rgy 'nog' Jeney (nog@s...) wrote:
> Since you brought up this whole effective address thing, what is the exact
> meaning of `effective address' when the arch manual says "DCBPR is written with
> the effective address"? Does it get translated by the mmu (the cache sits
> behind the mmu)? Currently it doesn't.
if somebody ins't up to speed with all the details in arch manual the DCBPR
is 'data cache block prefetch register'.
cache sits behind the mmu (like the ascii drawing below). let me first tell
you that prefetching is not yet implemented in the hardware as far as i
know.
so, in principle, if you write a EA to DCBPR, the hardware is responsible to
prefetch a physical block corresponding to the EA (at the time EA is written
into DCBPR), BUT this does not mean that MMU is behind cache. in hw you
could just go through MMU translation at the time of DCBPR write (and not
generate any exception) and use the PA to do the actual prefetch.
if DCBPR accepted physical address it would probably be usless in case you
use MMU, since the user would need to do the translation on his own. since
EA<->PA mapping can be dynamic you'd need to write extra code which would
find out EA->PA mapping... all this would in majority of cases negate any
positive effects of prefetch.
> > [EA] ---> [xMMU] ---> [Physical Addr] ---> [xCACHE] ---> [memory controler]
> > -----------------> [memory controler]
> > -----------------> [peripheral]
> >
> > actually after the cache 'memory' access goes to wishbone bus, where some
> > device 'owns' that portion of the memory (like memory controler, some
> > peripheral). if nobody owns it you get (in priciple) bus error.
>
> The evalsim_mem* functions now only hide stuff that is common to both eval_mem*
> and dc_simulate_read (same goes for setsim_mem*). You could say that I'm lazy
> and have just re-used the names for a different thing. Since I introduced the
> granularity specific callbacks, there should be no need for any sort of
> abstraction.
ok. but be careful, because EA (effectivly) holds a little bit more
information than just PA. since EA goes through MMU, you get cache inhibit
bit (and similar) in addition to PA.
for example if you have EA and you run it through MMU, you may get a valid
PA + information that cache inhibit bit is set. in this case hw will bypass
cache and go directly to memory....
feel free to commit this patch. if something will go wrong we can fix it
later (we are in the devel branch anyway, let's use it ;)
regards,
p.
|
 |
Browse
