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.