BUT: It
currently runs Chekmo at 100 Mhz!!!
Very cool!
Yes, that's nice.
There are some
severe synthesis warnings I simply ignored. Will investigate in the process of further
debugging the stuff.
Heh, it seems impossible to deal with the hundreds of warnings to figure out which, if
any, are important.
Oh, I have written "severe" - like not met (and
ignored) timing and a
strange "combinatorial loop" involving the not yet tried out and
debugged data break port.
Yes, the tools tell you too much... Sometimes I wish I could turn off
all the 599 unimportant warnings of 600...
A 100Mhz
Chekmo is a big step forward. And all that on a Spartan-3. On a Virtex-2 or -4 FPGA this
would become even faster.
Hmm...I don't share your need for speed :-) . I am more worried about being able to
interface with new and old external gear.
My TTY for example behaves like the original one and is connected via a
kind of SOC OMNIBUS. It would be no problem (but some work, of course!)
to write a module that attaches this to a real OMNIBUS (must generate
timing pulses etc).
Here the entity declaration of my teletype interface, just to give you
an imagination:
entity pdp8_tty is
generic (
tti_address : std_logic_vector(0 to 5) := "000011";
tto_address : std_logic_vector(0 to 5) := "000100";
clkfreq : integer := 75000000;
baud_rate : integer := 9600
);
port (
clk : in std_logic;
reset_n : in std_logic;
-- I/O interface
io_addr : in std_logic_vector(3 to 8);
io_wdata : in std_logic_vector(0 to 11);
io_rdata : out std_logic_vector(0 to 11);
io_wait : out std_logic;
io_active : in std_logic;
io_opcode : in std_logic_vector(9 to 11); -- Command code from instruction
io_cycle : in std_logic; -- IO signal qualifier!
io_cmd_ac_clear : out std_logic;
io_cmd_ac_or : out std_logic;
io_cmd_pc_load_abs : out std_logic;
io_cmd_pc_load_rel : out std_logic;
io_cmd_skip : out std_logic;
-- Interrupt line
io_interrupt : out std_logic;
-- Data break interface
break_cycle : in std_logic; -- IO signal qualifier!
break_address : out std_logic_vector(0 to 11);
break_ema : out std_logic_vector(0 to 2);
break_wdata : out std_logic_vector(0 to 11);
break_rdata : in std_logic_vector(0 to 11);
break_write : out std_logic;
break_request : out std_logic;
break_done : in std_logic;
-- Data Lines
tty_rxd : in std_logic;
tty_txd : out std_logic := '1';
-- Hardware Handshake lines
tty_go_out : out std_logic;
tty_go_in : in std_logic);
end pdp8_tty;
The break interface is not used by the TTY. I included it just for
completeness... The wires end open.
And there's no CLF line yet....
If multiple IO devices are to be connected, the IN lines (to the CPU)
must be OR'ed together.
When my project is in a usable state, I would like to put it on
opencores.org.
We have Hans' PDP-8 code from a few years ago, and
John Kent did some
nice work a year or so ago with us to clean up the build and to port to
the XESS FPGA card.
VHDL or Verilog code?
The code that Henk and I are using is derived from
this code base. We
haven't been able to reach Hans to get permission to redistribute, so
there are just the three of us with the code (four, if you count Hans),
as far as I know.
Ok, Hans is not reachable anymore? What a pity....
I've got the code running FOCAL and other stuff in
John's configuration,
and the 8/i front panel is pretty much working in that configuration.
How is it
attached? Shift registers?
There is currently a regression that broke the IOTs
that FOCAL needs, so
the more cool code examples don't work at the moment.
Hm... Which IOTs?
I will implement all basic 8/e functionality.
Because the state lights (Fetch, Defer, Execute, WC,
CA, Break, Pause)
don't map well to Hans' machine states,
Oh, yes... I have slightly
different states, too: decode, defer,
auto-index, io, break, fetch-exec.
But a reasonable mapping should be possible.
Cycle true MD would be a bit more complicated...
and (more importantly) because
we don't feel we can redistribute his code,
Sure, that he cannot be reached?
I have recently started to
implement a "direct coding" of the 8/i schematics in VHDL. That will
hopefully give a "clock accurate" implementation of the 8/i.
What a
task!!!
If you try the real thing, you will get lots of angry warnings about
flip flop clock input abuse! DEC used the D-flip flops with preset and
clear in a (today) very uncommon way....!
So far
that's a bit experimental -- I haven't interfaced the memory or finished
the timing generator, nor written the memory extension and timeshare
code yet. Then again, I just started a couple of days ago :-).
Oh, I haven't
built time-share and memory expansion yet, too. Only
partially implemented. But will be completely available.
What's the
current state of pdp-8 implementations on FPGA?
I'm sure there are other implementations out there. Maybe some more
will come out of the woodwork :-).
There must be a lot of other PDP-8 implementations... But nothing well
organized...
Best wishes,
Philipp :-)
--
http://www.hachti.de