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

dl324

Joined Mar 30, 2015
16,839
If your not concerned by them, then your the expert, and I can add no more.
If you know something we don't know, enlighten us. If you don't, then don't try to confuse the OP who's already having problems comprehending glitches from ripple counters. That isn't helpful.

After all, that *is* what most of us are trying to do here - be helpful. Not bash people (which I wasn't trying to do to the OP when he implied I was trying to "slag" him by giving constructive criticism) or obfuscate the issue(s).
 
Last edited:

ci139

Joined Jul 11, 2016
1,898
it actually should be straight forward - if you give your device enough time to pass/react_to the prev control signal before you send the next one to it -- you likely will have no problems . . .

. . . the issues rise from close to simultaneous signals that "start concurring for the priority" --e.g-- if you push your frequency limits too high either by "bit-rate" or "interleaves" in between (perhaps the active fronts of) the control signals

the 74HC194 gate timings (i donno if there're issues with the real chip)
74LS194.png simplifiedLogicTEST-0200_Bug.png simplifiedLogicTEST-0200.png smpLgcV_74x194.png simplifiedLogicTEST-0200_Verif.png
.
.
.
.
about the reliability of the JK triggers (note that only two of these are bug free near their frequency limit)

1589907470095.png

etc. ...
(there are loads of more examples . . . i just need to turn my archives upside down to spot such - something i won't do coz it makes 'em even more unordered)
.
.
.
another potential flaw (not confirmed in real -- i have the chips's substitute but no time to test it . . .)
the variety of "glitches" is unexpectedly . . . ? variable F;T
1589909864471.png
 
Last edited:

Deleted member 115935

Joined Dec 31, 1969
0
If you know something we don't know, enlighten us. If you don't, then don't try to confuse the OP who's already having problems comprehending glitches from ripple counters. That isn't helpful.

After all, that *is* what most of us are trying to do here - be helpful. Not bash people (which I wasn't trying to do to the OP when he implied I was trying to "slag" him by giving constructive criticism) or obfuscate the issue(s).

Like your slef, I was not bashing the Op,
I was pointing out that the problem is glitches. And I pointed out where at least some of the glitches are coming from,
The OP replied to the effect that it was not possible,
As such one can not disagree with them, I have tried to help, I have pointed out a problem ( glitches from the way the OP is generating the clocks ) , I have pointed out the solution ( use a synchronous design ) , and they have rejected that,
Thats fine by me, Ive been designing these things for a long time, mine work , the OPs dont, I can not argue with them,

But I can argue with people "telling us off"
 

dl324

Joined Mar 30, 2015
16,839
But I can argue with people "telling us off"
I was taken aback by the OP implying that I was just trying to "slag" him (whatever that means; I looked it up and it didn't seem applicable). I was just giving constructive criticism that was the same feedback I had already given him regarding readability on his encoder schematic.

In both cases I tried to help by redrawing portions of the schematics. Being new to a tool is one thing. Everyone should know that using a superb schematic entry program won't make you able to draw a clean schematic.
 

dl324

Joined Mar 30, 2015
16,839
@paulski
I have given (too much) thought to the issue of potential glitches caused by the way you're decoding addresses from the cascaded HC193 counters and I see no reason to be worried about glitches in that portion of the logic.

I checked the Nexperia and TI datasheets. If we give TI as much as Nexperia for trying to negate any propagation delay issues, the outputs will switch at the same time.

Nexperia logic diagram (TI's datasheet is disappointing in it's lack of information).
clipimage.jpg
Nexperia introduced buffers on the inputs of the NOR gate on the first stage to match the gate delays for all flip flops. So I'm fairly confident that they would have given the same attention to the design of the TFF.

TI's datasheet for HC21 is also surprisingly inadequate, but Nexperia gave the logic implementation for their gate. We can only assume that TI did the same thing because some parameters are dictated by JEDEC.
clipimage.jpg
The delay for any input to the output is the same. Furthermore, I assume that designers of SSI gates use the same design practices used by designers of billion transistor microprocessors and that they will layout devices such that the effects of process variation will not affect transistor matching. This didn't become of extreme importance in microprocessor designs until around the 65nm node where I first became aware of measures taken to match device performance. In 1997, Phillips was using a 3000nm process when microprocessors were around the 250nm node.

For timing critical designs, mixing and matching of 74HC and CD4xxx logic should be avoided because CD4xxx logic is significantly slower.

EDIT: Add to that the fact that your clock is less than 200Hz because the encoder bounce time is 5ms, even slower CD4xxx logic wouldn't cause any problems.
 

Attachments

Last edited:

ci139

Joined Jul 11, 2016
1,898
4040 with the latch diagram

i don't yet want to begin analyzing your circuit -- because it'd require printing it out on several A4 , taping together ....

??? why you use 2 complications 4040 & 40110 . . . and if you use them -- you use them unbuffered . . . basically describe in short what you wan't to achieve -- a single MCU can replace a lot of your circuitry . . . reduce the power demand . . . make things happening faster . . . and possibly smoother

if it's educational prj. and you want to test the solution you have -- \(\uparrow\) ignore the above \(\uparrow\)

. . . what i'm not telling is the possibility with complex designs that you pass the bug - for example - of concurrent signals on the same line . . . or conflicting controls (on different control lines fightng for priority ... or never occurring if they are also inter dependent ... ) , or other alike mistakes \(\leftarrow\) to avoid such :: you first need to sketch a logical functioning block diagram of your system including all major control signals . . . then put it together by modules -- each of which is tested (testable) independently . . . actually it's a lot less work than you may first think -- but such keeps you more firmly on track
 
Last edited:
Hi Paulski, i did work through al this discussion but I want to tell you something out of my experience from many years working with Logic IC´s .
First dont mix synchron and asynchron Logic in one circuit. Synchron is much easier to design as long as the speed is not very high. The system has to settled before the next active clock edge.
Second you can mix TTL with CMOS Logic but there is a special CMOS familiy with TTL compatible switching levels: 74HCTxxx. But the Fan out from CMOS to TTL is really limited. Try to avoid to mix the different technologys if possible.
Third if you want to learn the use of Logic try to find circuit diagrams of old systems (1960..80 for TTL or 1970 to 99 for HC and AHC) There exists a very good example: A hobby Computer build from discrete Logic IC in the net but I dont remember the author anymore.
 
Top