From: "Brad Parker": Wednesday, October 20, 2010 4:11 AM
On 10/19/2010 12:05 AM, Vincent Slyngstad wrote:
Yes, I was aware of your work. Yours is up and
running, where mine is a
ways away,
yet :-).
but your approach is aesthetically pleasing. I like it a lot.
Thanks! I'm hoping it continues to go well and will eventually work on
real hardware.
But I wonder how much of the 8/I design depends on
gate delays. From my
read of the schematics,
which I admit has been only cursory, there seemed to be a lot of "pulse
logic", which I worry about
in an FPGA. You should be able to simulate it, but it may be interesting
to see how that synthesizes.
I'm modeling the timing chains with shift registers for the delay lines,
with the shift registers driven synchronously by a master clock. The
toolset seems happy with that. The 8/I design is mostly set up with
TS[1234] being ended with TP[1234], so that the combinatorial logic
can settle before rising TPn triggers the latches. The FPGA tools seem
happy with all that.
Theoretically, it would be best to extract all the "clock-and"s from the
design, and put all the clock preconditions on the CE, rather than C
inputs to the latches (to minimize clock skew). I haven't done that, as
it would distort the relationship between the schematic and the Verilog
code quite a bit. My hope is that since the original design didn't need
it, that the FPGA version won't either.
There is one combinatorial loop in the design. Adder_l_ (the new value
for the link) depends on some stuff in the EAE, which in turn depends
on adder_l_. So I'm not sure what happens to link for certain operands
of the DIV instruction.
Other than that, what's done so far are the detailed Eagle schematics of
the 8/I backplane, some Perl to convert the netlist, pinlist, and partlist
to
Verilog, and the resultant Verilog, which compiles cleanly for synthesis.
There are several warnings about signals that are equivalent (bmb00_ and
mcbmb00_ are two copies of the same thing, for fanout). There are
also a couple of warnings about x_axis and y_axis, since there are no
D-A resources available internal to the FPGA to drive those (VC8I), and
a warning about latch inference for pwr_low_ (latch inference is the
intended result).
Next up, I am looking at issues with the pin-out, but if I multiplex the
front panel lights and also the switches, that should drop 90+ pins
from the pin-out, The plan is to add a hand-written
"top level", which
hooks up the MM8I emulation (block ram, already done),
and the various
"external" connections from the 8/I CPU core to the actual I/O
resources of the FPGA board.
I think I might have an RF08 VPI model if you want
one. It's simple but
it might give you a leg up.
Cool. I haven't used VPI before, but having a look couldn't hurt :-).
(I still like the idea of a big PCB with lots of TTL
which functions an
8/I. I'd buy one :-)
Hmm. I might choose the 8/L for something like that. Possibly soup
up the memory to 32K, but leave out all the option cruft of the 8/I
backplane. Otherwise you'd be looking at a mighty big board!
(I calculate about 4 feet on a side, to naively fold an 8/I backplane
flat.) Then again, the ratio of the 8/I to 8/L backplane sizes is about
2.5 to 1, so the board width (for a square board) would only be
about 1.6 to 1.
Vince