The schematics of the H316 can be netlisted to produce a verilog netlist. This netlist can then be simulated using a logic simulator, allowing the detailed operation of the CPU to be examined as it runs programs.
At the present time the schematics that can be netlisted and simulated cover the basic H316 processor and the high-speed aritmetic option.
The schematics and gate-level simulation environment can be downloaded as either:
- A compressed tar file
(place it in the directory where you want it and extract its contents with the command "
tar -xvzf schematics.tgz").
- A zip file, primarily for windows users.
The extracted directory tree has the following contents:
schematics |-- Makefile |-- SvnRevision.txt -- Version information |-- asr_assist -- Assist files for 'fixsch' |-- cpu_assist |-- fixsch -- Utility - fix up netlist | |-- ... | `-- fixsch.cc |-- gafrc -- gschem resource file |-- makesch -- Utility - text-to-schematic | |-- ... | `-- makesch.cc |-- net -- Netlists (derived data) | `-- h316_cpu.v |-- patch_ab16cct4.vmem -- Example program to run in simulation |-- print_a3.scm -- Print control files |-- print_a4.scm |-- sch -- The schematics themselves | |-- asr_340.sch | |-- ... | `-- h316_150.sch |-- sch_txt -- Early stage text-file schematics | |-- asr_340.txt | |-- ... | `-- h316_150.txt |-- sym -- Schematic symbol library | `-- ccc -- 'CCC' symbols | |-- ccc_and1.sym | |-- ... | `-- ccc_title.sym `-- ver -- Verilog source and related files |-- Makefile |-- ccc.v -- Gate model library |-- h316.f -- icarus control file |-- h316_cpu_bus.v -- Netlist bus wrapper |-- h316_tb.v -- Verilog testbench `-- h316_waves.sav -- GTKWave waves file
Assuming you're using linux (or another unix-like operating
system), the top level makefile will perform the following
steps ( "
cd" into the
directory and type "
- Build the utility program
makeschto process each of the text files in the
sch_txtdirectory. This is the way that the schematics were originally created. A text file describes each of the gates, its location, annotations, and named or labelled inputs. This is then processed to produce a schematic lacking just the wiring which was then drawn by hand.
None of this will be of interest unless you should want to create new schematics in the style used by Honeywell for the H316.
- Print each of the schematics to produce the
- Create the "book"
- Use the
gnetlistutility that is supplied along with the
gschemschematic editor to netlist the schematics to something close to verilog. At this stage a lot of warnings are produced because the signal naming conventions used in the schematics (names like
A01FF-, for example) don't comply with verilog naming conventions.
- Build the utility program
fixsch, together with an "assistance" file,
cpu_assist, to fix a number of issues with the netlist that has been produced. The issues addressed include:
- The signal names are systematically changed to comply
with verilog naming conventions. For example,
- Gate instance names are also adjusted to comply with
verilog naming conventions and given the prefix
- In general, nets are named by the gate that drives the net, this being the convention for labelling signals used in the Honeywell schematics.
- Where more than one gate drives a net (unlike more
modern logic technologies, it is perfectly normal to
"wire-AND" the outputs of several DTL gates together) the
"assistance" file can indicate which is to be preferred
preferstatement. Alternatively, if none of the driving gates' names are suitable, a
namestatement may be used, identifying the net to be named by specifying a named input to a named gate.
- Floating gate inputs may be tied either high or low
tielostatements. This is required in some cases because the
CC365has double usage (see the notes on LBD 0.117, for example). In other cases it it is because the CPU option that would drive the signal is missing from the schematics.
- The signal names are systematically changed to comply with verilog naming conventions. For example,
- Run a verilog simulation using "Icarus" verilog. This simulation loads a (somewhat patched version of) the CPU Verification and Test program AB16-CCT4 into memory and starts to run it.
- Display the resulting waveforms using
Supplying an overall
makefile provides a
convenient way to describe the various steps that need to be
taken in order to get a first example simulation up an running.
However, it depends on a series of programs being installed.
These dependencies are described here.
The three major suites of programs that are used are:
gschem is required to allow any modifications to the schematics to be made, and the resulting changes to be netlisted into a new verilog netlist. There really is no alternative to gschem since it is extremely unlikely that any other schematic editor will be able to understand the file format. Note that it is not required if you just want to simulate the unmodified netlist.
part of the gEDA project
that is developing a "full GPL'd suite and toolkit of
Electronic Design Automation tools". Many linux distributions
ship with gEDA, although not installed by default. On Ubuntu, for example, install the
geda-gschem using the Synaptic Package
Manager. I don't think there is a simple way to use gschem
under Windows. I'm sure that it is possible to build it from
source under either MinGW or cygwin, but that's a non-trivial
project in itself.
ps2pdf utility that is part of the
Compiling the two utility programs (
fixsch) requires a standard 'C' build environment,
For simulation, Icarus and GTKwave together provide a
perfectly useable verilog simulation environment, with the
significant advantage that they are available free of charge.
Both are available as packages in many Linux distributions (on
Ubuntu the packages
gtkwave) and both can be
run under Windows. However, there really isn't anything
particularly specific to these tools that is required, and
any verilog simulator should be able to simulate the
H316 netlist and its example testbench.
Unfortunately there are bugs in some of the released versions of Icarus verilog concerning the way that logic that requires strength reduction (like the DTL logic used in the Series-16 machines) is modelled. I recommend that you avoid anything earlier than the 0.9 series releases, since I've not tested the H316 logic simulation with these earlier versions. Versions 0.9.1, 0.9.2, 0.9.3 and 0.9.4 are all thought to simulate the H316 correctly.
Version 0.9.5 is known to have problems, although the issue is quite minor, affecting only the S/R latches that debounce the front-panel sense switches. As long as the sense switches aren't tested by the program being run on the simulated H316 then the simulation proceeds correctly, but when they are tested then the simulation quickly degenerates into all nodes having the value 'X'.
At the time of writing (late December 2011) the version of Icarus in the master branch of the git repository also does not work correctly. This is a much more fundamental problem, and it is not possible to simulate the H316 gate-level netlist with this version of Icarus verilog.