The CPU card can be used a main host CPU - owning the memory of the mainboard and using the local SRAM as 2nd level cache to accelerate the system.

I would like to invite people to discuss the usage as host CPU together with us now - and which options we have to configure the Card most effectively.

Let me give you some more information.

Features of the CPU card:
  One 68060 CPU.
  The 68060 CPU has 8KB ICache and 8KB DCache.
  4MB Local SRAM.
  The SRAM has a extrem low latency.
  The SRAM has a theoretical memory throughput of around 400MB/sec.
  Of course the 68060 has a busprotocol and because of
  protocol overhead and depending of the CPU clockrate
  the 68060 can not use every possible MB/sec of SRAM bandwidth.

  With normal C-code the 68060 can currently read about 160 MB/sec from the SRAM and can copy about 155 MB/sec.

  The CPU card is connected to the NATAMI MX over the SyncZorro port.
  The SyncZorro is a direct connection to the mainboard FPGA which acts as main memory controller/Northbridge.
 
  This design CPU card - connector - northbridge  is similar to how Early PC/Athlon systems and Pegasos or AMIGAOne were designed - with the difference that the CPU card on the 68060 features a quite large 2nd level cache.

The mainboard DDR2 memory has a bandwidth of around 1000 MB/sec.

Its worth to note that a 68K CPU is not able to utilize 1000MB/second.
A 68060 CPU can in theory with optimal conditions copy about 250 MB/sec maximum. Under "normal" conditions with normal code a 68060 is able to copy about 160 MB/sec.

The SyncZorro interface is able to transfer this amount of data,
This means even without the local SRAM on the CPu card - the 68060 would be able to copy 150 MB/sec of main memory.

The local SRAM has some advantages.
It does offload the main memory system, this means as long as your program operates somewhat locally in 4MB the CPU will work mostly in its 2nd level cache and not use the mainboard memory. This means the whole mainboard bandwidth of around 1000MB/sec is available to the Blitter and Co.

Another important feature of the SRAM is its very low latency.
This means algorithms which jump around a lot in memory, like software texture lookups, e.g. Demo effects like Rotozoom, array lookups etc  - will run a magnitude faster from the 2nd level cache than the could from any DRAM.

Ok now that you know how the CPU card work -
I would like to ask you for your opinion about the setup.

The 68060 1st level cache supports two options:
A) Caching as Writethrough
B) Caching as CopyBack

Both options have their PROs and CONs.

I wonder if it would make sense to map all the mainboard memory as "write through" cache able. This means the the CPU will push all writes immediately out of its 1st level cache, to the 2nd level cache and this will echo all writes down to the mainboard.

This disadvantage of this mode is that the CPU card will generate a constant write stream of data down to the mainboard.
Technically this is no problem as the Synczorro port can trasnfer all the writes and the mainboard memory can easily "eat" all of them.

The advantage of this mode is that the 1st level cache will not get polluted with any memory regions which are only written too.
Like e.g. framebuffer generated in fastmemory.
The CPU will just echo each write to such memory immediately and it will get pushed down to the main memory.

The other option would be to run the memory map in "copyback" mode.
Copyback more allows keeping memory operations "inside" of the CPU.
This means with stack operations like e.g storing parameters or return address on the stack - this stays inside the CPU and creates less noise on the memory bus. Copyback is ideally for Stack memory.
For framebuffer copyback is bad. As copyback would initiate a line-load on touched memory regions - which is totally unneeded for such cases.

What do you think?
What is your opinion?
Would in your opinion a mixed mode make sense?

My idea on this is to use only half of the SRAM as CPU Cache use Writethrough and use 1MB for stack and context switches, and 1MB to shadow Kickstart and drivers.
Doing this would reduce the bandwidth usage of the Szorro bus freeing up bandwidth for future adapters to operate consecutive with the 68060 CPU card.

Or isn't that one of the Goals here?

Yes, setting up the memory this way would be absolutely possible.
The memory map of the 4MB SRAM can be configured in the CPU-Card FPGA.
This means we have the option to use it as 4 MB 2nd level cache.
or
2MB 2nd level cache and 2MB local store.
Localstore e.g. Holding Kickstart and extra Stack memory.

Which option gives the most benefit is the key question. :-D

Could you introduce the mixed mode please?

thank you.

With mixed mode I mean running some part of the memory as writethrough and some as copyback.
Or meaning using part of the SRAM as cache and others as stack localstore.

I was asking people with knowledge about Amiga OS and experience in programming to participate in the PRO and CON discussion.
People with programming background can build a sensible opinion an about this based on the provided information.

Of course if you have no programming background but want to learn something you are invited to ask questions.

What i was thinking of was how to offload the bus and reduce latency in these cases.
This should result in a more reactive system.

I think that the characteristics of the copyback mode (CF "copyback more allows keeping memory operations inside of the CPU. This means with stack operations like e.g storing parameters or return address on the stack - this stays inside the CPU and creates less noise on the memory bus.") induce this choice.

This is IMHO the best of both worlds if the L2 cache controller can be intelligent enough.

Reserving some space for a local store isn't a good use of the resources with such a large L2 cache.

What about DMA? Can components DMA into this memory, or is it "local" to the 68060? Does the 68060 snoop only this memory, or all memory? (It might be that it cannot snoop all memory because the Natami bus is probably too fast for it).

Gunnar von Boehn wrote:

The CPU card can be used a main host CPU - owning the memory of the mainboard and using the local SRAM as 2nd level cache to accelerate the system.

If this is a second level cache, where is its cache controller? Or do you mean it is RAM that just appears under a specific hardware address and the CPU can use it to "cache" something manually?
 
Is this a "full" 68060 or the econo^H^H^H embedded controller version? (-;

Gunnar von Boehn wrote:

The CPU card is connected to the NATAMI MX over the SyncZorro port.

How much of the Zorro bus cycles are visible to the CPU? Say, if the blitter moves chip memory, does the CPU recognize such cycles? On a standard Amiga design, it wouldn't, thus blitter cycles cannot be snooped.

Gunnar von Boehn wrote:

The local SRAM has some advantages.   It does offload the main memory system, this means as long as your program operates somewhat locally in 4MB the CPU will work mostly in its 2nd level cache and not use the mainboard memory.

I guess I would need to understand this somewhat better. If this is really like a cache, then there should be mechanisms that synchronize this cache with the main memory. That is, I somehow need to "push" cache modifications in this RAM area to the board RAM. How is this done? Similarly, how do I allocate lines in this cache, and how do I invalidate it? CPU instructions won't do that since the CPU cache controller of course knows nothing about this memory.

Gunnar von Boehn wrote:

This means the whole mainboard bandwidth of around 1000MB/sec is available to the Blitter and Co.

Why wouldn't it without this memory? Usually, the blitter *may* (if the blitter nasty bit is set) overrule the CPU cycle allocation in the classical design - isn't that possible here?

I'm asking because I'm usually "afraid" of complicated designs - the win needs to outweight the complexity. Complexity means people need to understand it correctly, and not understanding it correctly leads to bugs, and bugs lead to stability problems.

Gunnar von Boehn wrote:

Another important feature of the SRAM is its very low latency.   This means algorithms which jump around a lot in memory, like software texture lookups, e.g. Demo effects like Rotozoom, array lookups etc  - will run a magnitude faster from the 2nd level cache than the could from any DRAM.

I also need to understand a bit more. How much do these programs run out of the first level cache such that they profit from a second level cache? Or is it a second level cache?

 

Gunnar von Boehn wrote:

Ok now that you know how the CPU card work -   I would like to ask you for your opinion about the setup.

I first need to understand the question. Then the answer will be 42. No, wait, wrong...
 

Gunnar von Boehn wrote:

The 68060 1st level cache supports two options:   A) Caching as Writethrough   B) Caching as CopyBack     Both options have their PROs and CONs.     I wonder if it would make sense to map all the mainboard memory as "write through" cache able. This means the the CPU will push all writes immediately out of its 1st level cache, to the 2nd level cache and this will echo all writes down to the mainboard.

Likely not. This keeps the push-buffer of the CPU busy, and writing out *local* data that is already in the CPU cache and thus very close to the core to memory that is far away from the core does not sound like a good idea to me. Even if the CPU can access the external SRAM at full bus speed, this still means that this access is *likely* slower than any write that remains local in the first level cache.

Gunnar von Boehn wrote:

This disadvantage of this mode is that the CPU card will generate a constant write stream of data down to the mainboard.   Technically this is no problem as the Synczorro port can trasnfer all the writes and the mainboard memory can easily "eat" all of them.     The advantage of this mode is that the 1st level cache will not get polluted with any memory regions which are only written too.

Huh? Yes, they will. The 68060 uses write-allocation, thus even if you write through, the data will end up in the cache.

Gunnar von Boehn wrote:

For framebuffer copyback is bad. As copyback would initiate a line-load on touched memory regions - which is totally unneeded for such cases.

I don't quite understand? Basically, what you need to do in case write allocation is a problem is that you need to configure those memory regions where it is as non-cachable, typically chip mem. If the CPU can snoop, writethrough *might* work, though I'm not yet quite clear on the implications.

Thanks,

Thomas