Tms320c64x


Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,307
Age
40
Location
Cleveland OH
At first I wasn't that enthusiastic about a DSP, as second CPUs don't really get a lot of attention from homebrew devs on GP2X and PSP (more on DS though). However, after reading the documentation, this one looks like it may be so powerful that it could be useful even when not really running in parallel with the Cortex-A8, ie through blocking remote procedure calls.

Here's the link again (thanks to Laurent for originally posting it):

http://focus.ti.com/dsp/docs/dspsupporttec...ctName=spru732g

I read through it pretty completely, it's pretty well written/organized and for the most part easy to understand (unlike the Blackfin documentation -_-).


Pros:

- 8 instructions per cycle over 4x2 functional units. There is two of every type of unit, so almost every instruction can be paired per cycle at least 2x. Furthermore, a number of common operations are redundant over 2 or even 3 unit types (add, sub, or, and xor can be done on 3 unit types)

- 32x2 general purpose 32bit registers. Nominally each set is tied to a functional unit block, but there are "cross paths" for allowing a register from the other set to be used directly in an operation, you're just limited to how much you can do this per cycle. This huge amount of registers should help for making algorithms more parallel.

- Lots of bit crunching instructions (extracts, packs, interleave, reverse, etc)

- Predication (conditional execution over registers, like in ARM but with more direct boolean values, if you're familiar with PPC or Itanium they have the same mechanism) - useful for avoiding the very costly conditional branches.

- Can do 2 64bit loads or stores per cycle (unfortunately not 2 loads AND stores, but can do one of each). Actually, the 64x+ has 256bit paths to dcache but I'm not too sure why. 64bit loads/stores use register pairs.

- Can do unaligned loads/stores w/o additional cycle penalty (maybe this is why there are 256bit paths). Unfortunately you can only do one memory access per cycle if it's unaligned.

- There's a strictly one cycle fire-off/throughput rate for every functional unit, with stalls (nops generated by the CPU) only being inserted in a few situations.

- Has a mechanism for assisting software pipelining. I understand the principle but don't really get the implementation yet.

- Has circular buffer addressing, although I think that the base has to be aligned to the offset size, which seems a lot less useful to me...

- Single cycle decrement + branch instruction (these are great, I don't know why so many modern CPUs have stopped favoring them)

- 80KB of L1 dcache. I wish the Cortex-A8 had this, although it's only 2-way set associative here (probably optimized for a single input + output set). There's also 64KB of unified L2 cache and 32KB of L2 SRAM (I wonder how fast it is..)


Cons:

- The latency for loads is pretty terrible, at 4 cycles. Because of the 1 cycle throughput these are all "delay slots." Good scheduling/unrolling is going to need to be done to compensate for this.

- Naturally branches are pretty bad too, with delay slots of 5 cycles. There's no branch prediction or anything like that. This isn't really a problem with loops; for them it's much better that these slots are exposed than if compulsory stalls were introduced (like on ARM and MIPS w/o branch prediction or mispredictions)

- Although there's 32KB of L1 icache, it's direct mapped so it's really just good for running one piece of code at a time, for a long time. Not good if the OS interrupts it a lot, but this is what we have a general purpose CPU for.

- It's very bare metal, in that it won't protect you from doing a lot of things. You have to be really careful not to cause dependency problems or performing multiple writes to the same register during the same cycle (especially a danger for the many instructions that have multiple cycle latency).

- There are some weird bugs, that I hope get fixed at some point :/


Applications:

- Obviously it'll be used for video and hopefully audio decoding too. Hopefully there will be libraries or at least binaries available for everyone to use this freely.

- One thing that immediately comes to mind is using it to render scanlines for 2D emulators. It should be able to fire off rendered tiles in quite a few less clocks than the Cortex-A8, although it is clocked a bit lower (430MHz vs 600MHz.. I wonder where they got 430MHz, and if that's off a separate clock than the CPU... their greatest common multiple seems to be ~3GHz, divided by 5 and 7)
 
Yes, its quite a powerful beastie :) I'm hoping to get something running on it over the next few months.
 
Yes, this thing looks really interesting. Should work well for post-processing filters too.
I just hope we will have full access to this, and it's not crippled in any way.
 
Anyone know anything about the c-compilier it mentions? It would be nice if was available for public use. Probally costs a couple grand for a license.... :unsure:
 
Pickle said:
Anyone know anything about the c-compilier it mentions? It would be nice if was available for public use. Probally costs a couple grand for a license.... :unsure:
Probably, and I have no expectations that GCC will do a good job of optimizing for it either. Programming this might not be for the faint of heart.

Maybe we'll get the optimizing assembler (I doubt it though). If we have to use GAS then I hope it at least analyzes the code enough to hand out warnings for when bad things are done (lots of potential hazards and a few bugs)
 
Last edited by a moderator:
Pickle said:
Anyone know anything about the c-compilier it mentions? It would be nice if was available for public use. Probally costs a couple grand for a license.... :unsure:
Hum, you're close but it's more than that : http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html

As far as binutils are concerned here is something : http://rtg.informatik.tu-chemnitz.de/forsc...inutils-c6x.php

And for gcc : http://rtg.informatik.tu-chemnitz.de/forsc...c6x/gcc-c6x.php

And if you want to play with a c62x cycle accurate simulator : http://saturn.ece.ndsu.nodak.edu/ecewiki/index.php/Group_243 look for tmscache.zip

Now if I could put my hands on a Pandora devkit... :p

Squidge said:
Yes, its quite a powerful beastie :) I'm hoping to get something running on it over the next few months.
This looks like a hint access to the c64x is granted.
Hum, that wouldn't be the first I over interpret what you write :blink:
 
Last edited by a moderator:
Exophase said:
- Can do 2 64bit loads or stores per cycle (unfortunately not 2 loads AND stores, but can do one of each). Actually, the 64x+ has 256bit paths to dcache but I'm not too sure why. 64bit loads/stores use register pairs.

- Can do unaligned loads/stores w/o additional cycle penalty (maybe this is why there are 256bit paths). Unfortunately you can only do one memory access per cycle if it's unaligned.

It's the instruction bus which has 256 bits to be able to load 8 instructions per cycle.

QUOTE
Cons:

- The latency for loads is pretty terrible, at 4 cycles. Because of the 1 cycle throughput these are all "delay slots." Good scheduling/unrolling is going to need to be done to compensate for this.

- Naturally branches are pretty bad too, with delay slots of 5 cycles. There's no branch prediction or anything like that. This isn't really a problem with loops; for them it's much better that these slots are exposed than if compulsory stalls were introduced (like on ARM and MIPS w/o branch prediction or mispredictions)

- Although there's 32KB of L1 icache, it's direct mapped so it's really just good for running one piece of code at a time, for a long time. Not good if the OS interrupts it a lot, but this is what we have a general purpose CPU for.

- It's very bare metal, in that it won't protect you from doing a lot of things. You have to be really careful not to cause dependency problems or performing multiple writes to the same register during the same cycle (especially a danger for the many instructions that have multiple cycle latency).

That's a basic VLIW with no interlocking mechanism. I find it funny. Perhaps it's time to dig out my c67 dev kit :D

For applications, look at diagrams for OMAP 35x. You will see that memory is connected to the SDRC which itself is connected to the L3 interconnect (probably an OCP bus). I don't know what its frequency is. But the bad news is that *many* peripherals are connected to it and it looks like the IVA 2.2 subsystem can only read 32 bits at a time (which looks extremely bad for cache linefills).
 
Last edited by a moderator:
Laurent said:
It's the instruction bus which has 256 bits to be able to load 8 instructions per cycle.
On the C64x+ they paths to dcache are 256bits as well (on the C64x they are only 64bit). See section 1.4.2. The C64x+ is the version the OMAP3530 has.

Laurent said:
That's a basic VLIW with no interlocking mechanism. I find it funny. Perhaps it's time to dig out my c67 dev kit :D
I haven't studied other VLIW much but it figures, a lot of burden is placed on the person or compiler writing the code to do things that are typically done in hardware on other platforms.

Laurent said:
For applications, look at diagrams for OMAP 35x. You will see that memory is connected to the SDRC which itself is connected to the L3 interconnect (probably an OCP bus). I don't know what its frequency is. But the bad news is that *many* peripherals are connected to it and it looks like the IVA 2.2 subsystem can only read 32 bits at a time (which looks extremely bad for cache linefills).
Isn't the DDR SDRAM that would be servicing most cache linefills only 32bits wide to begin with? That was my long standing assumption anyway.
 
Last edited by a moderator:
Laurent said:
Hum, you're close but it's more than that : http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html



I believe there's an evaluation version that you can use.

Laurent said:
This looks like a hint access to the c64x is granted.
Hum, that wouldn't be the first I over interpret what you write :blink:
At first, the DSP will probably by reserved by the kernel, but we'll try and make sure theres a way of uploading user code later on (and of course you'll have the full kernel source code if that isn't quick enough for you).
 
Last edited by a moderator:
Exophase said:
Laurent said:
It's the instruction bus which has 256 bits to be able to load 8 instructions per cycle.
On the C64x+ they paths to dcache are 256bits as well (on the C64x they are only 64bit). See section 1.4.2. The C64x+ is the version the OMAP3530 has.
I finally found the real description: http://focus.ti.com/lit/ug/spru862a/spru862a.pdf section 1.7.

Basically the CPU has a 256 bit bus to Icache and 2x64 bit busses to Dcache/write buffer.
The Dcache has a 256 bit bus to L2 cache which then has 32/64/128 bit bus to external memory.
The 256 bit bus matches the cache line size of 32 bytes.

Finally it makes sense :D
 
Last edited by a moderator:
Laurent said:
I finally found the real description: http://focus.ti.com/lit/ug/spru862a/spru862a.pdf section 1.7.

Basically the CPU has a 256 bit bus to Icache and 2x64 bit busses to Dcache/write buffer.
The Dcache has a 256 bit bus to L2 cache which then has 32/64/128 bit bus to external memory.
The 256 bit bus matches the cache line size of 32 bytes.

Finally it makes sense :D



Thanks for clearing that up. The description in the CPU/Instruction set reference guide sure was misleading.
 
Last edited by a moderator:
Exophase said:
- Can do 2 64bit loads or stores per cycle (unfortunately not 2 loads AND stores, but can do one of each). Actually, the 64x+ has 256bit paths to dcache but I'm not too sure why. 64bit loads/stores use register pairs.

- Can do unaligned loads/stores w/o additional cycle penalty (maybe this is why there are 256bit paths). Unfortunately you can only do one memory access per cycle if it's unaligned.

Looks like this is a bit tardy and you've already figured it out...

The 256-bit width to the *I*-cache is because you can have up to 256 bits per instruction (8 parallel instruction units times up to 32 bits per instruction). Most instructions aren't that long, but they don't call it very-long instruction word for nothing.

When you code for the C64x+, you typically find the 100 instructions or so where you spend 90% of your time and make sure that you've written it to use all 8 instruction units at once in the inner loop. This is really common for FFT, DCT, SAD, FIR, etc. functions typical in DSP-ish operations.

Also, there are some additional data types in the C64x+ C compiler not in most C compilers, as well as intrinsic functions to get to special instructions, that help you get a lot of efficiency. The ARM Cortex-A8 NEON has also added some other data types and intrinsics.

There is an eval of CCS to try out with the debugger, compiler, etc.. I'm working on getting TI to release the C64x compiler-only (no debugger) for x86 Linux for free for non-commercial development. I hope to get this done in time for when you can put your hands on a Pandora.
 
Last edited by a moderator:
jadon said:
Also, there are some additional data types in the C64x+ C compiler not in most C compilers, as well as intrinsic functions to get to special instructions, that help you get a lot of efficiency. The ARM Cortex-A8 NEON has also added some other data types and intrinsics.

Yeah C does not like SIMD stuff, so we have dozens of different incompatible intrinsics :(

QUOTE
There is an eval of CCS to try out with the debugger, compiler, etc.. I'm working on getting TI to release the C64x compiler-only (no debugger) for x86 Linux for free for non-commercial development. I hope to get this done in time for when you can put your hands on a Pandora.

That'd be great, but I never heard of TI releasing a Linux version of their codegen tools. And I can't get the c64x compiler to work correctly with wine.
 
Last edited by a moderator:
QUOTE

QUOTE
There is an eval of CCS to try out with the debugger, compiler, etc.. I'm working on getting TI to release the C64x compiler-only (no debugger) for x86 Linux for free for non-commercial development. I hope to get this done in time for when you can put your hands on a Pandora.

That'd be great, but I never heard of TI releasing a Linux version of their codegen tools. And I can't get the c64x compiler to work correctly with wine.


We released a C54x compiler on Linux for the Neuros OSD:
http://open.neurostechnology.com/node/1020

The tools are at:
https://www-a.ti.com/downloads/sds_support/...s/download.html

I expect the C64x tools will be put in the same place.
 
jadon said:
We released a C54x compiler on Linux for the Neuros OSD:
http://open.neurostechnology.com/node/1020

The tools are at:
https://www-a.ti.com/downloads/sds_support/...s/download.html

I expect the C64x tools will be put in the same place.

Phew I thought these were Windows tools and what you say seems to imply you were part of the process to get the C54x compiler, so this increases my hope it could happen!

I am so tired hacking into Windows and wine code to understand why the tools don't work :D
 
Last edited by a moderator:
obviously, if he was lying craigix wouldn't have suddenly switched to the omap after he mentioned he was an employee who was going to pm craig about it.
 
I'm not sure if TI have upgraded for the OMAP 3 family, but OMAP1 & 2 have dspgateway. This allows you to upload tasks to the DSP have handles IPC. I have a E3 (OMAP1510) at home which has a older DSP in it for which the toolchain is available and have been meaning to look into it but have no time a.t.m. :(
 
I'm not very knowledgeable about ARM internals, so bare with me.

Doesn't the linux kernel recognize the second cpu if it has a MMU? Wouldn't that allow us to write multi-threaded/process apps and have the kernel figure out the rest?
 
sindbad said:
I'm not very knowledgeable about ARM internals, so bare with me.

Doesn't the linux kernel recognize the second cpu if it has a MMU? Wouldn't that allow us to write multi-threaded/process apps and have the kernel figure out the rest?
Both processors really should be the same, in this case, one is a cortex and one is a DSP.
 
Last edited by a moderator:
Back
Top