DK-TM4C129X: Controlling relative Ethernet/µDMA bus priority

Hi Todd and Steven:

The attached oscilloscope trace, taken from a DK-TM4C129X board, shows

1. a GPIO used to trigger 4 16-bit DMA transfers in a single arbiter-locked transfer to SSI1 as a "pusher" to force an SSI receive,
2. the SSI1 clock, and
3. the SSI1 data.

The aqua jitter shadow between the oscilloscope cursors is 264 ns long.  Simultaneous with the Ping-Pong SSI output, there is a scatter-gather SSI input DMA which transfers 64 16-bit words.  I programmatically verify that an incrementing sequence I transmit over the SSI to a wire loopback makes it back via this DMA.  The SG DMA is looped, continuously transferring a request from memory location dmaTrigger to UDMA_SWREQ.  The request is usually zero, but, if software loads a request value to the location, it triggers a one-shot DMA which does some atomic hardware work synchronously with the looped DMA, and writes dmaTrigger back to zero.  The SG DMA also transfers EMACTIMSEC/EMACTIMNANO to memory after transferring a block from the SSI.  These gymnastics provide signal timing which ensures really good performance in the analog signal path.  The only arbiter lock greater than one transfer is the one which does the SSI output transfer which is jittering.

This scheme runs SSI in, SSI out, UDP out, dmaTrigger requests via HTTP every 1/2 second and a UDP broadcast overnight every 5 seconds with no errors.  The "dummy" tasks in the SG DMA are required to avoid a fixed 16-bit offset of the data in the SSI receive stream.  I am measuring jitter.  My hardware design will provide external hardware to adjust out the fixed portion of the latency in this periodic scheme.

I am using tirtos_tivac_2_16_01_14.  If TI-RTOS is doing high-priority, long-arbiter-lock uDMA's, that might be the cause.  But, then, I know of no uDMA usage registration scheme in TI-RTOS, so I would assume that isn't being done, because the OS probably doesn't have a way to know that I'm not using a channel it might select.  Is TI-RTOS occasionally globally-disabling the uDMA?  That might do it too.

Thanks,

Leo

Here is the jitter with SSI RX disabled and the Ethernet cable unplugged:

With SSI RX disabled and Ethernet plugged in, with or without high-speed UDP, there is no change from the above trace.  With SSI RX enabled and the Ethernet unplugged, there is no change from the above trace.  When I go back to full load, as shown in the very first trace in this thread, I'm now seeing about 148 ns.  This may be an address dependency, where moving a buffer somewhere and changing its alignment is causing access delay.

I just constrained the alignment of my DMA data buffers to 256 bits, since I read in the manual that uDMA uses "memory striping," which sounds like multibank wide accesses, so this may help.  The command structure table is of course already aligned.  I also constrained the task list alignment to 128 bits, which is the task size: 32*4=128.  If tasks are being copied into the alternate structure using misaligned accesses, that will surely be time-consuming.  Now I see about 280 ns!  Trying multiple hardware resets and disconnecting the debugger doesn't change the observed jitter.  Neither does a complete power-cycle.

Given the speed at which the design runs, I have to use DMA, and I'm reluctant to shoehorn in the driverlib implementation.  That is the threshold of effort at which I am willing to live with the problem.  It is tolerable -- just a performance loss I would rather not have.  A reduction in jitter of t nanoseconds allows me to decrease my ADC sample interval by just that amount.  If there isn't a hardware reconfiguration trick I can try, it's probably time to give up on this one.

One potential lead: I note that the SSI burst length is 256 ns, about the same length as the jitter, at least in this compile.  I wonder if there is timeslot-like behavior being excited in the SSI.  I haven't seen any configuration bits for the SSI which appear that they might affect that kind of behavior.  I do have HSCLKEN set, because I think I must have it to work at 66 MHz.

My current bet is that the timing of an off-boundary address alignment is enough to kick the SSI out of timeslot-like behavior.  I will save investigation of that for sometime when the workload is smaller.

Best regards,

Leo

By moving the trigger to the SSI clock, I get this trace:

Now, it looks highly probable that the SSI is cogging at its own transfer interval.  The real jitter, showing up as the transition width on the yellow trace, is less than 100 ns, while the transitions are separated by the SSI transfer time.  Perhaps the SSI TX needs to be a task which writes to an "End of transmission" bit, to keep the SSI from doing some sort of end of transmission timeout.