An experiment with Icarus Verilog

Something I've given serious consideration is creating a simulated Busicom 141-PF using the Verilog Procedural Interface (VPI, aka PLI) to interface the simulated system with the outside world.

While many Verilog simulators support VPI, the Xilinx iSim simulator is not one of them. However, Icarus Verilog does, and as engineers do I started gathering data and doing experiments.

My plan was to use the Qt widget toolkit to create the graphical interface. Qt runs on Windows, Mac OS X, and Linux, so this would make this simulation available to just about everyone.

My first attempt at running a simulation with Icarus was the EP102 emulation. I have a Verilog module that would drive a real EP102 printer, if I had one, and another module that emulates an EP102 printer. A testbench module feeds test input data into printer driver. This drives the emulator, which outputs a stream of printer codes. The testbench displays the printer codes, which should match the test input data. This is how I debugged the EP102 printer emulator.

Running this testbench with iSim takes almost 1.5 minutes. Uh oh.

What about Icarus? It runs the same testbench in a blazing 3.5 minutes.

This is just simulating the printing of one line going through just the printer, an elapsed simulated time of about 482 milliseconds. running on an otherwise-idle Intel Core i7-2600K CPU at 3.40 GHz. I'm not sure I even want to think about how slowly the full Busicom 141-PF emulation would run.

So how would I make this run faster? The first thing I thought of was to change the time precision specified in the "timescale" statement from 1 picosecond to something larger. However, research indicates that this won't change the wall-clock execution time of the simulation.

Something that will improve the simulation time is to reduce the number of time steps in the simulation. Since my hardware has a 50 MHz clock, my testbench causes a time step to occur every 25 nanoseconds of simulated time. Now that I've changed my 4004 emulation from flip-flops to latches, it won't require such a high-speed clock. I'm pretty sure it would run with a time step of 200 nanoseconds, which is the current delay between the trailing edge of CLK2 and the leading edge of CLK1. I'd just have to make sure this is fast enough for the other emulated parts.

To verify this, I changed the simulated clock cycle time from 50 ns to 200 ns and re-ran my EP102 testbench. That cut the iSim run time to about 23 seconds, and the Icarus run time to 53 seconds. A good improvement, but still longer than most people would wait for an interactive simulation.

It was a nice idea, and I've learned from the experiment, but somehow I don't think it's going to pan out.