ImageVerifierCode 换一换
格式:PDF , 页数:21 ,大小:201.40KB ,
资源ID:435171      下载积分:5000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-435171.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ANSI IEEE 683-1976 Recommended Practice for Block Transfers in CAMAC Systems《CAMAC系统中整块(成组)传送的推荐实施规程》.pdf)为本站会员(deputyduring120)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ANSI IEEE 683-1976 Recommended Practice for Block Transfers in CAMAC Systems《CAMAC系统中整块(成组)传送的推荐实施规程》.pdf

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1