LP-AM243: SPRADC3 - 8b/10b Intra Drive Communication Using 8b-10b Line Code With Programmable Real Time Unit - Application Note

Shawn,

  thanks for sharing your requirements.

PRU has min latency to memory and IO which provides you dual port memory performance on a chip 2 chip communication.

Below diagram shows various data path and memory latency figures on the AM64x/AM243x architecture. I take for example two extremes.

1. Fastest read latency using scratch pad memory which is shared between PRUs or PRU and RTU.

PRU0 can read/write single cycle up to 120 bytes using XIN/XOUT. Same memory is shared with PRU1 and can be used for small dual port RAM block. 3 ns latency for 120 bytes translates into very high bandwidth interface of 320 Gbit/s. Ultrafast but limited to smaller memory blocks. 

2. DDR memory with maximum size 

XFR2VBUS widget can read from any memory location including DDR memory. Read latency is typically in the range of 380 ns for 4 bytes. In this case other side has to wait for DMA to be complete for sending out data from DDR. Task manager has xfr2vbus read complete trigger which simplifies the coding for long delay requests. 

Other options for shared RAM are ICSS memory, on-chip 2 MB RAM or R5F TCM.

In general your read latency is delayed by external iso device and serial to parallel conversion of the interface.

If you choose for example ISO7242M device you get about 20ns delay in each direction. This device can go up to 150 Mbit rate and gets you two signals in each direction. Whether you do 2 data lines or 1 data and 1 clk for each direction has a couple of dependencies.

In case you can clock both Sitara device from single oscillator you may not require a clock signal as the inferface will not drift if PRUs on both Sitara run the same clock. Without shared clock synchronization and without clock signal you would need to add synchronization pattern and learning phase to the communication. I expect that this scheme is probably too long for your low latency interface. You also have the option to transfer double data rate in one or two data lines per direction. You can spread out the rising and falling edge data to two PRUs in case you want to do run the interface at e.g. 150 MHz. 

From a protocol perspective you can do standard type with /command/address/data scheme or any custom, pre-engineered data transfers which are repeated with fixed timing.  For example, every 4 us there is a 64 byte data exchange between the two chips.

CRC16/32 is a hardware widget from PRU which is called using broadside interface. You can also issue a single cycle CRC calculation over 32 byte register range.

For 8B/10B line code there is a source code reference in the HDSL SDK example.

See: C:\ti\mcu_plus_sdk_am243x_08_06_00_43\source\motor_control\position_sense\hdsl\firmware\datalink.asm

and search for function: recv_dec_10b. It uses two step look-up tables

;decode
    ldi     REG_TMP11, (PDMEM00+LUT_5b6b_DEC)
    lbbo &REG_FNC.b0, REG_TMP11, REG_FNC.w2, 1

;decode
    and REG_TMP0.w2, REG_FNC.w2, 0x0f
    ldi REG_TMP11, (PDMEM00+LUT_3b4b_DEC)
    lbbo &REG_TMP0.b0, REG_TMP11, REG_TMP0.w2, 1

The LUTs are pre-loaded from ARM side at: C:\ti\mcu_plus_sdk_am243x_08_06_00_43\source\motor_control\position_sense\hdsl\driver\hdsl_lut.c

On standard interface the FSI interface comes close to your requirement using 2 data line DDR (200 Mbit) with a clock. However you would still use PRU to read and write low latency data and not involve the ARM core in the interface.

Let me know if  you need further guidance or discussion on the interface. We can also take it step by step. 

- Thomas