Sorting of data from instructions ( ARM I-cache and D-cache )

Question

Some ARM cores like the ARM9 family of cores have a Harvard Architecture, at least at the cache level. That is they access two seperate caches, an I-cache for instructions and a D-cache for data ( example ARM926EJ-S ).

However the I & D caches wind up being interfaced to plain vanilla SDRAM externally. So it seems that at the RAM level we are back to the von Neumann design where one store ( SDRAM ) holds instructions >and< data.

In the example designs I've seen there seems to be just one single bus interfacing the SDRAM to the SOC chip.

How are the instructions and data differentiated, sorted and routed from the combined bus interfacing the external SDRAM to the internal I and D caches?

Answer 1

The control logic records why it issued a particular fetch to a particular address, so it can do something sensible with the result. There will be a small queue of outstanding fetches (remember, fetching from DRAM may take hundreds of cycles). On a value arriving, it's written back to the part of the architecture that requested it, and the relevant part of the processor's pipeline is un-stalled.

Answer 2

the L1 cache is often in the arm core, sram, very fast, L2 might be off chip might not.

The real answer to your question is go to infocenter.arm.com then go to the AMBA link on the left side then download one of the AMBA or AXI specs, even the oldest one there AMBA2 is okay.

Inside the core if there is an L1 cache the processor knows if a memory access is an instruction fetch or data, and that information is put on the internal bus and if the cache is enabled it will look up that result before going to the edge of the core. the edge of the core is some flavor of amba, ahb, or axi bus which has as one of the bits on the bus an access type which includes among other things cacheable or not. So whatever is glued onto that, in particular if the vendor has purchased L2 cache logic from arm to glue onto this core, that L2 logic will, using the items on the bus, look for and possibly return the result to the core. Otherwise goto main memory on the other side of the l2 cache (also an amba/axi/whatever bus) to resolve the transaction or evict something needed to complete the transaction, etc.

The differences in flavors of ARM busses or versions, can/will provide more or less information depending on the bus details. But if the system is capable of having a cache the transaction will indicate cacheable or not and indicate in some way instruction from data (if that cache can separate the two L1 might be able to and L2 might not for example L1 to some extent drives what is in L2)