9 Dec
2003
9 Dec
'03
12:46 p.m.
On Wed, 10 Dec 2003, Tony Duell wrote:
An FPGA implementation would be cheaper, easier to do, more flexible, easier
to debug (either with simulation or building debugging hardware into the
FPGA), buildable into the future, have higher performance and be more reliable
than a design made with bits-and pieces...
I have been thinking about this a lot...)
A simple RLL scheme could be used to encode longer times perhaps intersector
gaps or what not (say if we use a count of 4 bits, count value 15 means
continue the transition delay with the next nibble)
But you really dont need 2G bytes of RAM...
suitably encoded (instead of using
a wasteful bit stream, record and play back the delta-time between transitions
Alas it's not as simple as that!
There were 2 suggestions -- firstly to record the time of each
transisition as a 20 bit number (i.e. would would be the RAM address in
the simple scheme). The other is to record the time since the last
transisiton, presumably as fewer bits.
The second uses less memory _but_ suppose we use 8 bits for each time
value. What happens if there's no transition for 256 sample times? I
think that could happn at the end of a track if you're unlucky.
But both schemes have another, more serious, problem. It's hard to change
part of the data. You need to be able to re-write part of the track -- in
particular a single sector. This is trivial on the 'record-the-bitstream'
method. It's a lot harder if you're recording time values. It's not clear
just which time values you're replacing (remember this has to be worked
out in real time at abou 50-80MHz). What do you do if you replace a
sector with one with more transitions? You have to shuffle all the data
in the emulaotr's RAM down to make space for the extra transition time
codes -- again in real time.
Yes thats an issue with _any_ compression scheme, a linked list might do it
though. Remember the the delta T values are not at your 50-80 MHz, only 10 MHz
max. This means that 32 bit memory data rates would be in the 2 Mhz region...
Now, it may well be possible to compress the data in the emulator's main
memory, or on the modern hard disk, and decompress it before writing it
to the bitstream buffer. However, it's not clear how much compression
will be possible (it's obvious that, in general, not all data can be
compressed -- there are 2^n possible blocks of n bits, and you can't
replace each one with a different block of m bits (there are 2^m such
blocks) if m<n). And of course you need a sufficiently fast processor in
the emulator box to do compression and decompression 'on the fly' during
cylinder changes. Probably possible...
If you just compress your bitstream, a high compression rate is possible, at
least downto close to the original data content of the controllers data
stream (~8.5 kbytes per track?)
a $15 FPGA and a $15 Sync SRAM is just about all
thats needed + the hardware
If I had a pound for each time I've been told 'it can be done with an
FPGA' then I wouldn't be worring about designing a disk emulator. Simply
because I'd have a complete hard disk _factory_ of my own.
Of course it can be done with an FPGA, but now is not the time to say
that. Rather, you should be thinking about how to actually design the
thing (which, BTW, I am doing), and only later worry about building it.
I would not use an FPGA, though. There are several reasons for this, not
the least of which is that debugging the design is hard. I don't trust
simulators, and won't until I find one that gets all of my 'test cases'
right (most get them all wrong!. Anyway, the FPGA simuation software I
battled with couldn't even handle memory devices linked up to the FPGA,
let alone simulating a hard disk controller's bitstream as well... No,
I'd rather buiild the darn thing using standard ICs and debug it with the
logic analyser. When the design is solid, then you can consider turning
it into nn FPGA.
I have not had that much trouble with simulators, plus if there are free I/O
bits, its easy enough to built some temporary test scafolding into the FPGA. I
dont think I would like to try getting a 50-80 MHz wire wrapped system working
these days (even finding the DIP parts would be hard)
Even then, it may not be a good idea. I've learnt the hard way that if
you want a hobbyist to copy your design, you avoid programmed parts, no
matter how simple they are to program (even PICs...) And you certainly
don't get involved in providing ready-programmed parts unless you like
providing free replacements to idiots who connect the power lines
backwards...
But the FPGA is not a programmed part... only the downloaded bitsream contains
the "program" I dont worry too much about the inexpensive serial EEPROM
that stores the bitstream - they are easy to program (with nothing more than a
parallel port) and cost less than $1.50...
Then there's the issue that FPGA chips change -- all too often. The new
ones are claimed to be compatible (but 'better than the old ones'), but
I've been bitten. Admittedly I was trying to push the device to its
limits, but IIRC we had to hunt around for the old devices to have a
hope of the final design working in time....
I guess I would rather port a design to a new FPGA than have to do a complete
re-design because some particular chip becomes unavailable
-tony
Peter Wallace