clock timing

Hi,

I am driving a LCD display with a pixel clock of 66 MHz. The pixels are 
stored in a fifo, for parallel to lvds conversion I use an external IC, 
because my Virtex2 has a to small speed grade to do lvds directly.

I generate my pixel_clk with a dcm. Then I have

lvds_clk <= not pixel_clk;
lvds_ram_clk <= pixel_clk;

lvds_clk goes to the parallel to lvds converter IC and lvds_ram_clk to 
the fifo that contains the pixel data.

The pixel fifo takes its clock signal at rising edge.

I have a process where I set up my lcd control signals

process (pixel_clk,screen_reset)
begin
	if screen_reset='1' then
		....
	elsif rising_edge(pixel_clk) then
		....

the process sets up the control signals on the rising edge. I think with 
  this setup all the data should be ready at the falling edge. The 
problem is now, that the par->lvds IC needs the data 2.5 ns before 
falling edge (setup time) and 0.5 ns afterwards (hold time).

My constraints look like this:
NET "clk" TNM_NET = "clk";	-- clk goes into the dcm
TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %;

NET "pixel_clk" TNM_NET = "pixel_clk";	-- comes out of the dcm,
TIMESPEC "TS_pixel_clk" = PERIOD "pixel_clk" 10 ns HIGH 50 %;

-- pixel_clk = clk / 1.5

I think this is not enough to fulfill the timing requirements. Can 
somebody help me?

My display flickers a little bit, I am not sure where it originates 
from, timing issues or bad HF cable/circuit layout.

regards,
Benjamin

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

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&#4294967295;c" <benjamin@menkuec.de> schrieb im Newsbeitrag
news:dj19v2$7hj$04$1@news.t-online.com...
> Peter Alfke schrieb:
> > 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
> >
>
> 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

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:

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

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

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.