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

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

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

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

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 <= 0;
	row_count<= 0;
	DTMG <= '0'; -- pixel data enable
	VSYNC <= '0';
	HSYNC <= '0';
elsif rising_edge(lvds_tick) then
	if lvds_div = 3 then			
			case col_count is
				when num_col - 1  =>		
					DTMG <= '0';
					if row_count = num_row -1 then
						VSYNC<='1';
					elsif row_count = num_row+1  then
						VSYNC <='0';
					end if;
					HSYNC <= '1';
				when num_col + 28 =>
					HSYNC <= '0';
				when others =>
			end case;
			if col_count = num_col + 68 then
				col_count <= 0;
				if row_count < num_row -1 then
					DTMG<='1';
				end if;
				if row_count = num_row + 2 then
					row_count <= 0;				
					DTMG<='1';
				else
					row_count <= row_count +1; 								end if;
			else
				col_count <= col_count +1;
			end if;			
	end if;
end if;
end process;

Benjamin Menküc wrote:
> 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
>     );

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

Hi Brijesh,

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

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

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

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

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

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

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPageP
ath=19005&BV_SessionID=@@@@0453148829.1115333172@@@@&BV_EngineID=ccccaddeifmhfficf
lgcefldfhndfmo.0

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

Benjamin Menküc wrote:
> Hi,
> 
>> 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.
> 
> 
> I have to do that now, because simulation doesn't work if I connect the 
> inverted locked signal directly to the 2nd DCM.
> 
>
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPageP
ath=19005&BV_SessionID=@@@@0453148829.1115333172@@@@&BV_EngineID=ccccaddeifmhfficf
lgcefldfhndfmo.0 
> 
> 
> Here Xilinx says the same, however it seems that this is only neccessary 
> for simulation? Or is this any good for in hardware too?

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.


> 
> regards,
> Benjamin

Hi Brijesh,

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

regards,
Benjamin