Piccolo SPI timing requirements

Bob,

We are looking into this right now and appreciate your patience. There are some architectural questions that I need to dig into and I hope to have some answers for you very soon.

Thanks,

Mark

Bob,

I'm also trying to use the Piccolo as a SPI slave and am finding issues in the datasheet.

Based on the SPI timing specs it doesn't look like two Piccolo's could talk to each other at the rated maximum freq of 10MHz.
The time it takes the slave to put the data on the bus (T15 delay time) is 21ns.*
The setup time (T10) is 26ns.
The minimum clock pulse duration (T2) is (0.5tspc -10) which is 40ns in the case of a 10MHz SPICLK. So 40ns is the minimum available time to latch valid data, but the minimum total time required to latch valid data = 21 + 26 = 47ns.

*In testing I'm finding the delay time (T15) can be up to 50ns which is over double the spec.

Dave

Hi Dave,

Your note about T15 is interesting to me and consistent, I think, with what I've seen. I was looking at a 1-bit-wide data pulse on the Slave's data output, comparing to the SCLK. Watching the scope continuosly triggering on the first rising edge of the SCLK, I could see the pulse "dancing" between two locations. The pulse was meeting timing in one case, but then would move one SYSCLK period (12.5 ns in my case) to the right (exceeding the T15 spec).

It would appear that the DSP SPI peripheral samples the SCLK input and acts upon this sampled info. A little history: initially, I had an 8MHz SCLK waveform that had a 40% duty cycle. Things appeared to work just fine. But upon further examination of the Piccolo datasheet, I realized I had to change this to a 50% duty cycle. To do so, my SCLK master now needed to output the falling SCLK edge (latching edge) on a falling edge of its HF internal clock. Since this HF clock is synchronized with the DSP's external clock, I believe SCLK falling edge is now nearly coincident with the falling edge of SYSCLK within the DSP. It was only upon making this change that the "dancing" referenced above became evident.

Until TI chimes in, I am merely speculating on the sampling nature of the slave SPI behavior. And while it may be an interesting observation, it doesn't clear up any of my datasheet confusion I'm afraid.

Sincerely,

Bob

Bob,

I think you're right that SPICLK is sampled.  I increased the SYSCLK freq from 50 to 80MHz and T15 is now ~30ns instead of 50 in our case.  In fact, it jumps around between 25 and 40ns further supporting your sampling theory.

Dave

Bob,

To fix the "sampling" issue TI reminded me to set the GPxQSEL register for the SPI pins to asynchronous (3).

Dave

Bob,

Apologies for the delay, there has been a little back and forth while we looked into your questions.

1)      As long as the minimum pulse width is being met, then the max will be a  ‘don’t care’. 

2)      You are correct that a MAX timing does not make sense. As long as the minimum pulse duration is met for both High and low pulse, the SPI should operate properly.  If SPICLK is significantly slower than LSPCLK, then an asymmetric clock will be ok.

3)      We are looking at how this is implemented in the design, but T16, tv(SPCL-SOMI)s, will in fact be held until the next clock edge. If no clock ever comes, the data will still be held. This is incorrect on the diagram as well as the timing provided. Ideally, SOMI will have been sampled at the second clock edge.

 As David has seen, the QSEL configuration will have an impact on the output of the SPI signals. Please verify that your QSEL is properly configured to be Asynchronous w.r.t. SYSCLK on the SPI input signals.

We are still discussing this with our design team and will be revising the datasheets to reflect our findings. 

I hope this will help you out. Of course, if you still have questions, don't hesitate to ask.

-Mark

Mark,

Thank you for your time and effort to answer these questions. Is it possible to quantify "If SPICLK is significantly slower than LSPCLK" as you've indicated in 2), above? Would a factor of 5x, 8x, or 10x suffice?

If I may, I'd like to ask one additional question. Note 3 of Table 6-37 of the datasheet says the following:

Internal clock prescalers must be adjusted such that the SPI clock speed is limited to the following SPI clock rate:

... Slave mode transmit 10-MHz MAX, slave mode receive 10-MHz MAX.

Is this an absolute maximum clock rate as the note suggests? Specifically, if an external clock is driving the DSP at 10MHz, PLL1 is multiplying up to 80MHz internally, and the prescalars are adjusted such that the SPI clock rate is 10MHz (i.e. dividing SYSCLK by 8), would this spec be violated if the external clock was running fast? I assume that since everything would scale with the exernal clock source, then SCLK would exceed 10MHz and this would be in volation. But then I must ask: what if the internal oscillator (10MHz) were in use in a similar fashion? Since this can run a bit faster than 10MHz, would it violate this spec given the same prescalar values? If not, how high could the 10MHz oscillator go?

Sorry to expand the original question set. I should have perhaps included it in the original posting.

Again, thanks to you and those working with you for your help/support. Thanks also to David who forwarded your guidance on setting the GPxQSEL to asynchronous for the SPI pins. This is in fact improperly set in my present design.

Sincerely,

Bob W

Mark,

I believe you have answered all my questions.

Thanks for your time and effort. My apologies for this overdue/late response.

Sincerely,

Bob