Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DLL

Status
Not open for further replies.

Nilak

Programmer
Jun 9, 2004
14
CA
So I tried to use a DLL for implementing a phase shift (better performance at fanout), but when trying to simulate it using a testbench (in ModelSim XE II 5.7g), it doesn't work. Am I missing something? BTW, I used "XAPP132 DLL 1X and 2X" example from the xilinx home to make the code. Technically, a DLL should be able to output a phase shifted clock, or should I stick to PLL? Also, if someone could tell me what the purpose of "pragma and synopsys translate" is. Thanks in advance.

--Clocks (clk0, clk90) implemented using Delay locked Loop
--Outputs a 50/50 duty cycle, using DUTY_CYCLE_CORRECTION property
--(by default TRUE), equivalent clock and phase shifted (90deg) clock.
--NOTE: use "LOC=DLL2" for DLL location (top right).

library ieee;
use ieee.std_logic_1164.all;
-- pragma translate_off
library unisim;
use unisim.vcomponents.all;
-- pragma translate_on

entity clock_DLL is
Port ( clkin : in std_logic;
reset : in std_logic;
clk0 : out std_logic;
clk90 : out std_logic;
locked : out std_logic);
end clock_DLL;

architecture structural of clock_DLL is

signal clkIN_w, reset_w, clk0_dll, clk0_g, clk90_dll, locked_dll : std_logic;

component IBUFG
-- synopsys translate_off
generic(
TimingChecksOn: Boolean := DefaultTimingChecksOn;
InstancePath: STRING := "*";
Xon: Boolean := DefaultXon;
MsgOn: Boolean := DefaultMsgOn);
-- synopsys translate_on
port (I : in std_ulogic; O : out std_ulogic);
end component;

component IBUF
-- synopsys translate_off
generic(
TimingChecksOn: Boolean := DefaultTimingChecksOn;
InstancePath: STRING := "*";
Xon: Boolean := DefaultXon;
MsgOn: Boolean := DefaultMsgOn);
-- synopsys translate_on
port(
O : out std_ulogic;
I : in std_ulogic);
end component;

component clkDLL
-- synopsys translate_off
generic ( TimingChecksOn : Boolean := DefaultTimingChecksOn;
InstancePath : STRING := "*";
Xon : Boolean := DefaultXon;
MsgOn : Boolean := DefaultMsgOn;
DUTY_CYCLE_CORRECTION : Boolean := TRUE;
clkDV_DIVIDE : real := 2.0);
-- synopsys translate_on
port ( clkin : in std_ulogic := '0';
clkfb : in std_ulogic := '0';
rst : in std_ulogic := '0';
clk0 : out std_ulogic := '0';
clk90 : out std_ulogic := '0';
clk180 : out std_ulogic := '0';
clk270 : out std_ulogic := '0';
clk2X : out std_ulogic := '0';
clkDV : out std_ulogic := '0';
locked : out std_ulogic := '0');
end component;

component BUFG
-- synopsys translate_off
generic(
TimingChecksOn: Boolean := DefaultTimingChecksOn;
InstancePath: STRING := "*";
Xon: Boolean := DefaultXon;
MsgOn: Boolean := DefaultMsgOn);
-- synopsys translate_on
port(
O : out std_ulogic;
I : in std_ulogic);
end component;

component OBUF
-- synopsys translate_off
generic(
TimingChecksOn: Boolean := DefaultTimingChecksOn;
InstancePath: STRING := "*";
Xon: Boolean := DefaultXon;
MsgOn: Boolean := DefaultMsgOn);
-- synopsys translate_on
port(
O : out std_ulogic;
I : in std_ulogic);
end component;

begin
clkpad: IBUFG port map (I=>clkIN, O=>clkIN_w);
rstpad: IBUF port map (I=>reset, O=>reset_w);
dll: clkDLL port map (clkIN=>clkIN_w, clkFB=>clk0_g, rst=>reset_w,
clk0=>clk0_dll, clk90=>clk90_dll, clk180=>open, clk270=>open,
clk2X=>open, clkDV=>open, locked=>locked_dll);
clkg: BUFG port map (I=>clk0_dll, O=>clk0_g);
clk2xg: BUFG port map (I=>clk90_dll, O=>clk90);
lckpad: OBUF port map (I=>locked_dll, O=>locked);

clk0 <= clk0_g;
end structural;
 
the pragma's are used by various synthesizers to tell it different things (ie translate_off = ignore this code till you see translate_on)

for some reason I have this feeling that many DLL's don't really simulate, you have to do it on the real device to see what the output will be. But it seems strange that this would be the case.

I assume it actually simulates and you don't get errors, so you must have compiled the xilinx library to know what these parts are.

if you can, give it a try in a real device to see what is happening.

--
 
It synthesized after I removed all the generics from the buffer components. Also, when I made my test bench, I had set the reset signal initially to high for one clock cycle. When I just left the reset signal at low, I was able to get the desired outputs. Weird how the reset prevented the clocks from outputting even if it was set back to low. Maybe I should just remove it, after all, why would I need to reset clocks?
 
there is probably some state machine that gets reset. don't know why it would cause a problem, although 1 clock is kind of short, I would generally reset for a little longer in case there is some buffering of the reset signal.

The only thing I can suggest is going through xilinx datasheets and application notes for the dll to see what they have to say. Xilinx and Altera both have good information on their websites if you look for it.

But at least its working. Good luck

--
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Sponsor

Back
Top