14 Mar
2024
14 Mar
'24
6:33 a.m.
Hi,
I just wanted to provide a bit of a progress report on the SMD/ESDI
emulator project.
Now that I'm retired I have a bit more time to actually work on it.
Previously I was just doing a bunch of research and writing notes on the
design. I now have a solid design and I'm starting with the implementation.
I'm going to list some of the design goals and then sketch out a few of
the major issues and how they're being addressed.
Goals:
* Emulate any drive geometry
* Emulate a drive's performance characteristics
* Work across different interface types
* Fully built emulator cost below $500
Major Issues:
* SMD/ESDI have head switch times < 10 microseconds (basically the
time it takes for the read amplifiers to settle on a "real" drive).
Solving this issue drives the majority of the design
* Address marks on a "real" drive are implemented by writing a DC
signal on the track and the read circuitry detects that and
generates the address mark signal
When looking at the specifications for SMD and ESDI disks there aren't
really a lot of difference in how the drive behaves. The interfaces
differ in detail but in reality the differences are pretty minor. So
the current design should allow for 95+% code sharing between SMD and
ESDI emulators.
To solve the head switch performance, it is necessary to have an entire
cylinder in some sort of RAM. This allows for very fast head switch
times (e.g. the selected head just addresses a particular portion of the
RAM). However, this means that loading a cylinder (which in some cases
could be as much as 1MB) could take considerable time. It will take
even longer if some of the tracks in the cylinder are "dirty" due to
them having being written to prior to the seek.
Since I want the emulator to be able to faithfully emulate drives in all
respects, the limiting factor is the cylinder-to-cylinder seek time
(e.g. moving from one cylinder to another cylinder that is adjacent).
This is typically in the 4-8ms range. So doing the math, one must move
1MB in 4ms (that turns out to be ~250MB/sec of bandwidth...using 32-bit
transfers, this means over 60M transfers/sec).
The above implies that the cylinder RAM and where the storage holding
the cylinders of the image must be capable of at least 60M transfers/sec
between them. This is going to involve a complex FPGA that is able to
have large internal RAMs and a direct connection to some sort of DRAM to
hold the full image. I've chosen to use a SOM (System-On-Module)
version of the Xilinx Zynq 7020. This has dual 32-bit ARM cores (plus a
whole bunch of peripherals), 32-bit DDR3 memory interface, plus a fairly
large FPGA with enough block RAM to contain the maximum cylinder. The
calculations I've done should allow a new cylinder to be loaded from
DRAM into the cylinder RAM in 4-8ms (I think with a few tricks I can
keep it in the lower range).
I've looked a quite a few Zynq SOMs (and have acquired quite a few for
evaluation purposes). I finally found one that's ~$200 (most of the
others are in the $400-$1000+ range). This SOM brings out most of the
Zynq's I/Os (94 I/Os) in addition to having ethernet, USB, serial, SD
card, etc. as well as 1GB of 32-bit DDR3 DRAM. It also runs Linux which
means that developing the SW is fairly straight forward.
The next issue was how to emulate address marks. The emulated drive
will have a bit clock which is necessary for clocking out the data when
reading (or out when writing). The bit clock is always running (just
like a "real" drive when spinning). That will drive a counter (which
represents which bit is under the emulated "head"), that counter (along
with the head number) will be used to address the block RAM. The
counter is always running, so as to emulate the spinning disk. The
address marks are emulated by having a series of comparators (one for
each possible sector). They compare the bit counter with the value
associated with the comparator, if there's a match then that signals an
address mark. It's bit more complicated because writing address marks
(in the case of soft-sectors) has to be dealt with.
The emulator is composed of 4 major components:
1. Emulator application plus some utilities
I'm currently writing all of this code...since I'd been a SW
engineer for 50+ years, this is all "production" quality code and is
extremely well documented...still a ways to go.
2. Linux device driver which provides the interface between the
emulator application and the emulator HW
I haven't started on the driver yet but it should be fairly straight
forward as it really only provides an interface to the emulator HW
to the emulator application
3. Emulator HW RTL
I haven't started on this other than to do some basic blocks of
what's here. It mainly is the cylinder RAM, serdes (I *may* be able
to finesse this by having 32-bits on the AXI bus and 1 bit on the
interface side...a nice feature of the block RAM), address mark
logic, bit counter and some command decode/handling (it'll handle
the seek command all in the RTL...everything else will be handled by
the application.
4. Interface board
This should be a fairly simple board. It's a carrier for the SOM,
3.3v-to-5v level shifters, interface circuits for SMD or ESDI (they
use different interface ICs) and the interface to the cable.
I'm starting with SMD just to make the board layout easier (I can just
use 0.1" headers for interface cabling). I also have an SMD disk
exerciser that will make it easier to make sure it's working properly.
The idea is that once I have an SMD working reasonably well, I'll start
on ESDI.
Interacting with the emulator application can be any of the following:
* config file: indicates various emulator startup options including
which image (if any) to "mount" initially
* command line: same as the config file
* emulator utilities: these are mainly allow for changing which image
is mounted, changing write protect status, querying state of
emulator, etc. The utilities can be used locally by logging into to
Linux running on the Zynq 7020 or by using "host" versions if the
emulator is connected to a network via ethernet.
One of the key utilities is creating an "empty" (that is all tracks
contain all 0's) image. The image format has been finalized. It allows
for almost any geometry of disk (up to 32 heads and up to 65536
cylinders). The main restriction is the 1GB of DRAM on the Zynq 7020
SOM. I expect in reality that the largest drive that can be emulated
will be ~600-700MB due to DRAM.
I plan on providing some standardized "templates" (e.g. they'll describe
actual drive geometries and seek performance tables) so creating new
images won't be too onerous.
I'll be putting all of the source, RTL and board files on github under a
BSD license once I get further along.
--
TTFN - Guy