# How does the hardware simulator work?

4 messages
Open this post in threaded view
|

## How does the hardware simulator work?

 I might be asking this question a bit too early given my knowledge (just started this course), but I'd still like to understand how the actual HDL code is "ran" in the hardware simulator. I understand that the order in which the chips are described in HDL doesn't matter (they're just descriptors of the individual chips after all), but I would expect that at least that the order in which the signals are "sent" can matter - so how is this done? I would assume that if there are say 2 inputs, this could be in some sort of depth-first way, simply take the inputs a,b, find the all the chips that are connected directly to a and b, and have no other input, and calculate their value. Repeat on outputs, or something like that. But I'm not sure this is physically accurate. I haven't given this that much thought - I'm just wrote the above as an example and to describe what I'm trying to understand. Either way, I'd like to know how the signals are pushed through in the hardware simulator, and why it is done this way.
Open this post in threaded view
|

## Re: How does the hardware simulator work?

 Administrator There are a number of ways in which a simulation like this can be carried out, some simpler than others. I'm not sure of the exact approach used by this particular simulator, but it is definitely as the simpler (and hence more restrictive) end of the spectrum. One common way to carry out the simulation of combinatorial circuits is to simply cycle through all of the signals and update them until nothing changes. Each signal has a single driver (i.e., it connected to exactly one output pin, or is an input to the circuit overall). The simulator has to decide what to do with signals that either have no driver or that have multiple drivers. The best approach is to throw an error. I believe this simulator throws an error for multiple drivers but it assumes that undriven inputs are a logic LO. This latter behavior is dangerous and I believe it causes a lot of confusion and frustration among students who accidentally leave a signal floating and then get strange results but don't realize its because of this unrealistic behavior that the simulator imposes on floating signals. But let's assume that each signal has exactly one driver. Now put the chips in whatever order you want (the order they appear within the part is as good as any) and go through for each chip and update the signals it drives based on the current values of the other signals. Set a flag if any of the driven signals change from their prior values. Walk through the list of parts. When you are done, if the 'changed' flag is set, then you clear it and repeat the process. You keep doing this until the changed flag is still clear at the end of a pass. This simulator probably uses this approach and it does so in a fashion that assumes that the circuit is statically stable even if all of the gates have zero propagation delay through them. This works provided there is no feedback from an output back through the circuit in such a way that it could affect itself. This means that you can't simulate fundamental mode circuits such as latches, flip-flops, or oscillators. That's why this simulator has to provide a DFF part in addition to a NAND part as primitives. You can build a DFF from NAND gates, but you need a more sophisticated simulator to simulate it.