Clock to output timing achievable w/ PSOC5LP UDB?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
BuHa_1507271
Level 3
Level 3
10 replies posted 10 questions asked 10 sign-ins

How small can I get the clock-to-output delay for a UDB implemented component?

I've tried designing a simple experiment with a toggle flip flop driven by an external clock input (SCL) and sending it to the output pin (SDA).   The static timing analysis seems to be telling me it will take nearly 36 ns to update the output pad (see below.)   Is this a good figure, or am I missing something significant?  I had been hoping for something closer to 8-12 ns.

- Clock To Output Section

- SCL(0)_PAD

SourceDestinationDelay (ns)
cy_tff_1/qSDA(0)_PAD35.430
TypeLocationFanoutInstance/NetSourceDestDelay (ns)
macrocell1U(3,2)1cy_tff_1cy_tff_1/clock_0cy_tff_1/q1.250
Route1cy_tff_1cy_tff_1/qSDA(0)/pin_input5.779
iocell2P12[2]1SDA(0)SDA(0)/pin_inputSDA(0)/pad_out15.666
Route1SDA(0)_PADSDA(0)/pad_outSDA(0)_PAD0.000
ClockClock path delay12.735

P.S. I've verified the input and output pins are in transparent mode.  I'm assuming this avoids synchronizer delays.
0 Likes
1 Solution

OK, I got a chance to run a practical measurement with my new Rhode & Schwartz RTA4000 scope. It has a really good time base, 0.5 ppm @ 5GSa/s.   I updated diagram a little to clarify.

tsco.png

Using SIOs (port 12.0, .2, and .3) for their high sink currents.   I'm using the KitProg strictly as an asynchronous clock, and I have all pins in transparent mode.  I'm running it at room temperature, about 21 C.  Answering my own question...

 

PathMeasuredSTASTA (extended)
SCL to OUT_114.4 ns25.634 ns25.643 ns
SCL to OUT_222.8 ns36.300 ns36.885 ns

So it looks like the best tSCO I'm likely get is around 23 ns at typical temperatures, unless I go to some sort of external buffer/latch.  PSOC5LP is quite respectable, but there are FPGAs out there that spec timing meeting the I3C requirement.   I think the inexpensive ICE40 UltraPlus in an example, it has 2 specific pins for I3C.  

View solution in original post

0 Likes
12 Replies
BiBi_1928986
Level 7
Level 7
First comment on blog 500 replies posted 250 replies posted

Hello.

A few ideas to try.

Open project in Creator,

under cydwr, click on System tab.

Scroll to bottom and look at Temperature Range.  You can change (dependent on device) temperature range to 0 to 85C.  This will relax timing and might provide some improvement.  I say 'might' because it doesn't always.  But, it does reduce timing related conflicts when you run into them.

The other idea is to change physical pinout assignments.  You might find pin selection helps reduce timing delay.  Which pins, I couldn't say.  It's an experiment.  The clock path delay looks fairly long.

GPIO output pin drive current will effect timing delay as will (obviously) the slew rate setting.

Operating voltage will also have an effect.  5V faster vs 3.3V slower.

GPIO pin speed limit is around 33MHz (see datasheet), approx 30ns, for on-chip generated output signals.  So, 36ns for GPIO input to output delay is pretty respectable.

It'll be interesting to hear what Cypress has to say.

0 Likes
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

BuHa,

Did you set SCL and SDA pins to Transparent or Sync?

/odissey1

0 Likes

Thanks all, great to see this kind of response. 

Odissey1, yes, both input and output are set to sync mode transparent.

Bibi, I updated the temp, range as you suggested, the timing analysis did not seem to change, in fact it's currently a few 10s of picoseconds different.

To be clear, the timing I'm referring to is strictly from the timing analysis, not an actual measurement (yet.)  

0 Likes

Thank you Len,

Yes, SCL and SDA are I2C terms, and they have been adopted by MIPI's I3C sensor bus standard.  I3C differs from I2C in timing requirements,  and uses push/pull for SCL.  Maximum I3C SCL is 12.9 MHz, thought 12.5 is "typical" for what they call Standard Data Rate (SDR).   Download the I3C basic spec here.

The way the spec reads, the tSCO measurement does not need to account for bus delays, its strictly on-chip.  Just the dashed red line in the figure below.

tsco.png

0 Likes

BuHa,

If Figure 23 is correct, then  t_sco of 12ns or less is going to be very difficult to achieve in ANY system.

I'm reading in the figure that t_sco (= t6) is the total delay including t4 + t5 + (internal delays to get SCL to latch CLK).

Assuming (internal delays to get SCL to latch CLK) = 0, then the delays for buffer propagation delays need to be 6ns for each buffer.

This is usually achievable for systems operating 10C or above.  At colder temperatures, semiconductors tend to be more sluggish.  Therefore the rise and fall times tend to increase as do propagation delays.

On the PSoC5 for t5 timing , TriseF = TfallF 12ns (max).   There is already some delays for the output drive.   Also, for Fsioout frequency is 33MHz but it assumes a 25pF load cap.   The spec you list shows a 50pF load cap which will further increase the Trise and Tfall.

On the PSoC (as well as other processors) the assumption of (internal delays to get SCL to latch CLK) = 0 may not be valid.   The DFF in your test circuit appears to not require synchronization to BUS_CLK for the CLK signal.   However, there are other latching components that require the incoming CLK source to be sync'd.

Len

PS:  Now I understand your goal.   Your test circuit is a valid representation of what you are trying to achieve.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

OK, I got a chance to run a practical measurement with my new Rhode & Schwartz RTA4000 scope. It has a really good time base, 0.5 ppm @ 5GSa/s.   I updated diagram a little to clarify.

tsco.png

Using SIOs (port 12.0, .2, and .3) for their high sink currents.   I'm using the KitProg strictly as an asynchronous clock, and I have all pins in transparent mode.  I'm running it at room temperature, about 21 C.  Answering my own question...

 

PathMeasuredSTASTA (extended)
SCL to OUT_114.4 ns25.634 ns25.643 ns
SCL to OUT_222.8 ns36.300 ns36.885 ns

So it looks like the best tSCO I'm likely get is around 23 ns at typical temperatures, unless I go to some sort of external buffer/latch.  PSOC5LP is quite respectable, but there are FPGAs out there that spec timing meeting the I3C requirement.   I think the inexpensive ICE40 UltraPlus in an example, it has 2 specific pins for I3C.  

0 Likes

BuHa,

Since you got such fancy scope, can you please also measure timing from SCL to OUT_1 with and w/o SCL input buffer enabled? It is quite surprising that simple pass-thru from SCL to OUT_1 takes longer (14.4ns) than the rest of the logic (+8.4ns). I suspect that delay is caused by an input buffer and some board trace capacitances.

/odissey1

0 Likes

Sure, I'll try that out BoTa.  It will be a nice chance for me to learn how to use this new scope.   Also, I haven't experimented with "input buffer enabled" setting any, are you saying you think it might have an effect on the input pin's capacitance?  Note that the measurement I'm making is on the falling edge of SCL.  It is less effected by board capacitance than the rising edge.

Speaking of which, I've come to the conclusion that the CY8CKIT-059 doesn't have the right pull-up resistors for a 1MHz I2C bus, setting the bridge control program to 1 MHz doesn't give me a valid rise time on SCL because the signal never gets close enough to the 5 V rail.   (Here's my first screenshot with the new scope.)SCR01.PNG

So, I think that its fair to say there's a small design problem in the CY8CKIT-059's kitprog I2C (two really, because when the rate was set to 1 MHz with the bridge control Panel, it only generated 800 kHz.   It shouldn't impact my tSCO measurement, but I'll slow it down to the 400 kHz setting to be sure:

SCR04.PNG

A 14.8 ns clock fall time, due to board capacitance, seems about right, but the rise time (controlled mainly by the pull-up resistors and board capacitance, is a whopping 1,161.2 ns.      Now, lets see what happens to the pin representing the output of the toggle FF (in green.)

SCR08.PNG

So this is similar to my earlier tSCO measurement, here I get 23.7 ns, measuring from when both signals cross 4 volts.

Now, to answer BoTa's question, I turned off the "input buffer enabled" checkbox for the SCO input pin.   The unfortunate side effect was that my toggle signal stopped working.  In other words, without that checkbox set the pin stops being a digital input; but yes, it did change the capacitive loading, the clock signal fall time dropped from 14.8 ns to 11.8 ns, and the rise time stayed about the same: 1,161.2 ns up to 1,161.6 ns.

SCR09.PNG

0 Likes

P.S.  Are there engineers from Cypress on this thread?   It would be nice to get them to address the problems I think I found with the kitprog2 I2C frequency and pull-up resistors.

Could part of it be that the kitprog2 I2C master's output is operating with slew rate limiting on, even if the speed is set to 1Mb/s?  

Is the kitprog2 software open sourced?

0 Likes

BuHa,

I believe the Kitprog interface for the I2C on the Cy8CKIT-059 doesn't use the internal pull-ups.   The internal pull-ups (~5K) are designed to be used for I2C at 100Kbps.   The KitProg has the following circuit on the board for external pull-ups to support up to 400 kbps.  (See Table 7-2 below)

pastedImage_0.png

I found this info about the pull-up resistance need for I2C depending on desired data rate in the PSoC5LP family datasheet on page 50.

pastedImage_1.png

pastedImage_2.png

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

BuHa,

Judging from the first figure (130ns/division) the falling time is hardly 3 ns, not 15ns.

/odissey1

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

BuHa,

Check to see if there are any caps on the output port pin you are using.  The CY8CKIT-059 has caps on some pins in case you wanted to use these pins for Vref bypass (P3.2 & P0.3)  or SAR support (P0.2 & P0.4), the Capsense tank (P15.4) or the WCO circuit (P15.2 and P15.3).

As BiBi indicated the static timing analysis is using "worst-case" propagation delay (Td) across the specified temperature range.  Chances are at 20-25C your propagation delay should be in the 10ns range.

Note:  In your circuit listed,  SDA has Td from the toggleFF and the output buffer.

Yes.  Transparent mode has no MASTER_CLK resyncing.  It should be combinatorial logic without a latch.

Are you trying to achieve a very fast output clock?  Or are you trying to minimize the Td discrepancy between two outputs?

"In the old days", back when I designed CPU interfaces using discreet logic ICs, I would try to place the two outputs I needed to be within 10ns of each other on the same IC.   Same they were on the same IC, the Td variance would be >> 10ns as long as the capacitive and resistive loading is nearly equal.   If the temperature rose, the propagation delays on both outputs would track.

Since you're using the PSoC with many GPIO, this should be a problem.

Another trick is to add a 'buffer'-like logic to the signal with the shorter track.   Ie.  If signal A generates signal B with prop delay, then feed signal A through a buffer before exiting the IC.  The ideal is to provide a near-equivalent to the same amount of Td through each level of logic.

The circuit you listed is using I2C nomenclature.  Traditionally the SDA is set to the bit value before the rising edge of SCL and changed after the falling edge of SCL.  Assuming about a 50% DC of SCL, a Td of 12ns from SCL to SDA you can clock SCL to almost 41 MHz.   According to info on I2C, 5MHz is the top end of clocking.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes