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

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

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

"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,

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

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 Benjamin,
I've included comments.
"Benjamin Menk&#4294967295;c" <benjamin@menkuec.de> wrote in message 
news:dj30ji$58q$03$1@news.t-online.com...
> Hello,
>
> Okay, I want to latch all my data that goes to the lcd (via the external 
> lvds serializer). Or should I use a FF?

So, use FFs and clock them all with the rising edge of your 66MHz 
masterclock. This clock should be driven by a BUFG.

> I need something that takes the data on rising edge and has it available 
> on the output on the next rising edge with enough sample and hold time.
>
> Is it possible to do that with the IOB or do I have to build a latch in 
> VHDL?
>
Just write it as normal VHDL, but make sure your synthesis tool packs the 
FFs into the IOBs. This ensures you have very little timing skew between 
your outputs as each FF is clocked by the low skew masterclock. If the data 
came from CLB FFs you are at risk of the vagaries of the P&R software; each 
individual data signal could have a different delay before emerging from the 
device. Now you also need to pass a clock to your serialiser, as well as the 
data. The data's easy, as we said, and comes from the output FF in each data 
IOB. The clock is also sourced from the IOB FFs, but this time we use the 
DDR registers. Look at figure 11. of XAPP622. This ensures minimal skew 
between the clock output and the data output. If you just wire the clock 
straight out, you have to contend with routing delays. You may have to 
instantiate this DDR primitive in your code, although I vaguely recall that 
Synplify can infer this operation.
>
> Sorry for my basic questions :=)
>
Sorry for my basic answers!! Hopefully they give you enough info to try 
searching the Xilinx site for more detailed stuff.
>
> PS: In theory my rising and falling edge thing should work, why is it so 
> bad? Is it not possible to set a timing contraint so that a process that 
> is triggered by rising edge has every output available on falling edge?
>
The problem is the delays from the masterclock to the outside world signals 
are variable due to the routing, unless you can use something like I 
describe above.
>
> regards,
> Benjamin

HTH, Syms. 

Hi,

I thought about that too. Is that a common practice or bad coding with 
evil side-effects?

regards,
Benjamin

Benjamin Menk=FCc skrev:

> Hello,
snip
>
> PS: In theory my rising and falling edge thing should work, why is it so
> bad? Is it not possible to set a timing contraint so that a process that
> is triggered by rising edge has every output available on falling edge?

assuming the clock 50/50 duty cycle that should be the same as
constraining it to twice the frequency ;)=20

-Lasse

Hi Antti,

see my answer to Symon.

How do I set my outputs to have an FF in the IOB?

Is a DCM already neccessary to adjust clock phase at 85 MHz? If I 
remember correctly I have to use a special pin on a clock net to do 
phase correction with a DCM, I am not sure if this is the case in my 
design. Maybe I can change that for the next version.

regards,
Benjamin