[cctalk] Re: SMD/ESDI emulator progress report

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