> On Jul 12, 2016, at 6:00 AM, Paul Birkel <[email protected]> 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:[email protected]] 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 <[email protected]> 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
