|
Message
From: =?unknown-8bit?Q?Gy=F6rgy?= 'nog' Jeney<nog@s...>
Date: Sat May 14 21:50:58 CEST 2005
Subject: [openrisc] [or1ksim #85] [RFC] Overhoul memory code
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.
Another question, what is the `effective address' of the bus error if it is
generated while refilling a cache line but not while getting the data that was
asked for? In the present code it's that of the access that prompted the refill
in the first place. I'm not convinced that this always such a good idea.
(However, I do realise that this is something that should never happen).
> i still don't understand the evalsim_mem* and setsim_mem* changes, in
> particular the virtual address part. (my notation is: virtual == effective
> address == [EA])
>
> [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.
>
> i always thought of evalsim_mem* functions as an abbstraction of you access
> to the bus (and depending on the address, appropriate device generates
> response). so you can see why i get confused when this function takes an
> virtual address parameter...
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.
> about the endianness stuff i'm ok with it either way if it will end up
> working in the end, and it woun't be a black magic to implement a new
> peripheral...
The black magic stuff is precisely what I want to avoid. It's confuseing enough
as it is.
nog.
|
 |
Browse
