verilog counter - increment on posedge clk2 and reset on neg

  • Thread starter archilleswaterland@hotmai
  • Start date
A

archilleswaterland@hotmai

Guest
I want to code a counter in verilog.

count increments on every positive edge of CLK2
count is reset to 7 on ever negative edge of CLK1

CLK1 < CLK2 - I don't know the relationship between the clocks.

any suggestions on how I can get started ?

thanks,
archilles
 
archilleswaterland@hotmail.com wrote:
I want to code a counter in verilog.

count increments on every positive edge of CLK2
count is reset to 7 on ever negative edge of CLK1

CLK1 < CLK2 - I don't know the relationship between the clocks.

any suggestions on how I can get started ?

thanks,
archilles
Click to expand...
Coding this is verilog is simple. Getting it to synthesize
is another story. Are you trying to make synthesizable
code? For behavioral simulation all you need is two
always blocks. Synthesis tools generally don't allow this
nor would they synthesize blocks like:

always @ (posedge CLK2 or negedge CLK1)
....

unless CLK1 was used as an asynch reset term.
This is not exactly what you described, since
presumably a rising edge on CLK2 while CLK1 is
low should increment the counter. Generally you
would need to think of what kind of flip-flop could do
the job you're asking it to do, and then use the
appropriate synthesis template (if such a flip-flop
exists).

HTH
Gabor
 
archilleswaterland@hotmail.com schrieb:


count increments on every positive edge of CLK2
count is reset to 7 on ever negative edge of CLK1
Click to expand...
Do you need the counter be reset at the nedgedge of CLK1 or while
CLK1==1'b0?

CLK1 < CLK2 - I don't know the relationship between the clocks.
Click to expand...
If you can't sample CLK1 using CLK2 I guess you need pseudo dual-edge
flipflops: <http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf>.

But be careful! What will happen, if the negedge of CLK1 appears short
before the posedge of CLK2? The will result in a setup violation! So
think carefully about this solution and try to find a way to sample CLK1
using CLK1.

Ralf
 
Thanks for your input Gabor.

No, I do not need to synthesize this code. It is just for some
behavioural simulation.
Yes, the reset needs to be on the negative edge and posedge on CLK2
while CLK1 is low should increment the counter.

I think you mean use the flip flops for detecting the reset (negedge).
I will write more in detail of my implementation attempt later this
evening.

thanks,
archilles

gabor wrote:
archilleswaterland@hotmail.com wrote:
I want to code a counter in verilog.

count increments on every positive edge of CLK2
count is reset to 7 on ever negative edge of CLK1

CLK1 < CLK2 - I don't know the relationship between the clocks.

any suggestions on how I can get started ?

thanks,
archilles

Coding this is verilog is simple. Getting it to synthesize
is another story. Are you trying to make synthesizable
code? For behavioral simulation all you need is two
always blocks. Synthesis tools generally don't allow this
nor would they synthesize blocks like:

always @ (posedge CLK2 or negedge CLK1)
...

unless CLK1 was used as an asynch reset term.
This is not exactly what you described, since
presumably a rising edge on CLK2 while CLK1 is
low should increment the counter. Generally you
would need to think of what kind of flip-flop could do
the job you're asking it to do, and then use the
appropriate synthesis template (if such a flip-flop
exists).

HTH
Gabor
 
Thanks for your input Ralf, I appreciate your document too.

Yes, I need the reset at the negedge of the CLK1, and even while CLK1
is low level, the counter should increment on ever posedge of CLK2

You mean sample clk1 using clk2, right ? I will update on my
implementation effort and if I have any questions on the document later
this evening.

thanks,
archilles

think carefully about this solution and try to find a way to sample CLK1
using CLK1.

Ralf
Click to expand...
 
Thanks for your input Gabor.

No, I do not need to synthesize this code. It is just for some
behavioural simulation.
Yes, the reset needs to be on the negative edge and posedge on CLK2
while CLK1 is low should increment the counter.


I think you mean use the flip flops for detecting the reset (negedge).
I will write more in detail of my implementation attempt later this
evening.


thanks,
archilles
 
archilleswaterland@hotmail.com wrote:
Thanks for your input Gabor.

No, I do not need to synthesize this code. It is just for some
behavioural simulation.
Yes, the reset needs to be on the negative edge and posedge on CLK2
while CLK1 is low should increment the counter.


I think you mean use the flip flops for detecting the reset (negedge).
I will write more in detail of my implementation attempt later this
evening.


thanks,
archilles
Click to expand...
For simulation all you need to do is use two always blocks like:

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter <= 7;

These blocks operate independently and the only issue may
come if the two clocks are coincident (to the resolution of the
simulation, usually 1 picosecond). Then the order of the two
simultaneously scheduled updates is unknown. i.e. when
posedge CLK2 and negedge CLK1 are coincident, counter
may increment or it may be set to 7.

HTH,
Gabor
 
Could you remove the uncertainty with code like this?

always @ (posedge CLK2) counter = counter + 1;
always @ (negedge CLK1) counter <= 7;

Now if the negative edge of CLK1 and positive edge of CLK2 fire at the
same time, the counter will be incremented and also be scheduled for
update at the end of the timestep. This makes the clear always take
precedence over the increment.

David Walker

gabor wrote:
archilleswaterland@hotmail.com wrote:
Thanks for your input Gabor.

No, I do not need to synthesize this code. It is just for some
behavioural simulation.
Yes, the reset needs to be on the negative edge and posedge on CLK2
while CLK1 is low should increment the counter.


I think you mean use the flip flops for detecting the reset (negedge).
I will write more in detail of my implementation attempt later this
evening.


thanks,
archilles

For simulation all you need to do is use two always blocks like:

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter <= 7;

These blocks operate independently and the only issue may
come if the two clocks are coincident (to the resolution of the
simulation, usually 1 picosecond). Then the order of the two
simultaneously scheduled updates is unknown. i.e. when
posedge CLK2 and negedge CLK1 are coincident, counter
may increment or it may be set to 7.

HTH,
Gabor
Click to expand...
 
"dbwalker0min@gmail.com" <dbwalker0min@gmail.com> writes:

Could you remove the uncertainty with code like this?

always @ (posedge CLK2) counter = counter + 1;
always @ (negedge CLK1) counter <= 7;

Now if the negative edge of CLK1 and positive edge of CLK2 fire at the
same time, the counter will be incremented and also be scheduled for
update at the end of the timestep. This makes the clear always take
precedence over the increment.

David Walker
Click to expand...
Yes, that will work, but you can't do the reverse:

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter = 7;
Click to expand...
If you do, that, you have a race condition, as counter + 1 may get
calculated before or after counter = 7.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
 
How about the sequence...

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter = #0 7;

Now counter is not modified in the delta cycle where the the clock
events are processed. When the inactive events are processed, it will
be set to 7. After this, the non-blocking assignments will take place
and it will be set to counter+1, effectively ignoring the reset.

David Walker

Chris F Clark wrote:
"dbwalker0min@gmail.com" <dbwalker0min@gmail.com> writes:

Could you remove the uncertainty with code like this?

always @ (posedge CLK2) counter = counter + 1;
always @ (negedge CLK1) counter <= 7;

Now if the negative edge of CLK1 and positive edge of CLK2 fire at the
same time, the counter will be incremented and also be scheduled for
update at the end of the timestep. This makes the clear always take
precedence over the increment.

David Walker


Yes, that will work, but you can't do the reverse:

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter = 7;

If you do, that, you have a race condition, as counter + 1 may get
calculated before or after counter = 7.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
Click to expand...
 
Yes I can see that if the clock is delayed with "#0" the events are
right on top of each other.

You're right in saying it's not particularly practical, but for me
understanding exactly how Verilog handles events is important. That way
when I have some sort of problem in a simulation, I can debug it
intelligently instead of hacking away at it putting in random delays,
etc..

David Walker

sharp@cadence.com wrote:
dbwalker0min@gmail.com wrote:
How about the sequence...

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter = #0 7;

Now counter is not modified in the delta cycle where the the clock
events are processed. When the inactive events are processed, it will
be set to 7. After this, the non-blocking assignments will take place
and it will be set to counter+1, effectively ignoring the reset.

It will fail if CLK2 is delayed from CLK1 by a #0 delay, putting the
edge of CLK2 right back on the reset of counter.

And all this is moot. In real hardware, if these clocks are that close
together, you have a race condition and the result is unpredictable.
What is the point of making the simulation deterministic for a
situation where the real hardware is not?
Click to expand...
 
dbwalker0min@gmail.com wrote:
How about the sequence...

always @ (posedge CLK2) counter <= counter + 1;
always @ (negedge CLK1) counter = #0 7;

Now counter is not modified in the delta cycle where the the clock
events are processed. When the inactive events are processed, it will
be set to 7. After this, the non-blocking assignments will take place
and it will be set to counter+1, effectively ignoring the reset.
Click to expand...
It will fail if CLK2 is delayed from CLK1 by a #0 delay, putting the
edge of CLK2 right back on the reset of counter.

And all this is moot. In real hardware, if these clocks are that close
together, you have a race condition and the result is unpredictable.
What is the point of making the simulation deterministic for a
situation where the real hardware is not?
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top