The best material model of a cat is another, or preferably the same, cat.

–Norbert Wiener

As I start to compile notes for a series on Verilog models, one of the first issues that pops up is that simulation itself isn’t nearly as obvious as it looks on the surface.

This is true of any simulation of anything, of course.  A computer can’t reproduce the physical complexity of the world for anything other than itself, which is rarely that useful.  (One notable exception being testing that computer.)  But with Verilog simulation in particular, there is the issue of it having a malleable level of abstraction.

What I mean is, while Verilog’s first principle as a tool is to (mostly) throw away the subtle, analog details of circuitry, it has many capabilities which allow it to be used to represent very small, specific details of a circuit or very large collections of circuits.

This is even a bigger problem than it might appear at first, because if you build a model of a circuit which does not consider its many timing concerns, that model may fail to adequately represent the problems of the system.  But on the other hand, modeling too much of the circuit will slow down simulation, and often more obviously, use up hours, days, or possibly months of labor to construct.

Fundamentally, Verilog in any form must be written with some consideration for its target.  Even the most basic simulations imply something about the way Verilog is being employed, and this is often subtle: a Verilog simulation exists on a smooth continuum between a somewhat stripped-down but purely physical model and a block diagram with mathematical descriptions of the inputs and outputs.  (These are often called “structural” and “behavioral” Verilog respectively, but they are types of content within the same language, and can be used together in the same simulation.)

Further confusing matters is the design aesthetic of Verilog, which is this: make a Hardware Descriptive Language feel as much like a Software Descriptive Language such as C as is reasonable.  For the less detailed digital model, this is a very positive feature that can make it easy to quickly design a system specification.  For a more detailed model it can be downright self-defeating to use some of the language’s more comfortable features.

In the tutorials which will follow, I want to stress that I lean more heavily on the lower-level descriptive features of Verilog at first as an effect of starting at the bottom of the abstraction hierarchy.  When describing larger systems, it is acceptable, even preferable, to specify more loosely the behavior of a system.