27 Oct
2017
27 Oct
'17
8:27 a.m.
On 10/27/2017 3:54 AM, Dave Wade via cctech wrote:
Kip,
I think "emulation" and "simulation" get used pretty much
interchangeable.
SIMH is touted a simulator, Hercules/390 as an emulator yet they are both
programs that provide a "bare metal" machine via software on which an
operating system can be installed. Neither make any attempt to reproduce the
speed of the original CPU.
I am going to stick with "emulator" as I think of "simulation" as
process
whereby we can model some statistical or mathematical parameters e.g. how
long the queues are in a supermarket, what time is high tide in Boston using
only mathematics. Note this may involve a general purpose computer, or it
may use specialist machines such as the Doodson-Lege Tidal Predictor
http://www.ntslf.org/about-tides/doodson-machine
So to return to emulating other computers have at least five different
flavours...
1. Functional Software Emulation where we match the functions but not the
speed of operation using a program. SIMH and Hercules are such beasts
For much work this is fine. Most software emulators take this approach.
2. Cycle accurate Software Emulation/Simulation where we attempt to match
both function and speed of the underlying hardware. This may be necessary
for software which uses software loops to control say the speed of a UART. I
If you want to use the simulator for historical research this may help. Some
emulators can be switched to this mode when software needs it...
David Sharp's SSEM/Baby simulator is such a beast.
http://www.davidsharp.com/baby/
3. Behavioural Hardware Emulation
This is where we build a hardware implementation of a machine, but do not
attempt to duplicate the exact detail of the logic or its speed of
operation. Richard Stofer's IBM1130 in VHDL is such a project.
He doesn't have it available on the Web (I have a copy and have run it)
There is a Flash video on the IBM1130.org site
4. Cycle Accurate Behavioural Hardware Emulation
This is probably the most common approach to cycle accurate emulations.
Because FPGA's typically run several times faster than the clock on legacy
hardware, and they may contain high level function blocks, e.g. multipliers
its often "relatively easy" to match the instruction times of a legacy CPU
in an FPGA.
My BabyBaby FPGA implementation of the SSEM FPGA is such a beast. It runs at
the same speed as replica SSEM in MSI Manchester but internally it's a
parallel implementation whereas the real Baby is a serial machine.
https://hackaday.com/2016/01/06/babybaby-a-1948-computer-on-an-fpga/
5. Gate Level Hardware Emulation
It gate level hardware emulation we try and re-implement the hardware down
to the logic gate level. This is hard because FPGA's are may not be designed
to work this way, and gate level design will also have some dependencies on
propagation delays, which on an FPGA will be much smaller than on any real
hardware. A couple of examples of these are
Laurence Wilkinson's IBM 360/30 http://www.ljw.me.uk/ibm360/
Carl Claunch's IBM 1130 http://ibm1130.blogspot.co.uk/
I hope this doesn't muddy the water too much...
Dave
Well, the waters are sufficiently muddy that I figured little harm would
be dine if I throw my weeds in too... ;)
I like that you have clearly given this some thought, and have developed
a kind of taxonomy, so your comments are valuable because they are not
just off-the cuff.
Looking online at Merriam-Webster, the conclusion one might reach is
that these are all simulators. But emulation is also a term of art when
it comes to computers, so I don't think we should shackle ourselves to M-W.
I have generally used the term emulator for software that attempts to
provide some level of functionality (up to 100%) of the original machine
such that software (including operating systems) will operate, without
worrying about HOW that is done. So, I would throw most, if not all, of
the SimH programs, and Hercules as well into that pot. I would also put
the IBM 1401 and 1410 emulators that appeared on early model IBM
System/360 machines (which was done using software with microcode
assist) into that same bag, as well as the FLEX implementation of the
IBM mainframe architectures. So, I am on the same page with you with
regards to #1.
I have generally used the term simulator for software that attempts to
replicate the actual operation of the original machine, regardless of
speed - I view speed as just one of several possible measures of the
accuracy/level of the simulation. I have written an IBM 1410 simulator
that simulates the operation of the original machine at the machine
cycle level, based on the IBM CE instructional materials - but it pays
no attention at all to the absolute cycle time, only to the relative
cycle time (so that peripherals, such as tape drives, work in about the
same relative speed to the CPU as the original - in order that
diagnostics can be run). [It is convenient that it runs faster than the
original. ;) ].
When it comes to hardware, such as FPGA or other hardware that reproduce
machine behavior, I think the judgement is different. I would agree
with your definition #3, to call these emulations for those
implementations which pay little or no attention to the original
machine. That said, however, I tend to use the word "implementation" or
"model" here. Consider, for example, that the IBM 360 and 370
architecture, and the PDP-11 and VAX architectures were implemented by
their original manufacturers (or their competitors, e.g. Amdahl), using
very different hardware approaches - some hard wired, some micro-coded,
some mixed, for different models of the architecture.
But I can see using the term "simulation" in some cases, such as your
"BabyBaby".
But I would call IBM's P390 an "implementation" of S/390 (and S/370,
depending on which firmware you load).
With respect to your #5, I have some direct experience with that, and am
working on a tricky project to implement the IBM 1410 in a FPGA at the
gate level, based on the SMS Automated Logic Diagrams (ALD's). What I
have found so far is that a rule or two can be used to deal with the
speed and design technology differences. I don't think that the issues
pointed out make it "hard", really. The hard part, to me, is
deciphering the original design from drawings or other incomplete
engineering information. ;) The rules I have developed so far:
a. If the original implementation uses cross-connected gates (or
transistors), the FPGA model can follow those with a synchronous D
flip flop. It usually works because the clock times are often 10
or more times faster or more than the original machine clock. I
have successfully used this technique to implement an original
design that was not all that great (see "b." below for details) that
actually had some race conditions in the original design.
The information on this project can be found at:
https://drive.google.com/open?id=0B2v4WRwISEQRcFpNM0o2VDJiWFk
b. I did not come across delays in the one project I completed
this way (a re-implementation of a design done for a class in
college in 1973), but my next project will, and my plan is to use a
counter (or, I suppose, a small number of cascaded D flip flops
acting as a bucket brigade) in cases where that delay is needed for
the implementation to work properly. (In cases where the delay
exists only to match propagation times along different wire/cable
lengths in the original implementation, one might be able to turn
the delay into a wire).
JRJ