AM4372: McASP performance to interface to ADC3643

Hi Ueli,

Sorry about the delay.

In the ADC364x datasheet Table 6.10 Timing Requirements, I only see timings for Fout = 65 MSPS under "INTERFACE TIMING - PARALLEL DDR CMOS" - this mode uses 7 data pins per channel to transmit 14-bits in a single DCLK cycle.

It appears the fastest INTERFACE TIMING - SERIAL CMOS
Data valid, 2-wire serial CMOS: Fout = 30 MSPS (2 data pins per channel to transmit 14-bits in 3.5 DCLK cycles)
Data valid, 1-wire serial CMOS: Fout = 15 MSPS, DA/B6 = 240 MBPS (1 data pins per channel to transmit 14-bits in 7 DCLK cycles)

All of these mods transmit data on both rising and falling edges of DCLK. This is not a feature that McASP supports.

See Figure 7-3. Timing diagram: 1-wire serial CMOS and Figure 7-4. Timing diagram: 1/2-wire serial CMOS both show that data is transmitted on both rising and falling edges of the clock.

On the ADC3643 EVM, the data gets routed to an Altera Stratix IV FPGA that supports 1.5-GSPS LVDS I/O rates: up to 48 high-speed transceivers at up to 8.5 Gbps, or up to 24 transceivers at up to 11.3 Gbps. These transceivers are optimized for 100G applications and 1,067 Mbps (533 MHz) DDR3 memory interfaces.

I can ask the PRU expert if the PRU can latch data on both rising and falling edges of the clock, but I suspect the maximum data rate will be slower than the DCLK needed to reach 65MSPS DDR (65MHz) or 30MSPS 2-wire (105MHz?? Calculated as 30MSPS * 3.5 DCLKs per sample)

Regards,
Mark

It is definitely possible to use PRU to bitbang custom protocols to communicate with ADCs. See an example of using the PRU to interface with 6 different ADCs over SPI here: https://www.ti.com/tool/TIDA-01555, https://git.ti.com/cgit/apps/tida01555 . The main question around the PRU is, 1) is the PRU physically capable of doing this usecase, and 2) is the customer interested in the development work to write that PRU code? (probably in assembly)

Let's do some back of the napkin math for one specific example. I am not looking through all the documents mentioned above, so some of my assumptions may be off. But this should be enough to get the customer thinking about their use case.

ASSUMPTIONS:

10MHz data clock = 100 ns
Data sent on both rising and falling edges of data clock, and high and low portions of the period are symmetric
4 data lines must be read every rising & falling edge (i.e., every 50 ns).
PRU is generating the data clock, so no latency for PRU polling for a transition on an external clock signal before it starts sampling the data lines
AM335x PRU core clock is 200MHz, AM437x PRU core clock can go up to 225MHz. I'll use 200MHz

MATH:

At 200MHz, each PRU clock cycle takes 5ns. It takes 1 clock cycle to read in 1 PRU GPI signal, so 4 clock cycles to read 4 PRU GPI signals. Plus one clock cycle to update the data clock PRU GPO signal, takes 25 ns to read in and read out signals. That leaves 5 PRU clock cycles per high or low portion of the data clock to do other things, like pass data to the other PRU core to combine and pass to a host core. Take a look at the TIDA-01555 design guide for more factors to think about in a PRU design like this: https://www.ti.com/lit/pdf/tidudn4