«

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;

On Oct 18, 5:35*pm, Amit <amit.ko...@gmail.com> wrote:
> 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.

"Amit" <> wrote in message
news:46d0be0d-b4aa-4841-a953-...
On Oct 18, 5:35 pm, Amit <amit.ko...@gmail.com> wrote:


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
<snip>
> else -- falling edge
<snip>
> 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.

On Oct 18, 5:51*pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Amit" <amit.ko...@gmail.com> wrote in message
>
> news:46d0be0d-b4aa-4841-a953-...
> On Oct 18, 5:35 pm, Amit <amit.ko...@gmail.com> wrote:
>
> 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
> <snip>
> > else -- falling edge
> <snip>
> > 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.


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!

On Oct 19, 2:12*am, Amit <amit.ko...@gmail.com> wrote:
> On Oct 18, 5:51*pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
>
>
> > "Amit" <amit.ko...@gmail.com> wrote in message
>
> >news:46d0be0d-b4aa-4841-a953-...
> > On Oct 18, 5:35 pm, Amit <amit.ko...@gmail.com> wrote:
>
> > 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
> > <snip>
> > > else -- falling edge
> > <snip>
> > > 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.
>
> 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.

"Amit" <> wrote in message
news:c3cf8271-d27f-4337-9505-...

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

On Oct 19, 8:25*am, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Amit" <amit.ko...@gmail.com> wrote in message
>
> news:c3cf8271-d27f-4337-9505-...
>
>
>
> > > > 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.
>
> > 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


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

On Oct 18, 7:51*pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Amit" <amit.ko...@gmail.com> wrote in message
>
> news:46d0be0d-b4aa-4841-a953-...
> On Oct 18, 5:35 pm, Amit <amit.ko...@gmail.com> wrote:
>
> 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
> <snip>
> > else -- falling edge
> <snip>
> > 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.

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