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 |-- GitRevision.txt -- Version information |-- honeywell -- Honeywell copyright material | |-- sch -- The schematics themselves | | |-- asr_340.sch | | |-- ... | | `-- h316_275.sch | |-- sch_txt -- Early stage text-file schematics | | |-- asr_340.txt | | |-- ... | | `-- h316_275.txt | |-- software -- Honeywell software (used in example simulations) | | |-- AB16-CMT5_slst.vmem -- Memory test | | |-- ldr-apm_e_32k_slst.ptp -- Loader (for building test code from source) | | |-- patch_ab16cct4.vmem -- CPU test | | |-- silent_ab16cct4.vmem -- CPU test | |-- sym -- Schematic symbol library | | `-- ccc -- 'CCC' symbols | | |-- ccc_and1.sym | | |-- ... | | `-- ccc_title.sym |-- makefile -- Top level makefile |-- netlist -- Non-Honeywell material | |-- COPYING -- License information | |-- data -- Auxilliary data files | | |-- asr_assist -- Assist files for 'fixsch' | | |-- cpu_assist | | |-- h316_waves.sav -- GTKWave waves file | | |-- mex_assist | | |-- mlo_assist | | |-- notes.txt -- Notes on corrections to schematics | | |-- print_a3.scm -- Print control files | | `-- print_a4.scm | |-- makefile -- Simulation makefile | |-- tools -- Utility tools | | |-- fixsch -- Utility - fix up netlist | | | |-- ... | | | `-- fixsch.cc | | `-- makesch -- Utility - text-to-schematic | | |-- ... | | `-- makesch.cc | |-- ver -- Verilog source and related files | | |-- Makefile | | |-- ccc.v -- Gate model library | | |-- h316_asr_bus.v -- Netlist bus wrapper (ASR interface) | | |-- h316_cpu_bus.v -- Netlist bus wrapper | | |-- h316.f -- icarus control file | | |-- h316_memory -- Verilog testbench memory model | | |-- h316_tb.v -- Verilog testbench | | `-- sim_asr.v -- Verilog testbench ASR model | `-- vt -- Local verification and test code | |-- test_asr -- Exercise the ASR interface | | |-- loadscript | | |-- makefile | | `-- test_asr.asm | |-- test_mex -- Exercise memory expansion | | |-- loadscript | | |-- makefile | | `-- test_mex.asm | `-- test_mlo -- Exercise memory lockout | |-- loadscript | |-- makefile | `-- test_mlo.asm `-- README.md -- Description of repository
Assuming you're using linux (or another unix-like operating
system), the top level makefile will perform the following
steps ( "cd
" into the schematics
directory and type "make
"):
- Build the utility program
makesch
- Use
makesch
to process each of the text files in thesch_txt
directory. 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
.pdf
files, allowing the schematics to be viewed without needing thegschem
schematic editor. - Create the "book"
.pdf
files that contain all of the schematic sheets. - Use the
gnetlist
utility that is supplied along with thegschem
schematic 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 likeA01FF-
, for example) don't comply with verilog naming conventions. - Build the utility program
fixsch
- Use
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,
A01FF-
becomesA01FF_n
. - Gate instance names are also adjusted to comply with
verilog naming conventions and given the prefix
u_
. - 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
using a
prefer
statement. Alternatively, if none of the driving gates' names are suitable, aname
statement 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
using the
tiehi
ortielo
statements. This is required in some cases because theCC365
has 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
GTKWave
.
Dependencies
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.
gschem
is 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
package 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.
Since gschem
is required to netlist the
schematics, and not everyone will be able or want to install
it, the compressed tar file and
zip file include the netlist (it
is the file net/h316_cpu.v
).
Producing the .pdf
files relies on the
ps2pdf
utility that is part of the
ghostscript
package.
Compiling the two utility programs (makesch
and
fixsch
) requires a standard 'C' build environment,
typically gcc
.
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
iverilog
and 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.