Solid State Disk replacement for RD53, 54, RK05, RL02/02

Rob Jarratt robert.jarratt at
Thu Mar 11 16:37:59 CST 2010

> -----Original Message-----
> From: cctalk-bounces at [mailto:cctalk-
> bounces at] On Behalf Of Rob Jarratt
> Sent: 10 March 2010 21:49
> To: 'General Discussion: On-Topic and Off-Topic Posts'
> Cc: 'David Riley'
> Subject: Solid State Disk replacement for RD53, 54, RK05, RL02/02
> There was a thread recently on the comp.sys.dec newsgroup which ended
> up
> with the suggestion from David Riley that he would be prepared to build
> an
> FPGA-based board with a QBUS interface on one side and an SD interface
> on
> the other which anyone could then program to emulate any
> disk/controller
> they like. I have been in touch with him to see how much interest he
> has
> had, because he needs a minimum number of about 10 to make it viable,
> but so
> far there has only been me and one other person showing an interest.
> David
> reckons they would come to a little over $200 each (possibly less if
> there
> is more interest). David is not yet on cctalk so he agreed to let me
> cross-post this to cctalk on his behalf, but I have cc'd him so you can
> reply direct.
> Regards
> Rob

As David is currently unable to post to the list he has asked me to post the
following on his behalf:


So it seems there's at least quite a bit of discussion generated about the
board.  For those curious, here are the major design points (LONG email

- The main QBUS interface (before the buffers) will be an FPGA (Altera
Cyclone III EP3C16 at this point, for cost, but the same footprint will fit
a 3C25 or 3C40 as well).  This FPGA should be large enough to fit even
rather complex devices fairly handily (you can make a soft-core 32-bit
processor in less than 1k logic elements, and a 3C16 has 16k).  This is, of
course, assuming you build it all in the FPGA fabric; you don't have to

- The FPGA will be bolted to the bus (16-bit, of course) of a Freescale
MCF5208.  This is a ColdFire (68k architecture) which runs at 166 MHz (88
MHz external bus) and also contains a 10/100 Ethernet controller.

The controller requires an external PHY, but this is actually an advantage;
by connecting the processor's MII to both a real 10/100 PHY and the FPGA, we
can provide both RJ45 for straight-up Ethernet connections and build an
MII-to-AUI bridge in the FPGA (not a day's work, for sure, but certainly

This means you could use this as a replacement DELQA if you have a cable kit
for the external AUI connector; connect to thick/thinnet, etc.
Alternatively, you could stream hard disk/tape images from a remote file

Of course, it'll have a handful of serial consoles.  In theory, you could
make a CPU board with SLUs and all 4 MB RAM out of the FPGA, but this would
be an extensive design effort.  As to whomever asked for a clock, that
should work as well.  Anything you can do with a QBUS card can be done on
the FPGA, it's just a matter of how much work you want to put into it. :-)

I currently have 32 MB RAM and 4 MB flash slated for the processor (the
processor should read the FPGA image off the SD card).

- My vision for the basic build of the FPGA would actually be to just
provide an interrupt-based bus interface for the processor.  If the
processor defines apertures for the CSRs and uses an ISR to provide the data
for the reads and the writes, a 166MHz processor ought to be able to respond
quickly enough to make for a fairly speedy card.  If that's not enough
performance, one can always implement the device in the actual FPGA fabric
(if one is good with FPGAs, which can take a while for people who aren't
hardware designers).

Additionally, we should be able to support multiple "virtual" cards in a
single board; the only limitation is the number of apertures that will fit
nicely in the FPGA and the overhead of the software running on processor.
At least 4 should be easily achievable.  A simple DMA controller in the FPGA
would go a long way towards making the performance of mass storage
acceptable (processor DMAs into FPGA, FPGA DMAs into QBUS, or vice versa).
This means that even software-only people should be able to implement the
devices in an emulator-like fashion (without excluding the possibility of
actual FPGA implementations).

- Since the Coldfire is 68k and has excellent GCC support, it can be
programmed entirely with Free Software.  The actual hardware to program it
costs $80 standalone (more or less; depends on who's building it), but most
of that is assembly and PCB costs.  I could integrate the same hardware onto
the board for an additonal $5 or so instead.

The FPGA can be programmed entirely with Altera's free (not to be confused
with Free) Web Edition version of Quartus, but to program it you need either
a) a $75 JTAG cable to program it or b) something running on the ColdFire to
program the FPGA image (which will be the default mode on boot).  The JTAG
cable gives you the advantage of running the FPGA-based logic analyzer.

- And of course, yes, it will be a fully open architecture.  I'm using KiCAD
(FOSS) to do the schematic and layout.  Anyone should be able to make the
board if they want, but it'll be expensive for small runs.  For those of you
who think $200 each is in the stratosphere, here's my current (rough) BOM at
two different run sizes:

Part          Description         Qty        Price at 10     Price at 25
EP3C16E144C8N FPGA (EQFP-144)     1          26.70        26.70
DP83848       10/100 PHY          1          4.29         3.50
SST39VF3201   2M x 16 NOR flash   1          3.61         3.61
IS43R16160B-6 16M x 16 DDR RAM    1          6.00         5.40
EN5335QI      DC-DC converter     3          5.51(16.53)  5.41(16.23)
SN74AS641DW   Octal bus xcvr      4          4.80(19.20)  4.04(16.16)
J0026D21ENL   RJ45 w/magnetics    1          4.825        4.825
Assembly, 50 parts 1          47.00        39.80
PCB             1          72.44        36.26
Total                                        200.59       152.48

This doesn't include the scads of little resistors and capacitors and a few
other cheap parts I'd need to place, which while very cheap may drive the
cost of assembly up.  The PCB pricing is for a 5.3" x 8.4" board, 1 edge
gold fingers, 4 layers, controlled stackup (There are too many high-speed
buses on this thing to risk a 2-layer board and no controlled impedance).
Eliminating the gold fingers only brings the price down about $10.  My $200
figure was a sort of back-of-the envelope calculation (I hadn't made out a
detailed costed BOM yet).  The cost is still subject to change, and a number
of the parts (particularly the MCF5208) are long-lead (14 weeks and no stock
anywhere).  Most pricing was done at Mouser except for the components I
couldn't find there (the PHY and the FPGA, and the RJ45 was cheaper at DK),
which came from Digi-Key.

This also doesn't include the AUI transceiver buffering, which I haven't yet
worked out, and I still haven't 100% finalized the arrangement of the QBUS
buffers (as it is, I'll be using transistors for a few of them since the
signals don't all fit nicely in the mold of a '245-style transceiver like
the 74AS641).

Also, someone mentioned nonstandard thickness.  As far as I was aware, the
boards were 62 mils, but I haven't measured (and couldn't find a reference
anywhere, and don't have a micrometer).  Anyone know otherwise?

In any case, I hope this answers a number of the questions out there.  My
plan is to implement the basic FPGA hardware mentioned as well as an
implementation of the software stack for at least a few of the controller
cards I have in my possession.  The user end (serial console) of the
processor should be able to load board personalities from the SD card as
well, so setting up a repository of personalities (if others develop any)
would be the way to go there.

More information about the cctalk mailing list