Digital logic simulation (by alaric)
For a while, I've been considering moving into the soft IP market - designing logic circuits that can be used as modular black boxes in designing circuits for use in FPGAs or ASICs.
However, developing such soft IP blocks can be a challenge; they need testing and debugging. You can get an FPGA development board and put your designs into a chip along with test logic to run them through their paces, but it can be hard to inspect the internal signals that way. Or you can simulate them in software.
So, obviously, I'm going down the software route. Thing is, most digital logic design software has you specify the logic in Verilog or VHDL, neither of which I fancy, for many reasons.
So I've taken to writing my own; one where the design is input as a hierarchial netlist, an actual description of how a circuit would be wired rather than an abstract description of its behaviour. It's designed for purely digital logic, and optimised for speed and ease of debugging.
Currently, since I've yet to write an input driver, circuits and test inputs are set up in C++ source code, but before long there'll be a mini language for setting up circuits and test inputs. For debugging, I've defined a logic probe device that can examine a number of named input lines, or a bus; whenever one of the lines changes the change is detailled, and the new state of the entire bus displayed. Next, I'll define a trap capability, where logic probes can be told to suspend simulation in specified circumstances and give a command prompt, from which the states of lines, busses, and devices can be examined, and test signals injected.
The data model of the system is quite simple; a line is connected to any number of device outputs and inputs. Each device output has a state - 1, 0, ? (undefined), or Z (high impedance). The overall state of the line is ? if any output driving it is ?, or there are outputs driving it with 1s while others are driving it with 0s (in this situation it outputs an error message, too, since that condition can damage devices). If all the outputs driving it are Z, then the overall state is also ?; and if the outputs driving it are a mixture of 1s and Zs, or 0s and Zs, then the overall state is 1 or 0, respectively.
Whenever the overall state of a line changes, it notifies all the devices that have inputs connected to the line.
The system is driven by a scheduler. Devices schedule changes to their outputs at specified times in the future. A device cannot just change an output from 0,1,or Z to any other state - when a device asks to chane its output, what actually happens is that at the specified time the output changes to ? then, a little later, it changes to the desired value, modelling transmission line effects in the line. The delay consists of a small basic delay, plus a second delay factor times the number of device inputs driven by that line, to model the capacitance of all those transistors.
When a device's inputs change, it is notified - if lots of inputs change at the same point in time, it is notified just once, for efficiency (think about 64-bit data busses). The device then figures out if any of its outputs need to change, and if so, schedules changes at suitable times in the future, thus allowing for gate delays.
So far I've implemented an AND-gate device, as the quick and simple test, then I went on and implemented a static RAM. This is much more complex, especially when one considers the effect of timing and inputs having undefined states. The RAM device signals an error if the write line goes high while any address or data lines are undefined, so you need to make sure the address and data busses have stabilised before asserting that write, then when you drop the write line, you need to make sure it's had time to become 0 before removing the address and data signals, since when the write input is ? the RAM device considers that it might be writing.
Likewise, when reading, if the read line or address inputs are undefined, the data outputs are, too.
The point of all this is to make the simulator handle the messy details of logic being pushed with high clock rates. If you try and run things too fast, then you get undefined signals appearing in the wrong places because lines haven't had time to settle before they're needed, and you get errors flagged. With it, I'll hopefully be able to do quite accurate timing models of digital logic - a prerequisite for things like asynchronous microprocessors!
And, yes, when I've finished implementing the simulator (with the circuit input file parser, test input signal parser, VCD file output from the logic probes so the results can be viewed in nice graphical signal viewers, the interactive command line, and a wide range of devices - all the usual logic gates, every type of flip-flop, multiplexers, demultiplexers, and logic blocks like ALUs) - I'll make it open source!
Electronics | alaric | 
Thu 15th Jun 2006 8:08 pm
Subscribe
By Mads, Fri 16th Jun 2006 @ 1:07 am
Sounds like a great project 🙂
By Charlee, Fri 16th Jun 2006 @ 6:14 pm
I think Ash used to use something called Handel C when he was doing FPGAs