66AK2H06: question about L1P cache

Hi,

Please look at the same corepac document, Figure 1-1 C66x CorePac Block Diagram. Whether L1P is set up as cache or RAM, the fetch still happens.

Also, 2.3.1 L1P Cache Architecture
The L1P cache is a direct-mapped cache, meaning that every physical memory location
in the system has one possible location in the cache where it may reside. When the DSP
attempts to fetch a piece of code, L1P must check whether the requested address resides
in the L1P cache.

When the code is fetched, it is check inside L1P cache to see if already cached or not.

Regards, Eric

Hi,

This is explained in 2.3.1 L1P Cache Architecture

When the DSP
attempts to fetch a piece of code, L1P must check whether the requested address resides
in the L1P cache. To do so, the 32-bit address provided by the DSP is partitioned into
three fields (tag, set, and offset), as shown in Figure 2-1.
The offset of 5 bits accounts for the fact that an L1P line size is 32 bytes. The cache
control logic ignores bits 0 through 4 of the address. The set field indicates the L1P
cache line address where the data would reside, if it were cached. The width of the set
field depends on the amount of L1P configured as cache. L1P uses the set field to look
up and check the tag for any already-cached data from that address, as well as the valid
bit, which indicates whether the address in the tag actually represents a valid address
held in cache.

For the L1D, this is explained in 3.3.1 L1D Cache Architecture
L1D cache is a two-way set associative cache, meaning that every physical memory
location in the system has two possible locations in the cache where it can reside. When
the DSP attempts to access a piece of data, the L1D cache must check whether the
requested address resides in either way of the L1D cache.

The offset of six bits accounts for the fact that an L1D line size is 64 bytes. The cache
control logic ignores bits 0 through 5 of the address (the byte, bank, and sub-line fields).
Bits 0 through 5 only determine which bank and which bytes within a bank to access;
thus, they are irrelevant to the cache's tag compare logic. The set field indicates that the
L1D cache line address where the data would reside, if it were cached. The width of the
set field depends on the amount of L1D that you configure as cache, as defined in
Table 3-1 below. Use the set field to look up and check the tags in each way for any
already-cached data from that address as well as the valid bit, which indicates whether
the address in the tag actually represents a valid address held in cache.
The tag field is the upper portion of the address that identifies the true physical location
of the data element. The cache compares the tag to the stored tags for both ways of the
L1D cache.
If one of the tags matches and you set the corresponding valid bit is set on reads, then
it is a “hit,” and the data cache returns data to the DSP directly from the L1D cache.
Otherwise, the read is a “miss”, and the DSP stalls while the request is sent on to the
Level 2 (L2) memory to fetch the data from its location elsewhere in the system.
The DSP can also write data to L1D. When the DSP performs a store, the L1D performs
the same tag comparison as it does for reads. If a valid matching tag is found, then the
write is a “hit”, and the data is written directly into the L1D cache location. Otherwise,
the write is a “miss” and the data is queued in the L1D write buffer. This buffer is used
to prevent DSP stalls on write misses. Since the DSP does not wait for data to return on
writes, there is no reason to stall during the L2 access.

If you set L1D as all RAM, there is no such valid/dirty bit.

Regards, Eric