Interfacing TMS320C6416T to ADS5485

Hello Varun

You should use EMIF connector instead PCI, but some glue logic may be need to  add anyway.

More over, C6416 has not any interface work at 200MHz clock, so you should use something (e.g. FPGA) to convert 16bit @ 200MHz to 32 bit @ 100MHz.

BR, Serge

Dear Mr.Serge,

Sorry for the later reply.  I was busy with end semester assignments. 

So an FPGA has to be used because the transmission rates differ right ??

Thanks,

Varun Sridharan

Varun,

What do you want to do with these two devices? I mean to ask what your application is, not just the fact that you want to connect these parts.

Why have you chosen these two devices, the C6416T and ADS5485?

There have been a variety of discussions in the E2E forum about connecting various high-speed ADCs and DACs to various DSPs. You may find some of these discussions useful in understanding the possibilities and tradeoffs for this. The forums underwent some organizational changes over the past 48 hours, so searching may be spotty for a short while. But there are some good discussions to find.

Hello,

The application is converting a PMT (Photomultiplier tube) output current to a voltage using an Op amp and then quantizing it using an ADC. The ADC is then interfaced to the DSK 6416T, to perform an FFT and various other statistical calculations.

We are using a 200 MSPS ADC (ADS 5485), but due to the EMIF's 125 MHz speed, the sampling frequency on the ADC  has to be 125 MSPS.

The ADC transmits bits continuously. How do we write it to the DRAM on the DSK as and when we receive the bits from the ADC  ? Won't there be a bus conflict ?

I will search for these kinds of topics on the E2E forum

Thanks,

Varun

There are several dimensions to your project that need to be dealt with.

1. You have a finite number of ports that come to connectors on the DSK. Something will get plugged onto one of those connectors. You can buy expander connector boards that you can add logic to or you can buy data acquisition boards that you can use to collect data like you want to. 
2. You need to look at the datasheet for the ADS5485 to figure out what port on the DSK it can connect to. One hint is that the ADS5485 has byte-wide differential outputs and the DSK does not have any differential input ports. Clock rate aside, the interface needs to be converted from differential to single-ended. Unless the ADS5485 datasheet shows that it can be used single-ended.
3. For what frequency range are you hoping to build analysis data? Your sample rate of course needs to be higher than that. I do not know how much higher your sample rate needs to be for FFTs, so you should look into what your requirements are and then how high your sample rate needs to be. If you can meet that rate easily, then you can avoid building too complex of a capture system.
4. Will your FFT be real-time and continuous? Or will you capture a buffer of data, calculate the FFT, do other analysis of it, then capture a new buffer after all of that is completed.

Varun Sridharan said:

How do we write it to the DRAM on the DSK as and when we receive the bits from the ADC  ? Won't there be a bus conflict ?

The SDRAM will be on one EMIF and the ADC will be on the other. This way there is no bus conflict.

Hi

Thank you for those really important points.  Below are my answers to them

2. I think differential to single ended conversion is necassary. From other similar topics on the E2E forum, I learnt that an FPGA would be required .

Data from the ADC is sent to a FIFO and then sent in bursts to the DSP serially.

3. Frequency of the signal is approximately 60 MHz ( PMT output ) . This means that the sampling rate must be higher than 120 MHz. The maximum operating frequency of the EMIFA is 125 MHz ( TI datasheet says 133 but the DSK technical reference doesn't say so ).I am very much confused about the EMIF pins.

The TMS320C64X EMIF has an ECLKIN ( clock in from external - delivered  by FPGA in this case ). This is according to the datasheet, but when I see the pin descriptions on the DSK manual I cannot find the ECLKIN nor the ECLKOUT1 and 2 pins. There is an EMIF output clock ( ECLKOUT ) pin on the PCI (J3) connector.

4. FFT,SNR  is calculated after buffering the data.

Regarding the bus conflict ( your last point in the previous email ).. I see that the external memory and SDRAM share EMIFA. I do not udnerstand.

Thanks again.

Regards,

Varun

How many 16-bit samples do you want to capture into your buffer? Do you require that the FFT and SNR calculations be run while another buffer is being captured, in other words do you require real-time operation or will you capture a buffer and process it, then capture another buffer and process it?

Since you plan to use an FPGA, you will need to design one side of the FPGA to be compatible with the differential outputs of the ADC, the inside of the FPGA to provide a small buffer and some status or signaling, and the other side of the FPGA to interface with the DSP's EMIFA bus.

I was assuming that you would be able to use a different EMIFx bus for SDRAM and FPGA. But as you noted, the DSK connects all 64 bits to the SDRAM and the lower 32 bits to the external memory interface. Bus conflicts are handled by using a different CEn Chip Enable for the SDRAM and for the FPGA. Then when the FPGA is not selected, it does not drive the data bus.

You cannot drive ECLKIN. This must be set on the board to be the correct value for the SDRAM. In fact, it might be generated internal to the DSP.

ECLKOUT is available on the External Peripheral Interface, J3.

Since you have 32 bits available for the External Memory Interface to your FPGA, you can buffer up samples and send out 2 16-bit samples at a time as a 32-bit word from the FPGA. This will allow you to read up to 250M samples per second. But that will depend on your interface method.

It will not be easy to implement a high-speed interface over the expansion connectors, especially if you want it to run in a full-speed burst mode rather than an asynchronous SRAM interface mode. But the asynchronous mode will take at least 3 cycles per read, if I recall the C6416 EMIF correctly. That would allow only 80M samples per second.

So you will either have to find a way to get one of the full-speed synchronous interface modes to work through your FPGA, or you will need to build/buy a high-speed capture module from which you can download the data at the available asynchronous EMIF speed.

Hello Mr.Randy,

- How many 16-bit samples do you want to capture into your buffer? Do you require that the FFT and SNR calculations be run while another buffer is being captured, in other words do you require real-time operation or will you capture a buffer and process it, then capture another buffer and process it?

Me: We would like to have it in real time.  We store the bits from the ADC it in a buffer (FIFO)  and then read from the FIFO simultaneously at a speed identical to the EMIF speed. 

- Since you plan to use an FPGA, you will need to design one side of the FPGA to be compatible with the differential outputs of the ADC, the inside of the FPGA to provide a small buffer and some status or signaling, and the other side of the FPGA to interface with the DSP's EMIFA bus.

Me : Yes we figured out that we need to use an FPGA compatibe with the differential output of the ADC . The buffer used will be a FIFO.

- I was assuming that you would be able to use a different EMIFx bus for SDRAM and FPGA. But as you noted, the DSK connects all 64 bits to the SDRAM and the lower 32 bits to the external memory interface. Bus conflicts are handled by using a different CEn Chip Enable for the SDRAM and for the FPGA. Then when the FPGA is not selected, it does not drive the data bus. Now I understand this. Thanks.

- Since you have 32 bits available for the External Memory Interface to your FPGA, you can buffer up samples and send out 2 16-bit samples at a time as a 32-bit word from the FPGA. This will allow you to read up to 250M samples per second. But that will depend on your interface method.

RandyP said:

- Since you have 32 bits available for the External Memory Interface to your FPGA, you can buffer up samples and send out 2 16-bit samples at a time as a 32-bit word from the FPGA. This will allow you to read up to 250M samples per second. But that will depend on your interface method.

It will not be easy to implement a high-speed interface over the expansion connectors, especially if you want it to run in a full-speed burst mode rather than an asynchronous SRAM interface mode. But the asynchronous mode will take at least 3 cycles per read, if I recall the C6416 EMIF correctly. That would allow only 80M samples per second.

Varun Sridharan said:

Me : By connecting the ADC to the FPGA we can send 16 bit data close to 200 MSPS. But while sending it to the EMIF we will be sending 32 bit ( 2 - 16 bit samples as you mentioned ). So technically this will be 160 MSPS ( since its approximately 80 MSPS for 16 bit data which includes the all the delays associated ). So this will be a close approximation to real time, isn't it ??

Unfortunately, I was already accounting for the 2 samples per read cycle. With the asynchronous EMIF timing, the fastest possible is 3 cycles per read, which would be 120MHz/3 (125MHz/3 really, but 120 allows easier math). So at a 40MHz read rate for 32-bit words, you will transfer 80M 16-bit samples per second. Depending on the speeds of the FPGA driving across the expansion connector, you might have to go slower. For lab work, it will probably be okay with typical speeds but not production-worthy.

If you can buffer up enough of your samples on the FPGA/ADC capture board, then you could still capture a timeslot of N samples, then transfer them as fast as possible, then process them as fast as possible, then start another capture of N samples.

To transfer the data faster, you would have to go to a synchronous EMIF timing model, and then you may be able to get the full 200MSPS by reading 32-bit samples at 125MHz read rate. This is a harder FPGA design, but can certainly be done.

Real-time operation: Have you tried running your FFT and SNR calculations on sample data to find out how much processing time will be required?

For example, if you capture 2000 samples in 10us, and can execute the FFT and other analysis in less than 10us, then you can maintain real-time operation only if you get the data transfer rate high enough.

But if you capture 2000 samples in 10us, and require 25us to execute the FFT and other analysis, then you do not need to spend the effort to design higher-speed capture/transfer logic. Instead, you would need to either buffer data on the capture board and process in smaller bursts or you would need to lower the ADC capture rate at the FPGA to match your DSP execution time.

Hello Mr.Randy,

Unfortunately, I was already accounting for the 2 samples per read cycle. With the asynchronous EMIF timing, the fastest possible is 3 cycles per read, which would be 120MHz/3 (125MHz/3 really, but 120 allows easier math). So at a 40MHz read rate for 32-bit words, you will transfer 80M 16-bit samples per second. Depending on the speeds of the FPGA driving across the expansion connector, you might have to go slower. For lab work, it will probably be okay with typical speeds but not production-worth.

Real-time operation: Have you tried running your FFT and SNR calculations on sample data to find out how much processing time will be required?

For example, if you capture 2000 samples in 10us, and can execute the FFT and other analysis in less than 10us, then you can maintain real-time operation only if you get the data transfer rate high enough.

But if you capture 2000 samples in 10us, and require 25us to execute the FFT and other analysis, then you do not need to spend the effort to design higher-speed capture/transfer logic. Instead, you would need to either buffer data on the capture board and process in smaller bursts or you would need to lower the ADC capture rate at the FPGA to match your DSP execution time.

Me: I am currently working on the FFT part trying to calculate the processing time. There are numerous FFT functions given on the DSPLIB reference, so seeing which is the most optimized of all.As you mentioned may be I might try processing the data in smaller bursts or lets say operating the ADC at less than 200 MSPS.

We just ordered the FPGA so until we get it, we can only wait and perform FFT and SNR to find out the processing times. Since high speed signals cant be given to the line in of the AIC23 codec, I am going to generate data points using Matlab and perform FFT on the DSK. Is there any other way to feed in high speed signals from a function generator to the DSK ?

Thanking you,

Regards,

Varun

Varun Sridharan said:

Is there any other way to feed in high speed signals from a function generator to the DSK ?

I would recommend just capturing a couple of buffers of data and work off of static data loaded into memory, for evaluating your routines.

Or you could load in lower frequency data, capture a buffer's worth, then process it as if it were higher-speed data.

Regards,
RandyP

[For your information, if you select a portion of the message above when replying, then click Quote (in red), it will place the box around that text to show it is from the previous message.]

Thanks Mr.Randy.