On Jul 12, 2016, at 6:00 AM, Paul Birkel <pbirkel
at gmail.com> wrote:
Principles of Operation, I believe. Example:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/princOps/A22-6821-0
_360PrincOps.pdf
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at
classiccmp.org] On Behalf Of Curious
Marc
Sent: Tuesday, July 12, 2016 5:04 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: IBM 360/30 in verilog
What's a POP? As long as it emulates all the registers connected to light
and switches that might do for me, but I was assuming these would very
specific to the CPU detailed innards.
Marc
> On Jul 12, 2016, at 5:14 PM, Dave Wade <dave.g4ugm at gmail.com> wrote:
>
> It actually might be easier to produce a generic S/360 clone in FPGA
> using the POP rather than individual ALU's.
> Having built a very simple CPU (in VHDL not Verilog) and planning to
> start on a more complex (Ferranti Pegasus) Of course it wouldn't be
> cycle accurate, but perhaps that wouldn't be important.
It depends on what you're trying to emulate. If you want an instruction level
simulator, sort of a SIMH in silicon, then going from the POP or analogous documents
(processor reference manuals, computer family architecture manuals such as DEC published
for the PDP-11 and VAX) will do nicely. Such an approach is not going to show you the
peculiarities of a particular implementation, details too deep for the sort of
documentation you're using, let alone implementation bugs.
By way of analogy, if you build a CDC 6000 emulation using that approach, it won't do
the "zero written to memory at PC at deadstart time" property, because that is
nowhere documented or explained in any printed document I have ever seen. But it's
part of the unwritten lore of that machine. If you build a gate level model from the
engineering drawings, you can see it clearly (and you can readily discover its cause).
Building an accurate model from a POP requires a great deal of intellectual effort, to
understand all the critical details sufficiently to model them in behavioral models. You
can perhaps lift them from existing software emulators (SIMH, Hercules) and get
"close enough". Debugging would be hard, especially if the documentation
isn't quite accurate enough to allow all the diagnostics to pass.
A gate level model constructed from the engineering drawings is more cumbersome in certain
ways, almost certainly less efficient in FPGA resources -- but it's much more a
mechanical process. If the drawings are accurate (that's an "if" indeed),
then the model will be accurate. The diagnostics should pass without major effort,
serving more as confirmation tools than as debugging aids.
paul