Problem with 8 bit comparator - A=B goes high incorrectly

Thread Starter

paulski

Joined May 5, 2020
14
I'm building a digital volume / selector control circuit which uses an 8 bit comparator to compare the selected volume level (8 bit) with that from a clocked 4040 that cycles through 0 to 255. When the two are the same the circuit sends a latch signal to a display circuit (driven by the same clock and reset in sync with the 4040) so that the display shows the current volume level. This works for all values that are not divisible by 4. When you hit one those values - 4,8,12,16 etc - the displays will show an incorrect value or flicker. This seems to be caused by more than one latch signal being generated at these values - in theory there should be only one latch pulse for every 256 cycles of the clock. In the schematic 'LogicSMDV1' U16 compares the 4 least significant bits and, when they are equal, pin 6 goes high. This in turn enables pin 6 of U15 to go high when the 4 MSB are also the same which triggers the one-shot based around U18 and sends the latch pulse. When the volume data is 00000001 all looks good (Trace1 - only one latch pulse for 256 clock cycles), going to 00000010 and then 00000011 all remains good. When we reach 00000100 the displays shows '008' and the scope trace shows the output from pin 6 (A=B) has a clear high output corresponding to the length of a clock cycle and then two further short pulses that correspond with the 2 and 4 clock cycles later. These cause pin 6 of U15 to go high in the same fashion leading to the display circuit latching on 2 then 4 then 8. Since there's 250 clock cycles before the next latch the display shows a steady '008'. Every multiple of 4 shows similar issues, at 32 and 64 there are yet more 'false' latch signals - see traces.

Given the non-random nature of this there must be something that can be logically deduced here. I've spent several days trying to do that but I've run out of ideas. What I really don't understand is why U16 generates these brief A=B pulses on pin 6. Could it be an issue with U14 - the 4040?

In the 'scope trace images yellow = pin 6 of U18 (latch pulse), light blue = A<B, dark blue = A=B and purple = A>B these correspond to pins 7, 6 and 5 of U16 respectively.

The schematic for the display driver circuit is also included for reference.
 

Attachments

ci139

Joined Jul 11, 2016
1,898
might be transition artifacts (something you can't avoid if the digital comparator chip is designed to have such at certain inputs)
the "series" connection of the HC85 might be such cause ... no-one says the "parallel" would make the issue fade ... must be tested in a separate lab/test -- before integrating such to the final system . . .

. . . further more -- such always can't be told by data sheet provided "simplified schemaics" . . . trivia
 

JohnInTX

Joined Jun 26, 2012
4,787
The CD4040 is a ripple counter. That means that the internal flip flops are chained in series and as they count, the output of each flip flop clocks the next more significant one. The input clock 'ripples' through each flip flop in the counter chain. Unfortunately, this takes time at each stage and during that time the outputs will reflect some intermediate count that is not the final value. Consider the count going from 7 to 8 where the third flip flop clears and toggles the next one to transition the count from 0111 to 1000. It takes time for that 4th flip flop to set and propagate its new value to the pin. During that short time, the counter output will be 0000. Even though the time is short, it's plenty long enough for the fast HCTTL to see it and generate the A=B output while the counter settles. That's what is causing your short spikes and that's why you see the problem on powers of 2. It's a common problem and is why ripple counters are not recommended for applications where the count must be valid at all times.

Synchronous counters avoid this problem by clocking all of the flip flops at the same instant.

The usual solution is to use an edge triggered flip flop on A=B and clock it after the maximum propagation delay through the counter and comparator. Consider clocking the counter on one edge of the clock and the edge-triggered flip flop on the other edge or a short delay line. A short RC delay into a schmitt trigger input would do it. If you have extra CMOS gates, you can chain a bunch of them together to use their internal propagation delays to skew the clocking of the flip flop to after the counter has settled down.

As a quick analysis consider that the 4040 data sheet says that the transition time between flip flops is 100ns typ at 5V. That means that your invalid value between 0111 and 1000 can be about that long. Then look at the A=B propagation time for the HC85. It's about 14ns typ. So that means that the HC85 is plenty fast enough to respond to the short invalid counts of the 4040 ripple counter and generate those short spikes you are seeing. Sorry.

Good luck!
 
Last edited:

Thread Starter

paulski

Joined May 5, 2020
14
Thanks all for the explanations, it makes perfect sense now that I understand the issue with ripple counters! My thinking at first was to redesign with a synchronous counter but I would have had to do a major rework to the display circuitry to accommodate so I've gone for just dealing with the issue with the ripple counter. I had two spare 4069 gates, these are quoted as having a typical propagation time of 55nS at 5V. I also then used the spare 74HC14 gates to a) create a clean transition if an RC filter is needed to add more delay and b) bring the clock back in phase with that sent to the display counters. The typical 5V propagation delay for these is 12nS so, in total, I ought to have around 130nS or so of delay for the clock into the flip-flop, U20. The RC components C24 and R4 are in the schematic just in case they are required, if not I'll leave out C24 and put a link in place of R4. New schematic attached, does this look OK?
 

Attachments

Thread Starter

paulski

Joined May 5, 2020
14
Do you actually expect someone to take the time to read that mess?

Are you not changing the device labels again? Or are you actually mixing TTL and CMOS logic this time?
Thanks for the confidence inspiring response. I’m struggling hard with learning this stuff and and constantly walking a cliff edge which falls away into deep depression so thanks again.

I’m new to schematic design so yeah, maybe it’s not the best. I haven’t changed labels in this schematic and I believe you can mix CMOS and TTL even if it’s not best practise. Happy to be advised otherwise.

But, if all you are going to do is slag me off the just don’t bother.
 

dl324

Joined Mar 30, 2015
16,846
I haven’t changed labels in this schematic and I believe you can mix CMOS and TTL even if it’s not best practise. Happy to be advised otherwise.
The fact that you choose to do things that you yourself consider a bad practice is telling.

CMOS can drive TTL as long as you consider fanout limitations. TTL can't drive CMOS reliably unless you put pull up resistors on the CMOS inputs.
But, if all you are going to do is slag me off the just don’t bother.
When drawing schematics, you should
  1. avoid unnecessary wire jogs
  2. avoid unnecessary wire crossings
  3. avoid scenic routes
  4. showing decoupling capacitors on the schematic clutters things
  5. showing power connections on IC's clutters things
  6. flow should be primarily left to right and top to bottom.
 

Deleted member 115935

Joined Dec 31, 1969
0
I understand your wanting to learn digital logic , its a deep field.
can I suggest you have taken a big step,
may be too big one,

Mixing CMOS and TTL, yes is possible,
but you are doubling the the chances for problems ,
CMOS and TTL both have very different "strange" features.
CMOS being powered with out any power supplied, ( power via the inputs )
TTL ground bounce being a start.

Add to that the difference in TTL and CMOS speeds, glitches , drive capability and logic levels,
and the chances for problems increase almost exponentially,

Regarding logic design,
keep things synchronous.

Gates will glitch,
glitches will propagate through ,
so never use a gated signal to drive a clock input,

You need to do some timing diagrams,
Squared paper is great for that ,
though there are smart tools around , but paper and pencil is much more informative,

Break the design into bits, write out a requirement, even if its simple.
design each bit, do a timing diagram, do a schematic for each bit,
and put the bits up for us to have a look at.

As you have seen,
unlike software, hardware is all in parallel, and does not design well in the same "crazy way we normally design software,
( its much easier to add a line of code, than it is to add a gate )
 

dl324

Joined Mar 30, 2015
16,846
I redrew the latest schematic using buses:
clipimage.jpg
I didn't spend much time trying to optimize the layout or study the circuit. Some things look strange (the grounded input on U19C, the chain of inverters to clock U20A). I took the liberty of using a 2x20 connector for the input and didn't bother connecting the grounded pins that I suppose are for shielding.

For clarity, decoupling capacitors and unused gates aren't shown. Eagle can show power connections on schematics, but they're not attached to the logic symbols and I choose not to show them. If you want to show explicit decoupling, you could, but my assumption would be the typical one cap per power pin unless stated otherwise.

I finally had a reason to edit the "huge" TTL gate symbols Eagle uses.

EDIT: Updated the PDF; forgot to label a net on U19C.
 

Attachments

Last edited:

dl324

Joined Mar 30, 2015
16,846
@paulski Don't know if this was mentioned. One way to workaround the glitch problem coming from the 4040 would be to use the clock HIGH time to gate the output of the comparators.
 

Deleted member 115935

Joined Dec 31, 1969
0
The HC192,
Pins 4 and 5 are clock inputs.
Any glitch on these inputs will clock the 192.

Any gate circuit, such as your four gate decoder, U13, U11, U4, U2 network WILL glitch ,
draw the timing diagram of the four gate decoder to convince yourself of that
 

dl324

Joined Mar 30, 2015
16,846
The HC192,
Pins 4 and 5 are clock inputs.
Any glitch on these inputs will clock the 192.

Any gate circuit, such as your four gate decoder, U13, U11, U4, U2 network WILL glitch ,
draw the timing diagram of the four gate decoder to convince yourself of that
Why do you say this? HC192 is a synchronous counter so all outputs will transition at the same time. The paths through the gates you claim will glitch will have the same delays.
 

ci139

Joined Jul 11, 2016
1,898
there are loads of books written on the digital system design issues . . . starting from fan-out , trace length , timing (propagation , pulse edges / shape) . . . power/supplies management . . . cross-talk , noise . . .

if one thinks that the digital system design is any less demanding than the analog sys. -- one can't be more wrong . . . the sharp transition edges of the digital signal obviously induce/energize all possible harmonics/oscillations available by a "poor" design . . .
 

Deleted member 115935

Joined Dec 31, 1969
0
Why do you say this? HC192 is a synchronous counter so all outputs will transition at the same time. The paths through the gates you claim will glitch will have the same delays.
I say any glitch on the clock INPUTS will cause the counter to clock,
it might well be a synchronous counter, but thats the outputs,
the glitches will come from the gate circuit,

No two gates have identical delay, and the wiring will only have the same delay if it has identical length and impedance, other wires near them will affect the impedance.

No two gates have identical drive capabilities , even if they have identical identical , zero glitch power input, in real circuits, you wont have identical power on tow chips, they will both have different ripple.

The bottom line is, in digital design you can not guarantee that any gate system will not glitch on its outputs,

As some one else says, in theory, practise and theory are the same, in practise , theory and practise are different.

do not ever design a circuit that has a gated clock input, it will sooner or later fail,
 

dl324

Joined Mar 30, 2015
16,846
The bottom line is, in digital design you can not guarantee that any gate system will not glitch on its outputs,
You seem to be preoccupied with glitches.

The clock inputs of HC193 will not respond to narrow clock pulse widths. The OP has chosen gates in the same package which gives the best matching possible.

I'd appreciate a timing diagram showing how the AND or NOR gates can glitch. They're decoding 0xFF and 0x00, respectively. The outputs of the gates won't change unless all inputs are 1 or 0, respectively. Where are these glitches supposed to come from?
 

Deleted member 115935

Joined Dec 31, 1969
0
You seem to be preoccupied with glitches.

The clock inputs of HC193 will not respond to narrow clock pulse widths. The OP has chosen gates in the same package which gives the best matching possible.

I'd appreciate a timing diagram showing how the AND or NOR gates can glitch. They're decoding 0xFF and 0x00, respectively. The outputs of the gates won't change unless all inputs are 1 or 0, respectively. Where are these glitches supposed to come from?
Morning

You say Im pre ocupied with glitches caused by a random gate circuit such as yours.
I would say that is correct.

If your not concerned by them, then your the expert, and I can add no more.
 

ci139

Joined Jul 11, 2016
1,898
constantly walking a cliff edge
with circuit design it's always there . . . no special reason to feel stressed about it
The bottom line is, in digital design you can not guarantee that any gate system will not glitch on its outputs,
your examples may be not the best but basically i have to agree with you - there are more surprises waiting for you than you can imagine
--e.g.-- if the inner workings of the latches are not shown on the d/s - you basically need to test them out or buy a chip with sufficient specs.
 
Top