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
