how to constrain this

Hi,

my pad input clock is 100 MHz (clk_ibufg). I have constrained this to period 10 ns. How should I constrain the lvds_tick, which runs at max.

360 MHz ? Is this done automatically when I constrain clk_ibufg? Should I constrain the 180 MHz clock too?

regards, Benjamin

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

dcm3_1: dcm3 PORT MAP( CLKIN_IN => clk_180m , RST_IN => not lvds_locked, CLK0_OUT => open, CLK2X_OUT => lvds_tick, LOCKED_OUT => open );

Reply to
Benjamin Menküc
Loading thread data ...

Hi again,

when I add this constrain, my design doesn't work anymore.

NET "clk" TNM_NET = "clk"; TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %;

very strange, I don't understand this.

I am a little bit worried about this:

========================================================================= Timing constraint: Default period analysis for Clock 'clk' Clock period: 14.088ns (frequency: 70.984MHz) Total number of paths / destination ports: 3140 / 194

------------------------------------------------------------------------- Delay: 4.696ns (Levels of Logic = 14) Source: col_count_0 (FF) Destination: col_count_10 (FF) Source Clock: clk rising 3.0X Destination Clock: clk rising 3.0X

Data Path: col_count_0 to col_count_10 Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ FDCPE:C->Q 5 0.419 0.738 col_count_0 (col_count_0) LUT4:I0->O 5 0.351 0.738 Ker1511 (CHOICE236) LUT3_D:I0->LO 1 0.351 0.000 Ker1541 (N737) MUXCY:S->O 1 0.422 0.000 col_count_inst_cy_0 (col_count_inst_cy_0) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_1 (col_count_inst_cy_1) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_2 (col_count_inst_cy_2) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_3 (col_count_inst_cy_3) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_4 (col_count_inst_cy_4) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_5 (col_count_inst_cy_5) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_6 (col_count_inst_cy_6) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_7 (col_count_inst_cy_7) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_8 (col_count_inst_cy_8) MUXCY:CI->O 1 0.044 0.000 col_count_inst_cy_9 (col_count_inst_cy_9) MUXCY:CI->O 0 0.044 0.000 col_count_inst_cy_10 (col_count_inst_cy_10) XORCY:CI->O 1 0.973 0.000 col_count_inst_sum_10 (col_count_inst_sum_10) FDCPE:D 0.263 col_count_10 ---------------------------------------- Total 4.696ns (3.219ns logic, 1.477ns route) (68.5% logic, 31.5% route)

regards, Benjamin

Reply to
Benjamin Menküc

Hi,

I figured out, that I have to use Place & Route Timings, because the DCM constraints are not even included in the synthesize timings.

How can I manipulate the automatic DCM constraints? (besides overwriting single nets or groups with FROM-TO) Or is there never a reason to manipulate them?

regards, Benjamin

Reply to
Benjamin Menküc

Hi Group,

I figured out, that the automatic DCM constraints are only generated, if I specify the clk input of the first DCM with a manual constraint. Still I am wondering a little bit, if I have any impact on the automatic DCM cosntraints?

regards, Benjamin

Reply to
Benjamin Menküc

Hi,

I know a little bit of the answer already by now. It is because, the DCM auto constraints were not there, before I added the clk constraint.

Is it possible to get the DCM auto constraints into the synthesize constraints? At the moment they are only in the Post and Place constraints, so synthesize doesn't optimize according to the DCM constraints.

Next question: My lvds clock runs at 360 MHz now. However the Hsync and Vsync logic only needs to be updated every 7 cycles. At the beginning (see upper post) I had errors, complaining that the logic wasn't fast enough. I knew that, therefore I start the hsync and vsync calculations in cycle

3, but I need them only in cycle 1 (it goes 0-1-2-3-4-5-6-0, the signal is called lvds_div). I have attached the process.

My solution is this: I have put all the col and row lines into a group, and set the from-to constraint to 5ns (equals about 2 lvds cycles).

INST "row_count_0" TNM = "sync_logic_grp"; ... INST "col_count_0" TNM = "sync_logic_grp"; ... TIMESPEC "TS_sync_logic_grp" = FROM "sync_logic_grp" TO "sync_logic_grp"

5 ns;

It would be nice to know, how a fpga veteran would do this, my methodology is probably not the best yet. Can I do something with a period constraint on the row and col signals?

My route process has become very slow after these constraints, it goes now up to phase 25. Is there a way to get it faster again?

Thanks for Your help!

regards, Benjamin

process (lvds_tick,screen_reset) begin if screen_reset='1' then col_count

Reply to
Benjamin Menküc

When you are cascading DCM's you should bring out the second DCM out of reset after some delay from the time the first DCM is locked. There was an appnote which used 16 bit shift register to delay the 'locked' signal from the first DCM. That could be one of the problems.

Other thing I noticed is "Clock period: 14.088ns (frequency: 70.984MHz) " You said you constrained it to 100Mhz. Probably the constraint was not properly applied and hence ignored by the tool.

Brijesh

Reply to
Brijesh

Hi Brijesh,

I will look at that, but I think thats no problem at the moment.

Yes, my first experiments with the constraints didn't work, but now its already a little bit better (see my subposts to this topic) :)

regards, Benjamin

Reply to
Benjamin Menküc

Hi,

I have to do that now, because simulation doesn't work if I connect the inverted locked signal directly to the 2nd DCM.

formatting link

Here Xilinx says the same, however it seems that this is only neccessary for simulation? Or is this any good for in hardware too?

regards, Benjamin

Reply to
Benjamin Menküc

formatting link

Don't know if its needed in hardware or not, in all probablity it is needed in hardware too. But once you have it why bother remove it? It just uses a single LUT.

Reply to
Brijesh

Hi Brijesh,

yes thanks. I leave it in there and don't bother about it :)

regards, Benjamin

Reply to
Benjamin Menküc

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.