[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] F-CPU architecture...
hi,
Bogdan Petrisor wrote:
--- Yann Guidon <whygee@xxxxxxxxx> wrote:
Then we can go on : first, dust off the vital files (VHDL and other
source code) and then update the manual.
Hey, count me in for that. I've always hated PDF (except for resumees). If you want me to convert the bloody manual to HTML just say so :D:D
the original format was HTML.
and usually, it takes a few day of work to translate or change a format,
but it takes months to update the contents......
Now if I can divert a bit your attention to more boring questions. As fas as I understand from the
manual F-CPU uses virtual adresses right? Since the PC is 64 bits(just like a noral register)
stop ! the PC is not a real register.
in fact, there is no PC. It is just provided as an artifact
for old-school programming.
"PC" is just a read-only port as seen from the Xbar.
it is "built" at every cycle by the Fetcher, which concatenates
several internal fields and counters. that's all.
The PC is "advanced" simply because the running counters
are incremented to (speculatively) provide new instructions to
the instruction decoder.
and the pases
pages ?
can have several sizes (4 KiB, 32 KiB, 256 KiB and 2048 KiB .. page 42 of the manual) am
I right to assume that 21 bits will be used for offset (the lower ones) and the rest 43 bits for page?
no, and in fact there is no reason to think about that.
The TLB will receive 21 bits, or whatever it is the log2 of the largest
page it can hold.
that's all.
Also from the same page: "The internal TLBs are software-controlled through a set of Special
Registers. No microcode or hardware mechanism is foreseen that will help search a page table entry
in memory. An OS exception is triggered whenever a task issues an instruction that access a memory
location that is not in the internal Page Table (TLB)."
So then basically the fetch unit must get the instruction from ICache and trow and exception when
it doesn't find the page. Right?
- The Fetcher SPECULATIVELY fetches instructions from the L1 I-cache and
from outside memory in case of a miss.
- The Fetcher is composed of several "lines" (say, 8 for a start). These
are a sort of "cache" for the L1 cache,
but with many ports (read ports go to the decoder and I-L1, write ports
are fed by the external memory and the L1).
- Each line contains a field that says if the translation is OK, and an
additional field contains the "virtual address"s MSB
(so that the PC can be rebuilt)
- there is also a flag that says the size of the page. It is used both
for rebuilding the PC and to trigger a TLB lookup
when the internal counter overflows (we have to know which of the
counter'sbit will trigger the lookup).
This way, there is no interrupt/trap as long as the TLB contains entries
to all the software's code (when in user mode,
because this is not active when in supervisor mode). If the code spread
on several pages that are already in the TLB,
no trap will occur. The best part of it is that the TLB check occurs
speculativeley : the Fetcher's lines
work like a double-buffer, and whenever on line of a pair is not used
anymore, it fetches instructions
while the other line of the pair is being used. So the spurious TLB
lookup does not add latency.
When the "PC" goes beyond the limit of a page and there is not TLB entry
to the new address,
the corresponding page is marked as "bad" and whenever it is selected
for fetch (that is :
when an instruction is fetched from this line), a trap occurs. Because
of the speculative nature
of the Fetcher, we can't trigger a trap when a TLB returns false : it is
possible that the last
instruction of a page is a jump to somewhere else.
You see, it is quite complex, the function arises from the collaboration
of several specialised units,
rather than a single "black box" (that's why the term "MMU" is not
suitable at all).
And developping the Fetcher+LSU+TLB+Cache memory system is not as easy
as creating
an execution unit, because there are a LOT of side effects.
YG
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/