unsupported Clock statement. error message

[Amit]

hi group,

I'm getting an error as "unsupported Clock statement", I'm trying to
write a code for multiplier but the carry_out for the adder messes up
sometimes so I need to store it in a FF. Then all of a sudden I got
this message.

any help is appreciated.


Code is in following:



process(clk, reset)
variable counter :integer;
begin

if (reset = '0') then
ctrl <= '1';
clk_control <= '1'; --was '0'
counter := 0; <<<<<<<<<<<<<< error points to this line!

elsif(clk'event ) then
if (clk = '1') then
ctrl <= '0';
if (counter = (width) + 1 ) then -- was -1
clk_control <= '0';
else
clk_control <= '1';
counter := counter + 1;
end if;
else -- falling edge
carry_out <= carry_in;
end if;
end if;

load_ctrl <= NOT (clk);
end process;

 

[Amit]

hi group,

I'm getting an error as "unsupported Clock statement", I'm trying to
write a code for multiplier but the carry_out for the adder messes up
sometimes so I need to store it in a FF. Then all of a sudden I got
this message.

any help is appreciated.

Code is in following:

  process(clk, reset)
           variable counter :integer;
        begin

                if (reset = '0') then
                        ctrl <= '1';
         clk_control <= '1'; --was '0'
                        counter := 0;   <<<<<<<<<<<<<< error points to this line!

                elsif(clk'event ) then
                         if (clk = '1') then
                                        ctrl <= '0';
                                if (counter = (width) + 1 ) then -- was -1
                                        clk_control <= '0';
                                else
                                        clk_control <= '1';
                                        counter := counter + 1;
                                end if;
                        else -- falling edge
                             carry_out <= carry_in;
                        end if;
                end if;

                load_ctrl <= NOT (clk);
        end process;

One thing I forgot to add was that the logic control of this
multiplier is clocking this module using a gated clock. In case, if it
helps.

thanks.

 

[KJ]

Synthesis tools don't like the following form (which is from your code) for
inferring clocked things.

elsif(clk'event ) then
if (clk = '1') then

else -- falling edge

end if;

Some may accept the following

if rising_edge(clk) then
...
end if;
if falling_edge(clk) then
...
end if;

But as general rule, designing using both edges of the clock is not good
practice to begin with.

One thing I forgot to add was that the logic control of this
multiplier is clocking this module using a gated clock.

If you're planning on implementing this inside an FPGA, it is very bad
practice to use a gated clock because it is generally next to impossible to
pass static timing analysis so your design will be flaky and prone to fail
under various temperature conditions
KJ

thanks.

 

[Amit]

Synthesis tools don't like the following form (which is from your code) for
inferring clocked things.




Some may accept the following

if rising_edge(clk) then
  ...
end if;
if falling_edge(clk) then
  ...
end if;

But as general rule, designing using both edges of the clock is not good
practice to begin with.


If you're planning on implementing this inside an FPGA, it is very bad
practice to use a gated clock because it is generally next to impossible to
pass static timing analysis so your design will be flaky and prone to fail
under various temperature conditions
KJ

thanks.

KJ thanks for your comment. can you give me some hints on how I can
control my multiplier a control logic without using a gated clock?

thanks!

 

[Richard Head]

KJ thanks for your comment. can you give me some hints on how I can
control my multiplier a control logic without using a gated clock?

thanks!

In all my designs a break a clock cycle sequence in to a number of
strobes
(typically 4). The main FPGA fabric is clocked at maximum frequency.
Generate the strobe sequence with a shift register and 'nor' feedback.
All
FF's in your design multiplier pipeline should be DFFE's (Altera
speke),
with an appropriate timing strobe connected to each FF enable.

 

[KJ]

KJ thanks for your comment. can you give me some hints on how I can
control my multiplier a control logic without using a gated clock?

Rather than doing something like this...
process(Gated_Clock)
begin
if rising_edge(Gated_Clock) then
....Update signals here
end if;
end process;

You should be doing it like this
process(Clock)
begin
if rising_edge(Clock) then
if (Some_Condition = '1') then
...Update signals here
end if;
end if;
end process;

Where 'Clock' is a free running global clock in your design and
'Some_Condition' is a signal that happens only on whatever clock cycles you
want to update your signals. In order to have created a gated clock in the
first place, you already must have some idea of the conditions under which
you would want to update the signals so transforming the gated clock logic
into the equivalent clock enable logic (i.e. the logic that creates the
signal that I called 'Some_Condition') should be straightforward. Also,
'Some_Condition' need not be some discrete signal it can very easily be a
more complicated expression such as
if (This=That) and (World < Crazy) then
...Update signals here

The danger with gated clocks in FPGAs is that you can't control the timing.
There will always be skew between the free running clock and the gated clock
with the gated clock coming out some time delay later. The issue comes in
when using signals inside the 'Gated_Clock' process that were generated by
'Clock'. The clock to output delay of some flip flop in an FPGA can beat
the logic and routing delay of 'Gated_Clock'. In an ASIC it is possible to
design the clock generation logic such that this timing problem will not
occur, so gated clocks are a good way to reduce power...but if you're not in
an ASIC, you're in trouble with gated clocks.

Kevin Jennings

 

[Amit]

 Rather than doing something like this...
process(Gated_Clock)
begin
  if rising_edge(Gated_Clock) then
    ....Update signals here
  end if;
end process;

You should be doing it like this
process(Clock)
begin
  if rising_edge(Clock) then
    if (Some_Condition = '1') then
        ...Update signals here
    end if;
  end if;
end process;

Where 'Clock' is a free running global clock in your design and
'Some_Condition' is a signal that happens only on whatever clock cycles you
want to update your signals.  In order to have created a gated clock in the
first place, you already must have some idea of the conditions under which
you would want to update the signals so transforming the gated clock logic
into the equivalent clock enable logic (i.e. the logic that creates the
signal that I called 'Some_Condition') should be straightforward.  Also,
'Some_Condition' need not be some discrete signal it can very easily be a
more complicated expression such as
if (This=That) and (World < Crazy) then
  ...Update signals here

The danger with gated clocks in FPGAs is that you can't control the timing.
There will always be skew between the free running clock and the gated clock
with the gated clock coming out some time delay later.  The issue comes in
when using signals inside the 'Gated_Clock' process that were generated by
'Clock'.  The clock to output delay of some flip flop in an FPGA can beat
the logic and routing delay of 'Gated_Clock'.  In an ASIC it is possible to
design the clock generation logic such that this timing problem will not
occur, so gated clocks are a good way to reduce power...but if you're not in
an ASIC, you're in trouble with gated clocks.

Kevin Jennings

Hi Kevin,

Thanks indeed for your help. I found a brief article regarding
gated_clock explaining how glitch or wrong results will be caused (as
you had pointed that out).

Anyway, now, I'm using a free-running clock (main clock) and things
work out better. Thanks for that again!

One thing I'm still not sure (I guess still there is an issue in my
logic) is that multiplier works fine as long as its inputs are 4 bits
but as soon as I change it (generic width to 16) results go wrong. I
have to spend sometime to find this out.

So base on your comments I learned (correct me if I'm wrong): using
gated clock in FPGA field is absolutely worng unless we practice it
for having less power consumption in ASIC. Right?

Thanks,
amit

 

[Andy]

Synthesis tools don't like the following form (which is from your code) for
inferring clocked things.




Some may accept the following

if rising_edge(clk) then
  ...
end if;
if falling_edge(clk) then
  ...
end if;

But as general rule, designing using both edges of the clock is not good
practice to begin with.


If you're planning on implementing this inside an FPGA, it is very bad
practice to use a gated clock because it is generally next to impossible to
pass static timing analysis so your design will be flaky and prone to fail
under various temperature conditions
KJ

thanks.

Many synthesizers can handle both clock edge specifications in one
process, as long as the same object is not assigned on both edges. You
can also do:

if rising_edge(clk) then
....
elsif falling_edge(clk) then
....
end if;

I'm not saying this is a good (or bad) design practice, but when
necessary, it will work. In some cases it may mean that you don't have
to double the clock speed everywhere. And STA gets the timing right
without having to use multicycle timing constraints.

Also, most synthesizers will accept a combined clock specification and
enable, such as:

if rising_edge(clk) and (enable = '1') then

Note that this is not a gated clock, since the edge detection is only
performed on clk, not the result of the 'and'.

The last assignment to load_ctrl is probably not going to work the way
you want. Using the clock as an input to combinatorial logic in FPGAs
usually does not work too well. Some synthesis tools accept and
correctly implement signal assignments to expressions of variables
after the clocked 'if' clause in a clocked process, but this isn't an
expression of variables.

Andy