Randomise latches and FFs at startup?

[mengstr]

Floating wires have since long been upgraded to continuously randomise their values to mimic their real behaviour - at least in CMOS designs.

So shouldn't Latches, FlopFlops and Counters also have this randomised behaviour at start of simulation (power on)? I mean a real IC doesn't always start up with everything nicely zeroed.

Today those devices can be set for a "default value" in their properties and I guess it would break a lot of designs if you forced random values to all devices, but as a good middle ground maybe you could implement a "Random" value in the default drop-down?

[mengstr]

Ping @hneemann - Any thoughts about this? Now I'm trying to implement this by throwing a bunch of extra circuity around a D-FF to force it into a random state at startup.

I really would like to be able to test a design having a non-insignificant number of 74LS74 in it and the current implementation they don't startup randomly (nor do they fall back to a random state if both Set and Reset is de-asserted simultaneously - but that is another issue)

[mengstr]

I'll have a look at those examples.

But I seem to recall that a pair of cross-connected NAND/NOR gates tend to go into a infinite oscillation in sims if not being forced into a particular state at startup by having one of them as a 3-input device connected to a Reset-component. So is it possible to get a random value?

[mengstr]

Hmmm... Maybe I can force them into a stable state with a hi-Z wire. That could work ;)

[hneemann]

But I seem to recall that a pair of cross-connected NAND/NOR gates tend to go into a infinite oscillation in sims if not being
forced` into a particular state at startup by having one of them as a 3-input device connected to a Reset-component. So is it possible to get a random value?

Not here. In the stabilization phase after switching on, a slightly different simulation mode is used than afterwards. This means that dicrete flip-flops do not oscillate, but have a random state after starting. The fact that many simulators have problems simulating a simple flip-flop was one of the reasons why this project was started: It should be possible to simulate a simple flip-flop consisting of two NAND gates.
If a stable state is desired for a discrete flip-flop, you can do it like in reality: add a reset input, and then connect all reset inputs of the flip-flops together and connect them to a reset component, which then performs the reset at startup.

[hneemann]

This is how it would look like:

[mengstr]

Thanks. Many of my 7474's utilise both the C/D as well as one (or sometimes both) of the S/R inputs. But adding an OR gate to the R input where I've used it for "circuit purposes" to do a PowerOnReset where needed is of course not a big issue.

But It's always nice to be able to simulate a 7474 properly to see if there are some place I haven't done so where required.

The discrete DFF works as you say (of course ^__^) but when utilised as a 7474 with a Set and Reset it breaks the simulation when both of them goes inactive during at the same time. I admit that that condition probably should not happen in real life so it's not a big issue.

But I wish there was a flag that one could set to "silently ignore" oscillations and just pretend the node got a stable value and use that for the continued processing.

(Just as I wish there was a way to default the gates shape to not wide)

[hneemann]

But` I wish there was a flag that one could set to "silently ignore" oscillations and just pretend the node got a stable value and use hat for the continued processing.

This is difficult because the simulator cannot simply select a state, but must intervene in the simulation in a way that leads to a stable state.
And that is difficult to implement in a generally valid way.

[hneemann]

While thinking about my last comment, I realized that it is actually very easy to recover from an oscillation. You can simply switch to the same simulation mode used during the init phase.
The question now is rather whether it is a good idea to do that, because it would hide errors and make the simulation unpredictable in case of an oscillation and also very slow.

[mengstr]

It's good there's an easy solution if you decide to implement this. :) While I agree that it would hide problems in some cases, it would also make for a more realistic simulation where some oscillations settle by themselves.

If you implement a mode for this I guess it'd be a good idea to reduce the max-number-of-oscillations value to something really low so they settle fairly quickly.

[hneemann]

Please try the latest pre release.

[mengstr]

Ooohhh nice... It works just fine. It will be really good to have when trying to simulate circuits having discrete FFs in them. And I guess the can be used as a random generator as well in a pinch ;)

[mengstr]

I'm getting some debug info in the console that you might not have intended to have there...

cycles: 36290000
time  : 1.0s
freq  :3.629E7
cycles: 34775000
time  : 1.0s
freq  :3.4775E7
cycles: 37370000
time  : 1.0s
freq  :3.737E7
cycles: 37220000
time  : 1.0s
freq  :3.722E7```

[hneemann]

That's the console output of a speed test.

[mengstr]

Ah silly me... I forgot that I ran a few :)