Synchronous counter enable pulse length

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

"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

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

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
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

"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?

"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

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

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

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

"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