[Milkymist-devel] New repositories

[Sébastien Bourdeauducq]

Hi,

On Thursday 20 August 2009 13.58.18 Takeshi MATSUYA wrote:
> I think memory cache problem (between L1 and L2).

When booting Linux all memory accesses are done by the CPU, and go through the 
whole cache hierarchy. You only have cache coherency problems when different 
peripherals access the memory in different ways.

For example, if a peripheral does a DMA write through the L2 cache, you must 
invalidate the L1 cache before reading that data, or you may read an old value 
that is in the cache instead of the up-to-date value written by the 
peripheral. You can have a look at the source code of the sound driver 
(demo/snd.c) which implements this case.

From the CPU, you have only one case of cache coherency problem - when the 
code is self-modifying, because the CPU has separate instruction and data 
cache with no form of hardware cache coherence protocol between them. You can 
write code to memory which is not updated in the instruction cache, and then 
when you try to execute it, the CPU still gets the old instructions from the 
instruction cache. To prevent this, the instruction cache is invalidated 
before running the code (see bios/boot.c l.35 for an example).

NB. The caches in Mico32 use a write-through write-no-allocate policy, ie. on 
a write:
- if the write does not hit the cache, it is simply sent directly on the bus 
and the cache state is not affected
- if the write hits the cache, it is also sent immediately on the bus and the 
cache line is updated with the new value

The advantage is that you never write to memory when evicting a line on a 
cache conflict or flush, therefore dealing with coherency is simpler.

> Data cache cause many troubles.

It does not in most common cases, and provides a performance increase that we 
definitely need.

> for example,
> Page table data is invalid (out of range).
> ......

Can you elaborate?

> Did you try my binaries with data cache disabled?

I will, but if it makes any change I see only two explanations:
1. race condition (bug in Linux locks) triggered by the performance increase 
from the presence of a data cache
2. bug in the processor design or incorrectly synthesized netlist when the 
data cache is present

I think (1) is much more probable than (2) - I've run quite a bit of code on 
Mico32 with D-Cache enabled without any problem; on the other hand, I tried 
running the Linux kernel with the "debug locks" option and it printed out a 
lot of errors...

Sébastien