TMS320C6416T: Reference design

I want to be sure you have seen the notice on the product web page:

This product does not have ongoing design support from TI for new projects, such as new content or software updates. If available, you will find relevant collateral, software and tools in the product folder. You can also search for archived information in the TI E2E^TM support forums.

As for the reference design, please see https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1374451/tms320c6416t-reference-designs-availability-check?tisearch=e2e-sitesearch&keymatch=TMS320C6416T%2520schematic#

--Paul 

Hello!

Although HPI may work towards FPGA, still I would think of it when DSP is in a slave role with regard to other processor. When it comes to DSP-FPGA communication , why don't you look at EMIF? This way you will have straightforward read/write access to the whole FPGA memory range, though need to develop address decoder for your FPGA app. This device also has PCI for tha case one decides to go with IP cores.

Hi Victor,

  Thank you for your response.

As per your reply, our end customer requires an HPI-16bit interface. Could you provide guidance on implementing data read and write communication between FPGA and DSP using the HPI interface? Do you have any reference code or FPGA designs available?

Regards,

Satham

Hi Satham,

Though customer wish is a baseline, it's ain't that hard fixed if one communicate pro/cons and presents options.

These do arise immediately after we think how to implement details. To my memory, HPI is an interface where DSP operates as a slave. That's said, should another device want to perform direct access to DSP's memory, it should know DSP's memory layout, say address of preallocated buffers and alike. This could be natural if accessing device is of "higher intelligence" with respect to DSP. I meant that in top-bottom design we usually have host-->DSP-->FPGA-->HW hierarchy, where leftmost is the highest level. In your case somehow you have to tell FPGA's firmware, where is DSP's preallocated buffer. Yet FPGA must be smart enough to handle master role in HPI communication. I am not saying that's impossible, just way harder, and since very few did it it's unlikely you'll get examples.

So here I resort from your problem but focus on my experience with HPI in hope you might pick up some ideas.

Host processor is responsible for doing reads and writes to DSP. Both DSP and host can signal event to other party through interrupt. This is the only way DSP may actively communicate to host.

In our project we had two buffers with fixed and known location in DSP memory. We used some kind of command-event exchange scheme like in Bluetooth host to controller communication. So mentioned buffers were good to hold one packet of command or event. Once host want to send data to DSP it writes directly to h2d buffer and triggers interrupt to DSP. DSP copies data from incoming buffer to its internal structures and process them. If DSP is about to send data to host, it places data in its d2h buffer and triggers interrupt to host. Then host processor reads data out from d2h buffer to its respective data structures and doing its processing. Because h2d and d2h buffers reside at known fixed locations, host can configure HPI address register for read and write transactions.

That how it worked in our design. One may implement something similar with having FPGA as host. Just implement some automata to handle interrupts from DSP and perform read and write cycles.

I see it would be much easier to have DSP's EMIF to handle FPGA's memory though.

Hi Victor,

Thank you for your brief explanation.

I have some more questions regarding the DSP programming procedure. Could you please explain how to program the DSP processor and describe the processes involved in DSP processor?

Do we need to use a tool for DSP programming?

Regards,

Satham.

Victor - great input, thanks!

Satham - for HPI, take a look at TMS320C6000 DSP Host-Post Interface (HPI) Reference Guide

--Paul

Hi Paul,

Regards,

Satham

Hello!

The question is what you put behind programming. In some narrow scope, if we refer to loading executable to processor and let it run, one may avoid using other hardware tools. And since we are dealing with HPI - it also can be used to load executable to DSP upon reset.

In broader sense programming is a process of writing source code for the app, compiling it, debugging and then above mentioned firmware load to processor. In this case one needs software tool, which is Code Composer Studio, compiler, and emulation debug probe. The latter is somewhat expensive hardware tool, yet indispensable in the process.

One have to understand this won't be an easy walk. As debugging and verification consumes most of the development time, one should have realistic picture of the adventure. First, the device you are targeting is in essence a very old C641x core produced in some modern day tech process, simply saying old design produced in new fab. To my memory, they were using so called Real Time Data eXchange (RTDX) transport to handle debugging events, also realtime. This transport is obsolete for decades and new Code Composers would have no support for it. If you switch back to CCS v.3.3, I am not sure it was supported at that time, maybe no. If one decides to go with any modern Eclipse based CCS, then will have only stop mode debugging, that is no realtime messages, no graphs, no updates. That's still better than nothing, but believe me, one have to have good prior experience to walk that way.

Other than that one have to provide JTAG header to connect emulator, and that's it, one may load program directly to processor.

Hope this helps.

Satham

Below are a few guides related to programming the device. 

However, as mentioned by Victor, the tools are no longer supported. I believe that the C6416T is supported by an XDS510 emulator, but these are impossible to find at a reasonable cost and, even if found, are not supported by contemporary versions CCS.

You should considered a more modern device for your project as getting support for the C64x device will be limited at best. 

--Paul

How to Begin Development Today With the TMS320C6414, C6415, and C6416 DSPs (Rev. A)

TMS320C6000 CPU and Instruction Set Reference Guide (Rev. G)
TMS320C64x/C64x+ DSP CPU and Instruction Set Reference Guide (Rev. J)
TMS320C6000 C Compiler: C Implementation of Intrinsics
General Guide to Implement Logarithmic and Exponential Operations on Fixed-Point
Introduction to TMS320C6000 DSP Optimization
TMS320C6000 Programmer's Guide (Rev. K)
TMS320C6000 Chip Support Library API Reference Guide (Rev. J)

XDS560 will handle C641x too, the point is that emulator should work with CCS. I had positive experience with rather modern SD XDS560v2, both traveler and larger USB+Ethernet type, both worked well with Eclipse based CCS. As to CCS v3.3, XDS510 was working for me until died, also we had very old one TI XDS560 of PCI type in some older PC. That PC still runs Windows 7 and we keep it just for this reason. With any newer OS and PC be prepared for troubles. Specifically, don't even try with BlackHawk XDS560, they have no 64 bit drivers.