The order to change tap is "ce_data_inta <= 1'b1 ;"Could you highlighted which exact lines of code are about "the master delay will be ordered to change the delay tap." ?
assign incdec_data_im[i] = inc_dec[i] & mux[i] ; // Input muxes
assign incdec_data_or[i+1] = incdec_data_im[i] | incdec_data_or[i] ; // AND gates to allow just one signal through at a tome
assign valid_data_im[i] = valid[i] & mux[i] ; // followed by an OR
assign valid_data_or[i+1] = valid_data_im[i] | valid_data_or[i] ; // for the three inputs from each PD
As for ce_data_inta ,The order to change tap is "ce_data_inta <= 1'b1 ;"
if (ce_data_inta == 1'b1) begin
ce_data <= mux ;
if (inc_data_int == 1'b1) begin
inc_data_int_d <= mux ;
end
end
[phung@archlinux DDR]$ grep -n IODELAY *.v
phase_detector.v:23:// - State machine changed slightly to enable individual control of INC pins on IODELAY2s
phase_detector.v:67:input [D-1:0] busy ; // BUSY inputs from IODELAY2s
phase_detector.v:73:output cal_master ; // Output to cal pins on master IODELAY2s
phase_detector.v:74:output cal_slave ; // Output to cal pins on slave IODELAY2s
phase_detector.v:75:output rst_out ; // Output to rst pins on master & slave IODELAY2s
phase_detector.v:76:output [D-1:0] ce ; // Outputs to ce pins on IODELAY2s
phase_detector.v:77:output [D-1:0] inc ; // Outputs to inc pins on IODELAY2s
phase_detector.v:140: if (enable == 1'b1) begin // Wait for IODELAY to be available
phase_detector.v:156: 4'h2 : begin // Now RST master and slave IODELAYs needed for simulation, not for the silicon
phase_detector.v:168: 4'h4 : begin // Wait for IODELAY to be available
phase_detector.v:193: 4'h8 : begin // Wait for all IODELAYs to be available, ie CAL command finished
serdes_1_to_n_clk_ddr_s8_diff.v:70:wire ddly_m; // Master output from IODELAY1
serdes_1_to_n_clk_ddr_s8_diff.v:71:wire ddly_s; // Slave output from IODELAY1
serdes_1_to_n_clk_ddr_s8_diff.v:95:// IODELAY for the differential inputs.
serdes_1_to_n_clk_ddr_s8_diff.v:97:IODELAY2 #(
serdes_1_to_n_clk_ddr_s8_diff.v:125:IODELAY2 #(
serdes_1_to_n_data_ddr_s8_diff.v:89:wire [D-1:0] ddly_m; // Master output from IODELAY1
serdes_1_to_n_data_ddr_s8_diff.v:90:wire [D-1:0] ddly_s; // Slave output from IODELAY1
serdes_1_to_n_data_ddr_s8_diff.v:145:IODELAY2 #(
serdes_1_to_n_data_ddr_s8_diff.v:172:IODELAY2 #(
[phung@archlinux DDR]$
Yes, but it wasn't clear how multiple data lines are handled. It looks like the state machine "slowly" moves from pin to pin and adjusts the corresponding master and slave IODELAY2 primitives. "mux" is a one-hot register with a '1' for the data path that is currently being adjusted.@std_match the whole purpose of the phase_detector.v is used to control CAL pin of the IODELAY2 primitive
Why phase detector requires TWO ISERDES2 primitives ?
I mean that if we only look at the data samples that we want to take in the middle of the eye (the position is determined by the "master" delay line), there is no way to detect that the sample point drifts away from the middle of the eye.@std_match What do you exactly mean by "The master can't be used for the timing adjustment, because the need for a delay change wouldn't be detected until the data had already been corrupted." ?
1) Yes, this is done by the calibration mechanism inside the IODELAY2, and takes 8-16 GCLK cycles.I have a feeling that this dynamic phase calibration would only work well with two assumptions:
1. needs some clock cycles to use the data delay information to do deliberate phase adjustment
2. there has to be enough bit transitions for the incoming data bits
Please correct me if wrong
--- Updated ---
Would using bitslip be more suitable in this case ?
The data is invalid during the first calibration
Transitions can be guaranteed by using 8b/10b, 64b/66b coding or similar.
so the vaguely general description is that variations in things like PCB trace length can lead to variable amounts of skew between periodic (K clocks) or strobe (dqs) signals, such that the rising edge of these signals may not match up well with the data to be sampled. So, during DDR calibration you're going to first perform fine-tuned adjustment of the IODELAY taps in order to center the clocks/strobes between transition edges of your data. However, because the IODELAYs can only ...well, delay things...it's possible that the clocks/strobes can end up centered but a cycle out of sync. So the bitslip provides a way to delay the incoming signals on a cycle by cycle basis to account for that.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?