• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 99 subscribers
  • Views 1219 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Xilinx to DSP interface

murad qahwash
Genius 3770 points


Hi all,

We are redesigning our system using the new C6678 DSP

Old system:

Xilinx Spartan interfaces with C6414 using DPRAM and EMIF-32...once the Xilinx collects 3072-32bit samples, it sends them to DPRAM and HW interrupts the DSP

 

The new DSP (C6678) has IMIF-16 and many other peripherals, we also want all the Cores to process the SAME data

What is the best way to interface the Xilinx to the DSP(s)...we are re-designing the whole system, so if we have to change to another FPGA, we'll do it...

Should we:

- keep the DPRAM and send the 32bit in 2-16bit moves

-use the SRIO? and if so, how much work to do on the FPGA?

-????

Once a DSP receives the data, should we have one DSP doing that and put it in shared memory/DDR3 or interrupt ALL cores.....

Regards,

 

Murad

  • 0
    TI__Mastermind 30825 points

    Murad,

    I think the real question should start out with, whether or not the EMIF16 meets your needs.  What type of Throughput needs are you going to have.  Haopeng has provided linkes to a couple discussions on the throughput, one on EMIF16 and one on SGMII.

    Going from a C6414 (a device that's over 10yrs old now) to a C6678 is a big difference.  The speed has gone up, the processor instructions have expanded, comparing 1 core vs 8 cores, means that the C6678 can consume and process a lot more data than a C6414 did.

    Based on this I'd assume you'd want to process a lot more data, and thus the throughput requirements have grown as well.  The EMIF-32 on C6414 was the primary external memory interface (no DDR memories on that device.)  On C6678 it's a 16bit interface meant to access Flash (NAND/NOR) or Async FPGA's but it's not really a high speed interface relative to the other peripherals on the device and it may not meet your throughput needs.

    SRIO and PCIe are well known interfaces implemented on FPGA that would have much higher throughput rates. 

    I'd suggest taking a look at the Throughput Performance App Note SPRABK5 and determine what would be best for your needs based on your throughput requirements.

    Note that pushing the data directly out to DDR2 (or into MSMC shared L2/L3 space) is fine for any of the peripherals.

    Best Regards,
    Chad

  • 0 in reply to Chad Courtney
    Genius 3770 points

    Thanks guys for the reply,

    Let me give a different picture of the new design

    2-ADC, 2 (Quad DDC): so total of 8 different channels at a rate < 2MSPS each. The 8 channels to be fed into an FPGA (Spartan, etc ??). FPGA collects 3072 samples/channel, adds a time stamp to it (3073 samples, 32 bit/sample)/channel and need to send it to different core...i.e, channel "X" will be put in some memory (Xmem?) and processed by coreX. whats the best approach?

  • 0 in reply to murad qahwash
    TI__Mastermind 30825 points

    Murad,

    The picture is still a bit fuzzy because the details aren't all that specific so I'll try to recap.

    You've got 8 channels at  up to 2MSPS w/ 32bit/sample or up to 512Mbps data.  Any of the IO's are capable of this.  The timestamp @ every 3K samples really doesn't play into calculating what IO performance is needed from what I can see.

    All this said, do you know what processing needs to be done on this data?  You'd want to make sure you're going after a DSP that matches your processing needs and my gut is telling me that the C6678 would be overkill for just about anything at that type of data rate.

    Best Regards,

    Chad

  • 0 in reply to Chad Courtney
    Genius 3770 points

    Chad,

    Our current design used "ADC-DDC-FPGA- C6414" to process one channel only at the above rate and the DSP processing is enough...now we hoping that the 8 cores will allow us 8 different channels instead of having to put 8 different "old cards" in the box...

  • 0 in reply to murad qahwash
    TI__Mastermind 30825 points

    Murad,

    Without knowing a bit more about what you're actually trying to process (and how you're trying to process it) it's hard to estimate your processing needs, but if 1 core C6414 was sufficient for 1 channel, then C6678 would definitely be sufficient.  My only question is if it's overkill for your needs.

    Best Regards,

    Chad

  • 0 in reply to Chad Courtney
    Genius 3770 points

    Chad,

    We use the DSP for trunk radio diagnostics of P25 trunk radios, EDACS, P25, Smart-net smart-zone is 12.5 KHz channel and 9600 bps...mostly fft, filtering, and decoding, but we also want to use the DSP for TOA (time of arrival) technology used in our trunk radio locationning system...more "overkill" is better than less I guess...but still not sure how to move the 8 channel samples to the 8 cores from the FPGA. even the SRIO gives only 4x, but I need to move the 8 channels 3k blocks to the 8 cores independently...since each needs to be 3k+time stamp...

  • 0 in reply to murad qahwash
    TI__Mastermind 30825 points

    I don't see a reason why one SRIO channel couldn't do this for all 8 data channels. There's no reason why one physical channel cannot transmit all the information for each data channel.  It's simply a matter of providing the information about the channel w/i the packets which is a natural thing to do w/ SRIO.

    Best Regards,

    Chad

  • 0 in reply to Chad Courtney
    Genius 3770 points

    True Chad, after reading more about the SRIO, it will be fast enough to do the job. we will connect the 4 channels to the FPGA for future use.

     

    Thanks alot,

    Murad