Actually I am talking about emulating the bit stream, index to index - RLL 
encoded and containing gaps, marks, headers, data, CRC, ECC, etc.  Exactly as 
the bit stream would come out of a theoretical disk drive, no bit shift, no 
write splices, no instantaneous speed variation, no long term speed variation.  
That means the controller will have a very easy time of it.

My point is the ESDI/SME bit stream is 15 Mb/sec or lower and the others are 
lower still while any modern memory can transfer in the Gb/sec range so the 
track will arrive at the emulator hardware at much higher rate than the 
controller can absorb and since the track is coming from memory there is 
negligible latency.

You seem to assume that the transfer out of the emulator can't start until the 
entire track is in the emulator - that's not what I am saying.  To use your 
example, sure it takes 65us to transfer the entire track out of memory but it 
takes 16.67 msec to transfer it out of the emulator.   I suggest transfer out 
of the emulator hardware can start with the first word into it.


-----Original Message-----
From: Guy Sotomayor [] 
Sent: Saturday, April 16, 2022 5:14 PM
Subject: Re: idea for a universal disk interface

I think the issue is that you're thinking of somehow emulating the formatted 
data.  I'm working on just emulating the bit-stream as then it'll work with any 
controller and sector/track layout so I won't actually know what a sector 
really is (unless I do "hard sectoring" 
which some drives did support).

At a 15Mhz clock rate, 30 bytes is 1.3333us.  Not a lot of time. And frankly, 
that's defined by the controller and not the drive (though usually the drives 
specify some layout but that's only a recommendation).  Dealing with drive 
speed variations doesn't solve anything because it's actually done via the 
drive itself (e.g. the drive provides the clock to the controller so any 
variation is already accounted for).  The drive really cares about total bits 
bits-per-inch) that the media supports.

If we assume 32KB track at 500MB/s DMA transfer rate, that takes 65us.  But as 
I've said, the spec says that the time between a head select and read is 15us 
or so, you can see that you can't just transfer a track and still meet the 
minimum timings.  I will agree that you can probably take longer but I'm trying 
to have a design that can meet all of the minimum timings so I can emulate any 
drive/controller combination with at least the same performance as a real drive 
(and in many cases I can provide
*much* higher performance).

By keeping a full cylinder in the FPGA Block RAM I can keep the head select 
time < 1us (it's basically just selecting the high order address bits going to 
the block RAM).

By keeping the entire disk image in DRAM, I can emulate any drive (that fits in 
the DRAM) with identical (or faster) performance. If I wanted to do something 
simpler (not much though) I could have a smaller DRAM (but since the Zynq 
modules I'm using have 1GB or 4GB of DRAM there isn't much motivation) but then 
any seek would be limited by access to the backing store.  Also remember, in 
the worst case you have to write the previous track out if it was written to so 
that will slow things down as well.  With the full image maintained in DRAM, 
any writes can be performed in a lazy manner in the background so that won't 
impact the performance of the emulated drive.

TTFN - Guy

On 4/16/22 14:32, Tom Gardner wrote:
> -----Original Message-----
> From: Guy Sotomayor []
> Sent: Friday, April 15, 2022 3:25 PM
> To:;
> Subject: Re: idea for a universal disk interface
> I'm looking at what the spec says.  ;-)  The read command delay from the head 
> set command is 15us (so I was wrong) but still not a lot of time (that is 
> after a head set, a read command must be at least 15us later).
> <snip>
> -----
> And after the read command is given there is a gap, usually all zeros, at the 
> end of which is a sync byte which is then followed by the first good data (or 
> header) byte.  In SMD the gaps can be  20 or 30 bytes long so there is quite 
> a bit of time until good data.
> Tom
TTFN - Guy

Reply via email to