You start sampling at this point (typically, by setting the CE pin of your deserializer).
When you calibrate reading you need to write known data to the chip, otherwise there's no way to figure if your reading is Ok or not. But to write data, you need to calibrate writing first. Since you cannot read anything back because the read is not yet calibrated, you need to calibrate writes without reads, for example, by using write leveling.
From the portions of Altera's official DDR3 ram controller which arent encrypted, they have a test ram calibration during power-up. They do use a random number generator to generate write test data and read it back to confirm no bit errors. To do thing properly, your calibration test sequence should implement such a strategy to confirm the data integrity of a random data pattern during power-up.
But to write data, you need to calibrate writing first. Since you cannot read anything back because the read is not yet calibrated, you need to calibrate writes without reads, for example, by using write leveling. But write leveling will only align your phase within 360 degrees. This makes the process somewhat tricky. The process requires many steps until you fully calibrate anything.
As for "write leveling will only align your phase within 360 degrees." , write leveling could only help to align DQS strobe with CK signal. So, it is still not enough to perform the clocK-Centering activity for those parallel write data DQ bits signals.
Furthermore, someone told me that I shall encode the delay tap of IODELAY2 primitive as gray code (0, 1, 3, 2, 6, 7, 5, 4, C, D, F, E, A, B, 9, 8 ) . But does it really matter whether it is gray code or not for IODELAY2 ?
I always thought the Xilinx's delays are glitch free.
If you delay the clock (e.g. DQS) and the clock is fast, instead of worrying about glitches, I would rather worry about smoothness of changes and do 0,1,2,3 ... rather than allowing big changes (e.g. from 4 to C).
Most controllers simply write DQ with a clock which is nominally 90 degree shifted from the clock they use to write DQS, assuming that DQ and DQS are length matched and have minimum skew.
It is up to you to decide what you're going to calibrate and how.
@NorthGuy You mean the following skew situation would not actually happen for write activity ?
now, I am checking if I could eliminate either cal_master or cal_slave signal since I am only using one single whole deserializer
I suspect the same phase calibration mechanism could be done without using an extra SLAVE ISERDES
They use master and slave because they re-calibrate dynamically while maintaining communications at the same time. This adjusts the delays to ongoing temperature and voltage variation.
In other words, how to generate the D0 and D1 input signals for ODDR2 primitive ?
IF you write your own - you'll need two - one for D0 and one for D1.
QuoteIF you write your own - you'll need two - one for D0 and one for D1.
I have an SDR SERDES running at n clock rate (posedge of 303MHz), but the ODDR2 need to receive new bit (D0 or D1, depending on posedge or negedge) every 2n clock ticks (both posedge and negedge of 303MHz).
I do not understand how is having two separate OSERDES would help to solve the clock rate matching issue ?
By the way, how to move the DQS strobe to the center of write DQ bits ?
Another separate question on bitslip:
In https://www.xilinx.com/support/documentation/user_guides/ug190.pdf#page=366 , how to derive the table for DDR mode inside Figure 8-10 ?
As it says, when you apply BITSLIP it rotates 1 bit to the right, the next time it rotates 3 bits to the left and so on. This may be different in Spartan-6.
The rationale of using 3 bits rotation is a bit strange though ?
By the way, must I use IODELAY2 primitive in order to shift the incoming READ DQS strobe to the center of the parallel DQ bits ?