Concept and Interface of
the Cache Package for the virtual motherboard
Access to RAM over the virtual bus can be slow compared to a builtin simulator.
Therefore, as with real hardware, we use caches to reduce the overhead of the bus.
In the moment we assume having one CPU only, that is, one process that
reads and writes the cache. To make the cache as fast as possible, especially
on systems with several (real) CPUs, other threads - collectively called service threads -
will take care of the interfacing the cache with the virtual bus.
As a general rule, access to the resources should have no, or very little overhead,
in the (normal) case where we do not need the virtual bus.
Because we move access to the virtual bus into separate processes, all forms
of access to the bus is affected. That is, also interrupts, power-on, power-off
and reset, and registration.
This is a simple case, but illustrates the problem. A typical CPU will
check for interrupts once per cycle. If the CPU thread checks for input on the
virtual bus that can be very time consuming. Here is the solution:
We have 64-Bit interrupt vector. The CPU Thread is allowed reading it at any
time. If it is 0, there is no interrupt and the CPU thread can continue. This is the
normal, fast case. If the bitvector is not zero, an interrupt has occurred
and things become different. In this case, the CPU can lock the bit-vector,
copy bits into private variables (typically with an or operation) and reset
the bit-vector to zero.
If an interrupt arrives, the service thread will also lock the bitvector and add a bit to it.
Locking ensures, that write operations on the bit-vector are atomic. The read operation
is not atomic. The CPU gets a snapshot of the bit vector. This is, however, not
a problem. It will see the complete changes, either when locking it or if the
bit-vector is still zero, on the next cycle.
Reset, Power-on, and Power-off
Power is for the CPU thread a read only variable. There is no synchronization
needed. The CPU might miss short power-fails, if it isn't checking fast enough.
Reset needs a kind of acknowledge. Reading the reset variable again needs
no synchronisation. Resetting it to zero needs locking.
Startup and Shutdown
This is done by (one of) the service threads after the threads are started.
The service threads will shut down together and (one of them) will take case
A multiway cache is organized as an array of sets of lines. A given
address for memory access is mapped to a set typically by ignoring n low-order Bits and
m high-order Bits. After stripping these bits off, the remaining bits
are the index into the array of sets.
Within the set, there are up to k lines (1<= k).
Each line consists of a start address, 2^n content byte, and again
some administrative information. Next, we match the given address against
the start adresses in the set, neglecting the n low-order bit.
If the given address matches one of the start adresses in the set,
we have a cache hit. The content byte of the line are a valid copy of the
memory at the start adress of the line. In this case, we can use the n low-oder bits of the address
as an indes into the 2^n content byte and access the cache content for the
given address. If there is no match, we have a cache miss. The cache does not
contain any information about the data at the given address.
The number of lines in a set is limited by k. Therefor, we implement a set of
lines as an array with k elements and add to each line a status flag.
If this flag is zero (easy to test) the cache line is part of the set
and read to use.
We provide for a separate data and instruction cache. A second-level cache
might follow at a later point.
If data is requested from the cache, the cache organization
let you find easily a matching cache line. The sets are searched linearly.
If we have cache hit, we can retrieve or store data in the cache line found.
For later use each access on the cache will increment an access counter
(wrap around like a gigantic clock) for the cache as a whole, and stores
the time of the last access in the set.
If we have a cache miss, things are more complex. We have to read the data
over the bus and store it in a cache line, before we can continue in the same
way as with a cache hit. To read the data, we have to interface with the
service tread. To store the data in the cache, we have to find a cache line
that will hold the data. If there is an unused line in the set, we use it.
If all lines are in use, we find the least recently used and reuse it.
Before we can reuse the cache line, we have to check if there were any write
operations on this line. If so, we have to update the memory over the bus before
Locking, Waiting and Threads
The main part of the line is the data_address pair, which contains beside
data and address also status and size. The size is non negative can be less or equal to LINESIZE
The status can be Valid, Invalid, Reading, or Writing.
A line that is invalid is as good as non existing. Only the CPU thread can
change a line from Invalid to something else. No locking is required.
A line that is valid is under complete control of the CPU thread. The service
thread will never touch it.
A line that is valid can be changed by the CPU thread to reading or writing.
It should then forward the line to the service thread, otherwise it will keep that status forever.
A line that is writing is under the control of the service thread. The bus-write thread will
issue a bus message for the write operation and change the status back to valid
and reset the dirty flag. It will signal the CPU thread that a line became
valid again, just in case the CPU thread was waiting for it. If several write requests
are issued, the CPU can still wait only for one of them. If it is not the one it was
waiting for. It can continue waiting.
A line that is reading is under the control of the service thread. The bus-write thread will
issue a bus message for the read operation. Then it will forward the line as pending
to the bus-read thread. When the answer for the read request arrives, the bus-read thread will
check the pending lines, find the line and store the data received. It will then set the
status back to Valid and signals the CPU thread.
Note that only the CPU thread will ever set the address for a line. So what if an answer
arrives and there is no pending line for it? This should not happen in the first place
since requests are made only for lines that are pending.
If it happens anyway, the answer is ignored.
It might very well happen that a line becomes valid but the CPU is not waiting for a signal.
For instance there might be an instruction prefetch that causes a read operation on the
instruction cache. The CPU will issue the read but will not wait for it to complete.
Then the execution may take a different route and the data will never be needed. Or the
execution proceeds as predicted. In this case we will read the instruction, and it might be
in the cache as valid or as reading. In the later case the thread starts waiting for it
until the read completes.
By launching several read or write requests it can happen that the CPU thread can not
find an INVALID or VALID line for the next request. In this case, it will have to wait
until the first line in the set becomes valid.