Warning : :PhysDesignRules:372 - Gated clock.? what is it?

physdesignrules 372

HI everyone, I got this warning message in Generating program file under Xilinx ISE 8.2i.(VHDL)

WARNING hysDesignRules:372 - Gated clock. Clock net clk_RECOV_op_OBUF is
sourced by a combinatorial pin. This is not good design practice. Use the CE
pin to control the loading of data into the flip-flop.

Click to expand...

Sample of my program,
Entity temp is
port (clk : in Std_logic;
clk_recov_op : out std_logic);

ARCHITECTURE Behaviarol of TEMP is
SIGNAL clk_recov,clk_recov_inv : STD_LOGIC;


BEGIN
clk_recov_inv <= NOT(clk_recov);
clk_recov_op <= clk_recov_inv;
PROCESS(clk) IS
{
\\
\\
\\
}
END PROCESS;
END Behavioral;
What does than error report mean?....In xilinx answers database, I saw it's something related to DCM. Like when there is no clk is input, the device can be put into stop mode and when the clk is in again, it shouldbe restored within some 200ms for dcm to operate safely.This should be manually done in Virtex4 devices of old type.In recent devices,they have a macro inside to take care of this..In my design,I have no dcm for clk multiply or divide...Only counters...and my clk is continuous....Though it's a warning,the message said it'snot a good practise,so I'm afraid about any timming issues...which brought me posting here immediatly...If anybody has got something about it,plz let it here....Thanks

physdesignrules:372

Your code snippet is too small to see exactly what's going wrong (where does clk_recov come from? where does clk_recov_op go?), but ISE is warning you not to use a logic gate to generate a clock signal. Two possible problems: Starting and stopping a clock with a logic gate is risky design practice in an FPGA. Also, driving a clock net from a logic gate uses the FPGA's ordinary routing paths (instead of a low-skew global clock net), so the resulting routing delay skew may cause your synchronous logic to malfunction.

I'm guessing that instead of doing this:
clk_recov_inv <= NOT(clk_recov);
clk_recov_op <= clk_recov_inv;
maybe all you need to do is clock the output flops on the negative edge of clk_recov. That's just a guess.

The answer database message you found seems unrelated to the warning message.

physdesignrules:372 - gated clock. clock net

echo47 said:

where does clk_recov come from? where does clk_recov_op go?).

Click to expand...

Sorry for not displaying my code,it's hell lengthy and thought it might confuse the readers....And for the issue of clk_recov,I decode the data which is in manchester coding in the input stream!....I use the rising_edge time of the data stream to recover the transmitter clock inorder for sampling the data in synchronous to transmitter....Here the clk_Recov is the one which I have recovered....The received clk is inverted using NOT to clk_recov_inv...and it's passed to another output register "clk_recov_op"for viewing the recovered clk in the scope....
I'll give the part where I have used this clk_recov..So please help me by denoting if ther is any inefficient coding resulting in warnings..Thanks!,here is my little explanation
Mnchr_Rx is the coded data that is input from MODEM section of srd.This data is at 4MHz. and Rx is the decoded tranmitter data.This data is at 2MHz.I use to capture both the rising and falling edge of the input data to recover my clk.So I Xor the inpout data and it's inverted data...So I get train of impulses for both edges...Here I use the counter with the value of the transmitter clk width to exactly recover the clk...One thing I have added is some bit-delay which is unavoidable...Just check out if that's making this issue!...If anything you could identify,notify me!....Thanks
-------------------------------------
-- CODING PROCESS
-------------------------------------
PROCESS(clk,clk_data,CLK_RECOV,CLK_RECOV_inv,Tx,Mnchr_Rx)
VARIABLE FLAG_SHOT : STD_LOGIC:='0';
VARIABLE SHOT : INTEGER :=0;

BEGIN
-----------------------------
-- MANCHESTER DECODING
-----------------------------
IF RISING_EDGE(clk_RECOV_inv) THEN
Rx <= Mnchr_Rx;
END IF;
--------------------------------
---- CLK RECOVERY
--------------------------------
IF RISING_EDGE(clk) THEN
---------------------------
-- 13-Bit FF Delay
---------------------------
A <= Mnchr_Rx;
B <= A;
C <= B;
D <= C;
E <= D;
F <= E;
G <= F;
H <= G;
P <= H;
X <= P;
Y <= X;
Z <= Y;
Mnchr_Rx_DELAY <= Z;
---------------------------
-- 7-Bit FF Delay
---------------------------
A1 <= CLK_RECOV_PRE;
B1 <= A1;
C1 <= B1;
D1 <= C1;
E1 <= D1;
F1 <= E1;
CLK_RECOV <= F1;
-----------------------------------------
-- XORing for unishot pulse
----------------------------------------
MONOSHOT <= Mnchr_Rx_inv XOR Mnchr_Rx;
------------------------------------------
IF(MONOSHOT_inv = '1') THEN
FLAG_SHOT := '1';
END IF;

IF(FLAG_SHOT ='1') THEN
SHOT := SHOT+1;
IF(SHOT < 59) THEN
CLK_RECOV_PRE <= '1';
ELSIF(SHOT> 59) THEN
CLK_RECOV_PRE <= '0';
FLAG_SHOT := '0';
SHOT:=0;
END IF;
END IF;
END IF;

physdesignrules:372 - gated clock

ARCHITECTURE Behaviarol of TEMP is
SIGNAL clk_recov,clk_recov_inv : STD_LOGIC;


BEGIN
clk_recov_inv <= NOT(clk_recov);
clk_recov_op <= clk_recov_inv;
PROCESS(clk) IS

Click to expand...

i'm agree with echo47, i think this warning is due to the clock net are driven by a combinational logic which i think it should be the "NOT" over here.

so the frequency of clk_recov_op = clk_recov / 2?

physdesignrules

cherjier said:

so the frequency of clk_recov_op = clk_recov / 2?

Click to expand...

The freq between the two are the same,but it's jkust the inverted

warninghysdesignrules:372

if that's the case, the clk_recov_op are driven by logic gate and i have agree to what echo47 said. generate a clock using a logic gate is not a good design