pardon my ignorance but i really do not know (or care) what it is under the hood of a spice simulator. or why comparing input voltage against fixed levels need hysteresis at all on a gate that is not Schmidt trigger...

whatever the approach is, that is something that simulator creators should take care of. the whole point of simulation is to model real world and if it cannot do that well, that it is not a good simulation.

No simulator can model real world behavior completely and the more you model real world behavior, the slower the simulation becomes. It's a tradeoff and you have to decide how faithfully you want your simulations to reflect the real world. A simulation that takes weeks to complete (and, yes, I have had sims that took longer than that to run) isn't very useful for most design work. It may be what you have to live with for final verification against specs, though.

Model designers have to decide where to make that tradeoff. Simple digital models are designed for simulation speed and to evaluate basic functionality of the logic. They are generally not intended for evaluating the analog performance of the circuit. To get that, you need to use the transistor-level circuits that implement the gates. Hybrid models that let you interface digital models with analog models have interfaces instantiated behind the scenes to convert between logic levels and voltage levels. The basic ones are very simple, but most allow you to customize their behavior to better match your needs.

 

of course there need to be balance between complexity and performance. in this case we are not talking about something complex. circuit is a single AND gate.

 

why comparing input voltage against fixed levels need hysteresis

The hysteresis is not added, it is a given if you use both the high logic and low logic thresholds at the same time in the model.

you could using one model, by using params to setup the thresholds.

Yes you could, if you want to do more than one simulation for worst-case conditions.

 

of course there need to be balance between complexity and performance. in this case we are not talking about something complex. circuit is a single AND gate.

But it's the same AND gate that is going to be used in someone's circuit that has millions of them in it.

When I was designing ICs, we had multiple models for devices, some of which we developed in house and some of which we got from the process fab (e.g., TSMC).

We would start with pure digital models for our logic that all had no awareness of voltage levels, only HI, LO, and X (unknown) along with propagation delays that were in the ballpark for all of the processes we targeted. This allowed us to get the functionality working quickly since even if the logic ended up having hundreds of thousands of gates the sim would run in a few minutes.

For the analog portions of the chip, we would use the fab's nominal coarse transistor models which were simple and fast. But once the main approach was established, we used their high-fidelity models, which were actually a family of models that included fast/slow NFET/PFET in each of the four combinations, allowing use to examine the corners of basic process variation. We might also have models that were specific to various temperature ranges, since some of our designs operated as low as liquid nitrogen while others operated at elevated temperatures and just setting the TEMP parameter in the sim wasn't nearly good enough. On a few chips, we had to use even far more complex models. In one IBM process, the supplied transistor models were actually subcircuit files with over three hundred devices in them to model the behavior of a single transistor. Even using those for the core processing element that only had a few dozen transistors took hours to run -- but the fidelity to the performance when we got the chip back for testing was phenomenal.

As we progressed further, we would switch to using mixed-signal digital models that had inferred A2D/D2A interfaces between the analog signals and the digital models. These also modeled the propagation delays and drive strengths. These allowed us to see if the digital logic had a chance of playing nice with the analog circuits, which up to this point used simulation sources to drive them (often buffered through a transistor-level buffer to get realistic loading effects).

We usually finished with a simulation that used the mixed-signal models for all of the logic except those gates that interfaced with the analog circuitry, for which we would use the actual transistor-level implementations of the gates.

For some chips, we had to get even more draconian. On one chip, I had to figure out how to do Monte Carlo simulations that would support conclusions regarding expected yield that needed to go out to five-sigma, but nearly all simulators are hard-coded at three-signma. So I spent a couple of weeks figuring out how to use the Monte Carlo data to estimate the statistics for the overall critical portion of the chip and, from that, infer the expected yield. The customer's customer wanted to see at least 75%. My work estimated 82%, with a lot of uncertainly that I clearly outlined. They chose to proceed and the actual yield turned out to be 85%, which frankly shocked the hell out of me.

EDIT: Fix typos.

 

Thanks W, for your extremely comprehensive explanation.

 

all i see is posts repeating things i am well aware of, yet they continue to argue what it is instead of what it could/should be. how do i make my point simple?

But it's the same AND gate that is going to be used in someone's circuit that has millions of them in it.

sure but... so what?

that still does not change what product (in this case some spice) does to handle the task. and not all approaches are equal. for some reason software developers have no brain power to make products able to look at data at hand (in this case read a file/netlist), and choose how to process it (which settings to choose or prefer)?

DMM can be set to measure continuity and occasionally user will make a mistake and connect probest to AC socket. almost any modern DMM will survive because we have standards and expectations. apparently people using simulators have very low expectations.

for something that can spit result in fraction of a second in one case, and take months in another case, it would be prudent to do some preflight checks to estimate how long simulation may take. apparently some think that this is not something that developers could or should do. in this case what stops simulation to read file, check netlist (number and type of nodes) and pick or propose simulation strategy that serves humans? something that does not take lifetime to process and does not produce utter garbage even if circuit is tiny. what stops it from balancing/optimizing accuracy and processing time? if the netlist is tiny, hit it with more accurate strategy, simulate every transistor. another concept they don't seem to be familiar is watchdog timer - many circuits (even very simple ones) will result in sim to have a meltdown (run extremely slow and possibly never converge). why is it ok that the only "solution" is "it will finish when it is finished, even if it takes eternity"?

 

where is the innovation? time may be endless but human lifespan is not. so regardless of inner working of sim during "run" (calculating simulation), how about a low hanging fruit - before starting sim? how about simple display that shows simulation estimate based on current computer resources, loaded netlist and settings user clicks on? it does not have to be perfect but something that shows if sim would be done in seconds or days or years... with that step done, next could be to add a second feature, basically a one click option where user enters desired time for simulation, which would then let sim pick whatever settings are likely to produce result in that time.

i think many would appreciate one button convenience, rather than digging through pages of settings... so if you are in a hurry, you may say lets try to get this done in a minute or so but if you are done for the day and going home, let it run for 10 or 60h.

 

Based in this discussion, the place a logic gate simulation could differ wildly from the real device would be when the device was used for analog as i have seen in some circuits. Imagine the behavior of a hysteric oscillator on a gate that is not specifically a Schmitt trigger.

 

where is the innovation? time may be endless but human lifespan is not. so regardless of inner working of sim during "run" (calculating simulation), how about a low hanging fruit - before starting sim? how about simple display that shows simulation estimate based on current computer resources, loaded netlist and settings user clicks on? it does not have to be perfect but something that shows if sim would be done in seconds or days or years... with that step done, next could be to add a second feature, basically a one click option where user enters desired time for simulation, which would then let sim pick whatever settings are likely to produce result in that time.

i think many would appreciate one button convenience, rather than digging through pages of settings... so if you are in a hurry, you may say lets try to get this done in a minute or so but if you are done for the day and going home, let it run for 10 or 60h.

If it were that simple, it would have been done long ago. And many simulation developers are reluctant to change their code to avoid obsoleting, or creating problems for, legacy models and simulation schematics.
Most problems with long simulation times are caused by poor modeling of devices (like models with tiny oscillations occurring that shouldn't be there), or just pain improper use of the simulation tool.

 

all i see is posts repeating things i am well aware of, yet they continue to argue what it is instead of what it could/should be. how do i make my point simple?



sure but... so what?

that still does not change what product (in this case some spice) does to handle the task. and not all approaches are equal. for some reason software developers have no brain power to make products able to look at data at hand (in this case read a file/netlist), and choose how to process it (which settings to choose or prefer)?

DMM can be set to measure continuity and occasionally user will make a mistake and connect probest to AC socket. almost any modern DMM will survive because we have standards and expectations. apparently people using simulators have very low expectations.

for something that can spit result in fraction of a second in one case, and take months in another case, it would be prudent to do some preflight checks to estimate how long simulation may take. apparently some think that this is not something that developers could or should do. in this case what stops simulation to read file, check netlist (number and type of nodes) and pick or propose simulation strategy that serves humans? something that does not take lifetime to process and does not produce utter garbage even if circuit is tiny. what stops it from balancing/optimizing accuracy and processing time? if the netlist is tiny, hit it with more accurate strategy, simulate every transistor. another concept they don't seem to be familiar is watchdog timer - many circuits (even very simple ones) will result in sim to have a meltdown (run extremely slow and possibly never converge). why is it ok that the only "solution" is "it will finish when it is finished, even if it takes eternity"?

Once you come up with a standard for simulator protocols that include mindreading, your idea might have merit.

A simulator that detected that the simulation was going to take weeks and then made changes so that it would only take hours would be of absolutely no use to anyone that needs the level of results that are only obtainable in a simulation that takes weeks to run. The simulator has no idea what information I am looking for as a result of running the simulation.

 

you are making it harder that it should be (and i am making it easier than it is). every problem has solution, someone just did not think of it yet. things do not have to be extremely smart or extremely brute force to get the result more efficiently. even if there is a complex circuit with thousands of gates, there is no need to check levels as analogue values on every single input, only on those that are connected /driven by something in the outside world.

 

you are making it harder that it should be (and i am making it easier than it is). every problem has solution, someone just did not think of it yet. things do not have to be extremely smart or extremely brute force to get the result more efficiently. even if there is a complex circuit with thousands of gates, there is no need to check levels as analogue values on every single input, only on those that are connected /driven by something in the outside world.

So how do I determine what the peak switching transients are that get injected into the substrate near sensitive analog circuitry?

 

you can do it any way you like.

 

you can do it any way you like.

Not if the tool insists that it knows what I need more than I do.