IBM 360/30 in verilog
Ian S. King
isking at uw.edu
Tue Jul 12 09:54:15 CDT 2016
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:
> > _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.
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."
More information about the cctalk