Synchronous counter enable pulse length

[Tom Derham]

I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count' is
28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while it
is counting, then returns to 0 until it is retriggered by the pulse from the
first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that it
triggers the second clock? As I see it, if it is one clock cycle long, then
the second clock should trigger on the next clock rising edge (providing the
sum of clock propagation and the 2nd clock flip-flop setup is less than one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation tools
realise if there is a problem here?

Many thanks

Tom Derham

 

[John_H]

"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...

I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count'
is
28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while
it
is counting, then returns to 0 until it is retriggered by the pulse from
the
first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that
it
triggers the second clock? As I see it, if it is one clock cycle long,
then
the second clock should trigger on the next clock rising edge (providing
the
sum of clock propagation and the 2nd clock flip-flop setup is less than
one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation
tools
realise if there is a problem here?

Many thanks

Tom Derham

It is inherently safe in FPGA design as is all same-clock synchronous logic.

If you're using different clocks, phase shifted clocks, or discrete logic
devices with unusual hold requirements, it may not be a slam dunk.

- John_H

 

[Peter Alfke]

If you design synchronously and use a common global clock, you "have
nothing to fear but fear itself" (to quote FDR).
Instead of decoding TC of the big counter, you could waste a flip-flop
and build a digital differentiator of the MSB. Just an idea for simplification.

When you use Global Clocks, you can forget about any hild-time issues.
But it's good that you are not naďve ! Taht's worth at leaast an A- ( in
US notation)
Peter Alfke


Tom Derham wrote:

I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count' is
28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while it
is counting, then returns to 0 until it is retriggered by the pulse from the
first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that it
triggers the second clock? As I see it, if it is one clock cycle long, then
the second clock should trigger on the next clock rising edge (providing the
sum of clock propagation and the 2nd clock flip-flop setup is less than one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation tools
realise if there is a problem here?

Many thanks

Tom Derham

 

[Rene Tschaggelar]

Tom Derham wrote:

Question: how long must the pulse from the first clock be, to ensure that it
triggers the second clock? As I see it, if it is one clock cycle long, then
the second clock should trigger on the next clock rising edge (providing the
sum of clock propagation and the 2nd clock flip-flop setup is less than one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation tools
realise if there is a problem here?

You can delay the output signal with another FF and 'OR' its input and output.
That gives you another clock cycle in length.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

 

[John_H]

"Rene Tschaggelar" <some@know.me> wrote in message
news:da916fbbcc79413230e067ade436a0d4@news.teranews.com...

Tom Derham wrote:
[snip]
Question: how long must the pulse from the first clock be, to ensure
that it
triggers the second clock? As I see it, if it is one clock cycle long,
then
the second clock should trigger on the next clock rising edge (providing
the
sum of clock propagation and the 2nd clock flip-flop setup is less than
one
clock cycle)... but functionally the pulse will fall back at the moment
it
is triggered (one cycle later), so will only work if the hold time of
the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation
tools
realise if there is a problem here?

You can delay the output signal with another FF and 'OR' its input and
output.
That gives you another clock cycle in length.

Rene, wouldn't this enable the second counter twice?

 

[Glen Herrmannsfeldt]

"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...

I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count'
is
28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while
it
is counting, then returns to 0 until it is retriggered by the pulse from
the
first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that
it
triggers the second clock? As I see it, if it is one clock cycle long,
then
the second clock should trigger on the next clock rising edge (providing
the
sum of clock propagation and the 2nd clock flip-flop setup is less than
one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation
tools
realise if there is a problem here?

The problem should be exactly the same as that in building the synchronous
counter in the first place.

I still remember from many years ago, that the 74LS74 has 0 hold time, but
the 7474 has a positive hold time. You can make T flip-flops by connecting
Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
level of logic in between would be enough, though.

The LSB of a synchronous counter would normally have the shortest feedback
path. That would be the first place to look.

As I understand it, FPGA's are usually designed so that in a synchronous
design you don't have to worry about hold time, though possibly setup time.
It might be that it is not possible to make a feedback path short enough,
even if the FF itself has a positive hold time.

Now, some people might design a synchronous counter with a clock input from
the TC pulse of another synchronous counter. That would not qualify as
synchronous logic, and could cause timing problems.

-- glen

 

[Andrew Paule]

Hold time is a quantum statistical thing - thermal trip of a balanced
pair. Been through this in this newgroup before.

Andrew

Glen Herrmannsfeldt wrote:

"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...


I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count'


is


28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while


it


is counting, then returns to 0 until it is retriggered by the pulse from


the


first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that


it


triggers the second clock? As I see it, if it is one clock cycle long,


then


the second clock should trigger on the next clock rising edge (providing


the


sum of clock propagation and the 2nd clock flip-flop setup is less than


one


clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation


tools


realise if there is a problem here?



The problem should be exactly the same as that in building the synchronous
counter in the first place.

I still remember from many years ago, that the 74LS74 has 0 hold time, but
the 7474 has a positive hold time. You can make T flip-flops by connecting
Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
level of logic in between would be enough, though.

The LSB of a synchronous counter would normally have the shortest feedback
path. That would be the first place to look.

As I understand it, FPGA's are usually designed so that in a synchronous
design you don't have to worry about hold time, though possibly setup time.
It might be that it is not possible to make a feedback path short enough,
even if the FF itself has a positive hold time.

Now, some people might design a synchronous counter with a clock input from
the TC pulse of another synchronous counter. That would not qualify as
synchronous logic, and could cause timing problems.

-- glen

 

[Peter Alfke]

Here are some practical points.
For all but the most extremely fast applications ( say up to 200 MHz),
synchronous counters are built using a global clock, and the bult-in
free ripple carry structure, which of course determines a max frequency
(where the ripple carry can still meet the set-up time requirements of
the MSB.) Decoding TC can be quite tricky, that's why I suggested the
digital differentiator which actually detects TC+1.

Peter Alfke
=============

Glen Herrmannsfeldt wrote:

"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count'
is
28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while
it
is counting, then returns to 0 until it is retriggered by the pulse from
the
first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that
it
triggers the second clock? As I see it, if it is one clock cycle long,
then
the second clock should trigger on the next clock rising edge (providing
the
sum of clock propagation and the 2nd clock flip-flop setup is less than
one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation
tools
realise if there is a problem here?

The problem should be exactly the same as that in building the synchronous
counter in the first place.

I still remember from many years ago, that the 74LS74 has 0 hold time, but
the 7474 has a positive hold time. You can make T flip-flops by connecting
Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
level of logic in between would be enough, though.

The LSB of a synchronous counter would normally have the shortest feedback
path. That would be the first place to look.

As I understand it, FPGA's are usually designed so that in a synchronous
design you don't have to worry about hold time, though possibly setup time.
It might be that it is not possible to make a feedback path short enough,
even if the FF itself has a positive hold time.

Now, some people might design a synchronous counter with a clock input from
the TC pulse of another synchronous counter. That would not qualify as
synchronous logic, and could cause timing problems.

-- glen

 

[Peter Alfke]

With all due respect, I have a different explanation of hold time. It is
based on the mismatch between data and clock delay in the master latch:
If the data delay is longer than the clock delay, there is a set-up
time, but no hold time ( negative hold time)
If the clock delay is longer than the data delay, there is a hold time
requirement, but no set-up time.

The difference between data and clock delay moves the data capture
window. For a given circuit, temperature and voltage, this window is
extremely small ( see the metastability tests, which demonstrate a
sub-femtosecond window).
For reliable operation, the manufacturer specifies a worst-case window
of set-up + hold time.
All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.
An unduely large set-up time sacrifices max clock rate.
A positive hold time can mean unreliable operation at any speed. :-(

Peter Alfke

Andrew Paule wrote:

Hold time is a quantum statistical thing - thermal trip of a balanced
pair. Been through this in this newgroup before.

Andrew

Glen Herrmannsfeldt wrote:

"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...


I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count'


is


28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while


it


is counting, then returns to 0 until it is retriggered by the pulse from


the


first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.

Question: how long must the pulse from the first clock be, to ensure that


it


triggers the second clock? As I see it, if it is one clock cycle long,


then


the second clock should trigger on the next clock rising edge (providing


the


sum of clock propagation and the 2nd clock flip-flop setup is less than


one


clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation


tools


realise if there is a problem here?



The problem should be exactly the same as that in building the synchronous
counter in the first place.

I still remember from many years ago, that the 74LS74 has 0 hold time, but
the 7474 has a positive hold time. You can make T flip-flops by connecting
Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
level of logic in between would be enough, though.

The LSB of a synchronous counter would normally have the shortest feedback
path. That would be the first place to look.

As I understand it, FPGA's are usually designed so that in a synchronous
design you don't have to worry about hold time, though possibly setup time.
It might be that it is not possible to make a feedback path short enough,
even if the FF itself has a positive hold time.

Now, some people might design a synchronous counter with a clock input from
the TC pulse of another synchronous counter. That would not qualify as
synchronous logic, and could cause timing problems.

-- glen

 

[Glen Herrmannsfeldt]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F6F949F.E7846BD0@xilinx.com...

With all due respect, I have a different explanation of hold time. It is
based on the mismatch between data and clock delay in the master latch:
If the data delay is longer than the clock delay, there is a set-up
time, but no hold time ( negative hold time)
If the clock delay is longer than the data delay, there is a hold time
requirement, but no set-up time.

The difference between data and clock delay moves the data capture
window. For a given circuit, temperature and voltage, this window is
extremely small ( see the metastability tests, which demonstrate a
sub-femtosecond window).
For reliable operation, the manufacturer specifies a worst-case window
of set-up + hold time.
All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.
An unduely large set-up time sacrifices max clock rate.
A positive hold time can mean unreliable operation at any speed. :-(

I don't know that it was every explained why, but there have been
descriptions of the Cray-1 that included PC board traces taking extra long
paths, like zig-zags, to lengthen the propagation time. It may have been to
match hold time.

-- glen

 

[Glen Herrmannsfeldt]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F6F9240.E1B74AB5@xilinx.com...

Here are some practical points.
For all but the most extremely fast applications ( say up to 200 MHz),
synchronous counters are built using a global clock, and the bult-in
free ripple carry structure, which of course determines a max frequency
(where the ripple carry can still meet the set-up time requirements of
the MSB.) Decoding TC can be quite tricky, that's why I suggested the
digital differentiator which actually detects TC+1.

Maybe I misunderstood the application. I had thought it was a divide by N
counter, where at some count value the counter is reloaded with the initial
value, and at the same time the second counter is started.

Now that I think about it, you should get the carry out from the MSB when
the counter is about to wrap. That would seem easier than detecting other
values, and can be used as the load input for both.

-- glen

 

[Hal Murray]

All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.

Is there anything in the physics that encourages this?

My reading is that it simplifies the software. If the
hardware guys will promise that the prop time is
enough to cover the hold time plus clock skew, then
the software doesn't have to check that case.

An unduely large set-up time sacrifices max clock rate.
A positive hold time can mean unreliable operation at any speed. :-(

Only if the software doesn't check for that case.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Glen Herrmannsfeldt]

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:vmvmv083cu824@corp.supernews.com...

All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.

Is there anything in the physics that encourages this?

Before FPGA's, when gates and FF's were wired together, hold time would
limit what you could wire together. My previous example, the common 7474
dual D flip-flop with the Qbar output to the D input would, technically
fail. (I don't know if I ever tried it.) 74LS74 had a 0 hold time.

My reading is that it simplifies the software. If the
hardware guys will promise that the prop time is
enough to cover the hold time plus clock skew, then
the software doesn't have to check that case.

An unduely large set-up time sacrifices max clock rate.
A positive hold time can mean unreliable operation at any speed. :-(

Only if the software doesn't check for that case.

Only if you can guarantee that the software check works for all voltages and
temperatures at which the device might run.

Ony might hope that they scale the same, but I don't know that it is
guaranteed.

-- glen

 

[Rene Tschaggelar]

John_H wrote:

"Rene Tschaggelar" <some@know.me> wrote in message
news:da916fbbcc79413230e067ade436a0d4@news.teranews.com...

Tom Derham wrote:

[snip]
Question: how long must the pulse from the first clock be, to ensure
that it
triggers the second clock? As I see it, if it is one clock cycle long,
then
the second clock should trigger on the next clock rising edge (providing
the
sum of clock propagation and the 2nd clock flip-flop setup is less than
one
clock cycle)... but functionally the pulse will fall back at the moment
it
is triggered (one cycle later), so will only work if the hold time of
the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation
tools
realise if there is a problem here?
You can delay the output signal with another FF and 'OR' its input and
output.
That gives you another clock cycle in length.

Rene, wouldn't this enable the second counter twice?

I'd run a simulation on that and only extend the pulse if required.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

 

[Peter Alfke]

Hal Murray wrote:

All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.

Is there anything in the physics that encourages this?

No, it is just so much easier to sell something when you can tell the

potential customer: "Don't worry about hold time, as long as you use a
global clock. Period, no ifs and buts."

Peter Alfke

 

[Peter Alfke]

Starting with the XC3000, 16 years ago, Xilinx has always offered a
delay circuit in the I/O data input, in order to minimize the danger of
a hold-time issue. In XC3000 this delay was permanent, in XC4000 and
later, it was optional.
We knew that we left performance on the table, but we thought (and
think) that satisfied customers are more important than the ultimate
bragging numbers...
Peter Alfke

I don't know that it was every explained why, but there have been
descriptions of the Cray-1 that included PC board traces taking extra long
paths, like zig-zags, to lengthen the propagation time. It may have been to
match hold time.

-- glen