PDP-10 progress
David G. Conroy
of the processor instruction diagnostics running in an emulation of
my PDP-10 design's microprocessor running real microcode.
Getting the LSB correct on the last FDVR case was really nasty!
The instruction set implemented by the current version of the microcode
is small; it's the intersection of the KA and the KL/KS, which
is sufficient to run ITS. Everything else is complete and seems to
work; interrupts, traps, paging, page fail on trap instructions, XCTR,
the microcoded console, and so on.
The hardware should be easy to design (the microprocessor
is dead simple) but I don't plan to start designing hardware until ITS
runs in the emulator.
dgc
Ken Harrenstien
David G. Conroy <d...@spies.com> wrote:
>The hardware should be easy to design (the microprocessor
>is dead simple) but I don't plan to start designing hardware until ITS
>runs in the emulator.
Just wondering, what's the plan for devices? (eg disk, tape, net)
--Ken
Neil Franklin
> my PDP-10 design's microprocessor running real microcode.
>
> The instruction set implemented by the current version of the microcode
So yours is going to be microcoded. Where/how do you store microcode?
In the FPGA (if so what FPGA for that amount of space?) or externally
(if what is the impact on pins and speed?)?
> The hardware should be easy to design (the microprocessor
> is dead simple)
So more KS than KL? Or even simpler?
--
Neil Franklin, ne...@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer
- Make your code truely free: put it into the public domain
David G. Conroy
Plan is to do the same thing I did for my pdp-8 and pdp-4 machines,
which is to use modern devices and fix the software (this isn't quite what
I did on the pdp-8; there I designed a pdp-8 compatible uart because
apps knew how it worked, especially the non-destructive read).
In some sense doing this on a -10 is easy because the software can actually
be rebuilt from sources; I can create, compile, and execute fortran
programs on my pdp-4, and all I had was binaries (and binaries for the
pdp-9/15 at that), which meant hours of reading disassembler output.
Currently the spec says ...
The console is an industry-standard UART (the spec says 16450/16550
today, and that's what the emulator emulates.
The disk is IDE. Commands are PIO, and data is either PIO or DMA. The
disk DMA channel splits each 36-bit word into 4 9-bit frames and
puts each in a 16-bit IDE data word. The DMA channel does scatter/gather
with a channel chain (in ITS all I/O is to aligned 1K blocks).
The NET interface is built with an NSC chip which stores its buffer
rings in dedicated memory. A microcode assist copies data in
and out of the packet buffers, with the 32-bits of useful data stored
in the 36-bit words in an ITS-friendly way.
To Neil:
The microcode is off chip, stored in 3 32Kx8 3.3V SRAMS. The 12ns
version of these chips cost about $1.00, and come from many
vendors (cypress, alliance, winbond, paradigm, perhaps others). Much
of the control store is empty; the basic decode is a 512 way
dispatch into slots which are big enough to handle fairly complex
instructions, and many instructions are 2 or 3 instructions in length.
The external access sets the cycle time of the microprocessor to
something in the 33MHz range, with the SDRAMS running at 66MHz. The
micropipeline is 3 stages long (fetch + 2 execute) and all
microbranches have a 1-cycle delay.
If I wanted to make the machine faster I would not work
on the cycle time; I'd build more parallelism into the instruction
fetch and decode. I did some work on this, but it got quite
hairy quite quickly (there's executing from the ACs, there's writing
into the next instruction) so I decided to punt.
There really isn't much to the hardware. I can see places
where the timing will be interesting (the address computation for the
read port of the AC ram, which has to deal with the current/previous
block stuff and do the "+1" needed for ASHC and DADD and things
like that) but nothing seems unmanageable.
Zane H. Healy
What speed to you see it being at in comparasion to real PDP-10 models?
Zane
PS I hope once you get ITS up that you also add the ability to run
TOPS-10/TOPS-20.
David G. Conroy
most of that waiting for read data from memory.
The simple design aggravates the memory latency situation;
reads are kicked off late in the pipe but read data is
needed early in the pipe, so cycles get wasted.
I actually have a section in the spec which talks about
what needed to be done to make a TOPS-20 port possible; it's mainly
writing the TOPS-20 paging microcode, and filling in the
gaps in the instruction set. This is more work than anything else,
and the micromachine is easy to program; the microcode is
highly vertical, so it's like writing assembly language for
a somewhat weird general purpose computer. There's lots of space
in the control store and enough space in the scratchpad
for the various bases and things.
dgc
----------
In article <afqhh...@enews2.newsguy.com>, "Zane H. Healy"
Zane H. Healy
> I actually have a section in the spec which talks about
> what needed to be done to make a TOPS-20 port possible; it's mainly
> writing the TOPS-20 paging microcode, and filling in the
> gaps in the instruction set. This is more work than anything else,
Out of curiosity, have you put the spec online anywhere? I checked your
website and only see the the PDP-4/X and PDP-8/X pages. The spec sounds
like it might be an interesting read.
Zane
David G. Conroy
It's in a "me only" state right now, and it doesn't
describe the micromachine at all (that is only in my design notes and a
very cryptic include file shared by the simulator and the assembler).
----------
In article <afr7b...@enews3.newsguy.com>, "Zane H. Healy"