Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #457900 > unrolled thread

Binary counter - please check my work

Back to article view | Back to sci.electronics.design

Contents

  Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-28 19:14 -0400
    Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 16:20 -0700
      Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-28 19:31 -0400
      Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-28 22:39 -0400
        Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 20:07 -0700
          Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 00:27 -0400
            Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 22:44 -0700
              Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 22:46 -0700
              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 10:29 -0400
                Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 11:07 -0400
                Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-29 20:34 -0700
                  Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 23:43 -0400
                    Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-29 21:53 -0700
                      Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 01:42 -0400
                        Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-29 23:28 -0700
                          Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 20:10 -0400
                            Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 20:26 -0400
                              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 21:07 -0400
                                Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 21:20 -0400
                            Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-30 18:52 -0700
                              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-05-01 08:43 -0400
                                Re: Binary counter - please check my work krw@notreal.com - 2017-05-01 13:33 -0400
                                Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-05-01 23:02 -0700
                                  Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-05-02 11:42 +0000
                                    Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-05-02 06:10 -0700
                                      Re: Binary counter - please check my work upsidedown@downunder.com - 2017-05-03 03:26 +0300
                                        Re: Binary counter - please check my work pcdhobbs@gmail.com - 2017-05-02 18:41 -0700
                                        Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-05-02 19:39 -0700
                                  Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-05-02 11:30 -0400
            Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-29 20:25 +0000
              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 23:15 -0400
                Re: Binary counter - please check my work upsidedown@downunder.com - 2017-05-01 11:12 +0300
          Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 00:43 -0400
            Re: Binary counter - please check my work Winfield Hill <hill@rowland.harvard.edu> - 2017-04-29 05:31 -0700
              Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 09:48 -0400
            Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 08:45 -0700
              Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 12:51 -0400
                Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 14:54 -0400
                Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 12:34 -0700
                  Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 15:51 -0400
                    Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 21:37 -0700
              Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-29 20:49 +0000
                Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 14:08 -0700
                Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 17:31 -0400
                  Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-30 00:51 +0000
                    Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 21:42 -0400
            Re: Binary counter - please check my work bloggs.fredbloggs.fred@gmail.com - 2017-04-29 12:17 -0700
              Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 15:36 -0400
                Re: Binary counter - please check my work bloggs.fredbloggs.fred@gmail.com - 2017-04-30 08:00 -0700
                  Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 11:13 -0400
                    Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 11:24 -0400
                      Re: Binary counter - please check my work bloggs.fredbloggs.fred@gmail.com - 2017-04-30 08:30 -0700
                        Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 16:06 -0400
    Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-29 00:04 +0000
    Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-28 21:14 -0700
    Re: Binary counter - please check my work stratus46 <stratus46@yahoo.com> - 2017-05-01 01:51 -0700
      Re: Binary counter - please check my work stratus46 <stratus46@yahoo.com> - 2017-05-01 01:56 -0700
        Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-05-01 13:36 -0400

Page 1 of 3  [1] 2 3  Next page →

#457900 — Binary counter - please check my work

I'd like to have a 74HC163 4-bit counter count the following sequence:

1000
1001
1010
1011
0100
0101
0110
0111

So A, B preset inputs grounded, C, D preset fed back from the outputs C, 
D swapped, synchronous preset enable pin (active low) NANDed from A and B?

[toc] | [next] | [standalone]

#457903

On 4/28/2017 4:14 PM, bitrex wrote:
> I'd like to have a 74HC163 4-bit counter count the following sequence:
>
> 1000
> 1001
> 1010
> 1011
> 0100
> 0101
> 0110
> 0111
>
> So A, B preset inputs grounded, C, D preset fed back from the outputs C, D
> swapped, synchronous preset enable pin (active low) NANDed from A and B?

Why not just use the three LSb's of the counter "as is"and inverting the most
significant of those (with your NAND gate) to form the MSb (of four)?

[toc] | [prev] | [next] | [standalone]

#457908

On 4/28/2017 7:20 PM, Don Y wrote:
> On 4/28/2017 4:14 PM, bitrex wrote:
>> I'd like to have a 74HC163 4-bit counter count the following sequence:
>>
>> 1000
>> 1001
>> 1010
>> 1011
>> 0100
>> 0101
>> 0110
>> 0111
>>
>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>> C, D
>> swapped, synchronous preset enable pin (active low) NANDed from A and B?
>
> Why not just use the three LSb's of the counter "as is"and inverting the
> most
> significant of those (with your NAND gate) to form the MSb (of four)?

+1

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#457931

On 04/28/2017 07:20 PM, Don Y wrote:
> On 4/28/2017 4:14 PM, bitrex wrote:
>> I'd like to have a 74HC163 4-bit counter count the following sequence:
>>
>> 1000
>> 1001
>> 1010
>> 1011
>> 0100
>> 0101
>> 0110
>> 0111
>>
>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>> C, D
>> swapped, synchronous preset enable pin (active low) NANDed from A and B?
>
> Why not just use the three LSb's of the counter "as is"and inverting the
> most
> significant of those (with your NAND gate) to form the MSb (of four)?

Ah, indeed, indeed.

DUH.

This is why I ask...;-)

[toc] | [prev] | [next] | [standalone]

#457940

On 4/28/2017 7:39 PM, bitrex wrote:
> On 04/28/2017 07:20 PM, Don Y wrote:
>> On 4/28/2017 4:14 PM, bitrex wrote:
>>> I'd like to have a 74HC163 4-bit counter count the following sequence:
>>>
>>> 1000
>>> 1001
>>> 1010
>>> 1011
>>> 0100
>>> 0101
>>> 0110
>>> 0111
>>>
>>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>>> C, D
>>> swapped, synchronous preset enable pin (active low) NANDed from A and B?
>>
>> Why not just use the three LSb's of the counter "as is"and inverting the
>> most
>> significant of those (with your NAND gate) to form the MSb (of four)?
>
> Ah, indeed, indeed.
>
> DUH.
>
> This is why I ask...;-)

There are no "steady state" consequences of this.  However, the
temporal behavior of the "4th bit" will vary near the clock edge
as it will be more closely synchronized with the other three bits
in the case where the state is set-up *before* the clock edge
vs. derived from the TRANSITIONED third bit AFTER the clock edge.

[toc] | [prev] | [next] | [standalone]

#457948

On 04/28/2017 11:07 PM, Don Y wrote:

> There are no "steady state" consequences of this.  However, the
> temporal behavior of the "4th bit" will vary near the clock edge
> as it will be more closely synchronized with the other three bits
> in the case where the state is set-up *before* the clock edge
> vs. derived from the TRANSITIONED third bit AFTER the clock edge.

It looked to me like the only sequence of transitions where one can get 
a set of unique bit patterns where some two bits can be ANDed or ORed 
together to get 8 mutually exclusive "1" outputs where the output is "0" 
in all the other states.

But I believe I'm wrong. 4 choose 0 + 4 choose 1 is only 5.

[toc] | [prev] | [next] | [standalone]

#457951

On 4/28/2017 9:27 PM, bitrex wrote:
> On 04/28/2017 11:07 PM, Don Y wrote:
>
>> There are no "steady state" consequences of this.  However, the
>> temporal behavior of the "4th bit" will vary near the clock edge
>> as it will be more closely synchronized with the other three bits
>> in the case where the state is set-up *before* the clock edge
>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>
> It looked to me like the only sequence of transitions where one can get a set
> of unique bit patterns where some two bits can be ANDed or ORed together to get
> 8 mutually exclusive "1" outputs where the output is "0" in all the other states.
>
> But I believe I'm wrong. 4 choose 0 + 4 choose 1 is only 5.

The problem I'm alluding to is evident at the instant after the active clock
edge.

In the solution I proposed, the D output will change state *after* the C
output has changed to its correct state -- because the D output is derived
by passing the C output through an additional level of delay (the NAND
gate acting as an inverter).

So, if you assume the active clock edge is at the left most column of the
page (text), then the A, B and C outputs will each assume their correct
levels at some "propagation delay" from clock to Q after the clock edge.
If you assume some outputs exhibit *zero* delay while others exhibit
the maximum (Tphl or Tplh, as appropriate), then there will be a period
of up to max(Tphl,Tplh) time in which the output of the "counter" is
invalid -- an observer won't know what the output *will* be without
knowledge of the past.  Thereafter, the counter will be stable until the
next clock edge.

By adding the NAND on the output of the counter (to synthesize the 4th bit),
this period is *extended* by the propagation delay introduced by that gate.
Because the gate's *input* isn't stable until that previous mentioned time.

This is only a problem if you expect the outputs to change simultaneously
(which would be a recipe for failure) and tried to decode individual,
specific "counts" with combinatorial logic on the outputs.

For example, the 1011 to 0100 transition could look like (assuming clock
is at left column of this page)
1..1..1..1..0
1..0..0..0..0
0..0..0..1..1
1..1..0..0..0
    B changes
       D changes
          C changes
             A changes

The "output" isn't stable, in THIS case, until A has changed.  Yet, to
any logic monitoring those 4 signals, they see several different "counts"
occuring:
1011
1001
0001
0101
0100

A different component (and output loading) could result in:
1..0..0..0..0
1..1..1..1..0
0..0..1..1..1
1..1..1..0..0
    A changes
       C changes
          D changes
             B changes
which appears as:
1011
1010
1110
0110
0100

In each case, the only *real* (stable) states are the initial 1011
and the "final" 0100.

If you had attempted to decode state "0110" combinatorially, then
this second series of events would result in a glitch on your
"0110 decoder".  That glitch wouldn't be present if the first
sequence of transitions happened to take place (though a 0101
decoder would have glitched in the first case but not the second,
etc.)

Of course, if you don't *look* at the output of those decoders
until "much later" (when you KNOW things have settled down) -- like
at the NEXT clock edge, then you have no problem.  OTOH, if you
try to use the detector to trigger something (i.e., use it's
asserting or releasing EDGE as a CLOCK), then you're screwed.

(hint:  when you see a capacitor hanging off a digital signal,
chances are the designer made this sort of mistake)

By using the parallel load trick that you were initially pursuing,
you hide the delay of the NAND gate *before* the clock edge
so the outputs "settle" quicker (though this hazzard still exists).

If you want to decode counter states to trigger actions
(and DON'T want to do so with a synchronous stage following the
decoding), you employ a "counter" that uses a sequence in which
at most one bit (one output) changes at each clock edge.  In
this case, you don't have to worry about TWO (or more) bits
trying to settle at the same time:

000
001
011
010
110
111
101
100
000
...

Pick any two adjacent "counter values" and you should be able to
convince yourself that you'll never see a case where some "other"
count appears TEMPORARILY while the counter is transitioning between
those two values.

[toc] | [prev] | [next] | [standalone]

#457952

On 4/28/2017 10:44 PM, Don Y wrote:
> For example, the 1011 to 0100 transition could look like (assuming clock
> is at left column of this page)
> 1..1..1..1..0
> 1..0..0..0..0
> 0..0..0..1..1
> 1..1..0..0..0
>    B changes
>       D changes
>          C changes
>             A changes

[Note that this example -- in THIS particular instance -- is bogus because
D can't change before C does; the rest of the example -- A, B & C here and
below -- is still intact]

[toc] | [prev] | [next] | [standalone]

#457974

On 4/29/2017 1:44 AM, Don Y wrote:
<<< snipped usual long winded stuff >>>
>
> By adding the NAND on the output of the counter (to synthesize the 4th
> bit),
> this period is *extended* by the propagation delay introduced by that gate.
> Because the gate's *input* isn't stable until that previous mentioned time.
>
> This is only a problem if you expect the outputs to change simultaneously
> (which would be a recipe for failure) and tried to decode individual,
> specific "counts" with combinatorial logic on the outputs.

Even the most basic digital logic books caution the reader against doing 
this because of the very long winded explanation below which can be 
summarized by "the outputs can't be decoded when they are changing 
because they don't all change at the same instant in time".

<<< more long winded explanation snipped >>>

> In each case, the only *real* (stable) states are the initial 1011
> and the "final" 0100.
>
> If you had attempted to decode state "0110" combinatorially, then
> this second series of events would result in a glitch on your
> "0110 decoder".  That glitch wouldn't be present if the first
> sequence of transitions happened to take place (though a 0101
> decoder would have glitched in the first case but not the second,
> etc.)
>
> Of course, if you don't *look* at the output of those decoders
> until "much later" (when you KNOW things have settled down) -- like
> at the NEXT clock edge, then you have no problem.  OTOH, if you
> try to use the detector to trigger something (i.e., use it's
> asserting or releasing EDGE as a CLOCK), then you're screwed.
>
> (hint:  when you see a capacitor hanging off a digital signal,
> chances are the designer made this sort of mistake)

What?  I would see such capacitors when I first started in digital 
design some 40+ years ago and never since.


> By using the parallel load trick that you were initially pursuing,
> you hide the delay of the NAND gate *before* the clock edge
> so the outputs "settle" quicker (though this hazzard still exists).

Which is the key point, the hazard still exists and so there is no point 
in discussing the impact of the NAND gate.


> If you want to decode counter states to trigger actions
> (and DON'T want to do so with a synchronous stage following the
> decoding), you employ a "counter" that uses a sequence in which
> at most one bit (one output) changes at each clock edge.  In
> this case, you don't have to worry about TWO (or more) bits
> trying to settle at the same time:
>
> 000
> 001
> 011
> 010
> 110
> 111
> 101
> 100
> 000
> ....
>
> Pick any two adjacent "counter values" and you should be able to
> convince yourself that you'll never see a case where some "other"
> count appears TEMPORARILY while the counter is transitioning between
> those two values.

And finally to the point of the enormously long winded post.

If the user is using discrete logic devices, there is little chance he 
will want to use gray codes.  Heck, this whole thing is because he has 
asked for a particular output from the binary counter rather than just 
letting it count from 0 to 7.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#457980

On 04/29/2017 10:29 AM, rickman wrote:

> If the user is using discrete logic devices, there is little chance he
> will want to use gray codes.  Heck, this whole thing is because he has
> asked for a particular output from the binary counter rather than just
> letting it count from 0 to 7.

It's moot anyway, because in thinking more I realized this particular 
sample and hold switching topology/thing using the binary counter this 
way has no chance of working. Back to the drawing board.

Sorry, guys...

[toc] | [prev] | [next] | [standalone]

#458063

On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
> On 4/29/2017 1:44 AM, Don Y wrote:
> <<< snipped usual long winded stuff >>>
> >
> > By adding the NAND on the output of the counter (to synthesize the 4th
> > bit),
> > this period is *extended* by the propagation delay introduced by that gate.
> > Because the gate's *input* isn't stable until that previous mentioned time.
> >
> > This is only a problem if you expect the outputs to change simultaneously
> > (which would be a recipe for failure) and tried to decode individual,
> > specific "counts" with combinatorial logic on the outputs.
> 
> Even the most basic digital logic books caution the reader against doing 
> this because of the very long winded explanation below which can be 
> summarized by "the outputs can't be decoded when they are changing 
> because they don't all change at the same instant in time".

Synchronous counters are a whole lot better than ripple counters in this respect.

All the outputs change at once, all timed from the active edge of the clock.

Table 7 of the Nexperia 74HC163 data sheet gives a typical propagation delay from clock to Q of 20nsec at Vcc=4.5V with a worst case of 37nsec.

That leaves a window of about 30nsec when the outputs might be inconsistent, which is rarely long enough to matter. 
> 
> <<< more long winded explanation snipped >>>
> 
> > In each case, the only *real* (stable) states are the initial 1011
> > and the "final" 0100.

Only if the counter stops counting at these points.

> > If you had attempted to decode state "0110" combinatorially, then
> > this second series of events would result in a glitch on your
> > "0110 decoder".  That glitch wouldn't be present if the first
> > sequence of transitions happened to take place (though a 0101
> > decoder would have glitched in the first case but not the second,
> > etc.)

This is a synchronous counter, so an up-to 30nsec glitch is always possible, on any transistion, if your decoder is fast enough to react to it.

> > Of course, if you don't *look* at the output of those decoders
> > until "much later" (when you KNOW things have settled down) -- like
> > at the NEXT clock edge, then you have no problem.  OTOH, if you
> > try to use the detector to trigger something (i.e., use it's
> > asserting or releasing EDGE as a CLOCK), then you're screwed.
> >
> > (hint:  when you see a capacitor hanging off a digital signal,
> > chances are the designer made this sort of mistake)
> 
> What?  I would see such capacitors when I first started in digital 
> design some 40+ years ago and never since.

It would have been clear evidence that the designer didn't know what they were doing, and need re-education.
 
> > By using the parallel load trick that you were initially pursuing,
> > you hide the delay of the NAND gate *before* the clock edge
> > so the outputs "settle" quicker (though this hazzard still exists).
> 
> Which is the key point, the hazard still exists and so there is no point 
> in discussing the impact of the NAND gate.
> 
> > If you want to decode counter states to trigger actions
> > (and DON'T want to do so with a synchronous stage following the
> > decoding), you employ a "counter" that uses a sequence in which
> > at most one bit (one output) changes at each clock edge.  In
> > this case, you don't have to worry about TWO (or more) bits
> > trying to settle at the same time:
> >
> > 000
> > 001
> > 011
> > 010
> > 110
> > 111
> > 101
> > 100
> > 000
> > ....
> >
> > Pick any two adjacent "counter values" and you should be able to
> > convince yourself that you'll never see a case where some "other"
> > count appears TEMPORARILY while the counter is transitioning between
> > those two values.
> 
> And finally to the point of the enormously long winded post.
> 
> If the user is using discrete logic devices, there is little chance he 
> will want to use gray codes.  Heck, this whole thing is because he has 
> asked for a particular output from the binary counter rather than just 
> letting it count from 0 to 7.

Asking for a particular output is a perfectly sensible thing to do.

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#458064

On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
>> On 4/29/2017 1:44 AM, Don Y wrote:
>> <<< snipped usual long winded stuff >>>
>>>
>>> By adding the NAND on the output of the counter (to synthesize the 4th
>>> bit),
>>> this period is *extended* by the propagation delay introduced by that gate.
>>> Because the gate's *input* isn't stable until that previous mentioned time.
>>>
>>> This is only a problem if you expect the outputs to change simultaneously
>>> (which would be a recipe for failure) and tried to decode individual,
>>> specific "counts" with combinatorial logic on the outputs.
>>
>> Even the most basic digital logic books caution the reader against doing
>> this because of the very long winded explanation below which can be
>> summarized by "the outputs can't be decoded when they are changing
>> because they don't all change at the same instant in time".
>
> Synchronous counters are a whole lot better than ripple counters in this respect.
>
> All the outputs change at once, all timed from the active edge of the clock.
>
> Table 7 of the Nexperia 74HC163 data sheet gives a typical propagation delay from clock to Q of 20nsec at Vcc=4.5V with a worst case of 37nsec.
>
> That leaves a window of about 30nsec when the outputs might be inconsistent, which is rarely long enough to matter.

???  What???  Maybe if you are lighting LEDs, but for driving other 
logic it can matter a great deal.

If you need glitch free decoded outputs either they need to also be 
registered (which can be done without a clock delay by driving the 
decoder from the inputs to the counter register rather than the outputs) 
or you need to use a gray code counter such as a Johnson ring counter 
which can be decoded without glitches.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#458072

On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
> > On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
> >> On 4/29/2017 1:44 AM, Don Y wrote:
> >> <<< snipped usual long winded stuff >>>
> >>>
> >>> By adding the NAND on the output of the counter (to synthesize the 4th
> >>> bit),
> >>> this period is *extended* by the propagation delay introduced by that gate.
> >>> Because the gate's *input* isn't stable until that previous mentioned time.
> >>>
> >>> This is only a problem if you expect the outputs to change simultaneously
> >>> (which would be a recipe for failure) and tried to decode individual,
> >>> specific "counts" with combinatorial logic on the outputs.
> >>
> >> Even the most basic digital logic books caution the reader against doing
> >> this because of the very long winded explanation below which can be
> >> summarized by "the outputs can't be decoded when they are changing
> >> because they don't all change at the same instant in time".
> >
> > Synchronous counters are a whole lot better than ripple counters in this respect.
> >
> > All the outputs change at once, all timed from the active edge of the clock.
> >
> > Table 7 of the Nexperia 74HC163 data sheet gives a typical propagation delay from clock to Q of 20nsec at Vcc=4.5V with a worst case of 37nsec.
> >
> > That leaves a window of about 30nsec when the outputs might be inconsistent, which is rarely long enough to matter.
> 
> ???  What???  Maybe if you are lighting LEDs, but for driving other 
> logic it can matter a great deal.

Only if you don't know what you are doing. Using a decoded combinational output as a clock is never a good idea, so nobody in their right mind does it.
 
> If you need glitch free decoded outputs either they need to also be 
> registered (which can be done without a clock delay by driving the 
> decoder from the inputs to the counter register rather than the outputs) 
> or you need to use a gray code counter such as a Johnson ring counter 
> which can be decoded without glitches.

The whole point about synchronous counters is that the outputs are registered.

Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#458073

On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
>>>> On 4/29/2017 1:44 AM, Don Y wrote:
>>>> <<< snipped usual long winded stuff >>>
>>>>>
>>>>> By adding the NAND on the output of the counter (to synthesize the 4th
>>>>> bit),
>>>>> this period is *extended* by the propagation delay introduced by that gate.
>>>>> Because the gate's *input* isn't stable until that previous mentioned time.
>>>>>
>>>>> This is only a problem if you expect the outputs to change simultaneously
>>>>> (which would be a recipe for failure) and tried to decode individual,
>>>>> specific "counts" with combinatorial logic on the outputs.
>>>>
>>>> Even the most basic digital logic books caution the reader against doing
>>>> this because of the very long winded explanation below which can be
>>>> summarized by "the outputs can't be decoded when they are changing
>>>> because they don't all change at the same instant in time".
>>>
>>> Synchronous counters are a whole lot better than ripple counters in this respect.
>>>
>>> All the outputs change at once, all timed from the active edge of the clock.
>>>
>>> Table 7 of the Nexperia 74HC163 data sheet gives a typical propagation delay from clock to Q of 20nsec at Vcc=4.5V with a worst case of 37nsec.
>>>
>>> That leaves a window of about 30nsec when the outputs might be inconsistent, which is rarely long enough to matter.
>>
>> ???  What???  Maybe if you are lighting LEDs, but for driving other
>> logic it can matter a great deal.
>
> Only if you don't know what you are doing. Using a decoded combinational output as a clock is never a good idea, so nobody in their right mind does it.

Exactly.  That is why a ripple counter has no worse impact than a 
synchronous counter in a "properly" designed circuit.  It is silly to 
talk as if a synchronous counter is not a problem while a ripple counter 
is a problem.  Both have the same problem, finite delay and skew.  The 
advantage of a ripple counter is you *know* how the skew behaves and so 
you can count on certain patterns.


>> If you need glitch free decoded outputs either they need to also be
>> registered (which can be done without a clock delay by driving the
>> decoder from the inputs to the counter register rather than the outputs)
>> or you need to use a gray code counter such as a Johnson ring counter
>> which can be decoded without glitches.
>
> The whole point about synchronous counters is that the outputs are registered.
>
> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).

Nonsense.  Gray code counters are registered like all counters just as 
you said above.  They produce no glitches on the output because only one 
bit changes at a time unlike binary counters where multiple bits change 
at once with unpredictable skew making decoders glitch.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#458074

On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
> > On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
> >> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
> >>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
> >>>> On 4/29/2017 1:44 AM, Don Y wrote:
> >>>> <<< snipped usual long winded stuff >>>
> >>>>>
> >>>>> By adding the NAND on the output of the counter (to synthesize the 4th
> >>>>> bit), this period is *extended* by the propagation delay introduced by 
> >>>>> that gate. Because the gate's *input* isn't stable until that previous 
> >>>>> mentioned time.
> >>>>>
> >>>>> This is only a problem if you expect the outputs to change 
> >>>>> simultaneously (which would be a recipe for failure) and tried to decode 
> >>>>> individual, specific "counts" with combinatorial logic on the outputs.
> >>>>
> >>>> Even the most basic digital logic books caution the reader against doing
> >>>> this because of the very long winded explanation below which can be
> >>>> summarized by "the outputs can't be decoded when they are changing
> >>>> because they don't all change at the same instant in time".
> >>>
> >>> Synchronous counters are a whole lot better than ripple counters in this  respect.
> >>>
> >>> All the outputs change at once, all timed from the active edge of the clock.
> >>>
> >>> Table 7 of the Nexperia 74HC163 data sheet gives a typical propagation delay from clock to Q of 20nsec at Vcc=4.5V with a worst case of 37nsec.
> >>>
> >>> That leaves a window of about 30nsec when the outputs might be inconsistent, which is rarely long enough to matter.
> >>
> >> ???  What???  Maybe if you are lighting LEDs, but for driving other
> >> logic it can matter a great deal.
> >
> > Only if you don't know what you are doing. Using a decoded combinational output as a clock is never a good idea, so nobody in their right mind does it.
> 
> Exactly.  That is why a ripple counter has no worse impact than a 
> synchronous counter in a "properly" designed circuit. 

Ripple goes on for a lot longer than the uncertainty on a synchronous counter output. Very early in my career, when ripple counters were all that was available cheap, I used a monostable to stop the output stage from picking up the counter outputs while a count event was rippling through.

> It is silly to 
> talk as if a synchronous counter is not a problem while a ripple counter 
> is a problem.  Both have the same problem, finite delay and skew.  The 
> advantage of a ripple counter is you *know* how the skew behaves and so 
> you can count on certain patterns.

I didn't say that the synchronous counter didn't present a problem - merely that the problem was small and manageable.

> >> If you need glitch free decoded outputs either they need to also be
> >> registered (which can be done without a clock delay by driving the
> >> decoder from the inputs to the counter register rather than the outputs)
> >> or you need to use a gray code counter such as a Johnson ring counter
> >> which can be decoded without glitches.
> >
> > The whole point about synchronous counters is that the outputs are registered.
> >
> > Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
> 
> Nonsense.  Gray code counters are registered like all counters just as 
> you said above.  They produce no glitches on the output because only one 
> bit changes at a time unlike binary counters where multiple bits change 
> at once with unpredictable skew making decoders glitch.

Oops. I got that wrong. Long time since I looked at Gray codes.

The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#458175

On 4/30/2017 2:28 AM, bill.sloman@ieee.org wrote:
> On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
>> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
>>> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
>>>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
>>>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
>>>>>> On 4/29/2017 1:44 AM, Don Y wrote:
>>>>>> <<< snipped usual long winded stuff >>>
>>>>>>>
>>>>>>> By adding the NAND on the output of the counter (to synthesize the 4th
>>>>>>> bit), this period is *extended* by the propagation delay introduced by
>>>>>>> that gate. Because the gate's *input* isn't stable until that previous
>>>>>>> mentioned time.
>>>>>>>
>>>>>>> This is only a problem if you expect the outputs to change
>>>>>>> simultaneously (which would be a recipe for failure) and tried to decode
>>>>>>> individual, specific "counts" with combinatorial logic on the outputs.
>>>>>>
>>>>>> Even the most basic digital logic books caution the reader against doing
>>>>>> this because of the very long winded explanation below which can be
>>>>>> summarized by "the outputs can't be decoded when they are changing
>>>>>> because they don't all change at the same instant in time".
>>>>>
>>>>> Synchronous counters are a whole lot better than ripple counters in this  respect.
>>>>>
>>>>> All the outputs change at once, all timed from the active edge of the clock.
>>>>>
>>>>> Table 7 of the Nexperia 74HC163 data sheet gives a typical propagation delay from clock to Q of 20nsec at Vcc=4.5V with a worst case of 37nsec..
>>>>>
>>>>> That leaves a window of about 30nsec when the outputs might be inconsistent, which is rarely long enough to matter.
>>>>
>>>> ???  What???  Maybe if you are lighting LEDs, but for driving other
>>>> logic it can matter a great deal.
>>>
>>> Only if you don't know what you are doing. Using a decoded combinational output as a clock is never a good idea, so nobody in their right mind does it.
>>
>> Exactly.  That is why a ripple counter has no worse impact than a
>> synchronous counter in a "properly" designed circuit.
>
> Ripple goes on for a lot longer than the uncertainty on a synchronous counter output. Very early in my career, when ripple counters were all that was available cheap, I used a monostable to stop the output stage from picking up the counter outputs while a count event was rippling through.

"Properly" designed circuits.


>> It is silly to
>> talk as if a synchronous counter is not a problem while a ripple counter
>> is a problem.  Both have the same problem, finite delay and skew.  The
>> advantage of a ripple counter is you *know* how the skew behaves and so
>> you can count on certain patterns.
>
> I didn't say that the synchronous counter didn't present a problem - merely that the problem was small and manageable.

Yes, a *judgement* which depends entirely on the design and so pointless 
to discuss as a general rule.


>>>> If you need glitch free decoded outputs either they need to also be
>>>> registered (which can be done without a clock delay by driving the
>>>> decoder from the inputs to the counter register rather than the outputs)
>>>> or you need to use a gray code counter such as a Johnson ring counter
>>>> which can be decoded without glitches.
>>>
>>> The whole point about synchronous counters is that the outputs are registered.
>>>
>>> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
>>
>> Nonsense.  Gray code counters are registered like all counters just as
>> you said above.  They produce no glitches on the output because only one
>> bit changes at a time unlike binary counters where multiple bits change
>> at once with unpredictable skew making decoders glitch.
>
> Oops. I got that wrong. Long time since I looked at Gray codes.
>
> The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).

What decoder?  Again you are making assumptions about some design which 
may or may not be relevant and so is not a general rule.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#458176

On 04/30/2017 08:10 PM, rickman wrote:

>> The decoded output is going to be wrong while the change is
>> propagating through the decoder (which may not be a single stage
>> device, which can be another source of glitches).
>
> What decoder?  Again you are making assumptions about some design which
> may or may not be relevant and so is not a general rule.

That's true...it's nice to have discussions about things but I just 
thought I'd drop in to say I've been rethinking the design to avoid 
having to decode anything. ;-)

[toc] | [prev] | [next] | [standalone]

#458178

On 4/30/2017 8:26 PM, bitrex wrote:
> On 04/30/2017 08:10 PM, rickman wrote:
>
>>> The decoded output is going to be wrong while the change is
>>> propagating through the decoder (which may not be a single stage
>>> device, which can be another source of glitches).
>>
>> What decoder?  Again you are making assumptions about some design which
>> may or may not be relevant and so is not a general rule.
>
> That's true...it's nice to have discussions about things but I just
> thought I'd drop in to say I've been rethinking the design to avoid
> having to decode anything. ;-)

Are you looking for a circuit that will provide N outputs for N states? 
That is very easy to do either with a one-hot FSM or a Johnson ring 
counter.  If you don't know what FSM means, it is Finite State Machine, 
a general form of a counter type circuit.  A counter typically moves 
between states in sequence, up or down or both, sometimes with a reset 
or load.  A FSM can change between states arbitrarily.

A Johnson ring counter is very simple with N flip flops encoding 2N 
states with very simple decode done by AND gates and inverters.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#458179

On 4/30/2017 9:07 PM, rickman wrote:
> On 4/30/2017 8:26 PM, bitrex wrote:
>> On 04/30/2017 08:10 PM, rickman wrote:
>>
>>>> The decoded output is going to be wrong while the change is
>>>> propagating through the decoder (which may not be a single stage
>>>> device, which can be another source of glitches).
>>>
>>> What decoder?  Again you are making assumptions about some design which
>>> may or may not be relevant and so is not a general rule.
>>
>> That's true...it's nice to have discussions about things but I just
>> thought I'd drop in to say I've been rethinking the design to avoid
>> having to decode anything. ;-)
>
> Are you looking for a circuit that will provide N outputs for N states?
> That is very easy to do either with a one-hot FSM or a Johnson ring
> counter.  If you don't know what FSM means, it is Finite State Machine,
> a general form of a counter type circuit.  A counter typically moves
> between states in sequence, up or down or both, sometimes with a reset
> or load.  A FSM can change between states arbitrarily.
>
> A Johnson ring counter is very simple with N flip flops encoding 2N
> states with very simple decode done by AND gates and inverters.

I forgot to explain "one-hot".  That means each state has only one bit 
set.  For a 1 of N output this means the counter directly provides the 
outputs.  Very simple and often a very fast state machine.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#458180

On Monday, May 1, 2017 at 10:10:33 AM UTC+10, rickman wrote:
> On 4/30/2017 2:28 AM, bill.sloman@ieee.org wrote:
> > On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
> >> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
> >>> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
> >>>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
> >>>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
> >>>>>> On 4/29/2017 1:44 AM, Don Y wrote:

<snip>

> >>> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
> >>
> >> Nonsense.  Gray code counters are registered like all counters just as
> >> you said above.  They produce no glitches on the output because only one
> >> bit changes at a time unlike binary counters where multiple bits change
> >> at once with unpredictable skew making decoders glitch.
> >
> > Oops. I got that wrong. Long time since I looked at Gray codes.
> >
> > The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).
> 
> What decoder?  Again you are making assumptions about some design which 
> may or may not be relevant and so is not a general rule.

If there wasn't some kind of decoder there wouldn't be a problem to have a discussion about. Johnson/ring counters don't need decoders, but that wasn't where the thread started.

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | sci.electronics.design

csiph-web