Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #457951
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | sci.electronics.design |
| Subject | Re: Binary counter - please check my work |
| Date | 2017-04-28 22:44 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <oe190e$c9f$1@dont-email.me> (permalink) |
| References | <l1QMA.1138$aC3.305@fx02.iad> <oe0iha$10b$1@dont-email.me> <l1TMA.48233$uf1.15437@fx40.iad> <oe0vro$ogs$1@dont-email.me> <_CUMA.24965$kF7.13243@fx22.iad> |
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.
Back to sci.electronics.design | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web