• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 600 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.

AM5706: Using the PRU-ICSS as the interface to a parallel DAC and ADC

Francois Charlot
Mastermind 28237 points
Part Number: AM5706

Hello,

My customer designs a time-of-flight system around our DAC908. As they need a high DSP performance and a cycle-accurate control over the DAC and ADC interfaces, we are thinking of the AM5706 and to leverage the 2 PRU-ICSS, each one dedicated to the ADC or DAC. As I am not a PRU expert, I am seeking help to assess whether this concept seems feasible.

The waveform output on the DAC would be be pre-computed and stored in the PRU local RAM. There are 2048 14-bit samples to output along with a clock (page 5 of the DAC908 datasheet), so these samples could be stored in the PRU local RAM and some code would toggle the DAC CLOCK signal on the GPO. Does this scheme look ok? What would be the maximum achievable sampling rate? 100 Msps because the DAC CLOCK signal needs to be toggled, and 1 toggle at the PRU maximum 200 MHz frequency gives a DAC CLOCK of 100 MHz maximum. Is this correct? Is there any way to reach a DAC CLOCK of 200 MHz? (We would have to upgrade the DAC, of course.)

I will discuss the ADC later, the DAC being the simplest to start with, I think. Thank you.


Best regards,
François.

  • 0
    TI__Mastermind 37435 points

    Hi Francois,

    Let's break down the problem

    Memory : It's a 14 bit sample so would need 16 bits to store for ease of programming. 2048 x 16 bits means 4096B : There is enough memory inside PRU for this

    Pins : You need to toggle 14 pins using the enhanced GPIO interface (R30), there are 20 of them, so this is also ok

    Speed : PRU clock is 200 Mhz but you need to load the sample from PRU memory and it takes 3 cycles (min) to load to R30 and then another cycle for HW to read and toggle the pins accordingly, so total 4 cycles. Effectively, you can only output at 50Mhz from the pins.

    And this assumes that the PRU software is highly optimal with no additional processing. Actual throughput might be a bit lower.

    Is that enough for your needs ?

    Regards

    Vineet

  • 0 in reply to Vineet Roy
    TI__Mastermind 28237 points

    Hi Vineet,

    Thank you for the quick answer. So there is no 0-wait state memory available at all in the PRU?

    Would you know any other mechanism in AM5706 that would allow writing into GPIOs faster than 50 MHz? I am afraid that PRU is the only reliable, because using a DMA transfer from L3 RAM to GPIOs may lead to some jitter depending on the L3_MAIN and L4_PER buses traffic...


    Best regards,
    François.

  • +1 in reply to Francois Charlot
    TI__Mastermind 37435 points

    Hi Francois,

    Francois Charlot said:
    So there is no 0-wait state memory available at all in the PRU?

    No

    Francois Charlot said:
    Would you know any other mechanism in AM5706 that would allow writing into GPIOs faster than 50 MHz? I am afraid that PRU is the only reliable, because using a DMA transfer from L3 RAM to GPIOs may lead to some jitter depending on the L3_MAIN and L4_PER buses traffic...

    If you want send out a stored sample then there is no workaround IMO, PRU loads are blocking so it cannot be optimized.

    Regards

    Vineet

  • 0 in reply to Vineet Roy
    TI__Mastermind 28237 points

    Hi Vineet,

    Thank you. I will work with my customer. Let's close this inquiry.


    Best regards,
    François.