clock timing

Hi Symon,

fig. 11 in XAPP622 is about direct LVDS output. I am doing the parallel 
to lvds conversion with an external IC.

My VHDL Latch looks like this:
process (pixel_clk , screen_reset)
begin
	if screen_reset = '1' then
		lvds1 <= "0000000";
		lvds2 <= "0000000";
		lvds3 <= "0000000";
		lvds4 <= "0000000";
	elsif rising_edge(pixel_clk)then
		lvds1 <= lvds1pre;
		lvds2 <= lvds2pre;
		lvds3 <= lvds3pre;
		lvds4 <= lvds4pre;
	end if;
end process;

pixel_clk is my master clock. The lvds signals contain pixel color + 
control signals for the lcd. Somehow the results are worse now than before.
I am running 66 MHz pixel_clk at the moment. Is it neccessary to take 
special care of the pixel_clk output? My pixel_clk output is on a glck pin.

I generate my pixel_clk like this:

dcm2_1 : dcm2 port map (
	CLKIN_IN => clk_ibufg,
	RST_IN => RESET,
	CLKFX_OUT => clk_180m,
	CLKDV_OUT => pixel_clk,
	LOCKED_OUT => lvds_locked,
	CLK0_OUT => open);

where clk_ibugf is a 100MHz input clock that gets divided by 1.5. I have 
  connected the output "pixel_clk" of my entity directly to the dcm.

What is wrong or what should I improve?

regards,
Benjamin

Hi,

I have looked in the fpga editor. My VHDL code really uses the FFs 
inside the IOBs.

However I saw, that my clock output goes directly to the pad inside the 
IOB, furthermore it doesn't look like a good routing inside the FPGA. 
However the lvds_clk Signal in that reaches the IOB where the clk pin is 
  located is named "lvds_clk_OBUF" so I guess the compiler put an OBUF 
on it :) I remember that there was an OBUFG for clocks... Is it better 
to use this instead? If yes, how do I implement that in VHDL?

Antti said "use DCM to adjust phy clock phase". How do I do that in my case?

I have a mistake in my last post: My output definition in the entity of 
the design is lvds_clk.

Somewhere in the code I do just lvds_clk <= pixel_clk.

Thank You :)

regards,
Benjamin

"Benjamin Menk&#4294967295;c" <benjamin@menkuec.de> wrote in message 
news:dj3v5s$3t1$01$1@news.t-online.com...
> Hi Symon,
>
> fig. 11 in XAPP622 is about direct LVDS output. I am doing the parallel to 
> lvds conversion with an external IC.
>
Hi Benjamin,
You've missed the point. It's the DDR bit of the diagram I wanted you to 
look at, not the output buffer. That FDDRRSE is in the IOB. After looking up 
FDDRCPE in the libraries guide, try something like this in your VHDL:-

  component FDDRCPE
   port (
     Q : out std_logic;
     C0 : in std_logic;
     C1 : in std_logic;
     CE : in std_logic;
     CLR : in std_logic;
     D0 : in std_logic;
     D1 : in std_logic;
     PRE : in std_logic
   );
  end component;

begin

  not_clock <= not clock;

  fddrcpe_ins : fddrcpe
    port map (
      q   => output,
      c0  => clock,
      c1  => not_clock,
      ce  => '1',
      clr => clr,
      d0  => '1',
      d1  => '0',
      pre => pre
    );

The output can be any standard, set it in your UCF.

HTH, Syms.
p.s. The gclk pins have special features for incoming clocks, not outgoing 
ones AFAIK.

Hi,

the whole thing works now. I am doing the LVDS with the IOB now.

The Problem was:

* Some hand-soldered fixes on the par->lvds line make problems on high 
frequency

* I did not transfer all the code fixes (most important one is to latch 
the output data) to the direct lvds version

After I have taken the code improvements from the par->lvds version to 
the direct lvds version it works now very good. I am doing the LVDS Bus 
at 380 MHz, thats the highest a DCM can do on my speedgrade on a 2x 
output. If I want to do higher Frequency I would need a fast external 
clock or use the DDR functionality I guess.

The hardware part of my work is finished with that for now. Maybe later 
I will order a new PCB for the par->lvds version, with the bugfixes so 
that I can use that to. On the current board there is the clk to the 
par->lvds IC on the wrong pin of the board connector, because the MEMEC 
handbook is wrong :( I have fixed that with a wire, but it seems like 60 
MHz is too much for that wireing. Because the picture on the screen 
improves when I touch that wire with my hands :-o very strange...

Thanks to the group for the help so far :)

regards,
Benjamin

Hi Symon,

yes I figured out that there are only IBUFG but no OBUFG :)

See my other post in this topic - it works now. If I need later on a 
higher speed than the 2x output of my DCM can do (for me its 380 MHz), 
than I will look at the DDR stuff.

The thing I was missing was really to latch all the outgoing data. In 
later designs I will not use a falling edge thing again, it is really a 
pain.

regards,
Benjamin

Benjamin Menk�c wrote:
> Hi,
> 
> I have looked in the fpga editor. My VHDL code really uses the FFs 
> inside the IOBs.
> 
> However I saw, that my clock output goes directly to the pad inside the 
> IOB, furthermore it doesn't look like a good routing inside the FPGA. 
> However the lvds_clk Signal in that reaches the IOB where the clk pin is 
>  located is named "lvds_clk_OBUF" so I guess the compiler put an OBUF on 
> it :) I remember that there was an OBUFG for clocks... Is it better to 
> use this instead? If yes, how do I implement that in VHDL?
> 
> Antti said "use DCM to adjust phy clock phase". How do I do that in my 
> case?
> 
> I have a mistake in my last post: My output definition in the entity of 
> the design is lvds_clk.
> 
> Somewhere in the code I do just lvds_clk <= pixel_clk.

You probably want to use an FDDRRSE (DDR Flip-flop) to forward the 
clock, as this means that the clock signal to the output is routed 
properly over global clock resources - if you are trying to route it 
directly out, you get messy results (local routing etc).

You may also want to look at the output of your static timing analyser 
to determine what your output timing actually is.

Jeremy