idea for a universal disk interface

[shadoooo]

Guy,
I agree on keeping Linux out of the loop, to allow fast access on head location, selection.
However, I'm not convinced on the fact that a whole cylinder must be on blockram to achieve this. Given that ram access is fast (on Zynq with PL working at 200MHz and HP port at 64bits I'm running at around 1200MB/s peak), logic can jump across the whole disk without the software intervention, it's just a matter of being able to calculate conversion from CHS to address and read with sufficient buffer.
Probably using Xilinx IP cores could be a severe limit, as these are really full of bugs and inefficient implementations... but are free, so you can't argue.

On software side, given that you can go also slow, there's no need for very complex driver development, just an user level UIO driver could make do.
About language, I know very well VHDL, and it's a little bit at higher level than Verilog, so development with implementation parameters is maybe a little easier.

About interfaces which doesn't have separated clock recovery: these need a sort of oversampling, but you don't need to store every sample, just the ones with state change. Leveraging on IOSERDES you can work at a multiple of internal clock.

Please keep in consideration that the idea is to develop a single device that can work both as drive and as interface, so implementation should be reversible.
Probably this is not very difficult to obtain, as fast data paths for read and write are already in opposite directions.

Andrea

> 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).
>
>
> I chose ESDI and SMD fundamentally because the interface is 100% digital
> (e.g. the data/clock separator is in the drive itself). So I don't need
> to do any oversampling.