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 ADC

Part Number: AM5706
Other Parts Discussed in Thread: AFE5401-Q1

Hi all,

Related to my former question about interfacing the PRU-ICSS to a DAC, What would be the highest speed that we could reach with the AFE5401-Q1 quad-channel ADC connected to a dedicated PRU-ICSS? Page 10 of the AFE datasheet shows the timing diagram of its data interface, with CLKIN being the sampling clock to be generated by the PRU-ICSS (between 12.5 and 25 MHz) and DCLK being the data clock, 4 times faster than CLKIN in order to get the data from the 4 channels. DCLK is also to be generated by the PRU-ICSS.

Thank you.


Best regards,
François.

  • Hi Francois,

    Theoretically, you can bitbang and generate a signal using PRU-ICSS, best case is 100Mhz by just doing an XOR with R30 register so it keeps flipping, you can generate two outputs, one at 25Mhz and one at 100Mhz if you are not running anything else.

    But it really depends a lot on what all you are trying to do in the firmware. Do you have enough cycles to do these things ?

    Based on this and previous E2E, I would say that it's really difficult to comment on what's achievable unless you actually start writing some firmware on PRU-ICSS. You can take any AM57 IDK and try to prototype this first.

    Regards

    Vineet

  • Hi Vineet,

    In the application that we contemplate, 1 PRU-ICSS would be fully dedicated to the DAC and 1 fully dedicated to the AFE5401. Given we have a full PRU for the AFE5401 interface, I am trying to understand what the maximum achievable speed would be, using any brute force method (unrolled loops...). I would be grateful if you could make a crude estimate as I have no experience on the PRU (and no IDK); then if the estimate looks good enough to my customer, we will go ahead with a proper evaluation. Thank you.


    Best regards,
    François.

  • Hi Francois,

    The issue is that the best case PRU numbers are not useful for customer because PRU will generate the clock as well as send sampled values using GPIO. It depends entirely on the application scenario.

    Think of it like this crudely

    loop:

    counter++

    toggle R30.x  ;generates clock1

    load sampled values to R30 ; sends out sampled values

    if counter % 4 == 0

        toggle R30.y ;generates clock2

    goto loop

    It entirely depends on the way code is written.

    If you don't have an IDK then a beaglebone black should also suffice for basic prototyping and estimation. You can find plenty of resources online for writing a code to toggle GPIO using PRU quickly.

    I am unable to help with this immediately.

    Regards

    Vineet

  • Hi Vineet,

    Thank you. Before I close this case, could you please point me to the cycle count of the PRU-ICSS instructions? I did not find it in its instruction set reference guide. I would also need to know the number of extra cycles that it may take to perform a read or a write to the DATA RAM0/1/2, including extra cycles (if any) for concurrent accesses.


    Best regards,
    François.

  • Hi Francois,

    I think what you are most interested in is the read latency since that is a blocking instruction. Here is a report that documents read latencies for PRU for various memories.

    Logical and Arithmetic instructions take one cycle each, so does any register read/write (including the scratch pad register banks).

    Writes also takes some amount of time as read but it is non-blocking so the instruction itself consumes one cycle unless you read it immediately after, in which case the read will become blocking until write completes. So it's best to use scheduling writes to avoid latencies.

    Regards

    Vineet