I am trying to deserialize a DDR signal in my Cyclone. For reasons I won't go into the DDR clock comes in off a general purpose I/O pin. I need a way of deserializing this signal, and want to increase the frequency of the DDR clock by 2 so I can use rising edge flip-flops.
1.) Can I somehow drive a PLL with a general purpose I/O
2.) Is there another way of deserializing the DDR signal.
Currently I have a the DDR clock coming in my fpga and I not the clock so I can sample the DDR signal on the rising egde.
I don't think so. I'm using Cyclone II at the moment and I'm 99.9% sure you can't feed the PLLs with anything except one of the 'clock input' pins. (These can also be general purpose input pins, so I would always recommend connecting anything vaguely 'clock-like' to one of those pins, even if you think you might not actually use it as a clock.)
You don't say anything about frequency, but I'd be inclined just to sample on the falling edge as well, and then shift the two bits (+ve edge and -ve edge) into your shift register on the next +ve clock.
The problem I am having maybe due to jitter. I am not sure. I am running under 35 MHz, althougth I am using LVDS. I am sampling on the rising and falling edge of the clock, and the deserializer needs to take every 7 clocks (respective 14 bits) since it is DDR. When I look at the output clk/7 that I generate by a simple counter (when counter = 1-4 clk is high, when counter = 4-7 clk is low), I see that the duty cycle changes by about 1 clock. It seems as though the counter misses a beat or something of that nature.
What I expect to see is a newly generated clock where the rising edges occur at the same place every time, although, I see a rising edges "walk" with respect to my trigger on the scope. I have no idea the source of the problem, or how to fix it.
If your input clock is not on the global clock network you will be fighting with clock skew to the flops. When your clock edges are happening with respect to the data at the flops becomes an utmost concern for you.
If I understand what you're saying, it doesn't sound like it's anything to do with picking-up the falling-edges - surely your count-to-seven is only trigged off the positive edges anyway?
Will here I have the entire serializer, it looks like a lot of code but most all the lines are repeated. Just to clarify it desrialized 14 bits of a ddr signal. So every 7 clock cycles the 14-bit word is latched. Clk is the signal that is the clock that has a problem with duty cycle, it is driven by toggler and toggler is driven by the counter. Thanks so much for you help. Having a group like this is extremely valuable.
ENTITY ad9259deser IS -- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE! PORT ( dco : IN STD_LOGIC; fco : IN STD_LOGIC; sera : IN STD_LOGIC; serb : IN STD_LOGIC; serc : IN STD_LOGIC; serd : IN STD_LOGIC; cha : out STD_LOGIC_VECTOR(13 downto 0); chb : out STD_LOGIC_VECTOR(13 downto 0); chc : out STD_LOGIC_VECTOR(13 downto 0); chd : out STD_LOGIC_VECTOR(13 downto 0); clk : out STD_LOGIC ); -- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!
END ad9259deser;
-- Architecture Body
ARCHITECTURE ad9259deser_architecture OF ad9259deser IS
signal ba0,ba1,ba2,ba3,ba4,ba5,ba6,ba7,ba8,ba9,ba10,ba11,ba12,ba13 : std_logic := '0'; signal ba14,ba15,ba16,ba17,ba18,ba19,ba20,ba21,ba22,ba23,ba24,ba25,ba26,ba27 : std_logic := '0';
signal bb0,bb1,bb2,bb3,bb4,bb5,bb6,bb7,bb8,bb9,bb10,bb11,bb12,bb13 : std_logic := '0'; signal bb14,bb15,bb16,bb17,bb18,bb19,bb20,bb21,bb22,bb23,bb24,bb25,bb26,bb27 : std_logic := '0';
signal chat,chbt : std_logic_vector(13 downto 0);
signal count_dco : unsigned(4 downto 0) := (others=>'0'); signal count_fco : unsigned(4 downto 0) := (others=>'0'); signal toggler : std_logic := '0'; signal go : std_logic := '0'; signal test : std_logic;
BEGIN
process(fco) begin if(fco'event and fco='1') then go do with picking-up the falling-edges - surely your count-to-seven is only
As for the clock not being part of the global clock network, Quartus gives me the following message "Info: Automatically promoted signal "dco" to use Global clock in PIN 29" so I guess my clock is put into the global network.
It would be even more valuable if I was a VHDL person rather than a Verilog one, but it does appear that you're trying to count to 14, when I think I would be trying to count to 7, and dealing with two bits on every count.
So you'd have one bit of code which just samples the data on the negative edge of the clock and stores it, and another bit which works on the positive edge of the block, samples one bit and stores BOTH bits into your shift register on each positive edge.
Like I say, I'm not a VHDL person, but I suspect there is a rather neater way to write that code - hopefully someone else might offer some advice.
You're also assigning to count_dco in two places when it's equal to 13 - I don't know how that gets synthesised in VHDL, but it's the kind of thing I avoid.
Is this your original code or did you lift it from somewhere else?
Have you tried a functional simulation of this? (In Modelsim or ActiveHDL, for example?)
I don't really think you're doing anything terribly ambitious, and it's perhaps a bit early to be worrying about jitter and PLLs at this stage. (Don't be distracted by the efforts people make to get DDR266 interfaces working - that's a completely different type of problem.)
Will I did make a cleaner version with no counters: here it is.
ENTITY ad9259deser IS -- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE! PORT ( dco : IN STD_LOGIC; fco : IN STD_LOGIC; sera : IN STD_LOGIC; serb : IN STD_LOGIC; serc : IN STD_LOGIC; serd : IN STD_LOGIC; cha : out STD_LOGIC_VECTOR(13 downto 0); chb : out STD_LOGIC_VECTOR(13 downto 0); chc : out STD_LOGIC_VECTOR(13 downto 0); chd : out STD_LOGIC_VECTOR(13 downto 0); clk : out STD_LOGIC ); -- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!
END ad9259deser;
-- Architecture Body
ARCHITECTURE ad9259deser_architecture OF ad9259deser IS
signal dco_plus, dco_minus : std_logic;
signal ba0,ba1,ba2,ba3,ba4,ba5,ba6,ba7,ba8,ba9,ba10,ba11,ba12,ba13 : std_logic := '0'; signal ba14,ba15,ba16,ba17,ba18,ba19,ba20,ba21,ba22,ba23,ba24,ba25,ba26,ba27 : std_logic := '0';
signal bb0,bb1,bb2,bb3,bb4,bb5,bb6,bb7,bb8,bb9,bb10,bb11,bb12,bb13 : std_logic := '0'; signal bb14,bb15,bb16,bb17,bb18,bb19,bb20,bb21,bb22,bb23,bb24,bb25,bb26,bb27 : std_logic := '0';
signal chat,chbt : std_logic_vector(13 downto 0);
signal count_dco : unsigned(4 downto 0) := (others=>'0'); signal count_fco : unsigned(4 downto 0) := (others=>'0'); signal toggler : std_logic := '0'; signal go : std_logic := '0'; signal test : std_logic;
Have you read chapter 10 in the Cyclone Device Handbook? "Implementing Double Data Rate I/O Signaling Cyclone Devices" You are using a Cyclone and not Cyclone2, correct?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.