clock timing

You are running at 66 MHz, and you think Virtex2 is too slow? Are you kidding? Did you ever use the fine phase adjust capability in the DCM, where you can move the clock in 256 increments? Peter Alfke

Peter Alfke schrieb:

Hi Peter,

the lvds clock is 7*clk. I want to run at 85 MHz in the end, that would be 595 MHz.

regards, Benjamin

Hey Ben, Wherever I see "Falling edge" I worry! So, try making the Rising edge of 'pixel clock' your global data clock within the device. Shun that F-word. Make sure that everything you send outside the FPGA comes from a FF in an IOB clocked by the Rising edge of this clock. This includes the clock you're sending out. Search cyberspace for "clocks DDR". You can use the DDR magic in the IOB to copy the clock out in perfect synchronicity with your data. (Well, at 66MHz, perfect!) The DDR circuit absolves you of the F-ing word evil! Cheers Syms.

"Benjamin Menküc" schrieb im Newsbeitrag news:dj19v2$7hj$04$ snipped-for-privacy@news.t-online.com...

and that would be no big deal either. check out xapp265

85*7 means 1) output clock is 85MHz 2) highes clock on chip is 300MHz as you use DDR io flops

:)

for external lvds serdes

1) make sure data flops are on IOB 2) use DCM to adjust phy clock phase

given [1] and [2] you dont need any timing constraints on the phy output path, as the IOB clocked outputs have very little skew and DCM adjust your clock to the best timeslot

antti

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? 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?

Sorry for my basic questions :=)

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?

regards, Benjamin

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

Benjamin Menk=FCc skrev:

snip

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

-Lasse

Hi,

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

regards, Benjamin

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

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 answers!! Hopefully they give you enough info to try searching the Xilinx site for more detailed stuff.

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.

HTH, Syms.

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

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

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