IEEE 683-1976 en Recommended Practice for Block Transfers in CAMAC Systems《CAMAC系统中数据块传输的推荐规程》.pdf

《IEEE 683-1976 en Recommended Practice for Block Transfers in CAMAC Systems《CAMAC系统中数据块传输的推荐规程》.pdf》由会员分享，可在线阅读，更多相关《IEEE 683-1976 en Recommended Practice for Block Transfers in CAMAC Systems《CAMAC系统中数据块传输的推荐规程》.pdf（21页珍藏版）》请在麦多课文档分享上搜索。

1、Recognized as anAmerican National Standard (ANSI)Copyright 1976 byThe Institute of Electrical and Electronics Engineers, Inc. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the priorwritten permission of the publisher.IEEE Std 683-1

2、976(R2006)IEEE Recommended Practice for Block Transfers in CAMAC SystemsSponsor Instrumentation and Detectors Committeeof theIEEE Nuclear and Plasma Sciences SocietyReaffirmed March 30, 2006Approved September 9, 1976IEEE-SA Standards BoardReaffirmed December 21, 1990Approved November 9, 1990American

3、 National Standards InstituteiiApproved September 9, 1976IEEE Standards BoardWilliam R. Kruesi, Chair Irvin N. Howell, Jr., Vice Chair Ivan G. Easton, Secretary William E. AndrusJean Jacques ArchambaultDale R. CochranWarren H. CookLouis CostrellJay ForsterJoseph L. KoepfingerIrving KolodnyBenjamin J

4、. LeonAnthony C. LordiJohn P. MarkeyThomas J. MartinDonald T. MichaelVoss A. MooreWilliam S. MorganWilliam J. NeiswenderGustave ShapiroRalph M. ShowersRobert A. SodermanLeonard W. Thomas, Sr.Charles L. WagnerWilliam T. WintringhamiiiForeword(This foreword is not a part of IEEE Std 683-1976, Block Tr

5、ansfers in CAMAC Systems.)A wide variety of block transfer algorithms (or modes) are possible in CAMAC systems. However, a restricted numberof such algorithms can satisfy nearly all needs. This document presents recommended algorithms to encourageuniformity in design of CAMAC modules and controllers

6、 with resulting increased compatibility. It should be read inconjunction with, and is supplementary to, IEEE Standards 583-1975, Modular Instrumentation and Digital InterfaceSystem, 595-1976, Serial Highway Interface Systems, and 596-1976, Parallel Highway Interface System (CAMAC).The report on whic

7、h this document is based, and with which it is technically identical (ERDA Report TID-26616,February 1976), was prepared by the NIM Committee of the United States Energy Research and DevelopmentAdministration* and the ESONE Committee of European Laboratories.This standard was reviewed and balloted b

8、y the Nuclear Instruments and Detectors Committee of the IEEE Nuclearand Plasma Sciences Society. Because of the broad applicability of this standard, coordination was established withnumerous IEEE societies, groups, and committees, including the Communications Society, Computer Society,Industry App

9、lications Society, Industrial Electronics and Control Instrumentation Group, Instrumentation andMeasurement Group, and the Power Generation and Nuclear Power Engineering Committees of the PowerEngineering Society.At the time of approval of this standard, the membership of the Nuclear Instruments and

10、 Detectors Committee of theIEEE Nuclear and Plasma Sciences Society was as follows:D. E. Persyk, Chair J. A. Coleman, Vice Chair Louis Costrell, Secretary R. L. ButenhoffD. C. CookJ. F. DetkoF. S. GouldingT. R. KohlerH. W. KranerR. S. LarsenW. W. ManaganG. L. MillerJ. H. TrainorS. WagnerF. J. Walter

11、H. R. Wasson*NIM CommitteeL. Costrell, Chair R. E. ConnallyE. DaveyW. K. DawsonS. DhawanJ. GallagherC. E. L. GingellV. GuirogossianD. R. HeywoodN. W. HillG. A. HoltD. HorelickC. KernsF. A. KirstenR. S. LarsenA. E. Larsh, Jr.N. LatnerF. R. LenkszusD. R. MachenD. A. MackR. G. MartinV. C. NegroI. Pizer

12、S. RankowitzL. H. RedmondS. J. RudnickD. R. StillwellG. L. StrahlR. F. Thomas, Jr.J. H. TrainorH. R. WassonJ. W. Woody, Jr.ivNIM Dataway Working GroupF. A. Kirsten, Chair E. J. BarsottiJ. S. BobbittL. CostrellS. DhawanD. R. HeywoodC. KernsP. F. KunzD. HorelickR. S. LarsenD. R. MachenR. G. MartinL. P

13、affrathS. RankowitzS. J. RudnickR. F. Thomas, Jr.NIM Software Working GroupR. F. Thomas, Jr., Chair W. K. Dawson, Secretary L. CostrellS. DhawanV. P. ElischerR. W. GoinR. A. LaSalleF. R. LenkszusL. B. MortaraJ. P. SteffaniNIM Block Transfer SubgroupE. J. Barsotti, Chair W. K. DawsonF. A. KirstenR. A

14、. LaSalleF. R. LenkszusR. G. MartinR. F. Thomas, Jr.ESONE CommitteeA. C. Peatfield, England, Chair W. Attwenger, AustriaL. Binard, BelgiumJ. Biri, HungaryH. Bisby, EnglandB. Bjarland, FinlandB. A. Brandt, GermanyM. J. Cawthraw, EnglandM. Coli, ItalyW. K. Dawson, CanadaB. V. Fefilov, USSRF. Fioroni,

15、ItalyP. Gallice, FranceG. Giannelli, ItalyH. R. Hidber, SwitzerlandR. Hunt, EnglandF. Iselin, SwitzerlandW. Kessel, GermanyE. Kwakkel, NetherlandsJ. Lecomte, FranceJ. Lingertat, GermanyP. F. Manfredi, ItalyCh. Mantakas, GreeceG. Metzger, FranceH. Meyer, BelgiumK. D. Muller, GermanyJ. G. Ottes, Germa

16、nyA. T. Overtoom, NetherlandsM. Patrutescu, RournaniaR. Patzelt, AustriaG. Perna, ItalyI. C. Pyle, EnglandB. Rispoli, ItalyPer Gunner Sjolin, SwedenP. Skaarup, DenmarkL. Stanchi, ItalyH. J. Stuckenberg, GermanyR. Trechcinski, PolandA. J. Vickers, EnglandM. Vojinovic, YugoslaviaK, Zander, GermanyD. Z

17、immermman, GermanyESONE Dataway Working GroupR. Patzelt, Austria, Chair H. Klessman, Germany, Past ChairmanR. C. M. Barnes, England, Joint SecretaryI. N. Hooton, England, Joint SecretaryW. Attwenger, AustriaH. Barthel, GermanyM. J. Cawthraw, EnglandP. Gallice, FranceF. Iselin, SwitzerlandJ. Kaiser,

18、FranceJ. Lauwers, BelgiumJ. Lecomte, FranceB. A. Lofstedt, SwitzerlandH. Meyer, BelgiumK. D. Muller, GermanyJ. G. Ottes, GermanyA. C. Peatfield, EnglandP. Skaarup, DenmarkL. Stanchi, ItalyH. J. Trebst, GermanyA. J. Vickers, EnglandW. Wawer, GermanyvESONE Software Working GroupI. N. Hooton, Chair E.

19、De Agostino, ItalyW. Attwenger, AustriaG. Bianchi, FranceP. Christensen, DenmarkW. K. Dawson, CanadaH. Halling, GermanyA. Katz, FranceW. Kneis, GermanyM. Kubitz, GermanyA. Lewis, EnglandJ. Lukacs, HungaryH. J. Metzdorf, ItalyH. Meyer, BelgiumJ. M. Meyer, FranceA. Th. Overtoom, NetherlandsR. Patzelt,

20、 AustriaA. C. Peatfield, EnglandI. C. Pyle, EnglandP. Scharff-Hansen, SwitzerlandH. J. Trebst, GermanyJ. L. Visschers, NetherlandsP. Wilde, EnglandviCLAUSE PAGE1. Introduction.12. Classification of Block-Transfer Modes.22.1 CAMAC Address Sequencing. 22.2 Synchronization Source. 42.3 Block-Transfer T

21、ermination. 43. Block-Transfer Modes Described in IEEE Std 583-19751, Modular Instrumentation andDigital Interface System (CAMAC) (EUR 4100)43.1 UCS (Stop) Mode. 53.2 ACA (Address Scan) Mode. 53.3 UQC (Repeat) Mode 54. Additional Block-Transfer Modes64.1 UCW (Stop-on-Word) Mode. 64.2 ULS (LAM Synchr

22、onized Stop) Mode 74.3 UDS (Direct Synchronized Stop) Mode 74.4 MCA (Multidevice Action) Mode. 85. Compatibility85.1 Block-Transfer Mode MCA. 85.2 Block-Transfer Modes XCX, XLX, XDX. 85.3 Block-Transfer Modes ULS, UDS, ULC, UDC, UQC 95.4 Block-Transfer Modes ULS, UDS, ULW, UDW 96. Hardware Design.96

23、.1 Module DesignQ Response 106.2 Module DesignLAM Signal. 116.3 Interface Design. 127. Software Considerations.128. References.13Annex A (Informative)14Copyright 1976IEEE All Rights Reserved1An American National StandardIEEE Recommended Practice for Block Transfers in CAMAC Systems1. IntroductionThe

24、 basic CAMAC specication (see Ref 1) denes a single CAMAC operation as the activity which occurs in response to a single CAMAC command. This activity may consist of the transfer of a single data word between a CAMAC module and computer memory or the changing of the status of a module for example, F(

25、26), F(24) or return of a value for Qas the result of a test made on the module, or any compatible set of the previously named activities. A block transfer is dened as a sequence of single CAMAC operations involving data which the user species by a command said to be of a higher level than one which

26、 species a single CAMAC operation. The higher level command contains all the information required for the specication of the desired sequence of single CAMAC commands and is interpreted by a channel which governs the activity on the CAMAC highway. Control information such as the readiness of the com

27、puter to participate in a data transfer, the state of the CAMAC Qline and the state of certain LAMs (Look-at-Mes) or special synchronizing signals must be made available to the channel. The use made of the control information by the channel denes the block-transfer mode. If a module is to inuence th

28、e sequence of operations within a block transfer, then it must have the features required by the algorithm.A channel consists of an interface to the CAMAC system as well as a means for selecting and executing the algorithms of the implemented block-transfer modes. An algorithm may be implemented who

29、lly in hardware or wholly in software or by a combination of hardware and software. The possibility of software implementation of any algorithm means that CAMAC block transfers can take place on a system which does not have the hardware (such as direct memory access) required to carry out “computer”

30、 block transfers. Note that a module behaves in the same way when it is accessed by a hardware algorithm as it does when accessed by conventional programmed computer input-output. Regardless of the method of channel implementation, the use of the channel results in reductions in both the CPU time re

31、quired and in the programming effort through the use of pre-dened algorithms.Many different block-transfer algorithms (or modes) may be dened, all of which are compatible with the CAMAC specications. It is also possible to have a channel execute a sequence of CAMAC commands which does not involve th

32、e transfer of data. An example of such a “Multiple Action” mode is discussed in the Appendix. Many algorithms convey control information by either Qor a LAM signal or both. The requirements placed on these signals by one algorithm may conict with those placed on them by another algorithm. Hence comp

33、atibility problems between modes and channels can occur. This is especially true if no restrictions are placed on the choice of a suitable block-transfer algorithm. However, experience with many different CAMAC systems and extensive analysis of the problem has revealed that a restricted number of bl

34、ock-transfer algorithms can satisfy nearly all needs. To encourage uniformity in future designs of modules and controllers, certain algorithms are recommended to be used whenever possible, and some additional algorithms are suggested for special applications that cannot practicably be implemented wi

35、th the recommended algorithms. The possibility remains for a user to dene other block-transfer algorithms to meet special needs.2Copyright 1976IEEE All Rights ReservedIEEE Std 683-1976IEEE RECOMMENDED PRACTICE FORIn the following sections, the recommended block-transfer algorithms are discussed. In

36、Section 3, those given in the basic specication (see Ref 1) are described. These algorithms are well established and are supported by existing hardware, both in modules and in CAMAC interfaces available for many small computers. Section 4 discusses the new algorithms.The CAMAC user is reminded that

37、the block-transfer characteristics of his modules, his controller (Branch Driver or computer-crate interface), and the software in the computer must be matched in order for the block-transfer algorithms to be carried out correctly. The ability to perform block transfers is a feature of the total com

38、puter system and its interfaces.2. Classification of Block-Transfer ModesThe various block-transfer modes can be classied by specifying the nature of each of three fundamental characteristics: how the CAMAC address is determined, the source of the synchronizing signal, and the method used to termina

39、te the block transfer. In the following, these characteristics are described, and a notation permitting a compact specication of the various modes is dened.The notation is based on the use of a single letter to represent the nature of each characteristic. The letters are written in the order that th

40、e characteristics were mentioned above and the resulting three letters completely describe a block-transfer mode. If a certain characteristic need not be specied, then it is denoted by the letter X. Thus the symbol XXX describes a block-transfer mode in which all the characteristics are undened. Tab

41、le 1 summarizes the meaning of each letter used and Table 2 lists the modes described below and the IML (see Ref 2) support for each.2.1 CAMAC Address SequencingThe rst letter of the block mode descriptor indicates the method used to determine the CAMAC address of the next CAMAC operation.A block tr

42、ansfer accessing a CAMAC address which stays constant during the block transfer is typically used to access a buffer within a module or to access an external device (such as a computer peripheral unit) through a CAMAC module. Such Uniaddress block transfers are denoted by the letter U.A block transf

43、er accessing a sequence of CAMAC addresses is typically used to access a set of registers located at different places within a CAMAC system but containing related data. The algorithm for determining the next CAMAC address may depend on the state of Qresulting from the last operation.Copyright 1976IE

44、EE All Rights Reserved3BLOCK TRANSFERS IN CAMAC SYSTEMSIEEE Std 683-1976Table 1Block-Transfer Mode DescriptorTable 2Block-Transfer NamesThe ACA (Address Scan) Mode described in Ref 1 (Section 5.4.3.1) is the main example of this technique, although there does exist a variant, the ECA (Extended Addre

45、ss Scan) Mode, which is described in the Appendix.First LetterCAMAC Address SequencingU Uni-AddressM Multi-Address (Calculated or Given Array in IML*)*See Ref 2AAddress ScanE Extended Address ScanSecond Letter Synchronizing SourceC ControllerQ Q ResponseL LAM SignalD Pseudo-LAM SignalThird Letter Op

46、eration TerminationC Channel Word CountA Terminal Address ReachedS Q = 0 on last + 1W Q = 0 on lastL LAM SignalD Pseudo-LAM SignalDescriptorIEEE Std 583 EUR 4100 IML*UCSStop ModeUBCUCWnoneUBCUQCRepeat ModeUBRACAAddress Scan ModeMADMCAnoneMAULSnoneUBLUDSnoneUBLULWnoneUBLUDWnoneUBL4Copyright 1976IEEE

47、All Rights ReservedIEEE Std 683-1976IEEE RECOMMENDED PRACTICE FORThe sequence of CAMAC addresses may also be determined either by a list of all the addresses or by a starting address, increments to be applied to each part of the address and a nal address. These correspond to the Given and Calculated

48、 Arrays of CAMAC addresses in IML (see Ref 2), and both are indicated by the letter Mfor Multiaddress.2.2 Synchronization SourceThe second letter of a block-transfer mode descriptor indicates the source of synchronization of individual transfers. In some cases the module is continuously ready to eff

49、ect a transfer, and the channel controller may execute the CAMAC commands at any convenient rate. The block transfer is then said to be “controller synchronized,” and the descriptor for all such modes is of the form XCX.In other cases the module is not continuously ready. Following a particular transfer a certain time must elapse before it can effect another. The rate at which the block transfer proceeds is controlled by the module (or modules). Hence the module must provide synchronization information to the c