idea for a universal disk interface

[Guy Sotomayor]

I have proceeded as far as full block diagrams (still have to write all 
of the verilog) and basic SW architecture.  This is why I've had this 
discussion.  I've thought about this *a lot* and have gone through 
several iterations of what will or will not work given timing constraints.

I have all of the components for putting a prototype together but I just 
haven't had the time yet to write the verilog, the Linux device driver 
and the "personality board".  That is, there is still a lot to do.  ;-)

Some requirements that I've put on my design:

  * straight forward SW architecture
  * SW is *not* time critical (that is I didn't want SW in the critical
    path of keeping the data stream)
  * Must be able to emulate any SMD/ESDI drive
  * Must be able to match performance of the drive (or better)
  * Must be able to work with any controller (ESDI or SMD...depending
    upon interface)

With those in mind, that's how I came up with my design.

I found that the Zynq has sufficient Block RAM to contain a full 
cylinder of 512KB.  I'm keeping a full cylinder because that allows 
everything to be done in verilog except for seeks (see SW not being 
required to be in the critical path).  If I didn't do that, then SW 
would have to be involved in some aspects of head switch, etc and those 
can have tight (<< 100us) latencies and I just didn't want to try and 
get Linux to handle that.  Yes, I could use some form of RTOS (I'm 
actually in the middle of writing one...but that's still a ways away) 
but I don't see any that are really up to what I need/want to do for 
this project.

BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB 
of DRAM.  However, I'm also planning on a "bigger/better" one based upon 
the Zynq Ultrascale+ which has 4GB of DRAM so that I can support 
multiple/larger drives.

The amount required by Linux doesn't have to be large...I plan on having 
the KMD just allocate a really big buffer (e.g. sufficient for 
containing the entire drive image).  Linux will run happily in 
128MB-256MB since there won't be any GUI.  It could be significantly 
less if I were to strip out everything that isn't needed by the kernel 
and only have a basic shell for booting/debug.  My plan is to have the 
emulated drive data and the configuration file on the SD card...so 
there's no real user interaction necessary (and Linux would not be on 
the SD card but on the embedded flash on the Zynq module).

TTFN - Guy

On 4/17/22 10:28, shadoooo via cctech wrote:
> hello,
> there's much discussion about the right  method to transfer data in and out.
> Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB.
> About logic implementation, we know that the device must be able to work with one cylinder at a time. Given RAM bandwidth, this doesn't means that it must fit completely in blockram, also it can be produced at output while it is read, so delay time is really the time between first data request and actual read response. In between an elastic FIFO is required to adapt synchronous constant rate transfer of the disk to the burst transfer toward RAM.
>
> Guy, you mentioned about development of a similar interface.
> So you already produced some working hardware?
>
> Andrea
>
-- 
TTFN - Guy