Re: idea for a universal disk interface
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, shad 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
Re: idea for a universal disk interface
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
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.us. 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 (e.g. 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 [mailto:g...@shiresoft.com] Sent: Friday, April 15, 2022 3:25 PM To: t.gard...@computer.org; cctech@classiccmp.org 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). - 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
RE: idea for a universal disk interface
-Original Message- From: Guy Sotomayor [mailto:g...@shiresoft.com] Sent: Friday, April 15, 2022 3:25 PM To: t.gard...@computer.org; cctech@classiccmp.org 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). - 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
