07-24-2017 06:28 PM
I've read the DS162, UG381, and some posts here, and still can't figure out...
I have the IODELAY configured as a variable delay:
IODELAY2_inst_1 : IODELAY2
generic map (
COUNTER_WRAPAROUND => "STAY_AT_LIMIT", -- "STAY_AT_LIMIT" or "WRAPAROUND"
DATA_RATE => "SDR", -- "SDR" or "DDR"
DELAY_src=> "IDATAIN", -- "IO", "ODATAIN" or "IDATAIN"
IDELAY2_VALUE => 0, -- Delay value when IDELAY_MODE="PCI" (0-255)
IDELAY_MODE => "NORMAL", -- "NORMAL" or "PCI"
IDELAY_TYPE => "VARIABLE_FROM_ZERO", -- "FIXED", "DEFAULT", "VARIABLE_FROM_ZERO", "VARIABLE_FROM_HALF_MAX" or "DIFF_PHASE_DETECTOR"
IDELAY_VALUE => 0, -- Amount of taps for fixed input delay (0-255)
ODELAY_VALUE => 0, -- Amount of taps fixed output delay (0-255)
SERDES_MODE => "NONE", -- "NONE", "MASTER" or "SLAVE"
SIM_TAPDELAY_VALUE => 75 -- Per tap delay used for simulation in ps
port map (
DATAOUT => open, -- 1-bit output: Delayed data output to ISERDES/input register
DATAOUT2 => TP_S0, -- 1-bit output: Delayed data output to general FPGA fabric
DOUT => open, -- 1-bit output: Delayed data output
TOUT => open, -- 1-bit output: Delayed 3-state output
IDATAIN => MSTID0, -- 1-bit input: Data input (connect to top-level port or I/O buffer)
CLK => IODEL_CLK, -- 1-bit input: Clock input
IOCLK0 => IODEL_CLK, -- 1-bit input: Input from the I/O clock network
IOCLK1 => '0', -- 1-bit input: Input from the I/O clock network
ODATAIN => '0', -- 1-bit input: Output data input from output register or OSERDES2.
BUSY => S6_REG_2(0), -- 1-bit output: Busy output after CAL
CAL => S6_REG_1(8), -- 1-bit input: Initiate calibration input
CE => CE_1, -- 1-bit input: Enable INC input
INC => S6_REG_1(10), -- 1-bit input: Increment / decrement input
RST => S6_REG_1(11), -- 1-bit input: Reset to zero or 1/2 of total delay period
T => S6_REG_1(12) -- 1-bit input: 3-state input signal
I am using a microblaze to increment/decrement the delay. I can see the delay incrementing until I get to about 130steps, and after that it does not change anymore.
In my code, I am generating a 1 clock pulse to increment/decrement, so it is not a case of the IODELAY incrementing several times per pulse.
Also, I have not been able to figure out what is/should be the relationship between the CLK and the IOCLCK? I am running both at the same frequency right now. Is this good, bad? When I had them running at 250MHz, the max delay I was able to reach was 5.2ns When I increased the CLK to 400MHz, it the max delay I was able to obtain was ~4ns. Why???
07-24-2017 10:44 PM
@traianm I think I can answer your last question: delay is implemented by a delay line calibrated for the clock period you use. So the number of taps don't change and but the delay of each tap gets smaller if you use a higher speed clock, ie with lower clock periods the precision per tap gets better but also the total delay gets smaller.
07-24-2017 11:13 PM
Well, I understand that the number of taps doesn't change. Makes sense. What I don't understand is
1. How do I calculate the approximate (I get it...it varies with voltage, temp, silicone, etc) value of the taps. The UG381, uses an "example" to explain this: "In this example, the delay taps have an average value of 40 ps under current operating conditions. An I/O clock of 250 MHz (4,000 ps period) is applied to the IODELAY2 via CLK0 for SDR mode. When the calibrate (CAL) command is issued, a value of 4,000/40 = 100 is returned internally" Where did the average value of 40ps come from? And if the average value is 40, then what is the 100ps?
2. Why did the delay stop changing (way) before i got to 250 steps? As I said in my post, I stopped seeing a change in the delay, about half way
I am just trying to figure out the approximate clock speed I need to apply to the IODELAY, in order to get my performance requirements...trying to get a balance between maximum delay and adjustment step