Simulation in DipTrace 5.0

[Batiskaff]

I have created a schematic, see the attached screenshot. Now I am trying to simulate how it works in a digital SPICE simulator (built-in DipTrace 5.0 beta).

In general, it works almost reasonably. But there are strange signal distortions on some outputs of U3 on each falling edge of the clock coming to the input of decade counter U5. I have shown the problem with red marks.

What I am doing wrong? Is it a simulator issue or the schematic is incorrect?

[AndrewP]

Hi Batiskaff and welcome to the forum!

I might be the wrong person to answer this as I know nothing about NGSPICE simulation and almost nothing about the 74LS90.

However my first thought would be that running a ripple counter into a decoder might cause some weird glitches as it's quite possible that all the 74LS90's outputs will not transition at exactly the same time.

My second thought, depending on how accurate the 74LS90 Spice simulation is, is that it has propagation times on the order of 10s of nanoseconds but it looks like the simulation is stepping at 10ms. The 10Hz clock and second long output scale may not give you the resolution to see what is actually happening. Maybe try increasing the clock to 10MHz and increase the simulation step to 1ns and see if the output makes a bit more sense.

My last thought is that there is some feedback from QA to CKB (which is correct according to the datasheet) and that this will be occurring in 10s of nanoseconds. What this means for the simulation I don't know; but I don't think there's enough resolution to see what's happening there.

Cheers,
Andrew

[barnacle]

Exactly this: the '90 is a ripple counter - a stage doesn't clock until the previous stage tells it to, rather than everything changing on the clock edge. So the last stage doesn't change until tens of nanoseconds after clock that triggers the change, and that means that there are, for those few tens of nanoseconds, unexpected and unwanted signals on the outputs.

Which the '42 will happily decode, producing those glitches that you indicate. There are probably also other glitches which you don't see because they're too fast for the simulator to display. This is always an issue with simulators because they're rarely transistor-gate-accurate and sometimes not internal-logic-accurate - I have counter circuits which rely on that phase delay which simply won't work in the simulator I use, because the simulated chip apparently is synchronous.

Whether the glitches are an issue for you or not only you can answer. It looks as if you are using the '42 outputs to control a function in an ALU(?) in which case, any delays in the ALU circuit are likely to exceed the brief time that the control is incorrect, so no issue. But only you can tell - you may need to gate the decoder output with the clock, for example.

Neil

[Dr Jefyll]

AndrewP wrote:

all the 74LS90's outputs will not transition at exactly the same time.

barnacle wrote:

a stage doesn't clock until the previous stage tells it to, rather than everything changing on the clock edge

Welcome, Batiskaff

Just to shed some light on the terminology... the '90 is called a "ripple" counter because the outputs won't ever change all at once, even in the case where the counter rolls over from the maximum count (all ones) to zero. Instead what happens is, the least-significant stage will be first to change... followed by the next stage, then the next stage and so on. So to speak, the change "ripples" from one stage to the next. This is in contrast to a synchronous counter (such as the 74x163), whose Q outputs *do* all update virtually simultaneously.

-- Jeff

[barnacle]

Dr Jefyll wrote:

This is in contrast to a synchronous counter (such as the 74x163)... its outputs *do* all update virtually simultaneously.

-- Jeff

Um, except when they don't... even a synchronous counter doesn't guarantee the exactly co-synchronous change of state; process variations mean there may still be momentary glitches. But we're talking pico-seconds here, not nano-seconds. And that's generally too short to affect anything further downstream (it generally won't exceed the required minimum times to trigger or latch; driving a capacitive load it's unlikely to even reach the other logic level).

In general: you should never use unqualified combinational logic to make decisions on clock counts from ripple counters; and think carefully about how things might go wrong with synchronous counters.

But - for example - in a clocked CPU design one might generally design it so that one phase of the clock sets the inputs to registers, ALU, and suchlike, and the other phase of the clock does the latching when things have had time to settle down.

Neil

[Dr Jefyll]

Hi again, Batiskaff. Neil and I aren't in disagreement, just so you know. It's just that he took the trouble to give a rather fine level of extra detail (whereas I glossed that over by saying "virtually simultaneously"). I think it was worthwhile to explain why a Ripple counter is so called. But the pico-second-level stuff also bears discussion.

-- Jeff

[barnacle]

Indeed Jeff. And of course both of us have glossed over the great big white heffalump in the room: simulations are just that. They're not the real thing, and at the price most of us can afford, _none_ of them are exact in many details (and if they were, they'd be too slow to be of any great use).

So usually, a simulator will show the _logical_ outputs of designs or particular TTL parts, but won't care about e.g. exact voltage levels, or the effect of loading outputs, or running at voltages other than that specified. They may include some nominal gate delays, but they won't be accurate (and probably the same delay for all parts).

As an example, Logisim-Evolution offers a generic counter. It's a very handy part, but its output switches synchronously. You don't always get the same results if you choose to build a counter using chained flip-flops, for example. It's always important to be aware of what's really happening.

Neil

[Batiskaff]

Thank you for your help. Bests regards.