8 Jun
2010
8 Jun
'10
1:08 p.m.
On 6/8/2010 8:13 AM, Philipp Hachtmann wrote:
Xilinx
Spartan-3e board? Nice toy! A pdp8 fits several times...
Currently my PDP-8e compatible design on an Altera CycloneII EP2C20
takes about 9% of the total available resources (using internal block
ram for the first 4Kx12 memory; pages 1-7 use the external on-board
SRAM). So there is lots of logic left to implement peripherals.
I have the RX8e/RX01 controller passing the DIRXA diagnostic now, and am
in the processing of implementing the backing store on the SD card, so
hopefully in the next few weeks I'll get to boot an OS8 image from a
floppy image.
My PDP8e design runs at a basic 145MHz clock tick (this is a 4Kx12
config only, no external SRAM), and there are four clock ticks per
instruction state (thus about 27.5ns for a major state duration).
However, to get the memory expanded to the full 32Kx12, I use the 10ns
external SRAM, and slow the clock down to 80MHz (12.5ns) per tick. SIMH
still runs quite a bit faster, however (by 2X or more).
For the PDP8 architecture, SIMH on a fast CPU will probably always be
faster than a 'simple' FPGA state machine emulation of the architecture.
To make the inherently slower FPGA be able to outspeed a much faster
CPU, one would have to go to a much more parallel implementation (ie, a
pipelined/superscalar PDP8 design) that is able to make up for the lack
of raw FPGA lock speed. Such a PDP8 design is probably going to be very
difficult, as the nature of the PDP-8 architecture is not very amenable
to either pipelining or superscalar execution. It would certainly be a
'fun' project to consider, but my suspicion is that after implementation
one would find so many bubbles/wait states get inserted into the pipe to
make the instructions execute correctly there would not be much speed
advantage gained. It would certainly be an interesting design study,
however.
Don
PS: BTW for those ever considering implementing an RX floppy interface
for the PDP8 and want to run diagnostics, I did find a coding error in
the DIRXA (both rev C and D) diagnostics. In one specific test the XDR
IOT is being issued before checking for transfer request via the XTR
IOT. There is a simple patch to the diagnostic to fix it. Turns out it
runs OK on real hardware because the speed difference of a real PDP8e vs
a real RX01/2 controller, but if you speed up the RX controller past a
certain point the test will always fail.
The
flip-flops may be driven by the external clock input, but often
this
is not the case. Almost all modern FPGAs contain either PLL or DLL
blocks that can be used to synthesize other clock frequencies from the
external input.
Right. I've used Xilinx's DCMs before. They are pretty simple and
provide a wide range of output frequencies. My eval board has a
single SMA connector on it for high frequency connections. The forty
free I/O pins use a hirose FX2 connector, not sure what the highest
frequency is available there. I wouldn't think even to 100mhz? Despite
looking at the datasheet this morning, I have no idea what
the maximum frequency of my Spartan-3E XC3S500E-4FG320C, speed grade
-4 is. I've fed the coregen DDR controller at 100mhz before, but
never used anything faster.
I assume that you could reach about 150 MHz with very
good design or
very limited functionality. I have not yet fully understood the timing
constraints you pass to the Xilinx tools. It could speed things up if
you exclude some unimportant paths like wires going to LEDs on a pdp8
implementation. I assume that IO cells in timing paths add a lot
bigger delay than simple logic...