It's not really fast enough and you'll get into all sorts of complications once you start to think about trying to keep up with simulation rotations.  For example, if someone starts a read at half way through a rotation (e.g. after the index pulse) now you have to have logic/code that can start/stop the transfer in random places.  The way that I have it designed, it's all sequential so no random start / lengths and it's all done during a seek which the data isn't being clocked out.

The Zynq-7020 (which is my low end design) has 4.9Mb of block RAM (in 140 36Kb blocks).  In the cylinders I actually use 9-bits per byte as I need an escape in order to encode some other data.  ;-) With that it can hold the 512KB needed with some to spare.  My high end design will use the Zynq-Ultrascale+ (ZU3CG) has 7.6Mb of block RAM (in 216 36Kb blocks).  If I go to the next higher version (ZU4CG)the block RAM goes down to 4.5Kb (in 128 36Kb blocks) but gains 13.5Mb in "UltraRAM" which should allow for any reasonable cylinder buffering.

Of course, I'm just describing my design and design requirements.  First and foremost I wanted a simple HW & SW design that could provide accurate drive timings (e.g. I could faithfully reproduce the timings of any particular drive) so as to maximize the compatibility with any controller (and I have some weird ones).

I've been pouring over ANSI specs, controller specs and drive specs for SMD/ESDI for a few years now and have thought about a number of different ways to do this and what I've described is what I've come up with.

You may have different goals which may drive you to make different choices/decisions.

TTFN - Guy

On 4/19/22 11:49, shadoooo via cctalk wrote:
Guy,
I understand that cylinder command has no particular timing requirements, while 
head command must be effective within microseconds. My doubt is, RAM access on 
high performance port could be fast enough to satisfy also the latter.
In case it couldn't or was not assured, I think the best strategy could be to 
preload only a small block of data for each head, for prompt start on head 
command; enough to manage safely RAM access latency.
Each block also would work as buffer for data of subsequent RAM accesses, until 
whole cylinder had been processed.
This strategy would remove the strict requirement of blockram capacity for the 
Zynq, and given that bigger models cost a lot, it would be a significant spare 
for anybody.
Furthermore,  support for any hypotetical disk with bigger cylinder (not SMD) or for tape 
with very large blocks or "infinite" streams could not be feasible with the 
whole cylinder design. I would prefer to avoid any such limitation, in way to possibly 
reuse the same data transfer modules for any media.

Andrea

--
TTFN - Guy

Reply via email to