Use of Both Posedge Clk and Negedge Clock

[Chloe]

Hello everyone,

A couple of questions to all the Verilog experts from a Verilog newbie:

1. What are the implications of coding a flip-flop with both posedge of
clock and negedge of clock in the sensitivity list, ie

always @ (posedge clock or negedge clock or negedge reset)
begin
.....
end

2. How would the use of the above affect synthesis? Will a design be
synthesizable if it contains RTL with dual edge-triggered clocks?

Please help.

Thanks very much in advance.

-Chloe-

[Neo]

if your library supports dual edge FFs then its synthesizable else it
will throw an error. AFAIK there are no such libraries supported at
this time except in some cplds.

[Berty]

Since FF have generally speaking only one clock (unless you have
special libraries which are rarely the case) it will be more advisable
to use for example double the clock and than use only posedge (or only
negedge) of the clock.

Have fun.

[Chloe]

The problem is, I'm only using one clock, which frequency cannot be
doubled. The limitations of the design is such that I can only use one
clock, and this clock drives a counter at the same speed, ie the each
count is one clock period. This will still pass functionally, but I
worry about setup and hold violations later during synthesis.

I tried using two flip flops - one driving at posedge, and the other at
negedge of clk.

Any suggestions?

[Avrum]

I think you are probably over analyzing the problem. Most synchronous
circuits (or at least sub-circuits) use only a single clock for all flops in
the circuit. On the rising edge of CLK, all the flip flops update; they take
the values on their D inputs and place them on the Q outputs. Then the
signals have a full clock period to propagate through the combinational
logic connected to the Q outputs (and the primary inputs of the circuit),
before showing up on the D inputs prior to the next clock.

While you cannot ignore issues resulting from hold times, these are, for the
most part, taken care of by the library vendor and/or the tools used for
synthesis. Most ASIC libraries (and FPGA flip flops) have very small hold
time requirements - some/most are even negative. Furthermore the CLK->Q
propagation time for most flip-flops are usually larger than the hold time
requirements of flip flops. So, assuming you have a "reasonable" clock (one
that doesn't have excessive skew), the CLK->Q time is longer than the worst
case clock skew plus the worst case hold time requirement. In this case, it
is impossible to have a hold time violation. In the cases where this isn't
true, it is still quite rare to have a hold time problem; combinational
logic and even signal routing will all serve to "delay" the change in data
that occurs on the Q of a flip-flop from proagating to the next flip-flop so
that it doesn't violate the hold time requirement.

Finally, synthesis tools understand hold time requirements, and can be asked
to "fix" hold time violations, which they will do by adding delay on paths
from Q->D that would otherwise violate a hold time requirement.

Because of all these reasons, hold time issues can be dealt with without
requiring two different clocks (or any other heroic measures); for your
counter, you should be able to simply code it as

always @(posedge clk)
begin
if (!rst_n)
begin
count <= 0;
else
begin
if (count == MAX_VAL)
count <= 0;
else
count <= count + 1'b1;
end
end

Avrum

"Chloe" <chloe_m...@yahoo.co.uk> wrote in message
news:1117152046.6...@o13g2000cwo.googlegroups.com...

[ppo...@gmail.com]

using posedge and negedge clk , in fact, is equal to always @ ( clk or
negedge reset )

[e liu]

ppo...@gmail.com 在 2005年5月27日 星期五下午5:20:48 [UTC+8] 的信中寫道：

> using posedge and negedge clk , in fact, is equal to always @ ( clk or
> negedge reset )

I am facing the same situation when writing a FSM, and I wonder if I can seperate the posedge and nededge always.
For example:
always@(posedge clk or posedge rst) case(current_state) case1: .... case2: ...... case3:.......
always@(nededge clk or posedge rst) case(current_state) case1: .... case3:.......

[gnuarm.del...@gmail.com]

Stop thinking in terms of the code. Think in terms of what hardware you expect to have generated. Then describe the actions of that hardware, and the tools will follow your instructions. It's call a Hardware Description Language for a reason... "HARDWARE DESCRIPTION". So, describe the hardware you want built. If you don't know what that hardware is, how will the tools know???

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209