un-intentional gated clock after synthesis

E

Elinore

Guest
hi

During both of 'mapping' and 'generate PROM' step in ISE 6.3, the
warning below is encountered.

------------------------------------------
WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net
R2_C_MUX__n0392 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.
------------------------------------------


In C_MUX instance is just a state machine, composed of 3 processes.
I doubt that state machine creates a gated clock. I do not know how to
avoid this warning. Does anyone has this experience?

Thankyou in advance.


------------------------------------------
.....
process(reset,clock)
begin
if reset='1' then
Current_State <= S0;
elsif clock'event and clock='1' then
Current_State <= Next_State;
end if;
end process;
.....
process(Current_State,address_A) -- State Change
begin
case SC is
when S0 =>
if Adderss_A="100" then
Next_State <= S2; else
Next_State <= S0;
end if;

when S1 =>
end process;
.....
process(clock) --- Output Execution
begin
if clock'event and clock='1' then
case State is

end process;
....
------------------------------------------
 
I could be wrong but it might be putting the clock in the sensitivity
list that does it. Doing that always generates a warning but usually
different than the one one you are getting. Also, having a clocked
process generate the outputs means that they will always be delayed by
one cycle. So S2 will have the outputs of S1 and so on. Are you sure
that is what you want?
 
To understand what you mean,
is it meaning that the 2nd process is mapped into "gated clock" circuit
?

Thankyou again
 
Sorry, I actually got it wrong before, putting something in both a wait
statement and a sensitivy list creates the warning. So nothing wrong
there. May I ask what SC is in your design? Why are you doing a case
for SC? Shouldn't you be doing a case for current_state? Also think
about what I told you before about the outputs being delayed by one
cycle. If you want post here or email me the full code and I'll check
it out.
 
Elinore wrote:
hi

During both of 'mapping' and 'generate PROM' step in ISE 6.3, the
warning below is encountered.

------------------------------------------
WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net
R2_C_MUX__n0392 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.
------------------------------------------


In C_MUX instance is just a state machine, composed of 3 processes.
I doubt that state machine creates a gated clock. I do not know how to
avoid this warning. Does anyone has this experience?

Thankyou in advance.


------------------------------------------
....
process(reset,clock)
begin
if reset='1' then
Current_State <= S0;
elsif clock'event and clock='1' then
Current_State <= Next_State;
end if;
end process;
....
process(Current_State,address_A) -- State Change
begin
case SC is
when S0 =
if Adderss_A="100" then
Next_State <= S2; else
Next_State <= S0;
end if;

when S1 =
end process;
....
process(clock) --- Output Execution
begin
if clock'event and clock='1' then
case State is

end process;
...
------------------------------------------
Click to expand...

Look in the higher-level module. What is the source of the signal
called clock?

-a
 
Hi

I'd suppose the gating is caused by the conditional within
the clock statement in the third process.

If you need registered outputs, consider either using
Medwedjew-type outputs (i.e. state-bits = outputs) or
adding separate sync registers to the output signals,
but don't mix this in with the output logic process.

I'd also suggest you add a default statement to the
next state logic to avoid unwanted latch generation
(add a "Next_State <= Current_State;" as first state-
ment outside of any conditional blocks in the second
process).

Note that you can easily do this in two processes,
one for state assignment and output logic (purely
combinatonal logic) and one for state and possibly
output registers (sequential logic).

HTH, Robert

Elinore wrote:
hi

During both of 'mapping' and 'generate PROM' step in ISE 6.3, the
warning below is encountered.

------------------------------------------
WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net
R2_C_MUX__n0392 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.
------------------------------------------


In C_MUX instance is just a state machine, composed of 3 processes.
I doubt that state machine creates a gated clock. I do not know how to
avoid this warning. Does anyone has this experience?

Thankyou in advance.


------------------------------------------
....
process(reset,clock)
begin
if reset='1' then
Current_State <= S0;
elsif clock'event and clock='1' then
Current_State <= Next_State;
end if;
end process;
....
process(Current_State,address_A) -- State Change
begin
case SC is
when S0 =
if Adderss_A="100" then
Next_State <= S2; else
Next_State <= S0;
end if;

when S1 =
end process;
....
process(clock) --- Output Execution
begin
if clock'event and clock='1' then
case State is

end process;
...
------------------------------------------
Click to expand...
 
Robert Reutemann wrote:
Hi

I'd suppose the gating is caused by the conditional within
the clock statement in the third process.
Click to expand...
If by that you mean that

if (clock'event and clock = '1') then ...

is generating a gated clock, you might want to re-read your synthesis
manuals.

-a
 
Andy Peters wrote:
I'd suppose the gating is caused by the conditional within
the clock statement in the third process.


If by that you mean that

if (clock'event and clock = '1') then ...

is generating a gated clock, you might want to re-read your synthesis
manuals.
Click to expand...
I don't mean the std clock cond, but the conditionals *within* the
clock statement -- would usually be mapped to enable registers,
but with a "capable" synthesis tool can be mapped to clock
gating (w. automatic gating enabled for power optimization).

Might be something else (outside the block, ...) however, don't
know what synth tool has been used.

Robert
 
Robert Reutemann wrote:
Andy Peters wrote:
I'd suppose the gating is caused by the conditional within
the clock statement in the third process.


If by that you mean that

if (clock'event and clock = '1') then ...

is generating a gated clock, you might want to re-read your synthesis
manuals.

I don't mean the std clock cond, but the conditionals *within* the
clock statement -- would usually be mapped to enable registers,
but with a "capable" synthesis tool can be mapped to clock
gating (w. automatic gating enabled for power optimization).
Click to expand...
Ah, I see what you're saying. One would think that the synthesis
constructs are pretty standard, so the (clock'event and clock = '1')
would tell the synthesizer to "connect the signal clock to the flop's
clock input" whereas using the clock signal in a combinatorial
assignment without the 'event indicator, like

gated_clock <= clock and gate;

would do what you expect: create an AND gate with clock and gate as its
two inputs. If you used (gated_clock'event and gated_clock = '1') in
the flop process, then you should get a gated clock.

I'm sure there's a synthesis tool out there that doesn't work this way
....

-a
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top