|
---|
| | Vincent Rivière
Posts 87 31 Oct 2016 21:36
| I have been told that the Apollo Core handles the CPU caches transparently. In other words, that the caches are always on, and that the CINVA instruction has no effect. This looks quite surprising, so I would like to have more information about how to write correct code. Here are a few very common cases. 1) Load a program and execute it. The classic approach is: - flush the data cache so the freshly read data will really be stored to RAM - invalidate the instruction cache to force the CPU to load new instructions from RAM How does the Apollo Core handles this scenario? Is there some internal synchronization between the Instruction and Data cache, so maybe the RAM is not involved at all? 2) Read data with DMA The most common case is floppy track data read with DMA. The DMA will store the data directly into the RAM. Then the CPU will use it. But if the data cache is enabled, the CPU will read obsolete data from the cache, instead of the new data from actual RAM. How can the Apollo Core handle this situation?
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6254 02 Nov 2016 21:40
| APOLLO does cache fast-mem, but does NOT cache IO/Chipmem. This means a Floppy-DMA writing to Chipmem will go to chipmem. But Apollo will not cache chipmem. This means every access to this memory will be executed and we will always read latest version from memory. So this will work fine. Then Apollo does cache fastmem. Apollo has Harvard Cache design with 2 caches. 1 Cache for Instruction 1 Cache for Data Now if we for example read from IDE. The CPU will copy from IDE to Fast-mem. And update the memory and the DCache... Icache and Dcache of Apollo communicate. This is a new feature. All old 68K did only update DCache on writes. Apollo will also update the Icache... This means Icache is automatically always in Sync.
| |
| | Markus (mfro)
Posts 99 03 Nov 2016 05:45
| Gunnar von Boehn wrote:
| This means Icache is automatically always in Sync. |
I guess this mechanism will need to be extended (or "classic" cache flushes/invalidates implemented which would probably be more efficient as only the code itself knows about the right time to update) once you start integrating DMA-like functionality into the FPGA (i.e. in the standalone device)?
| |
| | Vincent Rivière
Posts 87 03 Nov 2016 09:59
| Gunnar von Boehn wrote:
| APOLLO does cache fast-mem, but does NOT cache IO/Chipmem.
|
OK, this avoids any trouble.BTW: I'm pretty sure that the QINDEX22 benchmark with EmuTOS for Amiga has been run from Chip RAM (so, with caches disabled). I would be curious to see the result from FastRAM :-)
| |
| | Szyk Cech
Posts 191 03 Nov 2016 14:49
| I suppose DCache is whole outdated after DMA writes to Chip memory. But I suppose ICache will NOT be outdated after DMA writes to Chip memory. Is that true?!? Or maybe whole (DCache and ICache) are reread after DMA writes to Chip memory?!?
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6254 03 Nov 2016 22:55
| Szyk Cech wrote:
| I suppose DCache is whole outdated after DMA writes to Chip memory. But I suppose ICache will NOT be outdated after DMA writes to Chip memory. Is that true?!? Or maybe whole (DCache and ICache) are reread after DMA writes to Chip memory?!?
|
Not sure I understand you. According to Commodore/Amiga guidelines - the Dcache will NOT cache the chipmem. So there is no problem at all - and nothing to worry about. ;-)
| |
| | Markus (mfro)
Posts 99 04 Nov 2016 08:16
| So the conclusion is - from what I learned from IRC - Apollo core currently just doesn't allow any other bus master than itself to the FPGA internal bus. Makes things a whole lot simpler.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6254 04 Nov 2016 18:50
| Markus (mfro) wrote:
| So the conclusion is - from what I learned from IRC - Apollo core currently just doesn't allow any other bus master than itself to the FPGA internal bus.
|
Err, no this is not how is it. The fact is that the AMIGA chipset bus and the 680x0 CPU Bus in the Amiga are not fully connected. The CPU can _NOT_ see DMA writes of the Chipset. Therefore its impossible for any CPU or Accelerator in the AMIGA to snoop them. This is not a limitation of the 68000 not Apollo-68080 this is how the AMIGA bus and chipset were designed.
| |
| | Markus (mfro)
Posts 99 04 Nov 2016 19:14
| Gunnar von Boehn wrote:
| Amiga are not fully connected. The CPU can _NOT_ see DMA writes of the Chipset. Therefore its impossible for any CPU or Accelerator in the AMIGA to snoop them. This is not a limitation of the 68000 not Apollo-68080 this is how the AMIGA bus and chipset were designed.
|
Aha. Understood. Thanks, Gunnar.
| |
| | OneSTone O2o
Posts 159 06 Nov 2016 12:38
| How about ATARI, would Apollo be able to detect DMA transfers there (ACSI/FDD-DMA, STE/TT-DMA-Sound, but this is read only)?
| |
| | John William
Posts 570 09 Nov 2016 01:51
| Gunnar von Boehn wrote:
|
Markus (mfro) wrote:
| So the conclusion is - from what I learned from IRC - Apollo core currently just doesn't allow any other bus master than itself to the FPGA internal bus. |
Err, no this is not how is it. The fact is that the AMIGA chipset bus and the 680x0 CPU Bus in the Amiga are not fully connected. The CPU can _NOT_ see DMA writes of the Chipset. Therefore its impossible for any CPU or Accelerator in the AMIGA to snoop them. This is not a limitation of the 68000 not Apollo-68080 this is how the AMIGA bus and chipset were designed.
|
That works for me EXTERNAL LINK
| |
|