hold violation cause by crossing clock domain
 

hi all:
I am using Xilinx Virtex2 V6000 BF957 , ISE 5.1.03i.
Now I have met hold timeing violation after PAR.The error message is like
below:

TIMESPEC TS_CLKA = PERIOD CLKA_grp 60 ns HIGH 50% ;
TIMESPEC TS_CLKB = PERIOD CLKB_grp 60 ns HIGH 50% ;
TIMESPEC TS_CLKA_TO_CLKB = FROM CLKA_grp TO CLKB_grp 60 ns ;

Data path delay : 1.752 ns
Source clock : CLKA ; Destination clock CLKB
Clock Skew : 2.789 ns

Well , both CLKA and CLKB are global clock, they have the same frequence
and the same phase.
Three methods I could think out to correct this problem :
1) tp longer the data path ,
in pratice, the ISE should have known this , however my resources
usage is up to 95%, could this be the reason that the tool
failed to longer the data path to meet this timing constraint ?
2) to reduce the clock skew :
both clock are global global clock ,and have the same frequeces, but how
to write constraints to let the tool reduce the clock skew?
3) use only one clock with clock enable .
Well , this design is too large , and the worse is that most of the RTL
is not written by me , doing this really takes time .

I am looking foward to your response , any suggestion will be highly
appreciated!

--
BestRegards
Black Huang

Re: hold violation cause by crossing clock domain
 

Well, I forgot to mention that both CLKA and
CLKB are derived from a clk named CLKIN.In
practice, CLKA and CLKB are almost the same,the only difference is that when
in power down mode the CLKB is not generated!

--
BestRegards
BlackShark Huang
"BlackSim" <[email protected]> wrote in message
news:[email protected]...
> hi all:
> I am using Xilinx Virtex2 V6000 BF957 , ISE 5.1.03i.
> Now I have met hold timeing violation after PAR.The error message is like
> below:
>
> TIMESPEC TS_CLKA = PERIOD CLKA_grp 60 ns HIGH 50% ;
> TIMESPEC TS_CLKB = PERIOD CLKB_grp 60 ns HIGH 50% ;
> TIMESPEC TS_CLKA_TO_CLKB = FROM CLKA_grp TO CLKB_grp 60 ns ;
>
> Data path delay : 1.752 ns
> Source clock : CLKA ; Destination clock CLKB
> Clock Skew : 2.789 ns
>
> Well , both CLKA and CLKB are global clock, they have the same frequence
> and the same phase.
> Three methods I could think out to correct this problem :
> 1) tp longer the data path ,
> in pratice, the ISE should have known this , however my
resources
> usage is up to 95%, could this be the reason that the tool
> failed to longer the data path to meet this timing constraint ?
> 2) to reduce the clock skew :
> both clock are global global clock ,and have the same frequeces, but
how
> to write constraints to let the tool reduce the clock skew?
> 3) use only one clock with clock enable .
> Well , this design is too large , and the worse is that most of the RTL
> is not written by me , doing this really takes time .
>
> I am looking foward to your response , any suggestion will be highly
> appreciated!
>
> --
> BestRegards
> Black Huang
>
>