North-Holland Microprocessing and Microprogramming 13 (1984) 331-339
331
An Example of Microprocessor's Application in Minicomputer Systems: A Copy Volume Design and Implementation Mauro Brusamolino Honeywell, Via Olivetti 2, Pregnana Milano, Italy
Luisa Reina Etnoteam, Via Staro 4, Milano, Italy
Massimo F. Spalla SGS-Ates Componenti Elettronici SpA, Via C. Ofivetti 2, 20041 Agrate Brianza, Italy
This paper deals with the management of a mass storage unit in a minicomputer system. The memory unit is constituted of two devices, each one containing two hard disks. The mass storage controller (based on an Intel 8086 microprocessor) is described first, considering both hardware and software aspects. Then the structure of the memory medium is shown, with emphasis on the main capability offered by this kind of hard disk. Finally the COPY VOLUME program is presented. The purpose of this program is to copy the content of one disk to another one fully. The main features of this program and the error management during I/O operations on the disks are also described. Particular emphasis is on the operations performed by the program to correctly execute the COPY VOLUME function.
Keywords: Direct Memory Access (DMA), Mass Storage Unit, In Circuit Emulator, Hard Disks.
1. I n t r o d u c t i o n
Management of mass-storage in data processing systems is increasingly performed by dedicated intelligent subsystems, implementing even fairly advanced functions and thus delivering the control computing unit from periphery-related actions. This is the case also in relatively small machines, typically in mini-computers. The present paper refers to one such example, in which a microprocessor controls data transfers between mass storage and a central processor. In this case, mass storage consists of a dual device, i.e. a removable cartridge and a fixed disk, each with dif-
ferent physical characteristics. The controlling microprocessor implements also the so-called " c o p y - v o l u m e " function, allowing total data transfers between these two devices. After a brief description of the controller hardware, the software package will be described with particular attention to original functions and to implementation philosophy. In particular, emphasis will be placed on the optimization method with the aim of achieving high speed thus possibly reducing disk access latencies.
2. Peripheral
Hardware
The overall system architecture is presented in Fig. 1. The central processing unit of the minicomputer oversees a number of intelligent peripheral controllers e.g.: - Disk, Diskette Controller - Work Station Controller - Dual Line Communication Controller - Main Memory Controller The disk controller, of particular interest here, is schematized in Fig. 2. A central microprocessor (Intel 8086) controls disk access [1]. Its memory is organized as follows (Fig. 3): - page 0: private controller's memory - page 1: public memory to controller and central processor. In turn (Fig. 4), page 0 is so divided: - work RAM memory - program memory (EPROM) - a RAM buffer - a scratch-pad register bank. The program memory co.ntains only the start-up procedure: all other 8086 programs are in massstorage, and the start-up procedure loads programs to be executed into work RAM memory. Communications with the disk are achieved through DMA access to the RAM buffer [2]. Necessity of
332
M. Brusamolino et al. / Copy Volume Design and Implementation
Minicomputer 's CPU
IT~SS
storage controller
~work ~ station controller ~
dual line ~ ~ 4 1 communication controller MODe42 controller
Fig. 1. System Architecture.
very high-speed transfers for control information led to introduction o f the scratch-pad memory. Information transfer between this m e m o r y area and the disk hardware involves: addresses of data on the disk selection of the wanted device. Recording errors are detected by a high-speed special processor performing Error Detection and Correction (EDAC) [3] and CRC analysis on data read from the disk. The E D A C analysis is based upon a particular kind of code, able to detect and correct up to eleven wrong bits in the considered data stream. The particular functions of the peripheral controller here described are better understood by briefly examining the characteristics of the peripheral itself, i.e. the L A R K disk. It consists of two parts: a removable cartridge - a fixed disk. -
-
-
All recording media have two faces, so that in each Lark unit there are four different heads. In the implementation here described the controller can drive two Lark units, using two different channel numbers identifiers (Fig. 5). Each data sector is then identified by the controller by means of: - channel number - head number - track number - sector number. The Lark unit uses a new technique for correctly driving the head on the tracks. In this medium we have no servo tracks (like in conventional disks), but small servo fields are distributed a m o n g the data sectors. Due to the dimensions of data fields it is assured that the head will be correctly driven on the data (Fig. 6).
M. Brusamolino et aL / Copy Volume Design and Implementation
333
interface to CPU
8086
error manage~nent
R/W
I
buffer
I
Fig. 2. Disk Controller Scheme.
3. Software Organization The minicomputer system software is organized on two levels, a higher and a lower. The higher level software is resident on the central processor of the machine. Actually, it provides the operating system kernel (referred to Honeywell's 6th level standard) performing such basic action as multitasking, real time processing etc. [5]. By the "lower level software" we denote the disk
controller management software. The basic features of the lower level software are: 1) control of the exchange of the information (both data and controls) with the central processor 2) management of the mechanical operations on the disks 3) managements of the interrupts from the disks 4) handling of the I/O data-transfers with the disks.
334
M. Brusamolino et al. / Copy Volume Design and Implementation
~'~'~'1"~ page I 80000h page 0 O0000h
Fig. 3. 8086 Memory Organization.
The exchange of informations with the CPU consists of three parts: data transfers (bidirectional) control transfers (bidirectional) - command transfers (bidirectional). The exchange o f data t o / f r o m mass storage is performed via a block of RAM memory shared between controller and CPU (actually page 1 of the 8086 address space). Correct access to this page is guaranteed by dedicated circuitry. As for the exchange of control information, the communication path is via mailboxes (Fig. 7). The memory area dedicated to this function is a particular fixed subset of page 1. There are three -
-
General
mailboxes, each one dedicated to one mass storage unit (Fig. 8). The command area in Fig. 8 is a register that specifies the mailbox to be used. This register contains a busy bit signalling if a command is pending. Both CPU and 8086 are polling, at fixed times, this register, until the b i t is seen set. The register also addresses the mailbox containing complete description of the command to be executed. The lower level software is capable of driving movements on media, e.g. seek or recalibrate or head selection operations. The lower level software verifies also if the particular operation is executed correctly. When interrupts from Lark are received, the low level software is able to test the diagnostic status of the medium. Data transfers between controller and disk, based upon a service area in page 0 of 8086
l
purl~se RAM I Lark unit 1 program ra~-r~ry
I/O buffer
channel 1
I@ ®I
disk controller Lark unit 2
scratch-pad registers
Fig. 4. More Particular 8086 Memory description.
channel 2
I@ @I
Fig. 5. Lark Visibility From Controller.
M. Brusamolino et aL / Copy Volume Design and Implementation
Conventional disk
I
Lark disk
= SERVO = DATA
Fig, 6. Lark Technique for Head Driving.
memory, are executed in DMA to ensure synchronization between medium and 8086 (Fig. 9).
4.
Copy
Volume
Implementation
The term " c o p y volume" describes a software operation that has to perform total data transfer from one hard disk to another one. This set of programs has to satisfy the following requirements: - high speed; (while this function is executed, access to mass storage is impossible) - insensitivity to faults, both in read or write mode. In our particular environment the copy volume
335
procedure is organized as a separate software package, i.e. is the only program loaded in RAM at this time. This is because of the continuous accesses to all controller's resources (e.g. disks, mailboxes, buffer in DMA). The following operations have to be performed to obtain a correct copy volume function: 1) command decoding [5], 2) copy volume software loading, 3) receiving from higher level software the specific of disks involved, 4) reset on disks, 5) construction of appropriate software structures for the disks, 6) sequence of: - read data from source disk - write data on destination disk - comparing if data were been correctly copied, 7) the program ends when all data have been transmitted. The above functions are implemented as follows: 1) Command decoding is the way in which the controller knows what kind of command is to be executed. In the present implementation this function is performed by high level software. Task o f low level software is to verify the correctness of the command. 2) High level software loads in the private RAM memory of the controller, from mass storage, the software dedicated to copy volume function. 3) The copy volume program (referenced as " p r o g r a m " in the following) reads from the
ccmmand transfer I 8086
data transfer
8086I
mailboxes pageI Fig. 7.
CPU
336
M. Brusamolino et aL / Copy Volume Design and Implementation
~ d
transfer
data transfer
8086
diskette mailbox
<
CI:'U
Lark unit I mailbox
Lark unit 2 mailbox
Fig. 8.
mailbox which are the disks to be used (particularly which is the source disk and the destination one). 4) the reset on disks is necessary in order to ensure that both disks are in an "initial state", i.e. with the head on cylinder zero, without interrupts pending etc. 5) The program " c r e a t e s " a software structure for each disk. These structures will load (during the execution) current values of control signals of the disks (error flags, current position of the head on the surfaces, number of sectors transmitted etc.). The initialization of these structures occurs when the disks are known, which are involved in the copy volume function. It is thus possible to set values in function of the particular media used. The goal of a program independent of the particular media (always in Lark family) was thus obtained. 6) The basic functions sequence of a copy volume procedure is: read data to be copied. - store data in a buffer. Every physical access to disk use a buffer for communication. This is because of difficulties due to synchronization of the disks. Data are read using a D M A technique that stores them in a dedicated buffer. The D M A technique was chosen because of the high baud rate from disk compared with the I / O speed of 8086. -
write data stored in buffer. F r o m the same buffer used for read operation data are transmitted, always in D M A mode, to the destination disk. Now buffer content is copied in another R A M m e m o r y bank. compare data in buffer with data written. Finally, data written are reread in a buffer to ensure, by comparing with data stored in memory, the correctness of the function performed. A scheme of the copy volume management sequence is in Fig. 10. -
-
[ oon'%l,Ier
'< £MA driven buffer
® [
general purpose RAM
]
page 0
Fig. 9.
i !!l
337
M. Brusamolino et aL / Copy Volume Design and Implementation
8086 for comparison
1)
DATA READ
COMPA~D
2) DATA W R I ~
q
I
©
I siter
destination disk
source
disk
Fig. 10. Copy Volume Operations Sequence.
4.1. Error Management Errors can appear during three different moments: 1) while reading f r o m source disk. After reading every sector a particular hardware register (status) is tested (Fig. 11). In case of Time out, Double index, or R / W fault error the copy program is aborted. In fact these are hardware errors, not correctable via software. If a Search error occurs the p r o g r a m simply rereads data. In case of a CRC error program reads on the error track the correct
data. The E D A C error is corrected by successive retries. The retries are executed with a small delay or a little before of the correct time. These retries are then called respectively: later and earlier. If the retry operation did not lead to good end the so called E D A C analysis (based upon self correctable parity checks, [3]) is performed. In case of unsuccessful result of the E D A C analysis, the copy volume function is aborted. 2) While writing on destination disk. The errors in writing are visible during the " c o m p a r e t i m e " ,
I ntld°ntlt ldo 'el l l ls chlout care
care
error
error
fault
error
Fig. 11. Lark Status Register.
error
error
338
M. Brusamolino et al. / Copy Volume Design and Implementation
where they are also corrected. In fact data stored in memory are correct, as seen in the previous paragraph. 3) While rereading from destination disk. The error management while rereading data is totally similar to the one described in case of reading from source disk. The only difference is that the analysis is executed on destination disk.
5. D i s k T i m i n g
The major requirement in copy volume is to reduce the time used. Basically the major loss is due to physical latencies while accessing the media. These delays are due to seek and head selection operations. But these are negligible compared with access time to a correct sector. The method we used for minimizing these time losses is based upon an analysis executed at debug time. Since maximum number o f sectors in a data transfer is limited (by hardware design) to 32 sectors, the optimum would seen to transfer 32 sectors at a time; i.e. copying a whole track during two disk's revolutions (a track contains 64 sectors). To guarantee that no problems will arise, an ICF (Indirect Command File) was prepared to run the program several times through ICE-86 (In Circuit Emulator for Intel 8086) [4]. The ICF runs the copy volume program throughly causing every time the transfer of a different number of sectors. The number of sectors transferred is: - 32 sectors for the first time,
- 16 8 - 4 - 2 -
sectors sectors sectors sectors
for for for for
the the the the
second time, third time, fourth time, fifth time.
At the end o f every run the time used is evaluated. The number of sectors to be transferred was chosen comparing the times used. The best time was obtained transferring 32 sectors and this number is the one used in the copy volume program. The method suggested has the following advantages: (1) It is easy to implement; in fact needs only an emulator and an ICF facility on the development system; (2) It is totally automatic.
6. C o n c l u d i n g R e m a r k s
The package described in this paper runs correctly in the above described system and performs the copy volume function (in case no errors occur) in about four minutes (it is to be remembered here that the data capacity of a Lark medium is of about 25 Mbytes). This paper describes a " c o p y volume" function implementation. At the beginning the system hardware architecture is described, then the system software organization is shown. The various operations that are to be performed by the " c o p y volume" function are then listed. Error and timing management are described with particular emphasis to the way chosen to optimize the timing on the disks.
7. A c k n o w l e d g e m e n t s
The authors are grateful to Prof. M. Sami for the careful review of the manuscript and helpful suggestions regarding the presentation of the material. They would also like to thank Prof. R. Galimberti, Dr. E. Maccario and all the members of Honeywell mass storage management group.
References [1] P. de Ferra, "Designing for microprocessor applications", Com. Electron. Eng.-Vol. 25- (April 1981). [2] C. Preston, "Hard disk" Microcomputer printout-Vol. 2(October 1981). [3] W.T. Greer, R. Breuninger, "32-bit Edac chips fix single-bit errors efficiently", Electronic Design (January 1983). [4] Intel Corporation, "ICE-86A microsystem in-circuit emulator, operating instructions for ISIS-II users". [5] Honeywell Information Systems Italia, "Livello 6, software: reference guide", Honeywell Italia (1979).
M. Brusamolino (born in Milan, Italy, in 1949) is with Honeywell Information Systems Italy since 1969. At the beginning he worked on management aspects of technical work in Honeywell. He was then engaged on the project of a new minicomputer, particularly on memory management design. Presently he works on the quality control of peripherals and magnetic memories. L. Reina (born in Varese, Italy in 1953) received her degree in Solid State Physics from University of Milan in 1975. She
M. Brusamolino et aL / Copy Volume Design and Implementation graduated filing a thesis concerning the Raman effect on crystals. From 1975 to 1981 was with Elema (company active in the field of control of processes). L. Reina presently works at Etnoteam (company active in software consulence) where she is involved in projects concerning control of peripherals. Her actual interests include also software for office automation on personal computers. Massimo F. Spalla (born in Milan, Italy, in 1958) received the Dr. Ing. degree in Electronical Engineering (computer science
339
specialization) from Politecnico di Milano in 1982. He graduated in 1982 with Prof. M.G. Sami (Politecnico di Milano), filing a thesis concerning fault tolerance problems in multimicroprocessor systems. From 1982 to 1983 he was with Etnoteam (company active in software consulence) where he was involved in a research on peripheral management in minicomputer systems. Presently M.F. Spalla works in SGS-Ates in the field of computer aided design. His actual interests include faulttolerant computing, fault analysis and fault simulation of integrated circuits.