DEFSTAN_21-24_I-2_2000

8/2/2019 DEFSTAN_21-24_I-2_2000

1/102

Ministry of Defence

Defence Standard 21-24 (NES 1024)

Issue 2 Publication Date 15 September 2000

Incorporating NES 1024 Category 1

Issue 4 Publication Date March 2000

Data Transmission - Direct Memory Access

Interface Standard

Part 1The Software Interface

8/2/2019 DEFSTAN_21-24_I-2_2000

2/102

8/2/2019 DEFSTAN_21-24_I-2_2000

3/102

Ministry of Defence

Naval Engineering Standard

CATEGORY 1

NES 1024 Part 1 Issue 4 March 2000

DATA TRANSMISSIONDIRECT MEMORY ACCESS INTERFACE

STANDARD

PART 1

THE SOFTWARE INTERFACE

E CROWN COPYRIGHT 2000

8/2/2019 DEFSTAN_21-24_I-2_2000

4/102

This NES Supersedes

NES 1024 Part 1 Issue 1 March 1985NES 1024 Part 1 Issue 2 December 1986

NES 1024 Part 1 Issue 3 August 1993

Record of Amendments

AMDT INSERTED BY DATE

1

2

3

4

5

8/2/2019 DEFSTAN_21-24_I-2_2000

5/102

(i)

NAVAL ENGINEERING STANDARD 1024

DATA TRANSMISSIONDIRECT MEMORY ACCESS

INTERFACE STANDARD

PART 1 ISSUE 4 MARCH 2000

THE SOFTWARE INTERFACE

This Naval Engineering Standard is

authorized for use in MOD contracts

by the Defence Procurement Agency and

the Defence Logistics Organization

Published by:

UK Defence Standardization

Defence Procurement Agency

PDB BM&D

Kentigern House

65 Brown Street

Glasgow G2 8EX

8/2/2019 DEFSTAN_21-24_I-2_2000

6/102

NES 1024 Part 1Issue 4March 2000

(ii)

8/2/2019 DEFSTAN_21-24_I-2_2000

7/102

NES 1024 Part 1Issue 4

March 2000

(iii)

SCOPE

Introduction

1. NES 1024, 1026, and 1028 cover the technical requirements for interfacing to current warshipcombat systems using the CSH or TWSH. For equipment that will interface to these systemsthe standards are Category 1, mandatory, but for systems and equipment relating only to new

platforms the standards should be considered as Category 2.2. This NES defines a standard interface between computers and intelligent peripherals which

implement the protocols of a digital communications system such as a data highway, local areanetwork or pointtopoint system. The standard embraces both an electrical and a softwareinterface.

3. This standard makes it possible to interface a given computer to different communicationssystems. Once the standard interface is supported by a computer, the hardware and softwaredevelopment involved in changing the communications system is much reduced.

4. Similarly, once a communications unit has been designed for a given communications systemthat design is readily applicable to all those computers that support the standard interface.

Although hardware compatibility is unlikely, only reengineering of a proven design will be

necessary.5. Figure 1 shows examples of the NES 1024 concept. It shows a terminal unit (constituting the

intelligent peripheral) connected to a host computer consisting of a central processing unit anda memory. The interface between the terminal unit and the host computer is of the directmemory access type (DMA).

Software Interface (NES 1024 Part 1)

6. The NES 1024 Software Interface consists of:

a. data tables stored in shared memory which is accessible by both the host computer andthe terminal unit; and

b. the protocols by which the data is passed in either direction between the host computer

and the terminal unit.7. There are two alternatives for the location of the shared memory:

a. Within the host computer (see Figure 1a).

b. Within the terminal unit (See Figure 1b). As can be seen this will be within the hostadapter unit in the case of an NES 1024 Electrical Interface compliant implementation.

8. The presence of the NES 1024 Electrical Interface is not a prerequisite for the use of the NES1024 Software Interface, and this is indicated in Figure 2a and Figure 2b. Where the NES1024 Electrical Interface is present, those aspects of the NES 1024 Software Interfacedesignated as the responsibilities of the terminal unit, are performed by the communicationsunit.

9. The Software Interface is mostly independent of both the communications systemimplemented on the terminal unit and of the particular host computer in use. For thoseinterested in relationships with the ISO 7layer model for Open System Interconnection (OSI),see ISO 7498, the interface may be considered as corresponding to that between the transportand network layers.

Electrical Interface (NES 1024 Part 2)

10. Interfacing to the memory and central processing unit of a host computer is usually computerspecific, and so the terminal unit will carry some host specific components (the host adapterunit) to couple the terminal unit to the host. Consequently, the NES 1024 Electrical Interfaceis to be found in the terminal unit between the host adapter unit and the communications unit.

11. It may be seen from Figure 1 that the host is unaffected if the communications specific

components are changed provided that the NES 1024 Electrical Interface is observed.Conversely, different host specific components can be used with a single set of communicationsspecific components.

8/2/2019 DEFSTAN_21-24_I-2_2000

8/102


(iv)

12. The intention is that the host adapter unit acts as agent for the host and that its design be keptas simple as possible. Nevertheless, the host adapter unit is expected to contain both all thetransmitters, receivers and logic required to maintain its side of the NES 1024 ElectricalInterface and the registers, counters and logic necessary to ensure correct manipulation ofdata across the DMA mechanism of the host.

13. The communications unit is assumed to be capable of undertaking the major part of the taskof maintaining the communications side of the host to terminal unit interface, in addition toperforming its prime task of implementing the protocols and signalling of the communicationsmedium it represents.

Compatibility with NES 1024 Parts 3 and 4

14. The enhancements provided in NES 1024 Part 3 and Part 4 have been implemented so thatbackwards compatibility is possible between:

a. a host and host adapter unit designed to NES 1024 Part 3 and Part 4 and acommunications unit designed to NES 1024 Part 1 and Part 2,

b. a communications unit designed to NES 1024 Part 3 and Part 4 and a host and hostadapter unit designed to NES 1024 Part 1 and Part 2.

15. It may be possible to design a compatible system using host, host adapter unit andcommunications unit components built to other combinations of the parts of this standard.However this will be dependent on implementation specfic details of the system design whichare beyond the scope of this standard. In particular it will be dependent on the organisationof shared memory, the DMA system used to access the shared memory, the use (if any) of a32bit data highway within the Electrical Interface and the use (if any) of the long messagetransfer packing facilities.

16. In any design which involves the use of components which are implemented to different parts

of this standard, the host system designer is responsible for ensuring that the combination ofcomponents to be used and the way in which they are implemented are compatible with thefacilities to be used.

Compatibility in the absence of an Electrical Interface

17. A NES 1024 terminal unit includes the host adapter unit function whether or not itincorporates a NES 1024 Electrical Interface.

18. In NES 1024 Parts 1 and 2, the host adapter unit function has only to deal with host computerword addresses provided by the communications unit. The introduction of doublet (two byte)addressing in NES 1024 Part 3 and Part 4 means that the host adapter unit function isresponsible for converting doublet addresses into word addresses, and in some DMA systemsfor accessing part words (possibly across word boundaries).

19. A terminal unit designed to NES 1024 Part 3 will treat the Control and Status Table addressand the addresses in that table as doublet addresses. Unless the word and doublet addressesare the same (i.e. the address mapping function within the terminal unit is effectively null),the terminal unit will access incorrect memory locations.

20. Similar considerations apply to the use of a terminal unit designed to NES 1024 Part 1 witha host computer designed to NES 1024 Part 3.

21. In a design using a terminal unit which does not include a NES 1024 Electrical Interface andwhich is not implemented to the same part of NES 1024 (1 or 3) as the host system, the host

system designer is responsible for ensuring that the host adapter function within the terminalunit, the usage of host memory and the NES 1024 facilities used by the host computer arecompatible.

8/2/2019 DEFSTAN_21-24_I-2_2000

9/102


March 2000

(v)

Figure 1 NES 1024 Electrical and Software Interfaces

CENTRAL

PROCESSING

UNIT (CPU)

HOST DMA

MECHANISM

NES 1024

ELECTRICAL

INTERFACE

NES 1024

SOFTWARE

INTERFACE

SHARED MEMORY

HOST

ADAPTER

UNIT

(HAU)

COMMUNICATIONS

UNIT COMMUNICATIONS

MEDIUM

CENTRAL

PROCESSING

UNIT (CPU)

COMMUNICATIONS

UNIT

HOST

ADAPTER

UNIT

(HAU)

NES 1024

SOFTWARE

INTERFACESHARED

MEMORY

a) All commonly accessible memory in the host computer

b) All commonly accessible memory in the unit

COMMUNICATIONS

MEDIUM

HOST COMPUTER

TERMINAL UNIT (TU)

HOST COMPUTER

MEMORY

HOST COMPUTER

HOST DMANES 1024

TERMINAL UNIT (TU)

HOST COMPUTER

MEMORY

8/2/2019 DEFSTAN_21-24_I-2_2000

10/102


(vi)

Figure 2 NES 1024 Software Interface Only

HOST COMPUTER

NES 1024

SOFTWARE

INTERFACE

SHARED MEMORY

a) All commonly accessible memory in the host computer

b) All commonly accessible memory in the terminal unit

HOST DMA

MECHANISM

NES 1024

SOFTWARE

INTERFACE

SHARED

MEMORY

CENTRAL

PROCESSING

UNIT (CPU)

HOST DMA

MECHANISM

COMMUNICATIONS

MEDIUM

CENTRAL

PROCESSING

UNIT (CPU)

COMMUNICATIONS

MEDIUM

TERMINAL UNIT (TU)

HOST COMPUTER

MEMORY

HOST COMPUTER

TERMINAL UNIT (TU)

HOST COMPUTER

MEMORY

8/2/2019 DEFSTAN_21-24_I-2_2000

11/102


March 2000

(vii)

FOREWORD

Sponsorship

1. This Naval Engineering Standard (NES) is sponsored by the Defence Procurement Agency(DPA), Ministry of Defence (MOD).

2. The complete NES 1024 comprises:

Data TransmissionDirect Memory Access Interface Standard

Part 1: The Software Interface

Part 2: The Electrical Interface

Part 3: The Enhanced Software Interface

Part 4: The Enhanced Hardware Interface

3. Any user of this NES either within MOD or in industry may propose an amendment to it.Proposals for amendments that are not directly applicable to a particular contract are to bemade to the publishing authority identified on Page (i), and those directly applicable to aparticular contract are to be dealt with using contract procedures.

4. If it is found to be unsuitable for any particular requirement MOD is to be informed in writingof the circumstances.

5. No alteration is to be made to this NES except by the issue of an authorized amendment.

6. Unless otherwise stated, reference in this NES to approval, approved, authorized and similarterms, means by the MOD in writing.

7. Any significant amendments that may be made to this NES at a later date will be indicatedby a vertical sideline. Deletions will be indicated by 000 appearing at the end of the lineinterval.

8. This NES has been reissued to reflect changes in Departmental Nomenclature due to theMOD reorganization and the changes to technical requirements.

Conditions of Release

General

9. This Naval Engineering Standard (NES) has been devised solely for the use of the MOD, andits contractors in the execution of contracts for the MOD. To the extent permitted by law, theMOD hereby excludes all liability whatsoever and howsoever arising (including but withoutlimitation, liability resulting from negligence) for any loss or damage however caused whenthe NES is used for any other purpose.

10. This document is Crown Copyright and the information herein may be subject to Crown orthird party rights. It is not to be released, reproduced or published without written permissionof the MOD

11. The Crown reserves the right to amend or modify the contents of this NES without consultingor informing any holder.

MOD Tender or Contract Process

12. This NES is the property of the Crown. Unless otherwise authorized in writing by the MODmust be returned on completion of the contract, or submission of the tender, in connectionwith which it is issued.

13. When this NES is used in connection with a MOD tender or contract, the user is to ensure thathe is in possession of the appropriate version of each document, including related documents,relevant to each particular tender or contract. Enquiries in this connection may be made tothe authority named in the tender or contract.

14. When NES are incorporated into MOD contracts, users are responsible for their correctapplication and for complying with contractual and other statutory requirements.Compliance with an NES does not of itself confer immunity from legal obligations.

8/2/2019 DEFSTAN_21-24_I-2_2000

12/102


(viii)

Categories of NES

15. The Category of this NES has been determined using the following criteria:

a. Category 1. If not applied may have aCritical affect on the following:

Safety of the vessel, its complement or third parties.Operational performance of the vessel, its systems or equipment.

b. Category 2. If not applied may have aSignificant affect on the following:

Safety of the vessel, its complement or third parties.

Operational performance of the vessel, its systems or equipment.

Through life costs and support.

c. Category 3. If not applied may have aMinor affect on the following:

MOD best practice and fleet commonality.

Corporate experience and knowledge.

Current support practice.

Related Documents

16. In the tender and procurement processes the related documents listed in each section andAnnex A can be obtained as follows:

a. British Standards British Standards Institution,389 Chiswick High Road,London, W4 4AL

b. Defence Standards Defence Standardization, BM&DKentigern House, 65 Brown Street,Glasgow, G2 8EX.

c. Naval Engineering Standards DSDC(L) Llangennech, Llanelli, Dyfed,SA14 8YP.

d. Other documents Tender or Contract Sponsor to advise.

17. All applications to the MOD for related documents are to quote the relevant MOD Invitationto Tender or Contract number and date, together with the sponsoring Directorate and theTender or Contract Sponsor.

18. The Form Facsimiles shown in this NES are not to be copied since they are only replicas forinformation purposes and will be subject to change by the form Sponsor to reflect currentMOD policy.

19. Prime Contractors are responsible for supplying their subcontractors with relevant

documentation, including specifications, standards and drawings.

Health and Safety

Warning

20. This NES may call for the use of processes, substances and/or procedures that are injuriousto health if adequate precautions are not taken. It refers only to technical suitability and inno way absolves either the supplier or the user from statutory obligations relating to healthand safety at any stage of manufacture or use. Where attention is drawn to hazards, thosequoted may not necessarily be exhaustive.

21. This NES has been written and is to be used taking into account the policy stipulated in JSP430: MOD Ship Safety Management System Handbook.

Additional Information

22. (There is no relevant information included.)

8/2/2019 DEFSTAN_21-24_I-2_2000

13/102


March 2000

(ix)

CONTENTS

Page No

TITLE PAGE (i). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SCOPE (iii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction (iii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Software Interface (NES 1024 Part 1) (iii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Electrical Interface (NES 1024 Part 2) (iii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compatibility with NES 1024 Parts 3 and 4 (iv). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compatiblity in the absence of an Electrical Interface (iv). . . . . . . . . . . . . . . . . . . . .

Figure 1 NES 1024 Electrical and Software Interfaces (v). . . . . . . . . . . . . . . . .

Figure 2 NES 1024 Software Interface Only (vi). . . . . . . . . . . . . . . . . . . . . . . . . .

FOREWORD (vii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sponsorship (vii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conditions of Release (vii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Categories of NES (viii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Related Documents (viii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Health and Safety (vii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Additional Information (vii). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CONTENTS (ix). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SECTION 1. PERFORMANCE SPECIFICATION 1.1. . . . . . . . . . .

1.1 Introduction to the Software Interface 1.1. . . . . . . . . .

1.1.1 Principles of Operation 1.1. . . . . . . . . . . . . . . . . . . . . . .

1.1.2 Message Forms 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1.1 Context of Operation 1.3. . . . . . . . . . . . . . . . . . . . . . . . .

1.1.3 Message Routeing and Filtering 1.4. . . . . . . . . . . . . . . .

1.1.4 Time Synchronization 1.4. . . . . . . . . . . . . . . . . . . . . . . .

1.1.5 Stimulation 1.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.6 Adaptation 1.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.7 Testing 1.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.8 Summary 1.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.9 Principles of Implementation 1.6. . . . . . . . . . . . . . . . . .

Figure 1.2 Data Areas 1.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Scope of the Software Interface Specification 1.9. . . . .

1.3 Shared Data Area Specifications 1.9. . . . . . . . . . . . . . .

Figure 1.3 Bytes/Word Working 1.11. . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1.4 Long Message Bytes/Word Selection 1.12. . . . . . . . . . . .

1.3.1 Control and Status (C & S) Table 1.13. . . . . . . . . . . . . . .

1.3.2 C & S Table: Interface Control 1.13. . . . . . . . . . . . . . . . .

8/2/2019 DEFSTAN_21-24_I-2_2000

14/102


(x)

Page No

1.3.3 C & S Table: Location of Tables 1.15. . . . . . . . . . . . . . . .

1.3.4 C & S Table: Short Message Input Control 1.16. . . . . . .

1.3.5 C & S Table: Short Message Output Control 1.17. . . . .

1.3.6 C & S Table: Communications Status 1.17. . . . . . . . . . .1.3.7 C & S Table: Long Message Input Control 1.18. . . . . . .

1.3.8 C & S Table: Long Message Output Control 1.19. . . . .

1.3.9 C & S Table: Time Synchronization 1.20. . . . . . . . . . . . .

1.3.10 Input Table and Output Table 1.21. . . . . . . . . . . . . . . . .

1.3.11 Fields in Input and Output Buffers 1.21. . . . . . . . . . . . .

1.3.12 The Message Type Table 1.23. . . . . . . . . . . . . . . . . . . . . .

1.3.13 Terminal Unit Data Area 1.24. . . . . . . . . . . . . . . . . . . . . .

1.3.14 Summary Figures 1.24. . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.15 Data Organization 1.24. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1.5 MTN Blocking and MTN Window 1.26. . . . . . . . . . . . . .Figure 1.6 Control and Status Table 1.27. . . . . . . . . . . . . . . . . . . . . .

Figure 1.7 Input and Output Tables 1.28. . . . . . . . . . . . . . . . . . . . . .

Figure 1.8 Word Map of Control and Status Tables 1.29. . . . . . . . .

Figure 1.9 Word/Byte Map of Short Message Buffers 1.30. . . . . . .

Figure 1.10 Coral Declaration Template 1.32. . . . . . . . . . . . . . . . . . .

Figure 1.11 Summary of Requirements for CommonlyAccessible Memory 1.33. . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 Protocol SpecificationInitialization and ModeChange 1.34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1 Introduction to Initialization 1.34. . . . . . . . . . . . . . . . . . .

1.4.2 The Initialization Protocol 1.34. . . . . . . . . . . . . . . . . . . . .Figure 1.12 Initialization Protocol 1.35. . . . . . . . . . . . . . . . . . . . . . . .

1.4.3 Host Computer Initialization 1.36. . . . . . . . . . . . . . . . . .

1.4.4 Terminal Unit Initialization 1.38. . . . . . . . . . . . . . . . . . . .

1.4.5 Introduction to Mode Change 1.39. . . . . . . . . . . . . . . . . .

1.4.6 The Mode Change Protocol (Reset) 1.40. . . . . . . . . . . . .

Figure 1.13 Mode Change Protocol (Reset) 1.41. . . . . . . . . . . . . . . . .

1.4.7 The Mode Change Protocol (Re-initialize) 1.43. . . . . . .

Figure 1.14 Mode Change Protocol (Re-Initialization) 1.44. . . . . . . .

1.5 Protocol SpecificationStimulation 1.45. . . . . . . . . . . .

1.5.1 Introduction 1.45. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.5.2 Interrupt Mechanism 1.46. . . . . . . . . . . . . . . . . . . . . . . . .

1.5.3 Scanning Mechanism 1.47. . . . . . . . . . . . . . . . . . . . . . . . .

1.5.4 Adaptation 1.48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.5 Significant Events 1.49. . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.6 Stimulation Protocol 1.51. . . . . . . . . . . . . . . . . . . . . . . . .

1.5.7 Protocol Examples 1.52. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1.15 Stimulation Sequences (Contd) 1.53. . . . . . . . . . . . . . . . .

Figure 1.15 Stimulation Sequences 1.54. . . . . . . . . . . . . . . . . . . . . . . .

1.6 Protocol SpecificationOperation 1.55. . . . . . . . . . . . . .

1.6.1 Short Message Transmission 1.55. . . . . . . . . . . . . . . . . . .1.6.2 Short Message OutputAction by the HostComputer 1.56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8/2/2019 DEFSTAN_21-24_I-2_2000

15/102


March 2000

(xi)

Page No

1.6.3 Short Message OutputAction by the TerminalUnit 1.57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.4 Short Message Reception 1.58. . . . . . . . . . . . . . . . . . . . . .

1.6.5 Short Message InputAction by the Terminal Unit 1.581.6.6 Short Message InputAction by the Host

Computer 1.60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.7 Long Message Transmission and Reception 1.60. . . . . .

1.6.8 Long Message OutputAction by the HostComputer 1.62. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.9 Long Message OutputAction by the TerminalUnit 1.63. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.10 Long Message InputAction by the Host Computer 1.64

1.6.11 Long Message InputAction by the Terminal Unit 1.65

1.6.12 Number of Short Message Buffers 1.66. . . . . . . . . . . . . .

1.7 Protocol SpecificationInterface Operation 1.66. . . . .

1.7.1 Time Message Reception 1.66. . . . . . . . . . . . . . . . . . . . . .

1.7.2 Time Message InputAction by Host Computer 1.66. .

1.7.3 Time Message InputAction by the Terminal Unit 1.67

1.7.4 Fault Reporting 1.67. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7.5 Fault ReportingAction by the Host Computer 1.67. .

1.7.6 Fault ReportingAction by the Terminal Unit 1.68. . .

SECTION 2. NATIONAL/INTERNATIONAL REGULATIONS 2.1

SECTION 3. MILITARY STANDARDS/REQUIREMENTS 3.1. . . .

SECTION 4. DESIGN REQUIREMENTS/GUIDANCE 4.1. . . . . . .

SECTION 5. CORPORATE EXPERIENCE & KNOWLEDGE 5.1.

ANNEX A RELATED DOCUMENTS A.1. . . . . . . . . . . . . . . . . . . .

ANNEX B DEFINITIONS B.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANNEX C PROCUREMENT CHECK LIST C.1. . . . . . . . . . . . . . .

ALPHABETICAL INDEX INDEX.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8/2/2019 DEFSTAN_21-24_I-2_2000

16/102


(xii)

8/2/2019 DEFSTAN_21-24_I-2_2000

17/102


March 2000

1.1

1. DESIGN REQUIREMENTS/GUIDANCE

Related Documents: BS 5905, ISO 7, ISO 7498, NES 1024 Part 2, 3 & 4, NES 1028,

CORAL 66; see also Annex A.

1.1 Introduction to the Software Interface

1.1.1 Principles of Operation

a. This part of NES 1024 defines the software interface between a host computerand a terminal unit which implements the protocols and signalling of a localarea network, communications interface or data bus. It describes:

(1) The facilities provided.

(2) The shared data areas accessible by both the host computer and theterminal unit.

(3) The protocols by which data is passed through the shared areas betweenthe host computer and the terminal unit.

b. Independence both of the communications system implemented by theterminal unit and of the host computer is largely achieved by using a directmemory access technique, so that the two elements, computer and terminalunit, communicate via shared data areas within a commonly accessiblememory.

c. This software interface definition provides the means by which messages canbe transferred between a host computer and a terminal unit. The objectivesof the standard are as follows:

(1) To be equally applicable to a range of digital communications systemsusing different communications protocols and message transfer

methods.(2) To be equally applicable to a range of computers.

(3) To impose minimum communications overheads on the host computerin terms of processor loading, shared data memory occupancy, andruntime software.

(4) To be as timeefficient as possible in the transfer of messages.

d. In order to understand the NES 1024 interface, it is necessary to appreciate thecontext in which it is to be found. Figure 1.1 illustrates a total system whichcomprises member systems (three shown) which cooperate to fulfil therequirements of the total system. The member systems will probably perform

different tasks and may be implemented in dissimilar hardware.e. The member systems exchange data by means of a digital communications

system. The communications system may be considered to consist of theterminal units in each member system and any other necessary items ofcommunication equipment (e.g. highway cables, multiplexers, controllersetc.).

f. From the point of view of the communications system, each member systemmay be variously called:

(1) A user system, in general.

(2) A source system, if originating messages.

(3) A destination system, if receiving messages.

This terminology is freely used in the software specification.

8/2/2019 DEFSTAN_21-24_I-2_2000

18/102


1.2

g. Figure 1.1 shows each member system as comprising a single computer and asingle terminal unit. In practice a member system may be a multicomputerimplementation with one or more terminal units. That part of the membersystem which interfaces to a given terminal unit is considered to be the `hostcomputer' for that interface and terminal unit.

1.1.2 Message Forms

a. The NES 1024 interface provides for the passage of messages in either directionbetween a host computer and a terminal unit. Messages may take one of twoforms, being either a short message form or a long message form.

b. The short message form is to achieve efficient sharing of the resources of thecommunications system amongst its users and to conserve the amount ofdedicated buffer space required within each user. The short message lengthwill be a maximum of 64 bytes, of which 6 bytes are assigned as a messageheader and a maximum of 58 bytes are available for user data.

c. Short messages pass between the terminal unit and the host computer bymeans of two sets of dedicated cyclic buffers. One set is for input to the hostcomputer, the other set is for output from the host computer. The actual buffersize is determined by the maximum length of short messages which is definedas 64 bytes.

d. The number of buffers used is a design decision local to a member system andis based upon the estimated traffic for a given member system and the capacityof that member system to process the messages. The number of input buffersand the number of output buffers may be separately defined and so the systemcan be tailored for different input and output message rates.

e. Long messages may be of any length, up to a maximum of 65535 bytes. Thereis no provision within the interface specification of space for these messages.Source and destination areas have to be found elsewhere in commonlyaccessible host computer memory and pointers to their location placed in theappropriate long message control area. It is the responsibility of the terminalunit to perform any necessary blocking or deblocking to achieve the longmessage service.

f. The terminal unit is responsible for ensuring that the transfers to and fromhost computer memory are in accord with both the actual and declared wordsize, see NES 1024 Part 2.

g. The shared data areas, accessed by the host computer software and theterminal unit software, contain the short message buffers, short messagecontrol fields, long message control fields, interface control fields andcommunications status reporting fields.

8/2/2019 DEFSTAN_21-24_I-2_2000

19/102


March 2000

1.3

MEMBER SYSTEM

(USER SYSTEM,SOURCE SYSTEM,

DESTINATION SYSTEM)

MEMBER SYSTEM


DESTINATION SYSTEM)

MEMBER SYSTEM


DESTINATION SYSTEM)

HOST

COMPUTER

TERMINALUNIT

HOST

COMPUTER

TERMINAL

UNIT

HOST

COMPUTER

TERMINAL

UNIT

COMMUNICATIONS

SYSTEM

TOTAL SYSTEM

COMMUNICATIONS

EQUIPMENT

Figure 1.1 Context of Operation

8/2/2019 DEFSTAN_21-24_I-2_2000

20/102


1.4

1.1.3 Message Routeing and Filtering

a. The interface supports two types of message routeing, namely pointtopointand broadcast. Pointtopoint messages pass between two specific terminalunits, the source and the destination, and the source identifies the destination

by a unique terminal unit address. Broadcast messages, however, have adestination address of zero and are received by all terminal units.

b. Provision is made within the interface for the host computer to apply a filterto incoming broadcast short messages so that, although the terminal unitreceives all the broadcast short messages, only those preselected by the hostare passed to the host. The filtering is achieved by the concept of `MessageType Numbers' (MTNs). Each broadcast short message is associated with anMTN by its originator and the MTN forms part of the message header. Eachhost computer informs its own terminal unit of the MTNs that it wishes toreceive and thus the filtering is achieved. The assignment of MTNs is beyondthe scope of this NES. However, the MTN mechanism is operated through the

NES 1024 interface, and so some understanding of the concept is required.c. The administration of MTNs has to be done globally across all the user systems

on the communications medium. The actual usage may vary. MTNs may beused to:

(1) Achieve multicast addressing, so that a source can send messages to apredetermined group of systems.

(2) Identify the function of the message so that any system can subscribe tothe data by selecting the MTN. In this case the source has no priorknowledge of the subscribers.

(3) Achieve terminal number independence, for the assignment of an MTN

to a message enables that message to be received by a destinationfunction whose terminal unit address is not fixed (i.e. it can be in any oneof a number of host systems).

d. The MTN filtering facility is only available to short message broadcasts.

1.1.4 Time Synchronization

a. In realtime distributed systems, as data is passed around, the passage of timemay be significant. The time at which measurements are made is importantif the value can have significantly changed before the measured data is used.

b. The NES 1024 interface specification includes specific provision for the receiptof time synchronization messages that are generated elsewhere within the

communications network. These messages form the basis of the common timeframe of reference available to all member systems of the total system.

1.1.5 Stimulation

a. The occurrence of events (e.g. message arrival) can be detected by the hostcomputer or the terminal unit by looking periodically at specific locations.However, there are circumstances in which the response may not be adequate(e.g. on receipt of a time synchronization message). The interface standardprovides two mechanisms to expedite response:

(1) An alert from the host computer to the terminal unit.

(2) An interrupt from the terminal unit to the host computer.

However, the employment of these mechanisms is totally dependent upon thearchitectural features of both the host computer and the terminal unit.

8/2/2019 DEFSTAN_21-24_I-2_2000

21/102


March 2000

1.5

1.1.6 Adaptation

a. In an implementation compliant with the NES 1024 Electrical Interface a hostadapter unit is provided. This is in order to achieve the objective ofcompatibility between NES 1024 and different host computers. This unit is

supplied with word addresses by the host computer for accessing the relevantmemory locations.

Note that these addresses are not necessarily as generated by the compiler orlinker.

During the initialization process, both the host computer and the terminal unithave to configure their operations into mutually acceptable forms. Thefeatures that must be configured are:

(1) The host computer ability to generate terminal unit alerts.

(2) The terminal unit ability to accept alerts.

(3) The terminal unit ability to generate host computer interrupts.

(4) The host ability to accept terminal unit interrupts.

1.1.7 Testing

a. The host computer controls the working mode of the terminal unit. FollowingInitialization (see Clause 1.4) the terminal unit adopts `idle mode'. The hostcomputer may then set the terminal unit into normal operational mode or intoa test mode. Normal operational mode is invoked when:

(1) The member system is contributing to the fulfilling of the assigned taskof the total system.

(2) The member system is connected to a simulator.

b. Test modes are modes in which the member system or the host computer andthe terminal unit can establish their operational availability. This NES doesnot include standard tests or test result returns but it does provide a standardframework within which testing of many types can be performed. Individualtest modes may be assigned to various types of testing, as follows:

(1) Testing which is internal to the terminal unit and requires noparticipation by the host except initiation. The terminal unit wouldmerely report back success or failure.

(2) Testing which involves program execution in the host and requires theterminal unit output stage to be reconfigured, isolating the output fromthe network, and perhaps substituting a `loop back' facility (either by

logic in the terminal unit or by manual disconnection from the networkand the application of shorting plugs).

(3) Testing which involves some limited participation with equipmentexternal to the member system (either the total system or a simulator).Such participation may be the acceptance of polls, or test accesses to thenetwork.

1.1.8 Summary

a. In summary the interface is designed for use by computers within membersystems forming a distributed total system within which a commoncommunications medium is used for data exchange. The interface is as

independent as possible of both communications and computer architectures.The interface provides a common standard irrespective of either the hostcomputer, the terminal unit computer or the communications standard.

8/2/2019 DEFSTAN_21-24_I-2_2000

22/102


1.6

1.1.9 Principles of Implementation

a. The operation of the interface requires three types of data areas, namely:

(1) Shared data areas.

(2) Terminal unit specific data areas.(3) Host computer specific data areas.

b. The shared data areas require memory which is accessible by both the hostcomputer and the terminal unit. This commonly accessible memory may belocated in either:

(1) The host computer, or

(2) the terminal unit.

c. The two alternative implementations are shown in Figure 1 and Figure 2 of thescope.

d. The second configuration, with the terminal unit owning the commonly

accessible memory, has the advantage that it presents least load to the hostDMA mechanism. With all the memory owned by the host computer, bothterminal unit and host central processing unit constantly compete for use ofthe host DMA mechanism, whereas with the second configuration, theterminal unit can access the commonly accessible memory independently, andthe contention can only occur when both host central processing unit and theterminal unit wish to access this commonly accessible memory simultaneously.

e. It is mandatory that commonly accessible memory in the terminal unit isaddressable by the host computer as part of its physical address space. Theterminal unit memory is therefore accessed by the host computer as if it werepart of the host computer.

f. The terminal unit may either contain private memory for its own specific dataareas or it may contain no such memory and therefore require a portion of thecommonly accessible memory for its own use.

g. In order to make such options within the terminal unit transparent to the hostcomputer, the commonly accessible memory must always contain provision fora terminal unit specific data area. Whether this area is used or not is dependentupon individual terminal unit design.

h. After the assignment of the shared data areas and the terminal unit specificareas, the balance of the commonly accessible memory is to be considered asthe property of the host computer and therefore not available to the terminalunit. Consequently, the host computer may use this balance as if it were its owndedicated memory. However, if the commonly accessible memory is owned bythe terminal unit, it may differ in some physical characteristics (e.g. accesstime) from that of memory supplied as part of the host computer.

Only those commonly accessible memory locations which are defined tocontain the shared data areas and the terminal unit specific data areas are tobe accessed by the terminal unit. In an implementation using the NES 1024Electrical Interface the responsibility for ensuring this rests with thecommunications unit.

i. Within the constraints of its own memory mapping, the host computer is freeto locate the host specific data areas anywhere in its memory space except that

occupied by the shared data areas and the terminal unit specific data areas.The location of the host specific data areas is of no concern to the terminal unitdesigner.

8/2/2019 DEFSTAN_21-24_I-2_2000

23/102


March 2000

1.7

j. The minimum size of the commonly accessible memory is to be that which isnecessary to accommodate both the shared data areas and the terminal unitspecific data areas.

k. In most cases the host computer software will be quite separately compiled

from that of the terminal unit. This means that the software in the terminalunit will need to access the shared data areas and perhaps even its own specificdata areas which are, in fact, both declared in the host's software.

l. A common mechanism for overcoming this problem is by linking through someabsolute addressing mechanism. The amount of linking is minimized by usinga single absolute link to establish a datum and all the addresses of data withinthe shared data can be found with knowledge of that datum.

m. The simplest way of maintaining a known memory address relationship is tokeep data in contiguous memory areas. This standard defines the followingfive individually contiguous memory areas:

(1) Control and Status Table.

(2) Input Table.

(3) Output Table.

(4) Message Type Table.

(5) Terminal Unit Data Area.

It should be noted that the way in which these tables are stored in hostcomputer memory is dependant on the host computer word size (see Clause1.2c.). These five areas may themselves be contiguous but this is not

mandatory.n. The Control and Status Table is the `keystone' element in the addressing of

data in the memory in which it is located. The Control and Status Tableaddress is the datum that is made known to both host computer and terminalunit.

NOTE The address of the Control and Status Table is not necessarily asgenerated by the compiler or linker.

o. The Control and Status Table will contain various shared fields namely:

(1) Interface Control (e.g. mode control, interrupt masks).

(2) The location of other areas of shared data (e.g. Input Table).

(3) Short and long message control fields.

(4) Communication status and configuration details (e.g. number of buffers,terminal unit number, error counts).

(5) Time Synchronization data and control.

The location in host memory of these areas is defined at the time ofinitialization and may only be changed on reinitialization. All areas must beaccessible by both the host and the terminal unit.

When a long message transfer is initiated the host will need to reference furthermemory areas to use for incoming or outgoing long message data. These longmessage data areas must be accessible by both the host and the terminal unit.

8/2/2019 DEFSTAN_21-24_I-2_2000

24/102


1.8

OUTPUT TABLE

CYCLIC BUFFERS FOR

SHORT MESSAGE OUTPUT

MESSAGE TYPE TABLE

INPUT SELECTION OF

BROADCAST SHORT

MESSAGES

INPUT TABLE

CYCLIC BUFFERS FOR

SHORT MESSAGE INPUT

TERMINAL UNIT DATA AREA

CONTROL AND STATUS TABLE

INTERFACE CONTROL

LOCATION OF TABLES

SHORT MESSAGE OUTPUT CONTROL

SHORT MESSAGE INPUT CONTROL

LONG MESSAGE OUTPUT CONTROL LONG MESSAGE INPUT CONTROL

COMMUNICATIONS STATUS

TIME SYNCHRONIZATION

Figure 1.2 Data Areas

8/2/2019 DEFSTAN_21-24_I-2_2000

25/102


March 2000

1.9

p. The addresses of the other tables held in the Control and Status Table will beword addresses in a form compatible with the host adapter unit and may be upto 32 bits in size.

NOTE These addresses are not necessarily as generated by the compiler or

linker.

q. The Input and Output Tables will hold the cyclic buffers for short messageinput and output respectively. The Message Type Table will contain theinformation for filtering broadcast short messages. The terminal unit Data

Area will be reserved for the use of the terminal unit. Figure 1.2 summarizesthis.

1.2 Scope of the Software Interface Specification

a. Clauses 1.3 to 1.6 inclusive of this standard define the software interfacebetween a host computer and a terminal unit. The software interface identifies

all the necessary data areas and associated protocols. Clauses 1.2b. to 1.2g. arean essential preface to Clauses 1.3 to 1.6.

b. The following specification assumes that:

(1) The host's central processing unit and the terminal unit may both accesscommon memory areas.

(2) The host computer's access and the terminal unit's access of commonmemory is completely asynchronous, and there is no means wherebyeither can lock the other out either temporarily or permanently.

(3) The readmodifywrite access to the common memory area available to

either may be divisible (therefore the protocols do not rely uponindivisible readmodifywrite).

(4) There may be means by which the terminal unit can raise interrupts tothe host computer (NES 1024 uses only a single type).

(5) There may be means by which the host computer can alert the terminalunit (NES 1024 uses only a single type).

1.3 Shared Data Area Specifications

a. Clause 4 restricts write access to certain fields in common memory to the hostonly or to the terminal unit only. It is the responsibility of the host system

designer and the terminal unit designer to enforce this. The effect of illegalwrite accesses is, in general, undefined.

b. The specifications are partially expressed in terms of CORAL 66 declarationsand statements; see BS 5905. This is only for convenience, and a successfulimplementation is not dependent upon the availability of CORAL 66.

8/2/2019 DEFSTAN_21-24_I-2_2000

26/102


1.10

c. In the following specifications where field sizes and contents are specified, theyare defined as follows:

(1) The byte length is 8 bits.

(2) Bit position in the byte is numbered from zero upwards, with the leastsignificant bit of a byte occupying bit position zero.

(3) Byte position within the word is numbered from zero upwards, with theleast significant byte occupying the least significant 8 bits of the word(0-7). This does not conform with some unofficial extensions of CORALto include byte arrays.

(4) Word position and the bit position within the word will be numberedfrom zero upwards, and the least significant bit of a word will occupy bitposition zero. This conforms to the Official Definition of CORAL 66.

(5) With the exception of the data for long message transfers, only 2 bytesper word are required (i.e. 16 bits). If any host or terminal unit wordlengths are greater than 16 bits, then only the least significant 16 bits areto be used (see Figure 1.3).

(6) The number of bytes per word to be transferred may be specified in longmessage transfers. The numbering will commence from the leastsignificant byte of a word (see Figure 1.4). Null bytes may be requiredto bring the number of bytes to a complete word length.

d. In the following specifications, the terms input and output are relative to thehost computer and are used as follows:

(1) Inputrefers to message flow that is input to the host computer from theterminal unit (i.e. the terminal unit has received the message from thecommunications medium).

(2) Outputrefers to message flow that is output from the host computerto the terminal unit (i.e. the terminal unit has to transmit the messageon to the communications medium).

e. The term preset value, applied to a field, means that the value should either:

(1) Appear in the compiled binary output, or

(2) Be dynamically loaded before the field could be read across the interface.

f. Where the value of a field is specified, hexadecimal numeration is used.

g. This specification imposes limits to various parameters such as:

Terminal Unit Number 0 to 255

Message Type Number 0 to 65535

Number of Input/Output Buffer 0 to 255

Any particular implementation may be able to support only a subset of theavailable ranges (e.g. 64 terminals and 512 MTNs).

8/2/2019 DEFSTAN_21-24_I-2_2000

27/102

1.11

15 14 13 12 11 10 9 8 7

16 BIT WORD

24 BIT WORD

23 22 21 20 19 18 17 16

7

32 BIT WORD

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 831 30 29 28 27 26 25 24

BYTE 3BYTE 5

BYTE 1

BYTE 3

BYTE 5

BYTE 1

BYTE 3

BYTE 5

BYTE 1

Figure1.3

Bytes/WordWorking

8/2/2019 DEFSTAN_21-24_I-2_2000

28/102

1.12

15 14 13 12 11 10 9 8

2 BYTES/WORD SPECIFIED

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

15 14 13 12 11 10 9 8


23 22 21 20 19 18 17 1631 30 29 28 27 26 25 24

15 14 13 12 11 10 9 8


23 22 21 20 19 18 17 1631 30 29 28 27 26 25 24

BYTE TRANSFERRED

BYTE NOT TRANSFERRED

Figure1.4LongMessag

eBytes/WordSelection

8/2/2019 DEFSTAN_21-24_I-2_2000

29/102


March 2000

1.13

1.3.1 Control and Status (C & S) Table

a. The table consists of a number of fields and by definition they are contiguous.The various fields may be grouped to cover the following functions.

Interface control

Location of tables

Short message input control

Short message output control

Communications status

Long message input control

Long message output control

Time synchronization

1.3.2 C & S Table: Interface Control

a. `Host Control' This byte field is to be preset to `00' and thereafter updated bythe host computer only. The field is to contain the working mode to be adoptedby the terminal unit, as determined by the following assignments:

00 idle mode

01 real mode

02-06 test modes

07 reinitialize

08-FF illegal values

b. `TU Status' This byte field is to be preset to `FF' and thereafter updated by theterminal unit only. The field is to contain the current working mode ofterminal unit, as defined by the following assignments:

00 idle mode

01 real mode

02-06 test modes

07 reinitialize

08 reset in progress

09-FE illegal values

FF uninitialized

On detection of an error which causes the terminal unit to cease operation itmay optionally indicate this to the host computer by setting this field to`uninitialized'.

8/2/2019 DEFSTAN_21-24_I-2_2000

30/102


1.14

c. `Host Capability' This byte field is to be preset with an indication of whetherthe host computer is capable of alerting the terminal unit or not. The field isnot to be modified by either the host computer or the terminal unit. Theterminal unit is to use the field to determine whether or not an alert drivenmode of working can be adopted. The bit assignments of the field are :

bit 0 Host capable of alerting TU

bits 1-7 Not Used, preset to zero.

Bits are to be set to 1 if and only if the corresponding statement is true.

d. `TU Capability' This byte field is to be loaded by the terminal unit atinitialization with an indication of whether the terminal is capable ofinterrupting the host computer or not. Once loaded, the field is not to bemodified by either the terminal unit or the host computer. The host computer

is to use the field to determine whether or not an interrupt driven mode ofworking can be adopted. The bit assignments of the field are :

bit 0 TU capable of interrupting Host

bits 1-7 Not Used, preset to zero.

Bits are to be set to 1 if and only if the corresponding statement is true.

e. `Host Attention' This byte field is to be preset to 00'. Both the host computerand the terminal unit will update the field. The terminal unit is to set the field

to '01' if, and only if, the field is `00'. The host computer is to set the field to'00' if, and only if, the field is `01'. The field is to be set `01' by the terminalunit to notify the host computer of the occurrence of a significant event (see`Host Int Mask'). The host computer is to indicate the acceptance of thenotification by setting the field to `00'. The values `00' and 01' are the onlylegal values for this field.

f. `TU Attention' This byte field is to be preset to 00'. Both the host computerand the terminal unit will update the field. The host computer is to set the fieldto `01' if, and only if, the field is `00'. The terminal unit is to set the field to `00'if, and only if, the field is `01'. The field is to be set `01' by the host computerto notify the terminal unit of the occurrence of a significant event within thehost computer (see `TU Int Mask'). The terminal unit is to indicate theacceptance of the notification by setting the field to `00'. The values `00' and'01' are the only legal values for this field.

g. `Host Int Mask' This byte field is to be preset to `00'. This field is set up bythe host computer during the startup protocol, in accordance with `TUCapability'. The field may be updated by the host computer alone, and thenif, and only if, the terminal unit is capable of interrupting the host computer.The individual bits of the field are to be associated with significant eventswithin the terminal unit. The setting of the individual bits of the field is toindicate whether the host computer wishes the terminal unit to raise an

interrupt on the occurrence of the associated event. A bit set to `zero' is to meanthat no interrupt is required, whereas a bit set to `one' is to indicate that aninterrupt is required. The bit assignments of the field are as follows:

8/2/2019 DEFSTAN_21-24_I-2_2000

31/102


March 2000

1.15

bit 0 Adoption of new mode

bit 1 Completion of loading a short message in an input bufferand (n+1) input buffers are now loaded. Where n isdefined as the number in the Ìn Int Count' field

bit 2 Completion of sending a short message from an outputbuffer

bit 3 Completion or termination of input of a long message

bit 4 Completion or termination of output of a long message

bit 5 Completion of loading a time synchronization message

bit 6 Detection of communication and interface faults

bit 7 Not used, preset to zero

h. `TU Int Mask' This byte field is to be preset to 00'. The field may be updatedby the terminal unit alone, and then if, and only if, the host computer is capableof alerting the terminal unit. The individual bits of the field are to be associatedwith significant events within the host computer. The setting of the individualbits of the field is to indicate whether the terminal unit wishes the hostcomputer to raise an alert on the occurrence of the associated event. A bit setto `zero' is to mean that no alert is required whereas a bit set to òne' is toindicate that an alert is required. The bit assignments of the field are asfollows:

bit 0 Change mode required in terminal

bit 1 Completion of loading a short message in an output bufferbit 2 Completion of preparation for a long message output

bit 3 Completion or preparation for a long message input

bits 4-7 Not used, preset to zero

1.3.3 C & S Table: Location of Tables

a. Ìnput Table Location' This 4byte field is to be preset with the base addressof the Ìnput Table' which contains the input buffers for short messages. Itmust not thereafter be modified by either the host computer or the terminalunit. The address provided must be a word address in a form compatible with

the host adapter unit. The content of this field is not defined if the field`Number of In Buffers' contains the value zero.

b. Òutput Table Location' This 4byte field is to be preset with the base addressof the Òutput Table' which contains the output buffers for short messages.The field must not thereafter be modified by either the host computer or theterminal unit. The address provided must be a word address in a formcompatible with the host adapter unit. The content of this field is not definedif the field `Number of Out Buffers' contains the value zero.

c. `Type Table Location' This 4byte field is to be preset with the base addressof the `Message Type Table' which contains the selection information for

broadcast short messages. The field must not thereafter be modified by eitherthe host computer or the terminal unit. The address provided must be a wordaddress in a form compatible with the host adapter unit.

8/2/2019 DEFSTAN_21-24_I-2_2000

32/102


1.16

d. `Terminal Unit Data Area Location' This 4byte field is to be preset with thebase address of the `TU Data Area' which is for specific use of the terminal unit.The field must not thereafter be modified by either the host computer or theterminal unit. The address provided must be a word address in the formcompatible with the host adapter unit.

1.3.4 C & S Table: Short Message Input Control

a. `Number of In Buffers' This byte field is to be preset with the number of inputbuffers contained in the input table. The field may be set to any value in therange 0 to 255. This field determines the size of the Input Table'. The fieldmust not thereafter be modified by either the host computer or the terminalunit.

b. `In Int Count' This byte field is to contain the number of input buffers thathave to be already filled and not yet processed by the host computer before theloading of a further input buffer causes the host computer to be interrupted

by the terminal unit. If the terminal unit is capable of interrupting the hostcomputer and the relevant bit is set in the `Host Int Mask' and the number ofinput buffers filled and not yet processed by the host computer is greater thanthe value of the field then the terminal unit should raise an interrupt. The fieldis to be preset to `00' and thereafter modified by the host computer alone. Therange of permissible values is from `00' to `Number of In Buffers'1.

When an incoming validated short message is loaded into an input buffer bythe terminal unit, the host computer will be stimulated according to the fieldsetting as follows;

00 Every time.

01 When one or more previously loaded input buffers have yetto be processed by the host.

02 When two or more previously loaded input buffers haveyet to be processed by the host.

`n' When n' or more previously loaded input buffers have yetto be processed by the host.

NOTE The terminal unit is to set `Host Attention' to `01' for each and everyinput buffer loaded, regardless of the content of this field.

c. `First Type Block' This byte field is to be preset to the block number of the firstmessage type block in the message type window in the message type numberspace. The field must not thereafter be modified by either the host computeror the terminal unit. The terminal unit is to use the field to determine whetherthe MTN of an incoming broadcast short message is below or above the startof the window. The permissible range of values for this field is from `00' to `FF'.

d. `Last Type Offset' This byte field is to be preset to the offset of the last messagetype block in the message type window measured relative to the first messagetype block in the window. Figure 1.5 illustrates the MTN window concept. Thefield must not thereafter be modified by either the host computer or theterminal unit. The terminal unit is to use the field to determine whether the

MTN of an incoming broadcast short message is within or above the window.This field determines the size of the message type window and consequentlythe size of the message type table. Message `Type Table' size is given by:

8/2/2019 DEFSTAN_21-24_I-2_2000

33/102


March 2000

1.17

[(blocks in window) x (MTNs/block) / (no. of bits/word)] wordsi.e. [(`Last Type Offset'+1) x (256) / (16)] words

The no of bits/word is 16 regardless of the actual machine bits/word size. Thepermissible values for this field are:

00 a single block window, always valid01-FF window size from 2 blocks to 256 blocks, but to be valid

`First Type Block' + `Last Type Offset' 255

Details of the definition and use of the Message Type Table window mechanismcan be found in Section 1.3.12.

1.3.5 C & S Table: Short Message Output Control

a. `Number of Out Buffers' This byte field is to be preset with the number ofoutput buffers contained in the output table. The field may be set to any valuein the range 0 to 255. This field determines the size of the Output Table'. Thefield must not thereafter be modified by either the host computer or the

terminal unit.1.3.6 C & S Table: Communications Status

a. `Terminal Unit Number' This byte field is to contain the number, preset withinthe terminal unit, by which the terminal unit is known to the communicationssystem, and this field provides the means by which the host computer is madeaware of the terminal unit's address within the communications system. Thefield is to be set by the terminal unit on initialization or reinitialization.

b. `Receive Error Count' This 2byte field is to contain an unsigned count oferroneous messages detected by the terminal unit. The field is to be preset tozero and is to be incremented by the terminal unit each time it detects anerroneous message. When the counter is full, the next increment is to cause

it to go to zero and it is then to be incremented as before. Each transition ofthis field from value `0000' to value `0001' causes the appropriate fault to bereported in the `TU Fault Done' field. This field is intended as acommunications system performance quality monitoring field.

c. `In Overflow Count' This 2byte field is to be used to store an unsigned countof the number of times the terminal unit is unable to write to the input bufferbecause that buffer is filled by messages that have not been unloaded by thehost computer. The field is to be preset to zero and incremented by the terminalunit each time an overflow occurs. When the counter is full, the next incrementis to cause it to go to zero and it is then to increment as before. Each transitionof this field from value `0000' to value `0001' causes the appropriate fault to

be reported in the `TU Fault Done' field. This field is intended as an interfaceperformance quality monitoring field.

d. `Data Starvation Count' This 2byte field is to store an unsigned count of thenumber of times the terminal unit is unable to obtain data from or transferdata to its computer host sufficiently rapidly to maintain the output/input ofa message (i.e. the DMA transfer rate is inadequate). The field is to be presetto zero and be incremented by the terminal unit each time starvation occurs.

When the counter is full, the next increment is to cause it to go to zero and itis then to increment as before. Each transition of this field from value `0000'to `0001' causes the appropriate fault to be reported in the `TU Fault Done'field. This field is used if either or both the input table (containing the input

buffers) and the output table (containing the output buffers) are held incommon memory owned by the host computer. This field is intended as aninterface performance quality monitoring field.

8/2/2019 DEFSTAN_21-24_I-2_2000

34/102


1.18

e. `Retransmission Count' This 2byte field is to store an unsigned count of thenumber of `repeat transmission' requests received by the terminal unit. Thefield is to be preset to zero and be incremented by the terminal unit each timeit receives a retransmission request. When the counter is full the nextincrement is to cause it to go to zero and it is then to increment as before. Eachtransition of this field from value `0000' to value `0001' causes the appropriatefault to be reported in the `TU Fault Done' field. This field is intended as acommunications system performance quality monitoring field.

f. `Medium Status' This byte field is to used by the terminal unit to report thestatus of the communications medium. The field is to be preset to `00' andthereafter modified by the terminal unit alone. The content of the field will beboth medium type dependent and medium configuration dependent. Thedefinition of this field is to be found in individual terminal unit specifications.

g. `TU Fault Done' This 2byte field is to be preset to `FFFF'. When the hostcomputer requires the terminal unit to commence fault reporting, the host

computer is to set the field to '0000' and thereafter must not modify it unlessit is nonzero. When a fault is detected, the terminal unit is to load the fieldwith a nonzero completion code identifying the detected fault if, and only if,the field is `0000'. On detection of a completion code, the host computer is toset the field to `0000' if further fault reports are required, otherwise it is to setthe field to `FFFF'. If the terminal unit is unable to set the field because it is`FFFF' it is to ignore the fault and take no further action. If the terminal unitis unable to set this field because it is nonzero and non`FFFF' it is to bufferfaults until the field is set to `0000' by the host. The terminal unit may reportmore than one fault at a time by setting the appropriate bits. The bitassignments of the field are:

bit 0 change in Medium Status' fieldbit 1 lost access to medium

bit 2 irrecoverable message loss has occurred

bit 3 reset received from communications medium

bit 4 retransmission count commenced

bit 5 receive error count commenced

bit 6 in overflow error count commenced

bit 7 data starvation count commenced

bit 8 Òut Buffer Length' incorrect

bit 9 Control and Status Table illegal value

bits 10-15 Reserved for future use

1.3.7 C & S Table: Long Message Input Control

a. Ìn Long Address' This 4byte field is to contain the base address of the longmessage data area into which the terminal unit is to write an expectedincoming long message. The field is to be set by the host computer prior to thecommencement of message reception. The address is to be of a word incommon memory and must be in a form compatible with the host adapter unit.

The terminal unit is not to modify this field. The minimum size of the data areais to be ((Ìn Long Length' + Ìn Long Pack') div (Ìn Long Pack' + 1))*(Ìn LongPack' + 1) bytes.

8/2/2019 DEFSTAN_21-24_I-2_2000

35/102


March 2000

1.19

b. Ìn Long Length' This 2byte field is to contain the number of bytes expectedin the incoming long message. The field is to be set by the host computer priorto the commencement of the long message input. The host computer will resetthis field to zero if an abort of the long message transfer is required. Theterminal unit is not to modify this field.

c. Ìn Long Pack' This byte field utilizes two bits to indicate the number ofincoming bytes that the terminal unit must pack into each computer word.The field is to be preset to `00' and thereafter modified by the host computeralone. If the field is modified, it must be prior to the commencement of longmessage reception. The assigned values of bits 0 and 1 are:

0 1 byte/word

1 2 bytes/word

2 3 bytes/word

3 4 bytes/word

The terminal unit is not to modify this field.

d. Ìn Long Source' This byte field is to contain the terminal unit number of thesource system from which the long message is expected. The field is to be setby the host computer prior to the commencement of long message reception.The terminal unit is not to modify this field.

e. Ìn Long Done' This byte field is used to initiate and terminate messagereception. The field is to be preset to 'FF'. The host computer is to set the fieldto zero when it has set all the necessary fields for long message input. The zerovalue is to indicate to the terminal unit that the host computer is ready for longmessage reception. The field is to be set to a nonzero completion code by theterminal unit when the transfer of the long message to the data area set up bythe host computer has been successfully completed or has been abnormallyterminated. The completion codes are assigned as follows:

01 successful completion

02 host setup error

03 input aborted

04-FE terminal unit program error

FF not permitted

Following receipt of a completion code the host computer is to set the field to`FF'.

1.3.8 C & S Table: Long Message Output Control

a. Òut Long Address' This 4byte field is to contain the base address of the longmessage data area from which the terminal unit is to read a long message fortransmission. The field is to be set up by the host computer prior to thecommencement of message transmission. The address is to be of a word incommon memory and must be in a form compatible with the host adapter unit.

The terminal unit is not to modify this field. The minimum size of the data areais to be ((Òut Long Length' + Òut Long Pack') div (Òut Long Pack' +1))*(Òut Long Pack' + 1) bytes.

8/2/2019 DEFSTAN_21-24_I-2_2000

36/102


1.20

b. Òut Long Length' This 2byte field is to contain the number of bytes in thelong message to be transmitted. The field is set by the host computer prior tocommencement of the long message transmission. The host computer willreset this field to zero if an abort of the long message transfer is required. Theterminal unit is not to modify this field.

c. Òut Long Pack' This byte field utilizes two bits to indicate the number of bytesthat the terminal unit is required to take from each computer word. The fieldis to be preset to `00' and thereafter modified by the host computer alone. Ifthe field is modified, it must be prior to the commencement of long messagetransmission. The assigned values of bits 0 and 1 are:

0 1 byte/word

1 2 bytes/word

2 3 bytes/word

3 4 bytes/word

The terminal unit is not to modify this field.

d. Òut Long Destination' This byte field is to contain the terminal number ofthe destination system to which the block transfer is directed. The field is tobe set by the host computer prior to the commencement of long messagetransmission. If the field is set to zero, the long message transmission will bebroadcast and will be available to all those terminal units that are set up toreceive it. The terminal unit is not to modify this field.

e. Òut Long Done' This byte field is used to initiate and signify termination oflong message transmission. The field is to be preset to `FF'. The host computeris to set the field to zero when it has set all the necessary fields for long messageoutput. The field is to be set to a nonzero completion code by the terminal unitwhen the transfer of the long message has been successfully completed or hasbeen abnormally terminated. The completion codes are assigned as follows:


02 host setup error

03 output aborted


FF not permitted

Following receipt of a completion code the host computer should set the fieldto `FF'.

1.3.9 C & S Table: Time Synchronization

a. Ìn Time' This 12byte field is to contain the time synchronization data. The

field is to be loaded by the terminal unit on receipt of a time synchronizationmessage from the communication medium, provided the Ìn Time Done' fieldis zero.

8/2/2019 DEFSTAN_21-24_I-2_2000

37/102


March 2000

1.21

b. Ìn Time Done' This byte field is to be used to initiate time data transfers tothe host computer and to indicate the reception of time synchronization databy the terminal unit. The field is to be preset to `FF'. The host computer isto set the field to zero if it wishes to receive time synchronization data,otherwise it is to set the field to `FF'. If, and only if, the field is zero, theterminal unit is to set the field to a nonzero completion code provided that thereceived message has been error free and that the time data has been enteredinto Ìn Time'. The completion codes are assigned as follows:



FF not permitted

The host computer is to clear the field if it wishes to receive further time data,otherwise it is to set the field to `FF'.

1.3.10 Input Table and Output Tablea. These two tables contain the buffers which are used for short message

reception and transmission. The sizes of the two tables are determined by theshort message maximum size and the number of buffers in the table. Thelocations of the two tables, and the numbers of buffers that they contain areto be found in the Control and Status Table fields:

Ìnput Table Location'

`Number of In Buffers'

Òutput Table Location'

`Number of Out Buffers'

b. Each of these tables consist of a set of contiguous equalsized buffers, the buffersize being the short message maximum length of 64 bytes. The input andoutput buffers have a common structure which consists of header fields and adata field.

c. Ìnput Table' This table is to be a contiguous memory area aligned on a wordboundary. Its size in bytes is to be:

64 x `Number of Input Buffers'

The input buffers so provided are to be numbered from zero upwards, and thewords in each buffer also numbered from zero upwards. Word zero of bufferzero is to be located at the address held in 'Input Table Location'.

d. Òutput Table' This table is to be a contiguous memory area aligned on a wordboundary. Its size in bytes is to be:

64 x `Number of Output Buffers'

The output buffers so provided are to be numbered from zero upwards, and thewords in each buffer also numbered from zero upwards. Word zero of bufferzero is to be located at the address held in Òutput Table Location'.

1.3.11 Fields in Input and Output Buffers

a. As these have a common structure, they are defined together in the followingparagraphs. The Buffer Length, Source, Destination and Message Type fieldsconstitute the header.

8/2/2019 DEFSTAN_21-24_I-2_2000

38/102


1.22

b. Ìn Buffer Length, Out Buffer Length' This 2byte field is to be preset to zero.The field is to be loaded with the number of words (including itself) in thebuffer that contains valid information. A value of zero is to indicate that thebuffer is free.

(1) Ìn Buffer Length' is loaded by the terminal unit when a complete shortmessage has been assembled by the terminal unit, and cleared by the hostcomputer when the data has been consumed.

(2) Conversely Òut Buffer Length' is loaded by the host computer when acomplete short message has been assembled by the host computer, andcleared by the terminal unit when it has successfully transmitted themessage.

c. Ìn Source, Out Source' This byte field is to be reserved for the terminalnumber of the sending system. Ìn Source' is to be loaded by the terminal unitfrom an incoming message. Òut Source' is a terminal unit specific field, it

reserves space for the terminal unit to insert terminal number prior to messagetransmission. The host computer has no need to load this field, and if it doesthe value loaded is ignored and may be overwritten by the terminal unit.

d. Ìn Destination, Out Destination' This byte field is to contain the terminalnumber of a message's destination. Ìn Destination' is to be loaded by theterminal unit from an incoming message and it must be either zero for abroadcast message or the terminal unit's own terminal number in the case ofa pointtopoint message. Òut Destination' is loaded by the host computerwith either the terminal number of the intended recipient or zero if themessage is to be broadcast.

e. Ìn Message Type, Out Message Type' This 2byte field is to contain themessage type number which is used for selection of broadcast short messages.

(1) Ìn Message Type' is to be loaded by the terminal unit from an incomingmessage. If the incoming message is of the broadcast type, then thecontent of In Message Type' must always correspond to one of the valuesthat the host computer has placed in the message type table, for theterminal unit must only transfer to the host those broadcast messagesthat the host has selected. If the incoming message is of thepointtopoint type, the host computer is to receive the message type assent by the source system, and no message selection is to take place.

(2) Òut Message Type' is to be loaded by the host computer and is to be readby the terminal unit. The field is to be loaded irrespective of whether themessage is broadcast or pointtopoint. If pointtopoint, the outgoingmessage will always be received by the intended destination, but ifbroadcast, only those host computers which have selected the messagetype loaded will actually have the message passed to them from theirterminal unit.

f. Ìn Data, Out Data' This 58byte field is to contain the data being passedbetween the users of the NES 1024 interface. The field is the balance of thebuffer not used by the header fields already described. Ìn Data' is to be loadedby the terminal unit and is to be read by the host computer. Òut Data' is to

be loaded by the host computer and is to be read by the terminal unit. The dataloaded into the field need not occupy the whole field. The extent of the validdata is to be determined by the Buffer Length Field.

8/2/2019 DEFSTAN_21-24_I-2_2000

39/102


March 2000

1.23

1.3.12 The Message Type Table

a. The message type table is a bit map where each bit corresponds to an MTN.Each time a terminal unit receives a broadcast message, the terminal unit hasto access the table to see if the host computer requires the message. This

imposes a load upon the shared memory which is directly related to the amountof broadcast traffic on the communications medium. Furthermore in the caseof the NES 1024 Electrical Interface a corresponding load will be imposed uponthe interface itself.

b. There are 16 bits assigned for MTNs, giving a range of MTNs from 0 to 65535.Full usage of this range would require 8192 bytes for the bit map. Few hostcomputers will require MTNs spanning the entire range and NES 1024 permitsthe host computer to define a `window' within it. The message type table hasonly to be sufficiently large to accommodate those MTNs which the hostrequires to select (see Figure 1.5).

c. The terminal unit can reject all MTNs falling outside the window by simplearithmetic tests. Consequently, the shared memory load (and anycorresponding load on the NES 1024 Electrical Interface) associated withbroadcast messages is limited to only those messages that fall within theselected window (provided that the window parameters are held locally withinthe terminal unit).

d. The terminal unit is only concerned with the location of the table and thewindow parameters. It is the responsibility of the host computer to ensure thatthe table size is consistent with the window size specified.

e. Figure 1.5 illustrates the MTN window concept. The available MTN range of

65536 numbers is divided in to 256 blocks of 256 numbers each, numbered from0 to 255. This division gives a direct correspondence between the block numberand the content of the most significant byte of the MTN.

f. An MTN window consists of a contiguous set of MTN blocks. Consequently,terminal unit window calculations involve only the most significant byte of theMTN. The bit positions in the map constituting the message type table arerelative to the first MTN in the window and not to MTN `00000'.

g. The host computer specifies an MTN window by identifying the start MTNblock number of the window in `First Type Block' and by identifying the offsetblock number of the last block in the window relative to the first block in the

window in `Last Type Block'. This method of specification is selected for easeof computation in the terminal unit. A typical example of a window is shownin Figure 1.5.

h. On receipt of an MTN, the terminal unit normalizes the most significant byteby subtracting the window start block number. If the result is less than zerothe MTN is outside the window. If the normalized byte is greater than theoffset of the last block in the window, then the MTN is again outside thewindow. If the MTN is inside the window, the terminal unit accesses the bitmap in the message type table using a `normalized' MTN (i.e. the mostsignificant byte is normalized, least significant byte is as received). If theappropriate bit is set, the incoming message will be loaded into an input buffer.

The MTN loaded in the input buffer will be the original MTN and not thenormalized derivative used in determining whether the message is wanted ornot.

8/2/2019 DEFSTAN_21-24_I-2_2000

40/102


1.24

i. The use of the MTN field defined herein allows total systems with differentMTN windows to coexist on the same communications medium with nomutual interference as far as MTNs are concerned. It also allows an individualmember system of a given total system to use a smaller window than the fullrange of MTNs in use may suggest, if the MTNs relevant to that membersystem are confined to a subset of the blocks used by the total system.

j. `Message Type Table' This table is to contain the input broadcast shortmessage selection criteria within the selected message type window. Thewindow size and hence the table size is defined by the field `Last Type Offset'as follows:

(`Last Type Offset' + 1) x 256 16 = Length in wordsThe table is to be regarded as a linear array of bits starting with the zeroth bitat bit zero of word zero of the table. A Message Type Number `N' falling in the

window starting at `W' has an offset `n' relative to the window start given by`n' = `N' - `W'. The offset `n' is to correspond to the `n'th bit of the table. Eachbit in the table is to be preset by the host computer. The host computer is toset to one those bits corresponding to the message type numbers it wishes toreceive and to set to zero those bits corresponding to the message type numbersit does not wish to receive. The host computer may alter the settings of the bitsin this table whenever its message type number selection criteria changes. Theterminal unit is not to modify this table.

1.3.13 Terminal Unit Data Area

a. `TU Data Area' This 32 byte contiguous memory area is a reserved space for

the use of the terminal unit. The terminal unit may use the area if it hasinsufficient or no private memory of its own. It is recommended that this dataarea is preset to zero by the host computer.

1.3.14 Summary Figures

a. Figure 1.6 illustrates the fields of the Control and Status Table in thegroupings used here, and Figure 1.7 similarly illustrates the input and outputtables and their respective buffers' fields.

1.3.15 Data Organization

a. The fields so far described are to be organized in a mandatory structure whichis orientated around 16bit word working (machines of greater word lengthmust use only the least significant 16 bits). As byte updating normally involveswriting a word, it is important that a byte updated from one side of theinterface does not share a word with another byte which can be asynchronouslyupdated from the other side of the interface.

b. Thus bytes updated from one side of the interface must share a word witheither:

(1) Another byte updated from the same side, or

(2) A nonupdatable byte, or

(3) Another byte synchronously updated from the other side of the interface.

8/2/2019 DEFSTAN_21-24_I-2_2000

41/102


March 2000

1.25

c. Some bytes are updated from both sides of the interface, and such a byte mustshare a word with either:

(1) Another byte whose updating is synchronous, or

(2) A nonupdatable byte.

d. Some bytes are inserted in the Control and Status table, either for theconvenience of 16bit alignment or because no suitable partner could be foundfor the other byte in the word. Bytes and words which are reserved for futureuse are to be set to `00' until such use is defined.

e. Figure 1.8 provides a word map of the Control and Status Table and Figure 1.9provides a word/byte map of a Short Message Buffer. Figure 1.10 is a CORALdeclaration of the standard format. The layouts shown in Figure 1.8 toFigure 1.10 are mandatory. Figure 1.11 is a summary of the commonlyaccessible memory requirement.

8/2/2019 DEFSTAN_21-24_I-2_2000

42/102


1.26

Figure 1.5 MTN Blocking and MTN Window

8/2/2019 DEFSTAN_21-24_I-2_2000

43/102


March 2000

1.27

FIELD SIZE

(BYTES)

FIELD REFERENCE

HOST CONTROL

TU STATUS

HOST CAPABILITY

TU CAPABILITY

HOST ATTENTION

TU ATTENTION

HOST INT MASK

TU INT MASK

INPUT TABLE LOCATION

OUTPUT TABLE LOCATION

TYPE TABLE LOCATIONTU DATA AREA LOCATION

NUMBER OF IN BUFFERS

IN INT COUNT

FIRST TYPE BLOCK

LAST TYPE OFFSET

NUMBER OF OUT BUFFERS

TERMINAL UNIT NUMBER

RECEIVE ERROR COUNT

IN OVERFLOW COUNT

DATA STARVATION COUNT

RETRANSMISSION COUNT

MEDIUM STATUS

TU FAULT DONE

IN LONG ADDRESS

IN LONG LENGTH

IN LONG PACK

IN LONG SOURCE

IN LONG DONE

OUT LONG ADDRESS

OUT LONG LENGTH

OUT LONG PACK

OUT LONG DESTINATION

OUT LONG DONE

IN TIME

IN TIME DONE

F

DEFSTAN_21-24_I-2_2000

Documents

Transcript of DEFSTAN_21-24_I-2_2000