IBM 360/30 in verilog

[Ian S. King]

It is my understanding - from conversations with numerous IBM engineers and
retirees - that ALDs are 'as-built' documents related to a particular
machine and were indeed kept with the machine at the customer site.
Otherwise, the poor CE would have to haul around a rack of ALDs for each
machine being serviced!  It's easy to underestimate the physical bulk of
these documents when printed and in binders.  -- Ian

On Tue, Jul 12, 2016 at 7:30 AM, Paul Koning <paulkoning at comcast.net> wrote:

>
> > 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
>
>
>


-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School <http://ischool.uw.edu>
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org>
Value Sensitive Design Research Lab <http://vsdesign.org>

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."