The First Simulation

Near the end of the reverse engineering process, we wind up with a Verilog netlist and a library. The next step is to see if it works.

The first thing we do is to put the design into our Verilog simulator, and run it. Typically, there are a lot of issues preventing it from running. These are generally simple issues of typographical errors, or pin polarity issues on the input or output statements.

For processors, the next step is to see if it can execute an opcode. We typically use a NOP as our first test, since it is the simplest opcode. And that typically doesn’t work. So, we begin the process of debugging.

Almost every problem is a library problem, though these library problems are much more complex than just modeling a NAND gate. Instead, we are dealing with bidirectional transmission gates. And in many cases, these transmission gates are composed of a single NMOS transistor. I would like to give two examples of these problems.

Most micros contain a microcode ROM for instruction execution. These ROMS consists of arrays of NMOS transistors capable of pulling a bit line low. The bit line is forced high with a PMOS precharge circuit. The bit lines go through muxes to connect to the sense amp, and the precharge is located at the sense amp. This means that the muxes are actually bidirectional, sending a zero to the sense amp, and sending the precharge one back to the bit lines. Modern design techniques discourage bidirectional transmission gates, so there is not a direct solution. As an indirect solution, we add a weak1 pullup to the bit lines at the mux inputs. This emulates the precharge, and allows the microcode ROM to work.

In another interesting problem, we had a register containing latches with three D-inputs. The D inputs also served as the output, somewhat analogous to the operation of a 6-transistor static RAM cell. Whether a write or a read occurred was dependent on whether someone else was driving the databus at that time. This problem has two possible solutions. The first is to evaluate everyone who might be driving the databus at the time the latch is enabled, and generate a new signal that can be used to determine whether a read or write is occurring. A second solution is to study the circuit. In some cases, a write might only occur on some of the D inputs, while a read might occur on the other D inputs. In that case, the model can be constructed to reflect that.

As shown above, models frequently contain engineering judgements that can be wrong. We can check this by running spice against the whole design. The spice run times increase with circuit size, and a whole chip simulation can take a very long time. But we can do it for a limited number of clock cycles, and that is frequently enough to allow us to perform an analysis on the Verilog models and simulation.

Date

2021-05-13