Meeting timing requirement for tQH on i.MX28 DDR2 interface

cancel
Showing results for 
Search instead for 
Did you mean: 

Meeting timing requirement for tQH on i.MX28 DDR2 interface

582 Views
jschoen
Contributor III

Trying to close static timing analysis on i.MX28 DDR2 interface.  Can't make the datasheet numbers work out for the tQH (DDR22) specification. 

The minimum tCH (DDR2) and tCL (DDR3) from the data sheet is 0.5*tCK-0.5ns. For tCK=4.88ns (205 MHz), that works out to 1.94 ns.  Also per the iMX28 datasheet, the minimum data hold time for tCK = 4.88ns is 0.25*tCK+0.75ns which for tCK = 4.88ns works out to 1.97ns. So, before we even bring the DDR2 into the picture, the iMX28 specification appears to be in violation of its own minimum data hold time for the minimum/maximum clock duty cycle case. Otherwise stated, the required data hold time (1.97ns) cannot be greater than the half clock period (1.94ns) in a DDR synchronous machine.

Now, if we bring in the DDR2 timing, DDR2 tQH(min) = tHP – tQHS(max) where tHP is the minimum absolute half-period clock driven by the iMX28, and tQHS(max)  is 250ps - 400ps depending on the DDR2 device used. 

To meet timing:

tQH(min) of i.MX28 <= tQH(min) of DDR2 

0.25 x tCK + 0.75 ns <= tHP(min) - tQHS(max) 

i.MX28 data sheet gives minimum tHP of 0.5 x tCK - 0.5 ns which results in the following:

0.25 x tCK + 0.75 ns <= (0.5 x tCK - 0.5 ns) - tQHS(max)

0.25 x tCK + 0.75 ns <= (0.5 x tCK - 0.5 ns) - 0.3 ns

0.25 x tCK + 0.75 ns <= 0.5 x tCK - 0.8 ns

tCK >= 6.2 ns

This indicates that to meet tQH requirement requires DDR2 clock be limited to only 161 MHz.

One observation about the tCH/tCL specifications in the datasheet :   For 206 MHz, this would be a max duty cycle range of 40% - 60%. 

45% - 55% is typical for most controllers.

Any insight into flaws in this analysis or comments on meeting the tQH spec at the max rated i.MX28 DDR2 clock frequency of 206 MHz is greatly appreciated.

Labels (1)
8 Replies

219 Views
jschoen
Contributor III

Hi Mark,

Thanks very much for the update. 

Regarding the new/proposed tCH and tCL numbers, the customer made some duty cycle measurements on a small sample of their custom boards and got the following data :

Duty(max) = 56.389%

Duty(min) = 45.0229%

Samples were taken using a Tektronix DPO7354C (40Gs/s, 1Ts oversampling) and TDP3500 3.5GHz differential probe with short longhorn-style probe head.  The differential CLKP-to-CLKN measurement was taken at the DDR2 device end escape vias.

The Tektronix DPO7354C integrated DPOJET jitter analysis software was used to obtain the "Duty" measurements.

Are you familiar with this setup? We were wondering if you might be able to weigh in on the appropriateness of this measurement methodology and comment on why the measured numbers exceed the proposed specification.

Thanks.

Joel

0 Kudos

219 Views
jschoen
Contributor III

Hi Mark,

Have you been able to finalize the datasheet changes for tCK duty cycle?

Also, will the tQH spec be changing per your thoughts about already including tQHS from the DRAM?

Thanks!

Joel

0 Kudos

219 Views
TheAdmiral
NXP Employee
NXP Employee

Hi Joel,

I'm sorry this has taken so long. I have seen the revised numbers come back from the PE's and I think they look much more reasonable. We are going through a final round of approvals now and I hope to get the changes into the hands of Tech Pubs early next week.

Right now we are agreeing on 0.48*tCK and 0.52*tCK as the min and max duty cycles.

And the min value for tQH, for DDR2, will be 0.48*tCK - 0.45 nanoseconds, with no maximum value given.

Cheers,

Mark

0 Kudos

219 Views
jschoen
Contributor III

Hi Mark,

Thank you very much for your help on this.  If minimum tCH and tCL are 0.45tCK and tQH spec already accounts for tQHS, that would definitely satisfy the static timing analysis.

Joel

0 Kudos

219 Views
TheAdmiral
NXP Employee
NXP Employee

Hi Joel,

No, there are no flaws in your analysis.

I believe that the problem is in the datasheet numbers themselves. I have initiated action to have the PE responsible for the datasheet to double check the way they were reported. If he agrees with my findings, we will submit a request to revise the datasheet to the new numbers.

I agree that the half clock pulse widths should fall in the range of 45% - 55%.

Hopefully this shouldn't take too long to confirm.

Cheers,

Mark

219 Views
TheAdmiral
NXP Employee
NXP Employee

Hi Joel,

We (the Austin team) have identified the exact PE resposible for the data sheet and are now actively involved in discussions on what the new values should be.

I'm sorry this is taking so long, but datasheets are legal documents, so we want to make sure we get this right.

Cheers,

Mark

0 Kudos

219 Views
reagan_revisore
NXP Employee
NXP Employee

Mark,

Thank you much for the support.

Is the assumption that the datasheet revisions will come back with numbers that allow for 200MHz clock speed in the worst case scenario?

0 Kudos

219 Views
TheAdmiral
NXP Employee
NXP Employee

Hi Reagan,

Yes, the assumption should be that the numbers will show that operating at 200 MHz will meet JEDEC timing requirements.

To that end, the worst case average duty cycle in the datasheet will show worst case as 45% - 55%.

The spec for tQH is a little harder to pin down, mostly because we have to apply it across

mDDR, DDR2 and LPDDR2. I am a little concerned that if the customer is using a simulation, they may account for tQHS errors twice, once as a specified parameter in the model, and again built into our tQH: For example, our tQH value assumes that the Read Data from the device may very by tQHS allowed by JEDEC specifications. So if the simulations actually applies this worst case varience to the model, then applies our tQH value as a fixed requirement, the simulation may fail even though our processor actual need for a held signal.

Cheers,

Mark

0 Kudos