[libre-riscv-dev] libresoc memory architecture
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Jun 23 21:52:05 BST 2020
On Tue, Jun 23, 2020 at 9:02 PM Michael Nolan <mtnolan2640 at gmail.com> wrote:
> On 6/23/20 3:52 PM, Luke Kenneth Casson Leighton wrote:
> > question: where do the PowerISA MMU tables get the information from about
> > which bits are IO, RAM, or other?
> > answer: they come from the information about the physical memory map.
> Wouldn't they come from the software that sets up the page tables?
and that software would need to read the information from somewhere,
in order to know what it was, and consequently by another level of
indirection we come back to that exact same hardware map function /
everything comes back to that map which expresses, in hardware terms,
the relationship about whether a given read/write is to a valid
now, we *could* not have that hardware function, we *could* set up the
page tables using software-only, but i am guessing / working-out that
this would imply that the MMU was now a soft-MMU.
and a soft-MMU has a maaassive performance penalty. every single page
now has a hundred if not a thousand cycles overhead.
also if that hardware-level function does not exist and has to be done
in software (in the kernel), the performance penalty is *really*
also, some of the granularity of the register maps for peripherals is
only a few bytes, certainly not an entire page.
basically all round: Generally Bad Performance.
so we need the hardware-level address-range-checking function, it
needs to be fast (called on every cycle of every physical-request).
this _is_ normal btw, to have this hardware-level function :) the
tables are read-only and contain peripheral physical memory-map start
address and end address.
for the IIT Madras code:
* each peripheral had a memory length (relative address). when
connected up, this became an absolute physical address range.
* each "Bus" (containing peripherals) had its own "valid_address"
function that checked each sub-peripheral to see if the read/write was
* further up the tree (a "Bus of Buses"), these functions were also
called on the sub-buses to check whether one of the sub-buses...
... you get the idea.
it's actually very simple and not a lot of work, being pretty much
exactly the same as how PowerDecode works.
More information about the libre-riscv-dev