IBM 360/30 in verilog

[Paul Koning]

> 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