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.

GTKWave view of H316 gate simulation results.

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:

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"):

  1. Build the utility program makesch
  2. Use makesch to process each of the text files in the sch_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.
  3. Print each of the schematics to produce the .pdf files, allowing the schematics to be viewed without needing the gschem schematic editor.
  4. Create the "book" .pdf files that contain all of the schematic sheets.
  5. Use the gnetlist utility that is supplied along with the gschem 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 like A01FF-, for example) don't comply with verilog naming conventions.
  6. Build the utility program fixsch
  7. 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- becomes A01FF_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, a name 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 or tielo statements. This is required in some cases because the CC365 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.
  8. 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.
  9. 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:

  1. The gschem schematic capture package.
  2. The Icarus verilog simulator.
  3. The GTKwave waveform viewer.

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.