AM572x/AM571x: McASP and EDMA use case (Master and slave) as high speed interface

Hi AnBer,

Let me ask the software and systems teams for their input on these questions. You might need to use fifo and DMA to reach the throughput at these frequencies.

You are correct that ACLKR that need to be running before the McASP init in receiver mode.

Make sure to adhere to the Transmit/Receive Section Initialization sequence, including the step where you must start the respective high-frequency serial clocks AHCLKX and/or AHCLKR. This step is necessary
even if external high-frequency serial clocks are used.

Regards,
Mark

Hi AnBer,

Its good that you are targeting McASP1 and McASP3 since McASP1/2/3 are mapped on the L3 interconnect (others are on L4 and have higher latency from the EDMA).

Can you clarify whether you need 16 separate serializers, or can you use 1 serializer for two channels resulting in 8 serializers?
If it’s 16 serializers @ 30 MHz, it might be a concern. With the 64-Word FIFO, that’s only 3 samples of latency that can be tolerated.

How many bits per sample?

Eventhough it is for a different processor, this wiki page has some throughput numbers for OMAP-L138 that you might use as a baseline.
processors.wiki.ti.com/.../AM1x_Multichannel_Audio_Serial_Port_(McASP)_Throughput_and_Optimization_Techniques

Regards,
Mark

Hi Mark,

Thanks for the input.
If I understand correctly both scenario are functionally possible (ie pin usage, pinmux).
Can you confirm this?

However there might be performance consideration to take into account.
We will provide more precise description on the exact usage and performance expectation.

Anthony

Hi AnBer and Mark,

I give you more data aboutof our real aplicattion. The reason we are going to use this MCASP modules in this way is beacause we need a a Hi BandwIh between our FPGA and AM57x (1Gbit/s). In RX mode (from FPGA to AM57x).

and we don´t have much more options with this microprocessor because we use PCIe  with 2 PCIe GMII (ethernet) transceivers. Moreover we use USB3.0.

Then the use we give to McASP is really more powerfull. We use 5 McASP modules(we can´t mux more) as follows  (MCASP1 and MCASP2 1Gbit/s):

MCASP1 --> 16 channels (RX only)  ACLR and FSR     (pin AHCLK is not connected)    (30Mhz/serializer)

MCASP2 -->  12 channels (RX only)  ACLR and FSR    (pin AHCLK is not connected)    (30Mhz/serializer)

McASP5 -->     2 channels (RX only)  ACLR and FSR    (pin AHCLK is not connected)    (30Mhz/serializer)

McASP3 -->  2 channels (TX only)  ACLKX and FSX      (pin AHCLK is not connected)     (>=15Mhz/serializer)  --> i realize TX mode with ACLK internally generated is the worst case (set up time minimum) therfore we admit less BW for TX blocks).

McASP4 --> the same as MCASP3

Yes, we realize on we need DMA for this frequencies.

Mark,
when you say "You are correct that ACLKR that need to be running before the McASP init in receiver mode."
Focusing in RX modules (1GBIT/s), please see my previous post, you are saying that ACLR is needed active before AXRn data is outgoing fron the device --> How many cycles?

Anyway AXRn data has to be ready (4ns min aprox) before rise flank of ACLKR, hasn´t ?. In this case FPGA can do this without problem.
Regarding the AHCLK (hi freq clock) :

- we are not connect pin externally
- McASPx is supplied with a clock from an internally DPLL. what is the freq needed in McASP block?
- AHCLK clock is the same as MCASPx clock supplied by DPLL?

Hi,

Sorry I missed these replies.

To check pin mux compatibility of these McASP pins and the other peripherals, you must enter the configuration into the pinmux tool. www.ti.com/.../pinmuxtool

Each pin has been timed against its relative clock and is guaranteed to perfom to the respective tables in the datasheet. The concern with utilizing multiple McASPs at 30MHz is the ability for the DMAs, cores, and interconnects to consume this kind of bandwidth in real time (made worse if sharing resources with other functions).

This is an untested usecase for the McASP peripheral requires experimentation, which can be done with the EVM. By clocking each McASP with the internal PLL, each McASP can capture artificial data from the floating input pins. This would only prove that there is suficient bandwidth with the FIFO, DMAs, and interconnects can handle the throughput.

I see no problem using the internal PLL for McASP clock generation as the usual problem is generating exact frequencies commonly required to generate audio clocks (44.1kHz, 192kHz, 384kHz, etc).

Regarding the requirement for ACLR to be active before AXRn, I was referring to the CAUTION statement in the TRM below 24.6.5.1.2.2 Main Sequence – McASP Global Initialization for TDM-Reception:

"Before performing McASP global initialization, If external clock ACLKR is used, it must be running already for proper synchronization of the MCASP_GBLCTL register. This is to provide a clock to the state machine. I would give it a few frames of bit clocks."

Are you using an operating system? Any other DMA use? How many bits per McASP sample? What is the frame clock frequency?

Regards,
Mark