Xilinx ISE iSim simulation modes

I've been doing some research into the various levels of simulation available using the Xilinx ISE toolchain and simulator. All of my simulation to this point had been at the behavioral level. I knew it was possible to simulate ASICs that had been designed using Verilog at the component level, but I'd never had need to look into this as behavioral simulation had been sufficient.

My research showed that using the Xilinx ISE toolchains, a design can be simulated in any of five stages along the way from HDL to loadable bit file:

1. Behavioral simulation

Behavioral simulation is the easiest mode to use. It interprets the HDL (Verilog, in my case) as if it was a computer language independent of any particular FPGA hardware. System tasks such as $display, which prints text on the console, can be used to debug the code. All the internal signals exist and can be monitored.

To all outward appearances, my i4004 CPU implementation runs properly under behavioral simulation.

2. Post-synthesis simulation

When implementing a design in an FPGA, synthesis is the first stage toward a loadable bit file. This converts behavioral Verilog to structural Verilog, flattening the design and using only the primitives available in the target FPGA primitive library. Debugging at this level and beyond is more difficult than a behavioral simulation because many of signal names have been modified or lost.

For some odd reason, the GUI interface in ISE does not support post-synthesis simulation, even though the iSim simulator does. I have not attempted a post-synthesis simulation of the i4004 CPU, but it doesn't seem like it would be beneficial to me.

3. Post-translation simulation

The next stage is translation. This translates the structural Verilog produced by synthesis to use the internal primitives described in the FPGA Family Overview. These include "X_FF" for a flip-flop, "X_LATCHE" for a transparent data latch, "X_LUT6" for a look-up table, and so on.

A post-translation simulation of the i4004 CPU appears to run properly. The instruction pointer increments with each fetch.

4. Post-map simulation

The next stage is mapping. This is where the internal primitives are mapped to specific hardware locations. look-up tables, flip-flops, and latches are mapped to specific CLB slices. Input/output buffers are mapped to specific IOBs. This mapping information is added to the internal primitives produced by the translation stage and some reorganization takes place. Initial timing and delay estimates are created.

Post-map simulations of the i4004 CPU fail. The instruction pointer does not increment. Timing violation warnings appear on the console.

5. Post-route simulation

The final stage is properly called "Place and Route". This is where the final placement of components is established and connections between the various CLB slices and other components are finalized.

Post-route simulations of the i4004 CPU fail.


Now I need to figure out how to narrow down the problem. While the CPU is already broken into sections that match my intended discrete component boards, I'm concerned that creating a valid testbench for the instruction pointer board (and others, later) may be challenging due to the multitude of inputs. The IP board has 20 discrete inputs, plus the 4-bit bidirectional data bus.

Maybe I can get iSim to do a behavioral simulation of the majority of the i4004 CPU, and a post-map simulation of the instruction pointer? That might help debug the instruction pointer section, if the problem isn't related to some other portion.