DM6437 cache size questions

Anonymous

Hi All,

I would like to ask some questions on DM6437 cache size.

I have found on the first page of SPRS345d that there are:

I would like to know why there are two different counting schemes here? We count memory by bytes, sometimes words; but why here bit are also used as counting unit?

How can a single, individual, isolated bit, rather than as part of a larger unit (byte for char, 32 bit for int, etc.), be used in computation? If it is only as a single bit, the only way I can thought of is to to aid conditional judgments in which comparison results like "<", ">", "=" can be stored in as individual bits rather than occupying an entire byte(s), so that space can be saved.

Is it correct or not? Does the programmer or the compiler need to handle these single-bit storage-read operations?

If bit are used in the counting scheme, why not nibble (4 bits)?

Or I am totally wrong here and the use of both bit and byte in the counting here is just for clarification in the sense that the user can infer from this information (256/32=8, 640/80=8, 1M/128K=8) that each "byte" is defined as 8 bits (there can be different definition of byte)?

http://en.wikipedia.org/wiki/Byte said:

The size of the byte has historically been hardware dependent and no definitive standards exist that mandate the size.

In RTSC platform setting, the default value(s) for L1D, L1P and L2 cache are all zero-K.

If DM6437 has in its internal 32KB L1P, 80KB L1D and 128KB L2 cache, why are they by default as 0 here? If I am leaving them as 0 unchanged (the documents says they are "flexible allocation", does that mean from 0 to their (L1D, L1P, L2) maximum physical size are all OK? ), will the code still work on the EVM?

Another setting I have question on is that the drop-down menu for L1D cache allows a maximum of only 32K (byte or bit?), but according to specification DM6437 actually has 80KB "flexible allocation" size. Why here only a maximum of 32KB can be selected?

Could anyone explain these to me?

Sincerely,
Zheng

over 14 years ago

0 AmitMookerjee over 14 years ago

TI__Expert 3550 points

Hi Zheng,

DM6437 is byte addressable and all the cache sizes shown in the platform wizard are in bytes.

>If DM6437 has in its internal 32KB L1P, 80KB L1D and 128KB L2 cache, why are they by default as 0 here? If I am leaving them as 0unchanged (the documents says they are >"flexible allocation", does that mean from 0 to their (L1D, L1P, L2) maximum physical size are all OK? ), will the code still work on the EVM?

The default cache values used in the platform wizard are set to the device cache settings when it comes out of reset. Any real world application will definitely use the cache but you can write programs with the cache disabled as well.

The term flexible allocation refers to the fact that you can configure parts of onchip memory as cache and internal memory. There are discrete combinations which are supported by the device and the selection really depends on your application usecase.

You can visually inspect the relation between cache size and corresponding internal memory sections in the platform wizard. For example if you set L1D to 32k the corresponding internal memory section- L1DSRAM - is set to 80-32 = 48k(0xc000). This means that you have 48k on onchip data memory that your application can use. You can configure L1P and L2 caches in a similar manner.

Regards

Amit

0 Brad Griffis over 14 years ago

TI__Guru*** 125430 points

Zheng Zhao said:
I would like to know why there are two different counting schemes here? We count memory by bytes, sometimes words; but why here bit are also used as counting unit?

Chip designers tend to think of the memory in terms of bits while we the users tend to think of it in terms of bytes.

Zheng Zhao said:
If DM6437 has in its internal 32KB L1P, 80KB L1D and 128KB L2 cache, why are they by default as 0 here? If I am leaving them as 0 unchanged (the documents says they are "flexible allocation", does that mean from 0 to their (L1D, L1P, L2) maximum physical size are all OK? ), will the code still work on the EVM?

I don't completely understand your question but maybe I can explain a bit. In many devices you have no choice in how to utilize the internal memory. That is, the data sheet will simply tell you how many kilobytes are used as cache and how many kilobytes are available as SRAM. In our device you actually can configure this value which is why you have a dropbox available to configure it. Generally speaking we do not expect you to change these values at run time, though it is possible. You would have to be extremely careful not to lose data in the process.

Zheng Zhao said:
Another setting I have question on is that the drop-down menu for L1D cache allows a maximum of only 32K (byte or bit?), but according to specification DM6437 actually has 80KB "flexible allocation" size. Why here only a maximum of 32KB can be selected?

This is determined by the hardware itself. Page 8 of the DM6437 data sheet under "on chip memory" specifies that only 32KB of L1D is able to be used as cache. This is part of the design of the cache controller and is discussed in the 64x+ Megamodule Reference Guide as well (e.g. see Section 3.1.2 Features).

0 Anonymous over 14 years ago in reply to Brad Griffis

the increments are discrete (2's power) rather than any arbitrary value between 0 and 32 (13, 14, 15, 17, 21, etc.)?

Any ideas from the circuit design perspective on why it is like this?

I am asking this because on page 131 of SPRU977a, VPFE document, the line offset vaue takes only 32's multiples and ignores the 5 LSBs. Of course this is different from L1D (0, 4, 8, 16, 32) which are 2's power rather than ignoring bits (if we insist on viewing it from the perspective bit ignoring, then left two LSB, but the multiplication over 4=2^2 are still not consecutive numbers (0, 1, 2, 4, 8), so technically l1D increment interval is not purely decided by bits ignoring).

Sincerely,

Zheng

0 Anonymous over 14 years ago in reply to AmitMookerjee

Dear Amit,

AmitMookerjee said:

The default cache values used in the platform wizard are set to the device cache settings when it comes out of reset.

I am a bit confused. Do you basically mean:

All caches (L1D, L1P, L2) are zero by default. "Platform wizard" won't set them for you automatically.
The user is responsible for changing them to the desired value.

And can cache information be viewed in linker.cmd or .map file? I checked both files of my program (a "naked" program without BIOS) but did NOT find any "cache" section so I wonder if I have enabled them:

linker.cmd said:

/*-stack 0x00000800 /* Stack Size */
-stack 0x00004000 /* Stack Size */
-heap 0x00004000 /* Heap Size */

MEMORY
{
L2RAM: o = 0x10810000 l = 0x00020000
DDR2: o = 0x80000000 l = 0x2000000
}

SECTIONS
{
vectors > 0x80000000, RUN_START(_ISTP_START)
.bss > DDR2
.cinit > DDR2
.cio > DDR2
.const > DDR2
.data > DDR2
.far > DDR2
.stack > DDR2
.switch > DDR2
.sysmem > DDR2
.text > DDR2
/* .ddr2 > DDR2*/
}

beginning part of .map file said:

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
L2RAM 10810000 00020000 00000000 00020000 RWIX
DDR2 80000000 02000000 00057172 01fa8e8e RWIX

Actually, even in projects with BIOS support and although I do have selected (L1D=32K, L2P=32K, L2=128K) cache sizes in the platform wizard, I still cannot find any cache information in configPkg\linker.cmd and the Debug\ .map files. Am I actually using cache then? What's wrong here?

And if I do intend to set cache in linker.cmd, how should I do that?

Sincerely,

Zheng

0 Brad Griffis over 14 years ago in reply to Anonymous

TI__Guru*** 125430 points

Zheng Zhao said:

the increments are discrete (2's power) rather than any arbitrary value between 0 and 32 (13, 14, 15, 17, 21, etc.)?

Any ideas from the circuit design perspective on why it is like this?

I think it boils down to the way cache works. Any given address in memory will map to a very specific location (or locations) in the cache. The number of places to which it maps is given by the cache associativity. In order to have "nice" correspondence of a given memory location and its position within the cache you generally want to be able to just extract specific bits out of the address. Forcing the cache size to be a power of 2 makes this easy/possible. If you had a weird cache size line 18KB then it would require math to figure out where a given address in memory actually maps into the cache!

0 Anonymous over 14 years ago in reply to Brad Griffis

Dear Brad,

Got it, thanks.

Zheng

0 AmitMookerjee over 14 years ago in reply to Anonymous

TI__Expert 3550 points

Hi Zheng,

Zheng Zhao said:

Actually, even in projects with BIOS support and although I do have selected (L1D=32K, L2P=32K, L2=128K) cache sizes in the platform wizard, I still cannot find any cache information in configPkg\linker.cmd and the Debug\ .map files. Am I actually using cache then? What's wrong here?

The RTSC platform is our software abstraction for managing device/board specific configuration. Most often we use it to specify the device clock speed, cache settings and external memory. Software components like SYS/BIOS reflects on these settings and initializes the device. In this particular case the actual cache registers are programmed based on the settings specified by your platform. You will not see the cache settings reflected in a linker command file. You can take a look at the Cache module in SYS/BIOS (navigate to <bios6_install_dir>\packages\ti\bios\family\c64p\ and review the Cache.* files) for more details.

Zheng Zhao said:

I am a bit confused. Do you basically mean:

All caches (L1D, L1P, L2) are zero by default. "Platform wizard" won't set them for you automatically.

This was the original behavior but based on similar feedback we have changed our platforms to provide "reasonable" defaults in XDCtools 3.20.05. Note that in the end you - the application developer - has to decide the cache/internal memory layout that is suitable for your application. If the defaults provided by the platforms we ship in XDCtools are not good enough you can use the platform wizard to create a platform with the desired settings. Based on these settings SYS/BIOS will set the cache accordingly.

Let me know if this helps.

Regards

Amit

0 Anonymous over 14 years ago in reply to AmitMookerjee

Dear Amit,

Perhaps it is just programming issue for CCS and its not like products towards home user (like Windows) that every hidden parameter has been set to a suitable value. It (CCS's RTSC wizard) can be made more "smart" but just haven't been written like that yet. Just like ten years from now own CCS should become much more powerful and easier to use than what we now have, in the same way if we comparing CCS 4 today with the IDE ten years before.

Zheng

0 AmitMookerjee over 14 years ago in reply to Anonymous

TI__Expert 3550 points

Zheng Zhao said:

Dear Amit,

that every hidden parameter has been set to a suitable value.

Zheng

Zheng,

Let me clarify this further. The configuration parameters are not hidden. They are exposed to users so that they can be configured appropriately. Think of configuration parameters as constants that can be set by you to meet your application needs. An appropriate value for this parameter will be determined based on your application requirements. The defaults seen in the platform wizard has been chosen based on common application use cases.

If you provide more information on your application we can provide further guidance on how cache and internal memory can be organized.

Regards

Amit

0 Anonymous over 14 years ago in reply to AmitMookerjee

Dear Amit,

Thanks, I shall try to experiment it further.

Zheng

Processors

Processors forum

DM6437 cache size questions