NASA Conference Publication 2158 Aerospace Applications of Microprocessors Preprint for a workshop held in Greenbelt, Maryland November 3-4, 1980 NASA https://ntrs.nasa.gov/search.jsp?R=19810003136 2020-03-21T16:10:32+00:00Z NASA Conference Publication 2158 Aerospace Applications of Microprocessors Preprint for a workshop sponsored by NASA Goddard Space Flight Center, Greenbelt, Maryland, and the American Institute of Aeronautics and Astronautics, New York, and held in Greenbelt, Maryland, November 3-4, 1980 NASA National Aeronautics and Space Administration Scientific and Technical Information Office 1980 FOREWORD NASA/Goddard Space Flight Center (GSFC), in cooperation with the AIAA Technical Commit- tee on Computer Systems, sponsored this workshop on Aerospace Applications of Microprocessors. The rapidly increasing capabilities and decreasing costs of digital computing systems in general, and microprocessors in particular, have meant orders of magnitude increases in their use in aerospace systems, particularly onboard satellites and aircraft. The objectives of the workshop were to assess the state of microprocessor applications and to identify current and future requirements and associated technological advances which allow effective exploitation of this rapidly advancing technology. There were four sessions in the workshop: I. Air/Space Applications of Microprocessors; II. Ground Based Aerospace Microprocessor Applications; III. Microprocessor Software Technology; and IV. Microprocessor Hardware Technology. This document contains only a synopsis and key figures of each presentation. The synopses and figures were submitted as camera-ready copies prior to the workshop. Only minor editorial changes have been made. In addition to the formal presentations, the workshop was structured to provide time for audi- ence interaction. On the evening of November 3, a panel discussion on "Are Microprocessor - Trends and Aerospace Requirements Heading in the Same Direction?" was held. The panelists were: Terry Straeter, General Dynamics Data Systems Service, (Moderator); Rocky A. Evans, Military Products Manager, Inter Corporation; Adrian Hooke, Jet Propulsion Laboratory; Charles Husson, Langley Research Center; and John Shea, Vice-President Integrated Circuit Electronics. The workshop was organized by a subcommittee of the AIAA technical committee on computer systems. Co-chairmen were: John Sos, Goddard Space Flight Center Terry Straeter, General Dynamics Data Systems Services. Other committee members were: M. Kelly, Sperry Flight Systems; T. McTigue, McDonnell Douglas Aircraft; R. Schwartz, McDpnnell Douglas Astronautics; and T. Smith, NAVAIR Systems Command; and NASA/GSFC members were: E. Connell R. Nelson. Use or identification of commercial products in this document does not constitute an official en- dorsement of such products or their manufacturers, either expressed or implied, by NASA. John Y. Sos Program Co-chairman in Page Intentionally Left Blank CONTENTS FOREWORD iii SESSION I — AIR/SPACE APPLICATIONS OF MICROPROCESSORS Chairman: Adrian Hooke, Jet Propulsion Laboratory 1. AN IMAGING INFRARED (IIR) SEEKER USING A MICROPROGRAMMED PROCESSOR Kerry V. Richmond, McDonnell Douglas Astronautics Co. 2. EIGHT MICROPROCESSOR-BASED INSTRUMENT DATA SYSTEMS IN THE GALILEO ORBITER SPACECRAFT* 7 Robert C. Barry, Jet Propulsion Laboratory 3. A COMMAND & DATA SUBSYSTEM FOR DEEP SPACE EXPLORATION BASED ON THE RCA 1802 MICROPROCESSOR IN A DISTRIBUTED CONFIGURATION 17 Jack S. Thomas, California Institute of Technology 4. SYNERGISTIC INSTRUMENT DESIGN . .. .. 21 Dale E. Winter, Jet Propulsion Laboratory 5. APPLICATION OF MICROPROCESSORS TO INTERPLANETARY SPACECRAFT DATA SYSTEMS. 29 Samuel G. Deese, Jet Propulsion Laboratory 6. THE ROLE OF THE MICROPROCESSOR IN ONBOARD IMAGE PROCESSING FOR THE INFORMATION ADAPTIVE SYSTEM 37 W. Lane Kelly, IV, and Barry D. Meredith, Langley Research Center 7. APPLICATION OF A MICROPROCESSOR TO A SPACECRAFT ATTITUDE CONTROL SYSTEM 47 D. H. Brady and F. W. Hermann, TRW Defense and Space Systems Group 8. A PLASMA WAVE FOURIER TRANSFORM PROCESSOR EMPLOYING 1802 MICROCOMPUTERS FOR SPACECRAFT INSTRUMENTATION 57 Donald C. Lockerson and James N. Caldwell, Goddard Space Flight Center 9. PROTOTYPE DEVELOPMENT OF A MICROPROCESSOR-BASED ONBOARD ORBIT DETERMINATION SYSTEM 65 Keiji D. Tasaki and Rose S. Pajerski, Goddard Space Flight Center SESSION II — GROUND BASED AEROSPACE MICROPROCESSOR APPLICATIONS Chairman: Louis Fulmer, Goodyear 10. THE REMOTE COMPUTER CONTROL (RCC) SYSTEM 69 William Holmes, Goddard Space Flight Center 11. A MICROPROCESSOR APPLICATION TO A STRAPDOWN LASER GYRO NAVIGATOR 73 C. Giardina and E. Luxford, The Singer Company-Kearfott Division 12. THE SPACELAB EXPERIMENT INTERFACE DEVICE (SEID) 79 Ron Kallus and Saul Stantent, Intermetrics 13. G-CUEING MICROCONTROLLER (A Microprocessor Application in Simulators) 93 Chris G. Horattas, Goodyear Aerospace Corporation 14. MICROPROCESSOR SOFTWARE APPLICATIONS FOR FLIGHT TRAINING SIMULATORS 103 Wayne P. Leavy, Goodyear Aerospace Corporation 15. AN EXPERIMENTAL DISTRIBUTED MICROPROCESSOR IMPLE- MENTATION WITH A SHARED MEMORY COMMUNICATIONS AND CONTROL MEDIUM 113 Richard S. Mejzak, Naval Air Development Center 16. DISTRIBUTED MICROPROCESSORS IN A TACTICAL UNIVERSAL MODEM 125 D. M. Gray, J. B. Malnar, and H. Vickers, Harris Corporation . SESSION III — MICROPROCESSOR SOFTWARE TECHNOLOGY 17. MICROCOMPUTER SOFTWARE DEVELOPMENT FACILITIES 133 J. S. Gorman and C. Mathiasen, Ford Aerospace 18. MICROPROCESSOR USER SUPPORT AT LANGLEY RESEARCH CENTER 139 Jerry H. Tucker, Langley Research Center 19. DEBUGGING EMBEDDED COMPUTER PROGRAMS 143 Gilbert H. Kemp, General Dynamics/Western Data Systems Center 20. REAL-TIME OPERATING SYSTEM FOR SELECTED INTEL PROCESSORS 151 W. R. Pool, Ford Aerospace 21. A FOURIER TRANSFORM WITH SPEED IMPROVEMENTS FOR MICROPROCESSOR APPLICATIONS ; 157 Donald C. Lokerson, Goddard Space Flight Center and Dr. Robert Rochelle, University of Tennessee 22. FAME—A MICROPROCESSOR BASED FRONT-END ANALYSIS AND MODELING ENVIRONMENT 161 Jacob D. Rosenbaum and Edward B. Kutin, Higher Order Software 23. APPLICATION OF SOFTWARE TECHNOLOGY TO A FUTURE SPACECRAFT COMPUTER DESIGN 167 Robert J. LaBaugh, Martin Marietta Corporation VI 24. A TRANSLATOR WRITING SYSTEM FOR MICROCOMPUTER HIGH- LEVEL LANGUAGES AND ASSEMBLERS 179 W. Robert Collins, Computer Sciences Corporation, John C. Knight, Langley Research Center, and Robert E. Noonan, College of William and Mary SESSION IV — MICROPROCESSOR HARDWARE TECHNOLOGY Chairman: Richard Balestra, NAVAIR Systems Command Headquarters 25. A HIGH PERFORMANCE MULTIPLIER PROCESSOR FOR USE WITH AEROSPACE MICROCOMPUTERS 187 P. E. Pierce, Sandia National Laboratories 26. APPLICATION OF ADVANCED ELECTRONICS TO A FUTURE SPACECRAFT COMPUTER DESIGN 195 Philip C. Carney, Martin Marietta Corporation 27. EVOLUTION OF A STANDARD MICROPROCESSOR-BASED SPACE COMPUTER 213 Manuel Fernandez, Litton Systems, Inc. 28. MICROPROCESSORS FOR IMAGING SEEKERS 227 R. G. Hix and D. W. Smith, General Dynamics 29. MODULAR MISSILE BORNE COMPUTERS .229 R. Ramseyer, R. Arnold, H. Applewhite and R. Berg, Honeywell Systems and Research Center > 30. MICROPROCESSOR-CONTROLLED TELEMETRY SYSTEM 257 Paul Holtzman and Stephen D. Hawkins, RCA 31. MICROCOMPUTER ARRAY PROCESSOR SYSTEM 259 Kenneth D. Slezak, Goodyear Aerospace Corporation vn SESSION I AIR/SPACE APPLICATIONS OF MICROPROCESSORS preceding Page AN IMAGING INFRARED (IIR) SEEKER USING A MICROPROGRAMMED PROCESSOR Kerry V. Richmond McDonnell Douglas Astronautics Co. St. Louis, Missouri A recently developed IIR seeker uses a microprogrammed processor to perform gimbal servo control and system interface via a MIL-STD 1553 port while performing the seeker functions of automatic target detection, acquisi- tion and tracking. Although the acquisition and centroid tracking are relatively low computation load seeker modes, the automatic detection mode requires up to 80% of the available capability of a high performance 2900 based microprogrammed processor. With the high speed processing capability available it is possible to implement a digital servo in the same processor using only 5% of the computation capacity. This digital servo includes six modes of gimbal control at the basic processor 60 Hz computation loop plus a 200 Hz rate loop, the latter being transparent to the main seeker functions. These two asynchronous timing loops plus a 50 Hz system interface loop driven from the 1553 port are implemented in the one processor. The fast response required by the rate loop for the rate sensor demodulator inputs also requires an interrupt driven analog data acquisition system. A 4K microcode program driven by eight interrupts implements these functions as well as the other operator and system interfaces. The eighth interrupt is used to force the processor into special "front . panel" code which suspends all other interrupt processing and saves the state of the processor to allow the programmer to view the contents of all registers and memory as well as enter new values and resume normal processor execution at the interrupted location or any other selected location. This programmer debug aid in the hardware coupled with a set of support software including a symbolic cross assembler and a software simulation of the 2900 based processor allow efficient program development and checkout. This system developed around the microcoded processor required by one of the system tasks has been designed, checked out and flown successfully. Although system complexity was increased significantly by adding the addi- tional functions this approach can be cost effective when the basic computa- tion capacity is already available. IIR SEEKER MISSILE INTERFACES SEEKER ELECTRONICS TELEMETRY GUIDANCE COMPUTER SEEKER BLOCK DIAGRAM GUIDANCE COMPUTER FROM RECEIVER fTO TRANSMITTER 1553 DATA BUS REMOTE TERMINAL MICROPROGRAMMED PROCESSOR [.DISPLAY VIDEO VIDEO FROM IMAGER CPU BLOCK DIAGRAM DATA BUS / \ * . y II/O ADDRESS LREGISTER > r ^ 1 I/O DATA LXCVR y ^ y / ^ N 1 DATA MEMORY • CURRENT STATUS 0 MOST INSTRUMENTS HAVE AN OPERATIONAL BREADBOARD DATA SYSTEM NOW • EXPECT ON-TIME DELIVERY OF ADVERTISED CAPABILITY • EXPECT TO SIGNIFICANTLY ENHANCE THE SCIENCE VALUE OF THE MISSION • EACH INSTRUMENT PROVIDES SCIENCE OPTIMIZATION FOR ITS INVESTIGATORS t EACH HAS PROVIDED FOR INCREASED IN-FLIGHT FLEXIBILITY • ADDITIONAL EFFORT MUST BE EXPENDED TO SOLVE PROBLEMS ASSOCIATED WITH: . • SYSTEM REQUIREMENTS DEFINITION t IMPROVED USE OF MICROPROCESSOR DEVELOPMENT TOOLS • FUNDING CONSISTENT WITH THE ENHANCED CAPABILITY AND COST FUTURE PROJECTIONS • TECHNOLOGY IMPROVEMENT • SEMICONDUCTOR TECHNOLOGY (ADVANCED wP, DENSE MEMORY, HIGHER SPPED, ETC.) • ADVANCED ARCHITECTURE AND SOFTWARE DESIGN (MULTIPLE MICROPROCESSORS, HIGH LEVEL LANGUAGES, ETC.) • APPLICATION ADVANCES 0 INSTRUMENT AUTONOMY • HIGHLY FUNCTIONAL COMMANDING 0 -EXTENSIVE ON-BOARD PROCESSING (ESPECIALLY FRONT-END APPLICATIONS) 15 Page Intentionally Left Blank A COMMAND & DATA SUBSYSTEM FOR DEEP SPACE EXPLORATION BASED ON THE RCA 1802 MICROPROCESSOR IN A DISTRIBUTED CONFIGURATION Jack S. Thomas California Institute of Technology Jet Propulsion Laboratory Pasadena, California The Command and Data Subsystem (CDS) is an RCA 1802 CMOS microprocessor-based subsystem that acts as the central nervous system for the Galileo Orbiter Spacecraft. All Communication between the ground and spacecraft flows through the CDS. The CDS also distributes commands in real time, algorithmetically expanded from a data base loaded from the ground and in response to spacecraft alarms. The distributed microprocessor system is configured as a redundant set of hardware with three microprocessors on each half. The microprocessors are surrounded by a group of special purpose hardware components which greatly enhance the ability of the software to perform its task. The presenter shows how the software architecture makes a distributed system of six microprocessors appear to each user as a single virtual machine, and collectively as a set of cooperating virtual machines that prevent the simul- taneous presence of the several users from interfering destructively with each other. 17 u u_ O 18 GALILEO CDS FLIGHT HARDWARE CONFIGURATION STRING-A, PRIME STRING-B, BACKUP un HCP , ' 1A, IB -1 f - < CC/DC TO f PPS, RFS -^ 1 ENGR MDS DATA LOW RATE ^^T TFI FMFTBY ~~" C f HLM1A 1802 HLM1B 1802 32 KB 32 KB | BC | | BC | • LLM1A —11802 Tb |l6 KB GOLAY _e CODE 1A DMS • (TAPE) —^>*- SSI PWS HI RATE «^o-"^~~ DBUM 1A (REQ8 KB J. \ DBUM IB (R/T) 8 KB BUM 1A 16 KG "sol 16 KB ^- 1 - r ^_ r- ^ CC/DC TO f ENGR PPS ^~T DATA *" IUS, STS ^T" TELEMFTRY ^^ 1 LLM2A TS 1802 i DSB-A DSB-B | AACS | ^| MAG | | PWS | | DDS~[ [ EPD~| | SSI "| | uys | | NIMS | | PPR~~] J "T^ LLM1B J — ' 16 KBLL1 DATA -| 1 I CRITICAL ENABLES ^ rsc ^ _ CONFIG CONTROL -* VA 10IA, IB MEM PROTECT -^ J — T_ GOLAY 1 7~° — CODE IB 1 ~ -^°~ BUM1B 16 KB "i^ 0" fsQ -1| 1 1 SHUN DESPUN J LLM 2B -1|— ^ ENGR — _^ 1802 I TS ^ ' DAT/^ L 1-| 1 CRITICAL CONFIG CONTROL -* 2A> 2B "* MEM PROTECT -+ J 19 GALILEO CDS FLIGHT SOFTWARE ARCHITECTURE I UNKNOWN RESOURCE UTILIZATION EXCEPT BY LIMITED KNOWN RESOURCE UTILIZATION | GROUND FUNCTIONAL MODELING UNRESTRICTED ACCESS RESTRICTED ACCESS 10 CONCURRENT ADMINISTRATIVE PROGRAMS PGM 10 . CONCURRENT F/P PROGRAMS 16 CONCURRENT PROGRAMS CONSTRAINT CHECKED 32 SINGLE INSTRUCTION PROGRAMS I STATIC REAL TIME CONCURRENT } PROGRAMS WITH STATIC PARAMETERS COOPERATING VIRTUAL MACHINES > SHARE FUNCTIONAL COMMANDS CYCLE SERIALLY I/MINOR FRAME FUNCTIONAL COMMAND INTERPRETER ROUTINES \ VARIABLES FOR ALL PROGRAMS RESTRICTED WRITE ACCESS MUTUALLY EXCLUSIVE HLM PROCESSOR TIME ALLOCATION 1. FOREGROUND EXECUTIVE 2. ADMINISTRATIVE PROGRAMS 3. IMMEDIATE ACTION COMMAND PROGRAM 4. FAULT PROTECTION PROGRAMS 5. ENGINEERING SEQUENCE PROGRAMS 6. SCIENCE SEQUENCE PROGRAMS 7. DELAYED ACTION COMMAND PROGRAMS 8. PROCESSOR TIME MARGIN RTI 1 2 1 1 I 2 ',3 4 i i i i l L 4 | 5 i i i 15| 6 1 i l i 1 1 1 6 | 7 l 8 l 1 i i 8 8 8 1 8 8 0 RTI 1 RTI 2 RTI 3 RTI 4 RTI 5 RTI 6 RTI 7 RTI 8 RTI 9 RT 1 MINOR FRAMF 2/3 SECONDS 0 20 SYNERGISTIC INSTRUMENT DESIGN Dale E. Winter Jet Propulsion Laboratory Pasadena, California I. The Synergistic Approach A. Do a functional design 1. Block-out all system functions. 2. - Identify all areas that are exclusively analog. 3. Identify all areas that are exclusively digital. 4. Identify any analog/digital hybrid areas. B. Design hardware to promote efficient software. 1. Supply task-efficient timing. 2. Supply task efficient I/O structures. 3. Design a task/code efficient system architecture. C. Design software to promote efficient hardware. 1. Structure software to minimize hardware. 2. Customize coding to be task efficient. 3. Directly replace hardware functions wherever possible. 4. Use time and memory space wisely. D. Completed design yields bonuses. 1. Additional features can be included with nominal hardware increases. 2. Design changes can be made easily. 3. Less hardware means less power, less mass and fewer failures. II. The Galileo Television Camera A. Taking pictures. 1. Filter selection and shuttering with software timed pulses directly to mechanism drive amplifiers. 2. CCD readout HI rate timing executed in hardware. 3. CCD readout LO rate timing and video/data system time syncronization executed in software. 4.. Software timing is precision synchronized with system clock to assure exposure accuracy. B. Telemetry acquisition. 1. Software controlled ADC and Mux. 2. Precision sample times. 3. Software can position sample times anywhere within the camera cycle to monitor specific activities. 21 C. Communications 1. Non-immediate bus adapter does most work in software.. 2. Software sequencing sync's up with time broadcast. 3. Software rate buffers telemetry for transmission. D. In-flight problem solving. 1. Programmable telemetry can profile electrical activity. 2. Multi-mode memory switching and mixing. 3. In-flight re-programming capability. 4. Diagnostic software reports and time .tags errors. SSI Timing SSI image parameter control and timing signal generation is based on applicat.on of microcomputer technology. In addition to controlling serial pixel shifting and pixel analog-to-digital con- version, all timing, sequencing, mechanism control, engineering and status data acquisition, and buffering shall be performed under programmed microcomputer control. SSI data rates and formats shall be as specified in GLL-3-280, Telemetry Measurements and Data Formats. Additional SSI rates and timing intervals are presented in Table 1. Figures 2A, 2B and 2C present the relationship between the various SSI timing parameters for SSI imaging modes of 8 2/3, 30 1/3 and 60 2/3 seconds respectively. TABLE 1. SSI TIMING PARAMETERS a. b. c. d. e. f. 9- h. i. j. k. 1. Pixel bit rate Pixel rate Line time Read frame time Frame repetition time Prepare time Filter steps allowed Maximum normal exposure Maximum extended . exposure SSI reply data rate CDS sync Real -time interrupt 8 2/3 Second Hode 806.4 KBPS 100. 8K Pixels/s 8 1/3 m sec 6 2/3 sec 8 2/3 sec 2.0 sec 2 800 m sec 6400 m sec 403.2 KBPS 806.4 KBPS 15 Hz 30 1/3 Second Mode 806.4 KBPS 100. 8K Pixels/s 33 1/3 m sec 26 2/3 sec 30 1/3 sec 3 2/3 sec 3 800 m sec 25600 m sec 403.2 KBPS 806.4 KBPS 15 Hz 60 2/3 Second Mode 806.4 KBPS 100. 8K Pixels/s 66 2/3 m sec 53 1/3 sec 60 2/3 sec 7 1/3 sec 7 800 m sec 51200 m sec 403.2 KBPS 806.4 KBPS 15 Hz 22 FROM TO PPS CDS (LASH 1 HEATER * * riL S 'oTA' "0...0. co'SSot TO TO COS COS ' A rV ' • r- '1 IM ^r— ?o'v» X 0"'" | X SH™ X 5HUTU> X Jl HEATED jl BOO . ex CCD : T) . ;>— : — : — -T-T-" T • , CDS FILTER WHttL ENCODER >IA «Y PP« J S _. CLOCK S ^^ DRIVERS • PREAM^S 1 " Tj— .-TO 1 »C '— ' CDS | ELEC.REPl. FROM TO HEATER PPS COS | * , [r] •*— FLASH HEATER K "* T POWER SIBGf ^1 SUPPLIES I - LIMITEt TO . — - . COS i cC m • f PIXEL DATA DOUBLE ...., 1LOCK ADAPTIVE RATE J""tn PIXEL DATA •-» SAMPLING — *• iL -«-»• CONTROLLED COMPRESSOR/ — » — O £> — — » INTHFAC? PROCESSOR AOC | REED-SOLOMON CODER ^ INTERFACE • 1 • . ^F •»- REH. HEATER PC • SSI POWER -» OPTICS HOOD T -^ FRON7 OPTICS T • PIXEL DATA 1 (« • PIXEL DATA 2 ('I ' — »- PIXEL WORD SYI- — »• RADIATOR PLATE — *• CCD HOUSING T «--. ...ruiiir innr «. FREQUENCY IUSADAPTER/ , CONTROL • REAL TIME INTER • SUPERVISORY DA 1 . 1 » SSI REPLY DATA , — w FRONT ELECTRO —^ REAR ELECTRONI *^ MICROCOMPUTER T< •A4 (16 MEASUREMENTS) — »• PIXEL ENAtLt — •• PIXEL IIT SYNC PPS. NORMAL PIXEL DATA 2 (CS) NORMAL PIXEL WORD SYNC COMPRESSED PIXEL OATA I (MSB'S) COMPRESSED PIXEL OATA 2 ( I™5 M I ' D 5 2 1 \ rr, ; — 1 CDS 1 — •'\ . 1 | . s . •DISCRETE COMPONENTS -1C' s, MSI, LSI (TTL) -LSI (CMOS) •RANDOM LOGIC 'PLATED WIRE . . / * / > •CORE MEM; -SEMI COND. MEM -SEMI COND. MEM. CAPABILITIES; TOOLS-. •HARDWIRED 'PROGRAMMABLE 'PARALLEL 'DISTRIBUTED SEQUENCERS SEQUENCERS PROCESSORS SYSTEM (128 WORDS) (SEMI-DISTRIBUTED) (176 K MEM) •HAND CHECK -DETAILED 'DETAILED SIMULATOR v/> ASSEMBLER SIMULATOR 'ASSEMBLER 4 4 SIMULATOR •ASSEMBLER MACROPROCESSOR 'BREADBOARD THE BASELINE - UDS THE UDS, A DEVELOPMENT SPONSORED ,BY THE NASA UNDER CONTRACT NAS7-100 WITH THE CALIFORNIA INSTITUTE OF TECHNOLOGY AT JPL. SALIENT FEATURES: ' . - REAL TIME CONTROL - PRECISE TIMING - DISTRIBUTED ARCHITECTURE + DISTRIBUTED FUNCTIONS (HI-LEVEL CONTROL, LOW-LEVEL EXECUTION) + INTERACTION MINIMIZED + HIERARCHICAL CONTROL + COMPUTER INDEPENDENCE - STANDARDIZED SOFTWARE AND SUPPORT EQUIPMENT - STANDARD INTERFACES FEASIBILITY DEMONSTRATED VIA: - BREADBOARD OF BASIC SYSTEM UTILIZING NAKED MINI'S - ONE REMOTE TERMINAL UNIT (RTU) INCLUDING 8080 MICROPROCESSOR - DEVELOPED CONCEPT OF UDS DESIGN LANGUAGE (UDL) - DESIGNED AND .IMPLEMENTED "TYPICAL" APPLICATION SOFTWARE - EXPLORED CONCEPTS OF DEBUGGING A DISTRIBUTED SYSTEM 30 RTI- THE UDS DESIGN (MARINER CLASS S/C) COMMAND PROCESSOR (CP) FORMAT PROCESSOR (FP) 1 1 nt '1 J ITMI ENG CONTROL B1 E | ITMI SCIENCE USERS SPARE 1 [TMJ ATTITUDE CONTROL 1 1 ITMI ITMJ DATA MOD. 1 STORAGE DEMOD . (ONE OF N) 2 B3 PRIORITY ASSIGNMENT *M 1 1 I I 1 ~| tiP 1 [T 1 3 RTI— • • HP ric~i I T r M BA | BA BA TERMINAL MODULE HIGH LEVEL MODULE THE RTU INITIALLY DEVELOPED AS A PART OF THE UDS. ' ' . - - UDS I/O TYPE INTERFACES - UDS BUS INTERFACE - MICROPROCESSOR DRIVEN PROPOSED FOR DEVELOPMENT AS A NASA STANDARD FOR'POSSIBLE USE WITH: - MMS (DHCS - NSSC-1) - GALILEO - VARIOUS PREPROJECT STUDIES CONCEPT DIED - BURDENED WITH UNIVERSAL I/O - SALE OF THE CONCEPT - NO VOLUNTARY FIRST USER - FEW SUPPORT FACILITIES MAIN INHERITANCE FROM THIS EFFORT - RCA 1802 MICROPROCESSOR, IMPLEMENTATION CONCEPTS OF BA AND BC. 31 GALILEO A COMMITMENT TO A DISTRIBUTED DATA SYSTEM UTILIZING THE MICROPROCESSOR TECHNOLOGY IN A FLIGHT DEVELOPMENT ENVIRONMENT DRIVERS ON DEVELOPMENT - DOS AS A BASELINE - LOW POWER AND RADIATION DICTATE ACCEPTANCE OF THE RCA 1802 - COMBINING FDS AND CCS INTO SINGLE SUBSYSTEM - CHEAPER OPERATIONS - - VOYAGER AS A BASELINE - CMOS (4000 SERI,ES) SUPPORT LOGIC - MUST USE HOL (SPECIFICALLY, HAL-S) - NOTION THAT THE MORE YOU DO ON BOARD - THE CHEAPER ON GROUND STATUS - DESIGN COMPLETE (HARDWARE) - ARCHITECTURAL DESIGN OF FLIGHT SOFTWARE IN PROGRESS. SOME PROTOTYPE/ BREADBOARD DESIGNS. (J. THOMAS PRESENTATION) - BREADBOARD AND SUPPORT EQUIPMENT INTEGRATED DESIGN VERIFICATION IN PROCESS - HAL-S HAS BEEN REMOVED AS A REQUIREMENT. - DESIGNS FOR SOFTWARE AND OPERATIONS SUPPORT TOOLS IN PROGRESS. GALILEO DESIGN GNDCMDS- SE- COMMAND || DECODER I] MULTIPLEXORi HIGH LEVEL- MODULE' (1) HIGH LEVELMODULE(2) L CRITICAL [ CONTROLLER f P CRITICAL ENABLES CONFIGURATION CONTROL MEMORY PROTECTS HIGH LEVEL MODULE LOW LEVEL MODULE 32 OTHER PROPOSED APPLICATIONS COMET RENDEZVOUS - MANY IMPLEMENTATIONS PROPOSED DEPENDING ON CHARACTER OF MISSION AT ANY GIVEN TIME AND ECONOMIC ENVIRONMENT. f BASED ON "CORE" DISTRIBUTED DATA SYSTEM + USERS NEED COMPUTING POWER + COMPUTING POWER DERIVED AS A STANDARD .FOR THE S/C AND WOULD SIMPLY BE INCORPORATED INTO THE USER DESIGN (RTU SANS THE I/O). OTHER PROPOSALS HAVE BEEN MADE, PRIMARILY BASED ON THE DISTRIBUTED SCHEME. . . COMET RENDEZVOUS PROPOSED DESIGN GND CMOS SEP Of LINK ENG. S/S ENG. S/S V PROBE SUPUR BUS ' CDS (GALILE DESIGN RELAY LINES ! • BAU AACS GND CMOS S/C RF LINK 0 ) ' 1 TMS TAPE REC. IMAGING SENSOR . PLASMA WAVE ANAL. m RFS » * DPU DPU DPU _L DPU LOW RATE CIENC 1 BAU , RIU 1 SEP CSDH TO/FROM SCIENCE SENSOR R* BUS TIM.& CONTROL TO/FROM COS DATA PROCESSING UNIT 33 THE CHRONOLOGICAL PATH OF PROBLEMS EARLY DESIGNS (M69, H71, M73)' - SIMPLE DESIGNS EASILY UNDERSTOOD - COMPONENT COMPLEXITY LESS; EASILY TESTED AND SCREENED + PROCESS PROBLEMS (PURPLE PLAGUE, CORROSION, ETC.) - HARDWARE AND SOFTWARE DESIGN AIDS AVAILABLE EARLY + DETAILED SIMULATOR • MEMORY SIZING • TIMING • TEST SOFTWARE DEVELOPMENT AND VALIDATION + ASSEMBLER/LOADER - SIMPLER SOFTWARE (128/500 words) RECENT DESIGNS (VIKING, VOYAGER) - DESIGNS MORE COMPLEX - INCREASED COMPONENT COMPLEXITY - HARDWARE AND SOFTWARE DESIGN AIDS AVAILABLE EARLY + DETAILED SIMULATOR + ASSEMBLER/MACRO PROCESSOR THE CHRONOLOGICAL PATH OF PROBLEMS (CONT.) REC E N T DESIGNS (VIKING, VOYAGER) CONT. - INCREASED COMPLEXITY IN SEQUENCING - ON-BOARD FAULT MANAGEMENT (LIMITED) - MORE COMPLEX SOFTWARE - DECREASING R8AD FUNDS GALILEO AND FORWARD - LACK OF EARLY DEVELOPMENT TOOLS - VERY COMPLEX COMPONENTS - INCREASED COMPLEXITY IN SEQUENCING, ON-BOARD FAULT MANAGEMENT - MORE SEVERE ENVIRONMENTS - LACK OF CONTINUITY OF MISSIONS - FURTHER DECREASE IN R&AD FUNDS - MUST BE CHEAP . SPECIFIC PROBLEMS - DIFFICULTY IN APPLYING HOL (HAL-S) TO RCA 1802 - RCA 1802 ARCHITECTURE PROBABLY NOT BEST SUITED FOR CDS TASK. 34 THE CHRONOLOGICAL PATH OF PROBLEMS (CONT?) SPECIFIC PROBLEMS (CONT.) - RADIATION HARDENING PROBLEMS - ARCHITECTURAL EVALUATION • MEMORY SIZING • BUS TRAFFIC • TIMING MARGINS - DEVELOPMENT AND TEST OF TEST SOFTWARE - COMPETITION IN LABOR MARKET 35 Page Intentionally Left Blank THE ROLE OF THE MICROPROCESSOR IN ONBOARD IMAGE PROCESSING FOR THE INFORMATION ADAPTIVE SYSTEM W. Lane Kelly, IV, and Barry D. Meredith Langley Research Center Hampton, Virginia The Information Adaptive System (IAS) is an element of the NASA End-to- End Data System program and is focused toward high speed onboard data pro- cessing for NASA missions in the 1980's. Particular emphasis is placed on multispectral-image data processing since the speed and quantity of that variety of data places the greatest burden on the current NASA data system. Some of the image processing functions planned for the IAS include sensor nonuniformity correction, geometric correction, data editing, formatting, packetization and adaptive system control. The design of the IAS is intended to apply to a variety of future missions; therefore, architectural flexibility is a key design feature. The programmability of the microprocessor lends this required flexibility to the system, allowing it to accommdate new processing functions and interface with a variety of sensor configurations. .The high throughput rate required for multispectral image data processing prohibits the use of conventional computer software approaches without significant increases in the speed of the central processing unit. Hence, a combination of high speed special purpose hardware and microprocessors for control and computational support, appears to offer the best technical approach for the near term. In addition, a sophisticated microprocessor will serve as the overall system supervisor interfacing with commands from the spacecraft and the ground. . .This paper presents the preliminary design of the Information Adaptive System and discusses the role of the microprocessor in the implementation of the individual processing elements. 37 THE CURRENT NASA DATA SYSTEM PROBLEM • EVER INCREASING DEMAND MET WITH PROBLEM BY PROBLEM SOLUTIONS. • CURRENT DATA LOAD - 10" bits/day. • DATA PROCESSING DELAYS ARE EXCESSIVE. • DATA PROCESS ING COSTS ARE TOO HIGH. • FORTHCOMING PROJECTS WILL INCREASE DATA LOAD BY AN ORDER OF MAGNITUDE. • SHUTTLE CAPABILITY WILL BOOST LAUNCH RATE BY FACTOR OF 6. NEEDS?H-INFORMATION ADAPTIVE SYSTEM GOAL: DESIGN, DEVELOP AND DEMONSTRATE IN EARLY 1983 A SYSTEM ARCHITECTURE THAT UTILIZES ADVANCED TECHNOLOGY FOR HIGH-SPEED MULTISPECTRAL IMAGE DATA PROCESS ING. DESIGN FEATURES: • HIGH DATA THROUGHPUT RATE • PROGRAM/VIABILITY • FLEXIBLE ARCHITECTURE • ADAPTABILITY 38 IAS DEMONSTRATION SYSTEM BLOCK DIAGRAM DISTRIBUTIVE DATA BUS RADIO/METRIC CALIBRATION GEOMETRIC CORRECTION MP CONTROLLER DATA SET SELECTOR (EDITOR) MP CONTROLLER FORMATTER MP CONTROLLER PACKETIZER MP CONTROLLER MP CONTROLLER ADAPTIVE SYSTEM CONTROLLER TEST SUPPORT EQUIPMENT -SPACECRAFT DATA/ COMMANDS STATAS/DATA RADIOMETRIC CORRECTION - LINEAR CURVE FIT APPROACH DIGITAL SENSOR INPUT DATA INPUT DATA CLOCK CORRECTED OUTPUT DATA 39 LOOKUP TABLE DESIGN FOR RADIOMETRIC CALIBRATION INPUT SENSOR DATA S W ADDRESS BUS LOOKUP TABLE MEMORY PIA MC6800 SYSTEM MEMORY S W I T C H E S CORRECTED OUTPUT DATA DATA BUS SOURCES OF DISTORTION IN IMAGE DATA AND THEIR CORRESPONDING ERROR MEASUREMENT TECHNIQUES EPHEMERIS VARIATIONS -GLOBAL POSITIONING SYSTEM (GPS) SPACECRAFT AHITUDE VARIATIONS SENSOR MISALIGNMENT EARTH CURVATURE -ADVANCED STAR TRACKER •PERIODIC GROUND CALIBRATION -GPS WITH LOCAL EARTH RADIUS INFORMATION 40 GEOMETRIC CORRECTION INPUT MATRIX PIXEL CENTERPOIIMTS f f I L. OUTPUT MATRIX O X— GEOMETRIC CORRECTION PROCESSING FROM ASC RADIOMETRICALLY CORRECTED INPUT PIXELS ATTITUDE EPHEMERIS LOCAL RADIUS ALIGNMENT ERROR • SPECIAL PURPOSE RESAMPLING HARDWARE • APPLIES CUB 1C CONVOLUTION ALGORITHM TO INPUT PIXELS • PERFORMS ALONG TRACK AND ACROSS TRACK RESAMPLING CONTROL l\ UNDISTORTED -/OUTPUT PIXELS DISTORTION PARAMETERS SOPHISTICATED GENERAL PURPOSE PROCESSOR • PERFORMS COORDINATE TRANSFORMATIONS • SUPPLIES DISTORTION PARAMETERS . • CONTROLS RESAMPLING HARDWARE 41 EDITING CRITERIA UNDER INVESTIGATION FOR THE IAS TIME SPACECRAFT POSITION INFORMATION FROM OTHER EXPERIMENTS CLOUD COVER IMPLEMENTATION OF CLOUD DETECTION ALGORITHM BAND1 1.55 urn' BAND 2 0.65 urn BAND 3 . 0.85 ym RATIO AND THRESHOLD S.P. HARDWARE HIGHSPEED MULT. AND COMPARATOR CIRCUITS PlXft COUNTER MP BASED CONTROLLER TO 42 BUFFER MEMORY SYSTEM FOR DATA FORMATTING INPUT DATA SWITCHING CIRCUITRY MEMORY A MEMORY B SWITCHING CIRCUITRY MICROPROCESSOR FORMATTED OUTPUT DATA NASA DATA PACKET FORMAT h PRIMARYHEADER SECONDARYHEADER SOURCEDATA PACKET _|PARITY"! SOURCE I.D. MISSION I.D. PACKET LENGTH ETC. • } 1 ANCILLARY DATA: TIME/SPACECRAFT POSITION AND ATTITUDE ETC. — < ( ) J VARIABLE LENGTH PROCESSED DATA -( I... ERROR CODES 43 HIGH SPEED PING-PONG MEMORY APPROACH TO DATA PACKETIZATION 3_s PROCESSED DATA > INPUT [SWITCHES | PING-PONG MEMORIES CONTROLLER U F F E R S [SWITCHES! PACKET PARAMETER MEMORY SWITCHING AND CONTROL MICROPROCESSOR PACKETIZED DATA ADAPTIVE SYSTEM CONTROLLER TASKS • INITIALIZE INDIVIDUAL CONTROLLERS • ASSIST CONTROLLERS IN INITIALIZATION OF IAS COMPONENTS • ESTABLISH AND MAINTAIN OPERATING MODE • MONITOR STATUS OF ALL IAS COMPONENTS • FORMULATE ERROR MESSAGES • MAINTAIN COMMUNICATION WITH SPACECRAFT AND GROUND • PROVIDE COMPUTATIONAL SUPPORT TO IAS MODULES 44 ADAPTIVE SYSTEM CONTROLLER DESIGN FEATURES SOPHISTICATED MICROPROCESSOR ARCHITECTURE ADAPTABLE EXPANDABLE COMPATABLE WITH HIGH ORDER LANGUAGE 45 Page Intentionally Left Blank APPLICATION OF A MICROPROCESSOR TO A SPACECRAFT ATTITUDE CONTROL D. H. Brady and F. W. Hermann TRW Defense and Space Systems Group Redondo Beach, California The space-qualif ied TDRSS attitude control system (ACS) microprocessor development work spanned three main design areas: hardware and instruction set, ACS firmware, and hardware/firmware verif ication testing. The Control Processor Electronics (CPE) hardware utilizes two parallel AM2901 4-bit microprocessors, with a microprogrammed instruction set tailored to the TDRSS controls application. Fourteen special purpose I/O instructions interface with the ACS hardware, each transferring data for one sensor while meeting timing and data-handling requirements. The ACS firmware resides in 5120 bytes of ROM with 1024 bytes of RAM for scratch data storage. The 16-bit add, subtract, and divide operations are overflow-protected and multiplies are done in hardware. The firmware includes data processing for five sensors, four attitude control laws, and telemetry and commands. The main design limitations were: 16-bit word length, 1024 8-bit byte RAM, and computation speed/task sharing tradeoffs. It performed ACS computations quickly and without significant data degradation. The word length limitation motivated the careful selection of control filter topology and sacrif ice of dynamic range in favor of null per- formance. The flight program design was tested with three tools: Varian V-73 mini- computer, CDC Cyber computer, and the CPE development station. The V-73 simulation tested source (assembly) programs prior to development station availability. The CDC Cyber simulation was used primarily for accuracy analysis. The development station included commercial versions of the flight hardware which were run at full speed. All formal verification tests were run on the development station to verify timing, accuracy, and interface re- quirements. From this development experience, additional hardware and software re- quirements were identified: 0 Rapid Memory Examine/Change • Floating point hardware • High level language • . 47 COARSE SUN SENSOR SINGLE ACCESS ANTENNA SINGLE ACCESS ANTENNA SPACE/GROUND LINK ANTENNA FINE SUN SENSOR COARSE SUN SENSORS ROLL TDRSS SPACECRAFT CONFIGURATION TRACKING AND DATA RELAY SATELLITE (TDRSS) MISSION: • COMMERCIAL COMMUNICATION FOR WESTERN UNION t SATELLITE TRACKING AND DATA RELAY FOR NASA INTRODUCTION TRW t TDRSS IS ONE RECENT TRW APPLICATION OF THE USE OF A MICROPROCESSOR TO PERFORM SPACECRAFT ATTITUDE CONTROL SYSTEM COMPUTATIONS • DEVELOPMENT WORK SPANNED THE FOLLOWING AREAS: - HARDWARE DESIGN OF THE CONTROL PROCESSING ELECTRONICS (CPE), A SPECIAL-PURPOSE MICROCOMPUTER BASED ON THE AMD 2901 BIT- SLICE MICROPROCESSOR - DEFINITION OF THE INSTRUCTION SET - DESIGN AND CODE THE FIRMWARE FLIGHT PROGRAM - VERIFICATION TESTING OF THE FIRMWARE 48 TDRSS ATTITUDE CONTROL HARDWARE TRW • CONTROL ELECTRONICS ASSEMBLY • SENSORS - EARTH SENSOR - COARSE SUN SENSORS - FINE SUN SENSORS - GYROS - REACTION WHEEL TACHOMETERS - SOLAR ARRAY DRIVE RESOLVERS t ACTUATORS - THRUSTERS - REACTION WHEELS TDRSS CONTROL ELECTRONICS ASSEMBLY TRW SERIAL COMMANDS SERIAL TELEMETRY ANALOG AND SERIAL - DIGITAL I SENSOR - DATA SENSOR INPUT ELECTRONICS SERIAL „ DATA , L CLOCK , STROBES REDUNDANCY NOT SHOWN I f COMMAND AND . TELEMETRY ELECTRONICS t . 4 •sx OQ 0 g H H- CO GO CQ CD CONTROL PROCESSING ELECTRONICS SERIAL n«T/v CLOCK STTO — V — » VALVE DRIVE ELECTRONICS WHEEL DRIVE ELECTRONICS " VALVE FIRING ••COMMANDS .REACTION WHEEL TORQUE "COMMANDS 49 CPE BLOCK DIAGRAM TRW ENABLEVDt SABLE CTE-ON-Y -On DATA STROBE ADDRESS STROBE STROBE STROBE CPE INSTRUCTION SET TRW • SPECIFIED BY CPE CONTROL FIRMWARE DESIGNERS TO BE OPTIMUM FOR TDRSS APPLICATION • INSTRUCTION SET MICROPROGRAMMED BY HARDWARE DESIGNERS • 108 TOTAL INSTRUCTIONS INCLUDING: - SINGLE- OR MULTIPLE-BIT SET, RESET AND TEST - 16-BIT FRACTIONAL FIXED-POINT ARITHMETIC - 16-BIT ADD, SUBTRACT AND DIVIDE CLAMPED AT ±1.0 WHEN OVERFLOW OCCURS - MULTI-BIT LOGICAL AND ARITHMETIC SHIFTS (SINGLE AND DOUBLE-PRECISION) - FOURTEEN INPUT/OUTPUT INSTRUCTIONS DEDICATED TO PARTICULAR SENSORS OR ACTUATORS WITH ALL HARDWARE TIMING BEING TAKEN CARE OF IN THE MICROCODE. FOR EXAMPLE, INSS INSTRUCTION INPUTS ALL DATA ASSOCIATED WITH THE COARSE AND FINE SUN SENSORS TO PAGE 0 OF RAM; OUWTQ OUTPUTS TORQUE COMMANDS TO THE REACTION WHEELS FROM PAGE 0 OF RAM. 50 PROGRAM STRUCTURE TRW CYCLE PERIOD " 0.06 SEC 0.10 SEC • 0.08 SEC 0.10 SEC 0.10 SEC 0.20 SEC 0.20 SEC 2.0 SEC 0.20 SEC 2.0 SEC 0.20 SEC START 1 INITIALIZATION 1 . | PROGRAM SYNCHRONIZATION SENSOR INPUT TELEMETRY FORMATTING AND PROCESSING COMMAND PROCESSING EIA/SSA PROCESSING QYRO PROCESSING INERTIAL MODE CONTROL LAW PROCESSING EARTH MODE CONTROL LAW PROCESSING NORMAL MODE CONTROL LAW PROCESSING SUN MODE CONTROL LAW PROCESSING RWA CONTROL LAW PROCESSING VOE OUTPUT PROCESSING TELEMETRY BIT RATES OF 200, 1000, AND 4000 BITS/SECOND AHE SELECTABLE FOR THE 512 BIT MAIN FRAME. THESE PRODUCE TELEMETRY CYCLE TIMES OF 2.048, 0.512. AND 0.128 SECONDS RESPECTIVELY. 'EXECUTION FREQUENCY (NOT EXECUTION TIME) FOR EACH PHOQRAM MODULE. FIRMWARE DEVELOPMENT/VERIFICATION PHILOSOPHIES TRW DESIGN SCOPE - 0 MICROPROCESSOR DEDICATED TO ATTITUDE CONTROL FUNCTION • INSTRUCTION SET TAILORED TO CONTROL NEEDS (ARITHMETIC LIMITING, CONTROL HARDWARE I/O) DESIGN PERSONNEL • FIRMWARE DESIGNED CODED, AND TESTED BY CONTROL SYSTEMS ENGINEERS - IMPROVED COMMUNICATION FOR MECHANIZATION OF CONTROLS REQUIREMENTS IN FIRMWARE - INTERACTION IMPROVED FOR ACHIEVING ADEQUATE PERFORMANCE IN THE FIRMWARE INDEPENDENT VERIFICATION • ACHIEVED BY SWAPPING MODULE RESPONSIBILITY AT VERIFICATION TIME • VERIFICATION TEST PLAN INDEPENDENT OF MODULE DESIGNERS t REVIEW OF TEST RESULTS BY CONTROL LOOP ANALYSTS 51 CONSTRAINTS AND THEIR EFFECTS ON FIRMWARE DESIGN TRW 16 BIT WORD LENGTH MAXIMUM, 8-BIT BYTES t CAREFUL MAGNITUDE SCALING FOR COMPUTATIONS • QUANTIZATION EFFECTS ON CONTROL FILTER TOPOLOGIES • LOW LEVEL PERFORMANCE/DYNAMIC RANGE TRADEOFFS . 1024 8-BIT BYTES ADDRESSABLE IN RAM • ATTITUDE CONTROL FILTER COMPLEXITY t FILTER STATE ACCURACY/MULTIPLE PRECISION ARITHMETIC DATA PROCESSING 0 COMPUTATION COMPLEXITY/TIME DELAYS t COMPUTATION COMPLEXITY/TASK SHARING FILTER IMPLEMENTATION TOPOLOGIES TRW WORD LENGTH EFFECTS - • ACCURACY, QUANTIZATION FILTER TOPOLOGIES - .• POLYNOMIAL FORM (REJECTED) • CASCADED FORM (ACCEPTED) OTHER ALTERNATIVE FORMS • PARALLEL FORM • MATRIX FORM • DFT, FFT SCALING CONSIDERATIONS • TOPOLOGY AND GAIN DISTRIBUTION FOR INTERMEDIATE STATES • DYNAMIC RANGE, ETC. 52 TRW FIRMWARE DEVELOPMENT 8 VERIFICATION TOOLS • VARIAN V-73 MINICOMPUTER • 8 AND 16 BIT ARITHMETIC • FORTRAN FUNCTIONS SIMULATING INDIVIDUAL CPE INSTRUCTIONS • PROVIDES INTERFACE IN ENGINEERING UNITS FOR MAXIMUM VISIBILITY . i INPUT SAME AS ASSEMBLER INPUT • CYBER 71 TIMESHARE • SCIENTIFIC SIMULATION OF ARITHMETIC INSTRUCTIONS • PROVIDES TOOL FOR CONTROL LOOP DESIGNERS - .".ASSESS LIMITED WORD LENGTH EFFECTS - FILTER DESIGN . • RESIDENCE FOR CONTROLLED CPE SOURCE PROGRAM t RESIDENCE FOR CPE ASSEMBLER PROGRAM FIRMWARE DEVELOPMENT 8 VERIFICATION TOOLS (CONTINUED) TRW TI 990/10 MINICOMPUTER t VERIFICATION TOOL • USED AS DRIVER FOR VERIFICATION TESTS • DATA COLLECTION AND PRINTOUT • PROVIDES DYNAMICS SIMULATION FOR DYNAMIC ENVIRONMENT CPE DEVELOPMENT STATION • BREADBOARD CPE • FRONT PANEL FOR PROGRAM ENTRY, EDIT, AND EXECUTION INTERFACE BOX • HARDWARE LINK OF TI 990/10 AND BREADBOARD CPE • GROUND STATION COMMAND SIMULATOR 53 CO Q_ O LU > LU O cc LU5 O cc 0. O oc 0. O 54 REVIEWING THE FIRMWARE DESIGN TRW DESIGN IMPROVEMENT, FUTURE DESIGNS ARE ENHANCED BY DESIGN REVIEW AT SIGNIFICANT MILESTONES - • INITIAL DESIGN • COARSE PROGRAM FLOWS • DETAILED PROGRAM FLOWS • CODE CHECKOUT, MODULE LEVEL t TOTAL INTEGRATED PROGRAM VERIFICATION • SUBSYSTEM TESTING • SPACECRAFT OPERATIONS DESIGN • FLIGHT EXPERIENCE DESIGN REVIEW AREAS - • HARDWARE DESIGN • MICROCODE DESIGN • INSTRUCTION SET DESIGN • GROUND STATION COMMANDS SET • TELEMETRY DATA AVAILABLE • PROGRAM STRUCTURE • DESIGN PHILOSOPHIES REVIEWING THE FIRMWARE DESIGN TRW SOME DESIGN IMPROVEMENTS UNCOVERED - t RAM MEMORY LOAD AND MOVE DATA INSTRUCTION t EXECUTIVE PROGRAM AND SUBROUTINES STRUCTURE t GROUND COMMANDS TAILORED TO SPACECRAFT OPERATIONS i MICROPROCESSOR DEVELOPMENT STATION SOFTWARE CHECKOUT FEATURES - RAM - SCRATCHPAD VISIBILITY - RAPID MEMORY EXAMINE/CHANGE • CONTROL FILTER STATES WORD LENGTH >24 BITS t FLOATING POINT HARDWARE 0 HIGH LEVEL LANGUAGE 55 Page Intentionally Left Blank 8A PLASMA WAVE FOURIER TRANSFORM PROCESSOR EMPLOYING 1802 MICROCOMPUTERS FOR SPACECRAFT INSTRUMENTATION Donald C. Lokerson and James N. Caldwell Goddard Space Flight Center Greenbelt, Maryland The requirements of low power, small space, low weight, and high data compression limit the capabilities of interplanetary plasma wave processing. The processing of plasma wave signals in spinning spacecraft in the range from D.C. to SOOHz are described. Another signal source from the intermediate frequency of a sounder transponder is processed by the same hardware, but with linear Fourier transform software. . Three antenna inputs are filtered to prevent aliasing above SOOHz. A 92db range of data is multiplexed to an analog-to-digital converter, and then to three RCA 1802 microcomputers. Groups of this data are collected under DMA control by each microcomputer. A logarithmically- spaced Fourier transform is computed. Each computer requires 2 kilowords of read-only-memory and a half kiloword of random access memory. Data at lower frequencies is spin modulated by the spacecraft. For these signals, data is sampled 512 times in one spin and also processed by logarithmically-spaced Fourier transform techniques. A fourth microcomputer performs this task and coordinates all operations. This microcomputer requires 5 kilowords of read-only-memory and 3.5 kilowords of random address memory. The computer also performs data averaging, peak detection, data formatting, output compression, and ground commanded tasks. 57 1000 10 1000 1.33 ms SOUNDER PULSE >J 4->10ms U CYCLES IN 1 T 6 4 0 - 1 7 0 4 1 7 6 8 1 8 3 2 1 8 9 6 r 9 6 0 1 1 0 2 4 1 1 0 8 8 1 1 1 S 2 1" 1 2 \ 6 ri 2 8 0 T ~ ' TRANSLATED ^ FREQUENCY 4 58 O) o o H o o o c 3 Pu 59 rUJ -I- + o z 2 1 i 0 CCo s Q. — cc r- CM 9 9 t— o z 0CCy i DO £ Q Z O <" LLJ 2 2 «- jOD 3^ g£ 0 n l o o CC to L 5 <6 r— 1 ••• — _ - _^ -^ 0 z 0 CC ^ i ) f- CM 9 9 CM O .z o CC o 2"" m tQ £ i . M ) H cc$2 * g 1 \- oc °2 «- CM 9 9 CO 6 z 0 CC 0 ^ 03 £ 0 ? i Ji ) z £ _ u - ( v ii i ^OQ SS2 S25 " SQ S [ 1— CC S2 ^ •z- o _ u . . \ J > OQ 60 INPUT STATE 0 • GAIN RANGE ALL INPUT GROUPS • STROBE ALL SAMPLE AND HOLD AMPLIFIERS STATE 1 .• A/D CONVERT S/H NO. 1 • DMA GAIN RANGE AND A/D DATA FOR GROUP NO. 1 TO MICRO NO. 1 STATE 2 • A/D CONVERT S/H NO. 2 • DMA GAIN RANGE AND A/D DATA FOR GROUP NO. 2 TO MICRO NO. 2 STATE 3 • A/D CONVERT S/H NO. 3 • DMA GAIN RANGE AND A/O DATA FOR GROUP MO. 3 TO MICRO NO. 3 GROUP NO. 2 GROUP NO. 3 MICRO NO. 1 ' DATA BUS •M1DMAIN MICRO NO. 2 DATA BUS • M2DMAIN MICRO NO. 3 ' DATA BUS M3DMAIN 61 DMA CONTROL MICRO NO. 1 Q EF1 DMAIN MICRO NO. 2 EF1 DMAIN MICRO NO.3 EF1 DMAIN MICRO NO. 4 EF2 DMAIN DIGITAL MUX NO. 1 DIGITAL MUX NO. 2 DIGITAL MUX NO. 3 A/D NO. 1 DATA READY CONVERT •STATE 1 •STATE 2 •STATE 3 SOUND •A/D NO. 2 DATA READY •M1 -3 DATA READY 62 GAIN RANGING GROUP SIGNALS IN ANALOG MUX "0 1 T t i °0 Q1 Q2 CE COUNTER RESET CK SAMPLE AND HOLD S/H i ' WINDOW COMPARATOR V* • V, TIMING LOGIC RESET CK S/H CE n rLTLTLTL L 63 h-Q. CO Z> UJ CC O CC DC 01 D I- O Z CO O (D O O O O O O O O 2 l - U J ( r O C D Q . H - l < J - O I U J < / 3 00. CC CC UJ CO LLJ DC co«« CO 00. co> 12 oo> 00 O O CO D CO 64 PROTOTYPE DEVELOPMENT OF A MICROPROCESSOR-BASED ONBOARD ORBIT DETERMINATION SYSTEM Keiji K. Tasaki and Rose S. Pajerski Goddard Space Flight Center Greenbelt, Maryland DEVELOPMENT STAGES OF ONBOARD ORBIT DETERMINATION SYSTEMS [OPERATIONAL! I_SYSJ_EMS_| FLIGHT EXPERIMENT SYSTEM • WILL USE MOST ADVANCED FLIGHT- QUALIFIED PROCESSOR • WILL PROCESS MEASUREMENTS MADE ONBOARD • WILL HAVE SUPPORT EQUIPMENT X HI _l Q. o u PROTOTYPE SYSTEM • USES PDP-11/23 • OPERATES IN A SIMULATED ENVIRONMENT • PROCESSES REAL OR SIMULATED DATA DEMONSTRATION SYSTEM USEDIMP-16'S PERFORMED COMPLEX MATH FUNCTIONS DEMONSTRATED FEASIBILITY 1978 1980 1982 1984 TIME OBJECTIVES 1. DEVELOP A MICROPROCESSOR-BASED AUTOMATED ORBIT DETERMINATION SYSTEM (AODS) USING: • PDP-1 1/70 AS THE DEVELOPMENT MACHINE • PDP-11/23 AS THE TARGET MACHINE • HIGH-LEVEL LANGUAGE - FORTRAN 2. EXERCISE THE SYSTEM IN CONJUNCTION WITH A SIMULATOR. \ 3. REFINE SOFTWARE TO ACHIEVE HIGHER EFFICIENCY. 65 ONBOARD NAVIGATION WITH TDRSS USER SOLVES FOR: POSITION VELOCITY TDRS-2 UPLINKEDTDRS-1 EPHEMERIS AND ONBOARD DOPPLER MEASUREMENT USER SATELLITE* IV ATT1 UPLINKED TDRS-2 EPHEMERIS AND ONBOARD DOPPLER MEASUREMENT IJSER SATELLITE ATT2 HARDWARE OVERVIEW Environment Simulator P^DF- 11/70 • 768 K Bytes Memory • FP-11C Floating Point Processor • 1 76 M Bytes Disk Storage • 1 600 Bpi Tape Drives • RSX-1 1 M Operating System S Tracking Data & Uplink Tables Performance Log Performance Plots & Reports Simulation Scenario AODS Prototype PDP-11/23 256 K Bytes Memory Floating Point Microcode (32 and 64 Bit) No External Storage RSX-11S Operating System RSX-11S Console Commands Programmer/Analyst 66 SOFTWARE OVERVIEW Environment Simulator Automated Orbit Determination System (AODS) Data Preparation • Simulation Schedule • Select Tracking Data • Verify Uplink Data / Tracking Data Processing • Max of 500 Observation Pairs Over 24 Mrs. • TORS Orbit Propagator ^B Uplink Tables, Tracking Schedule, / ^^^L- Simulation Schedule / Simulation • Perform Scheduled Uplinks to AODS • Data Corruption • Fast Time Option Uplink Messages Telemetry Output AODS Control / \ Orbit Determination • Batch Least-Squares Estimator • Solve for Orbit (6), Drag and Time Coef. (4) ^1 Event History, \ ^^^L AODS Performance Log \ Analysis/Output • Format Telemetry Ouput • Orbit Comparison With "True" Orbit \ Orbit Propagator • 8th Order Cowell • Complex Force Model- 8x8 Harmonics, Drag, Solar Radiation TYPICAL AODS SIMULATION SCENARIO Propagate Orbit Compute Doppler Output AODS Status Log Output Performance Reports Determine Process Tracking Data Process AODS Initialization Parms. Load code into 11/23 ' • • - ^ - - I - • > • I I - • 1 • • • • 'ime from Start(1rev = 90minutes)0 23 4 5 6 7 8 9 10 11 12 13 14 15 61 FLIGHT EXPERIMENT CONFIGURATION TO ANTENNA DOPPLER SIGNAL & TATUS TRANSPONDER OSCILLATOR & CLOCK MODULES STAT & EPh f- A DOPPLER EXTRACTOR COMMAND & DATA HANDLING US 1EM 1 N A C v c 1 1^ G F A >- T 1| E 0 F N EPHEMERIS EPHEMERIS 0 CONTROL SPA & DATA SUBj ) 1 > 1 t 1 EPHEMERIS TDRSS SCHEDULE GENERAL PURPOSE ONBOARD COMPUTER OTHER ADDITIONAL EQUIPMENT FOR NAVIGATION FLIGHT EXPERIMENT CONSIDERATIONS 1. SELECTION OF A FLIGHT-QUALIFIED PROCESSOR • 64-BIT FLOATING POINT ARITHMETIC • LARGE ADDRESSABLE MEMORY (BEYOND 64K) • MULTITASKING OPERATING SYSTEM 2. HARDWARE INTERFACE • RECEIVER - ADDS - COMMAND AND DATA MODULE • AODS - OTHER ONBOARD PROCESSORS 68 SESSION II GROUND BASED AEROSPACE MICROPROCESSOR APPLICATIONS 10 THE REMOTE COMPUTER CONTROL (RCC) SYSTEM William Holmes Goddard Space Flight Center Greenbelt, Maryland A system to remotely control job flow on a host computer from any touchtone telephone is currently being developed at Goddard Space Flight Center (GSFC). Using this system a computer programmer can submit jobs to a host computer from any touchtone telephone. In addition the system can be instructed by the user to call back when a job is finished. Because of this system every touchtone telephone becomes a conversant computer peripheral. This system known as the Remote Computer Control (RCC) system utilizes touchtone input, touchtone output, voice input, and voice output. The RCC system is microprocessor based and is currently using the INTEL 80/30 microcomputer. Using the RCC system a user can submit, cancel, and check the status of jobs on a host computer. A user can also have the RCC system call when a specified condition is fulfilled. For example, a user could have the RCC call when a specific job has been successfully completed on a host computer. The peripherals used for communication with the user over the telephone are the MH88235 DTMF Receiver/Decoder by Mitel for touchtone input, the MC14410P integrated circuit by Motorola for touchtone output, the Voice Recognition Module (VRM) by Interstate Electronics for voice input and the ML-I Multi-Lingual Voice System by Federal Screw Works for voice output. The RCC system peripherals consist of a CRT for operator control, a printer for logging all activity, mass storage for the storage of user parameters, and a PROM card for program storage. This RCC system enables a user to communicate with a host computer and control job flow on a host computer from any touchtone telephone at any time. The use of this system can decrease turnaround time on a host computer by minimizing the time between job termination and user notification of job termination. This system can help distribute the work load of a host computer to off hours by enabling a user to control the host computer job flow from any remote touchtone telephone. 69 •c o o 0> 3 a £ o a 0) o E 0) DC or uu I— H- oo •=> o a. UJI— ZD ^Q_ UJ s: i— O 00 <_> >- o oo C£ CQ O o az. CO UJ :z> aLU cr: oD_ oo Q_ UJ UJI— «=c o: UJ z / UJ CD cc UJ S f— o => _l Q_ oo o UJ I l 70 EQ> (0 > V> *•> 9 LU CD ^o CO CO UJ CO LlJ CC. O CO CO UJ O O or a. o OtL LU or I— Q >- —• CO OQ I I I o cr: Q_ 71 CO to rx, "Z. o - CO e o t—i CO Q E- CO >l CO o i~r-»fc.— j Q t t r— f w.1 < > :r E-1 t— 4i t T£ Q DJ E- U W c: c: - c CJ CO -D 1— 1 CJ 1-1 ce CJ2^ " 5 ^ s o CJ) o vj 1 CJ <-£ r -,r ' CO . o *T^ w--» Z t-< C^O >-< Q f-yr xC C Q D M Cx3 a CQ 0 O r . i— .c* " CO ) CJ U i-( cc; ce Oi CJ s r? CO 2 CO 0 >< .!-: CQ E- co . M ^D ^ E^ CQ < O E- CO 00 ! 1 Q M CQ O »— ^ ~ CJ i-< a: CJ £ 3 2 >! CO a to CJ 2 < CJ 1 a: w CQ «t7* •— * fc— ' S3 W "^ *6 *j^. ^ ' w »-? w e-< >< .^ < o c- JH En M E^ O 2: 1 CO 12 11 A MICROPROCESSOR APPLICATION TO A STRAPDOWN LASER GYRO NAVIGATOR C. Giardina and E. Luxford The Singer Company-Kearfott Division Littjle Falls, New Jersey This paper is concerned with replacing analog circuit control loops for laser gyros (path length control, cross axis temperature compensa- tion loops, dither servo and current regulators), with digital filters residing in microcomputers. The object of using this type of design is to improve on system reliability (through part count reduction), reduce size and power requirements, and therefore, improve on system performance. Consistent replication in the design is a further benefit derived by replacing analog components with digital software. In addition to the control loops, a discussion will be given on applying the microprocessor hardware to compensation for coning and skulling motion where simple algorithms are processed at high speeds to compensate component output data (digital pulses) for linear and angular vibration motions. Highlights are given on the methodology and system approaches used in replacing differential equations describing the analog system in terras of the mechanized difference equations of the microprocessor. Here standard one for one frequency domain techniques are employed in replacing analog transfer functions by their transform counterparts. Direct digital design techniques are also discussed along with their associated benefits. Time and memory loading analyses are also sum- marized, as well as signal and microprocessor architecture utilized to do the "best job". Trade offs in algorithm, mechanization, time/memory loading, accuracy and microprocessor architecture are also given. 73 RLG CONTROL LOOPS - PERFORMANCE INFORMATION Loop Dither Current Regulator Path Length Control Cross Axis Temperature fnmppnsatnr Variable Beam Inten- sity Corrector Purpose of Loop Eliminate damping in dither spring mecha- nism Balance anode currents Maintain path length in cavity at an in- tegral number of wave lengths Center beam in cavity Locate mirrors to minimize total back- scatter "vector" from the three mirrors (thereby reducing effective lock-in level) Method of Improving Performance Overcome backscattered light between two beams due to mirror (reflector) imperfections and thereby circumvent lock-in Minimize drift due to gas flow in laser cavity Minimize drift due to temperature variation of block Minimize drift due to temperature variation of block Minimize output random noise resulting from dither Required Control Loop Bandwidth ; Moderate when compared ] to microcomputer speeds i Long when compared to microcomputer speeds Long when compared to microcomputer speeds Long when compared to microcomputer speeds Long when compared to microcomputer speeds RLG CONTROL LOOPS - OBSERVABLES AND METHOD OF CONTROL COMPARISON Loop Dither Current Regulator Path Length Control Cross Axis Temperature Compensator Variable Beam Itensity Corrector Observed Signal Dither Amplitude ' Difference in anode currents Beam Intensity Beam Intensity Variation in beam intensity (distor- tion) as gyro period- ically locks in during dither reversals. Variation usually occurs only with a given gyro turn-on. Control Signal Force applied to gyro dither spring through voltage applied to PZT device Base voltage applied to control transistor Force applied to movable mirror through voltage applied to PZT device Force applied to gyro block through voltage applied to PZT device Force applied to a set of two movable mirrors through voltages applied to PZT devices Method of Obser Analog Full -wave recti- fied dither ampli- tude Output voltage from difference amplifier repre- senting difference current Rectification of a carrier signal mod- ulating beam inten- sity Rectification of a carrier signal mod- ulating beam inten- sity Rectification of a carrier signal mod- ulating "winking" amplitude ving Signal Digital Measurement of peak dither ampli- tude through succes- sive measurement of amplitude Same as analog Measurement of beam intensity variation with path length variation through successive iterations of path length Measurement of beam intensity variation with force applied to the block through suc- cessive iterations of that applied force Measurement of "wink- ing" signal through successive iterations of position of two movable mirrors. The signal amplitude will be determined through direct integration. 74 RLGF.UK1CTIOMAL DLOCK UlAGRAMD, DITHER SERVO FUNCTIONAL DIAGRAM TIME 75 PATH LENGTH CONTROL LOOP FUNCTIONAL DIAGRAM PATH LEMGTH VARIATIONS OP THE GYRO CAVITY i REPLACE VVITH A MICRO PROCESSOR U V 76 D I G I T A V . D I T H E R , Loop 5ETT COUNT COUNT CCO1 NT- i. Ou-r REDUCTION IN SYSTEM COMPLEXITY AND COST SAVINGS Electronics Circuit Board Area Required for this Function Number of parts Cost Reliability (Predicted) failure rate X = failures per 10^ hrs Analog * 250 in2 1400 discrete parts $4000 200 Microprocessor (Digital) 50 in2 10 chips $1000 30 * With hybridization approximately same board area could be achieved but.cost factor then becomes about 8:1. 77 ' C O M M EN TS 03 (J < fe o S\. ^ r •"• M >j a ME- ui J L:| i? i 2 CJ t-a c: M u < O Q E O E- Q -« P r.W IA M E N T I M EM O R Y J ; >• o: O§1 S Q U < r^-^ 1 gj l ' So • W CiJ , a, i a M 1 SB : H w ' o en Q J « 2 1 -^ ""1 U -a > 2 U • . o J Q. • < E U ^.%t*Q in u a. Xy 2 1 0t) o 1 N, ! < CL 2 X 0 0 U u > ^ in "•Z X o < a u Eo. n z> < — a: c; a:O a: W H o CJ Q. LI O 2 E- K 2 CC - z 5 M a SiiS 2i.» f "-1 Z) J3 w C 3 a 2 H 2 2 2 D 2 w < O < * U 03 U W O w 2 e u CD M < W 3 J- H U H vtn 2 u, i-f u o oE o in u u ZJ til o: w in (- Z C*j in o o ,J 2 M O *t -. E- v , g U O E- - 3 <•"§ •-< c; c» t.m t- ?. -H.C. a: in o £- a. •» 2 M >• c U CM i- E- ffl 3 go t- £2 •-« in m a n y C C ^ s g i _ _j ^ a- u S3 W U Ug & + 1 t- < £ D E- Z5 E- OM -a 0) .J i^ C E- V) < (J " < Q 1 1 i-i i i ^ P-! < 5 1 tn o. i E- 2 i m : -§> •-n < u U 2 2 S- < O in u *" tt u E- o g 0 7. tv O f- CJ J S2 b™5 n(- o. e •f ' £ o.£ a &si£ ' s~£ nc u ° jE -H" 5% c- 2 a. a. u c. 5^1 5^1 . . t- J » u c. 2 o in SS ' iE X | O ™ u ! * a O :U tu u 2 a w t a ~ < s i u *> 3: u f- U f- ° in E-if, 2 0. o\ 3 J > ZOO D ~ S Q VI ^ E D U 1 I O 1 W O 1 CJ 21 W W 3 (J (J >- L.1 Ifi D V) i C t t - T W O J 32 D ! E-.2 in in J K O ^ J V ) O D I 3 ^ H - - a r - j 2 - < -.: E- => o -J 2 .-i E- -H • - >• £- i £ c. c, S3 i 3 C_ i K r ' a < (J < I W \ 3 w ' s Q 2 1 ? c • - """ * > < - U ! > C U m \ O E- ' in \ s- -f 1C = u ; + <; w 1! i 1 . o ' o 2 : 2 : D w ' •x i- | < Z)i ' i :-. . 1 f- 3- — 1 S ° < Q c < S r co C £- 3 , J « 0 ,in < -^ _i ! W 2 -. J O >• < Q <£ 2 i * in ui UJ u >• >• a: i U ~i S - ^ "^ •- £ 8 d-tr.. dErg = 1 1 i s x a «• H c. a: cc u Q.Z M K. U O H J U 2 CJi-< > m a. u a. J E 5«^ H ra « z O t-u M m 03 LJ W S VI E- tn m cc w => « o E- z m 5j in o "^ J Z M * ••» «« f* V — Ul in H aJ M a: Q Eeo a a ^ a o* ce oc rf 3 v in Q S »1< D 5 ° gH ^ o ^ S § f f l§S- 2 -o- 3 ~< -* >• c. C- u . M a u 2? < = \ 0. C H O fr* O CO J oo o E- W < O tJ 2 -H >• < 0 | j D f \ D | < a • z ; M M iS "" jc • < Q : in u >• K W . t- ! (X o y 0 O » U r< E- OM ec - a u 5, ? j 1 ! ! i "3 \A U 0 > iS ~~ " i in u 2 J : "* o ! o •W : [d W ! W ~ : i - - ! K " iW ' UJ 1 S ' 3 1 z 4 ! H °7 -* W (M E --5 MO n a a Si S2 1 w i 1 Q WS a ° i°I& !:*0 : f 2 •• t-i ,0 -< n * 3 - C, a 3 (X U <. o<\ o.-^ o a a ai a > i 2; c < tno •; x o +-x o < ffi « < (U T 1 | j i o 1 o . o o 2 Z Q Q E IX§Z < O 2 < oo = oo m = < o \ D vOOH E- a) O " J M O fl U 3 ;j «> 1-3 1 •* 2 * ol 78 12 THE SPACELAB EXPERIMENT INTERFACE DEVICE (SEID) Ron Kallus and Saul Stantent Intermetrics Cambridge, Massachusettes The Spacelab Experiment Interface Device (SEID) has been designed and built to simulate the spacelab.>CDMS/RAU Interface for spacelab experiments. Its purpose is to provide a low cost method to aid in experiment hardware/ software verification and spacelab/experiment interface verification. Until recently a spacelab experimenter would have to set aside time and resources for the design and construction of a suitable interface simulator. Any incompatibilities discovered during spacelab integration could result in the removal of the experiment from the flight. The consequences of integration failure may substantially increase project cost and create unacceptable project delay. The SEID simulates the electrical, and logical connections of the Spacelab Remote Acquisition Unit (RAU), the interface functions of the spacelab experiment computer software, and the electrical aspects of the High Rate Multiplexer (HRM). . The SEID meets ESA and NASA electrical, level, timing, drive, and loading requirements for the RAU and HRM interface. Simulated RAU interfaces include PCM serial channels (up to four), User Time Clock (UTC), flexible inputs (UD to 128) and descrete outputs (up to 64). Connectors are logically compatible with the RAU. . The SEID accepts commands from any ASCII source, to execute RAU functions which are normally driven from the software resident in the central experiment computer. The commands are entered in a symbolic or a compressed format and can be executed singly or in user defined groups. 79 The experiment can thus be connected to the SEID, subjected to various sequences of operations and checked for proper system interface characteristics. The SEID can be instructed to execute sequences of input/output commands to the RAU, similar to those performed during flight. This approximation of the experiment computer software is adequate to detect interface problems and prevent these from occurring during SpacelaD--Payload integration. The SEID hardware is a microprocessor based system, utilizing an 8085 micro- processor with 6K of PROM and 4K of static RAM. 80 SUMMARY The Spacelab Experiment Interface Device (SEID) has been designed and built to simulate the spacelab CDMS/RAU Interface for spacelab experiments. Its purpose is to provide a low cost method to aid in experiment hardware/ software verification and space!ab/experiment interface verification. Until recently a spacelab experimenter would have to set aside time and resources for the design and construction of a suitable interface simulator. Any incompatibilities discovered during spacelab integration could result in the removal of the experiment from the flight. The consequences of integration failure may substantially increase project cost and create unacceptable project delay. The SEID simulates the electrical, and logical connections of the Spacelab Remote Acquisition Unit (RAU), the interface functions of the spacelab experiment computer software, and the electrical aspects of the High Rate Multiplexer (HRM). The SEID meets ESA and NASA electrical, level, timing, drive, and loading requirements for the RAU and HRM interface. Simulated RAU interfaces include PCM serial channels (up to four), User Time Clock (UTC), flexible inputs (UD to 128) and discrete outputs (up to 64). Connectors are logically compatible with the RAU. The SEID accepts commands from any ASCII source, to execute RAU functions which are normally driven from the software resident in the central experiment computer. The commands are entered in a symbolic or a compressed format and can be executed singly or in user defined groups. 81 The experiment can thus be connected to the SEID, subjected to various sequences of operations and checked for proper system interface characteristics. The SEID can be instructed to execute sequences of input/output commands to the RAU, similar to those performed during flight. This approximation of the experiment computer software is adequate to detect interface problems and prevent these from occurring during Spacelab--Payload integration. The SEID hardware is a microprocessor based system, utilizing an 8085 micro- processor with 6K of PROM and 4K of static RAM. The basic unit has been augmented with an LSI-11 microcomputer to provide disk storage and a more dynamic environment for generation of control data. A simulation of the General Monitor Loop (GML) is provided to emulate spacelab system timing. 82 SPACELAB EXPERIMENT INTERFACE DEVICE FOR PAYLOAD DEVELOPMENT SEID 83 MOTIVATION * THE PRINCIPAL INVESTIGATOR IS TOTALLY RESPONSIBLE FOR THE CORRECT OPERATION OF HIS EXPERIMENT, * THE EXPERIMENT MUST HAVE BEEN TESTED PRIPr: TO LEVEL IV INTEGRATION, • HARDWARE/SOFTWARE ERRORS OCCURRING DURING PAYLOAD INTEGRATION MAY RESULT IN REMOVAL OF EXPERIMENT, • LEVEL IV INTEGRATION FACILITY (OR SIMILAR FACILITY) WILL NOT BE AVAILABLE FOR INDIVIDUAL EXPERIMENT TESTING/VERIFICATION, SEID OBJECTIVES • TESTING OF EXPERIMENT HARDWARE. • TESTING OF EXPERIMENT PROCESSOR SOFTWARE. • TESTING OF SPACELAB/EXPERIMENT INTERFACE. • OFF-LINE TROUBLE-SHOOTING DURING PAYLOAD INTEGRATION, • INTERFACE CIRCUITS IDENTICAL (OR FUNCTIONALLY IDENTICAL) TO SPACELAB SPECIFICATIONS, • ALL INTERFACE CONNECTORS FUNCTIONALLY COMPATIBLE TO SPACELAB HARDWARE, • ABILITY TO APPROXIMATE ECOS/EAS SEQUENCES OF I/O OPERATIONS, 84 SPACELAB CONFIGURATION MITRA 125 1 T KEYBOARD EXPERIMENT COMPUTER EXPERIMENT I/O UNIT ( t > O.D.U. SPACELAB ENVIRONMENT REMOTE ACQUISITION UNIT R.A.U. TO HRM USER Time clock channels 64 Discrete ON/OFF commands 4 Serial PCM CMD channels 4 Serial PCM DATA channels 128 Flex, inputs USER EXPERIMENT ENVIRONMENT SEID CONFIGURATION LPT CRT DISK y \ |/l LSI 11 TERMINAL 1 > 1 F RS232 * s »— fc TST ( 'OINT \ — i i V v M 4 i UTC • W ON/OFF CMOS ^ PCM CMOS I Er A nA' 'A ™ FLEX. INPUTS ^ ^ HRM E X P E R I M E N T SEID USER SUPPLIED 85 SEID OPERATION MODES EQUIPMENT INTERFACE TESTING SEQUENCING DYNAMIC REAL TIME CONTROL 86 EQUIPMENT INTERFACE TESTING STIMULUS: SEND DIGITAL PATTERN TO SELECTED CHANNEL OQoaooaooQODOQQDoaoaQa DDaDDDDDDDD CRT OR TTY SEID m XI CHANNEL SELECTION DATA 101101101101 BUFFER RESPONSE: READ DATA FROM SELECTED CHANNEL AND DISPLAY OR PRINT DDDDDQaDDDD DDDDaQDDDDD DDDDDDDDDDD CRT OR TTY SEID BUFFER CHANNEL SELECTION = -a EXPERIMENT 3= O S-o 'EXPERIMENT Examples of Commands: >ISSUEJS12, ON; >SENSE008 >WRITE 0, 2, -1A3F, B003 87 SEQUENCING CRT OR TTY S E I D DDDDDaaaoaaggggggggggg STIMULI RESPONSES USER GENERATED SEQUENCE EXPtRIMENT «« * • User may specify sequences via keyboard • The sequence can form a loop and generate stimuli and buffer responses for CRT or TTY presentation • No external support software required Example: ENTERING A SEQUENCE > DEFINE seq 10 begun (echoed from SEID) = ISSUE07,ONx = WAIT 3,0j = READ02\ = SENSE015j = START010) = ENDDEF\ > STARTS10 > STOP010) / 88 DYNAMIC REAL-TIME CONTROL TEST EQUIPMENT LSI-11 DYNAMIC ENV. ' SIMULATOR USER In those situations where even more computer power may be necessary the SEID can beQ interfaced to a user (or I -) supplied computer. This configuration enables the use of a GML simulation. Example: RRINT TESJ MONITOR ON LOAD TEST PERFORM TEST 89 SEID COMMANDS Mil SEQilEN£E > ISSUE NN,ON (OFF) DEFINE PULSE NN.ON (OFF) ENDDEF SENSE NNN START NNNN SAMPLE NNN STOP NNNN WRITE N,CC,HHHH,HHHH,H WAIT SS,MM DEL-WRITE N,cLc2,HHHH,HHHH TYPE AAA— READ N SET-GMT DDDyMMMMMMMM SET-MET DDD,MMMMMMMM WRITE N GMT TIME D£P SPSME LINK N SPSME N DEP-RESP N,CC,HHHHHHHH— SISSUE NN,ON (OFF) DEP-WRITE SS,MM SSENSE NN.NN,— POLL-RATE SS.MM SSAM-BLK NN,NN,— POLL-N SSAMPLE NN IS I-II COMMANDS I/O MONITOR SEQUENCE MANIPULATION MONITOR ON (OFF) DEVELOP ASSIGN II.NN END END SAVE NAME . REMOVE II,NN DESPLAY NN.MM SEQUENCE EDITING SEQUEWCF. EXECUTION INSERT NN LOAD NAME END DELETE NN PERFORM NAME CHANGE NN 90 CO z o I- CL O z o ir o LL Z O o s: s: X •a: i— LU LU o: 0 i — i l— •=c CO OO 0 t ~~ l 1 — Q_ O *a- «3- co oo x x V£> OO < — 1 i — i 1^0 ^O « — i 1 X t— 1 r-H 1 IS , t X ! (/) QJ "O •- (J =3dj ro ro C 4- CQ C i- ro ai iv -C ^ +J ,— 00 : c -Q o i— i ro ro i — co 4-> 4-* C_J | ^ LO r— O ro 13 4-J ro cu Q dj Q. 3 -r— I — ^ E 4-> Q- CO 1- d) T3 •!- 3 C c — d> OO C 1 — .CD » — 1 dj OO ro c: ^ E S- oj dj c "O ooEd) 4-J < — ro 3 o co dj *o -C ro en <_) ^ S- -i- • CJ CQ •— ' O X 1 ^ "O co d> ^" o O <-> c -r- . — o: o •— ( n ro ^~^ 1 1 T" po »— ' LU o: o: 3: X X X 1 X X X 1 1 d) s_ ro 3 d) -(-> S- 14- ro d) 0 3 ! - oo 4-> ro M- 3 => 0 4-> <: co M- o; o 1 LU 00 Q 2! i— i 00 0. LU Q. LU OO CO Q LU o; 3 Ll_ o 00 X X X X 1 1 dl s- ro 3 T3 S- ro dj T" J_ ro S- 3 d) +-> i — O O 00 !_ +-> C C 0 O •!- t-5 1 ' ro -o ^- C • 3 LU Ei ., +-> 00 I s! U_ CO OO 1 — 1 t— f OO 91 FUTURE USES OF THE SEID CONCEPT SHUTTLE PAYLOAD INTERFACE DEVICE: - PAYLOAD MDM - PCMMU - MTU MORE GENERALIZED TEST EQUIPMENT: - ANALOG, SERIAL, DISCRETE INTERFACE CIRCUITS AS APPROPRIATE 92 13 G-CUEING MICROCONTROLLER (A MICROPROCESSOR APPLICATION IN SIMULATORS) Chris G. Horattas Goodyear Aerospace Corporation Akron, Ohio Digital Simulation of aircraft flight requires the iterative solution of a time and event dependent mathematical model. Simulation realism is enhanced by high rate of solution. A simulation whose solution rate produces cues which are per- ceived to be the same as real-world cues, is considered a real-time simulation. Achieving real time simulation is a prime consideration in simulator design. The computation system required to produce real-time simulation is either a single, high cost, extremely high speed processor, or an array of less powerful processors which share the computation task. When multiple processors are used in such array, each is usually dedicated to a simulation subtask and must oper- ate synchronously with the other processors in the array. One such dedicated processor is the G-Cueing Microcontroller (G-CM). The G-CM consists of a tandem pair of microprocessors, dedicated to the task of simula- ting pilot sensed cues caused by gravity effects. This task includes execution of a g-cueing model which drives actuators that alter the configuration of the pilot's seat. The G-Cueing Microcontroller receives acceleration commands from the aerodynam- ics model in the main computer and creates the stimuli that produce physical acceleration effects of the aircraft seat on the pilots anatomy. One of the two microprocessors is a fixed instruction processor that performs all control and interface functions. The other, a specially designed bipolar bit-slice microprocessor with on-board hardware multiply and firmware implemented divide square root and sine functions, is a microprogrammable processor dedicated to all arithmetic operations. The two processors communicate with each other by a shared memory. The G-Cueing Microcontroller contains its own dedicated I/O conve-rsion modules (analog-to-digital, and digital-to-analog) for interface with the seat actuators and controls, and a DMA controller for interfacing with the simulation computer. Even though the microcontroller is programmed to perform the g-cueing model, it is not limited to this specific application. Any application which can be micro- coded within the available memory, the available real time and the available I/O channels, could be implemented in the same controller. Furthermore, the micro- controller capacity can be expanded by the addition of memory and I/O modules. 93 5 UJ UJ 5 O oo 94 95 96 91 98 SIAAULATlOsJ GOAPUTE.R. I/O CONVERTER - CONTROLLER. SIAAPLIFIE.D 99 IN MICROCODE GENERATOR AD AM- 100 MPU (ARITHMETIC) / / DUAL FUNCTION MEMORY [ ADDRESS] DATA CONTROL 1 ANALOG S DISCRETE OUTPUTS ANALOG & DISCRETE OUTPUTS OUT OUT G-CUEING MICROCONTROLLER ANALOG & DISCRETE OUTPUTS V OUT LOAD DATA TO DMA CONTR. BUFFER MEMORY INTERRUPT TO CONTROLLER MPU EXIT/ r SYNCHRONIZATION-G-CUEING MICROCONTROLLER 100 ADAM - FUNCTIONAL BLOCK DIAGRAM (INSTRUCTION WORD FORMAT) 5 5 4 0 3 7 3 3 3 0 2 6 2 1 1 9 1 7 1 3 9 6 BRANCH ADDRESS TEST BRANCH CTL MEMORY CTL DATA BUS ENABLES DIV/SQRT MPY/SINE ALU CARRY ALU SHIFT RgREG ADR RARE6 ADR ALU DEST 3 ALU FUHCT . 0 ALU SOURCE 10 13 FIELD 1 2 3 4 S 6 7 8 9 10 11 12 13 FUNCTION BITS BRANCH ADDRESS CONDITION CODE TEST BRANCH CONTROL MEMORY CONTROL DATA BUS ENABLES DIV/SQRT/MPY/SIN ALU CARRY SELECT ALU SHIFT SELECT RB SELECT Rft SELECT ALU DESTINATION ALU FUNCTION ALU SOURCE 55-40 39-37 36-33 32-30 29-26 25-21 20-19 18-17 16-13 12-9 8-6 S-3 2-0 ALU [ ] INDICATE OPTIONAL ARGUMENT IN INSTRUCTION NOTE THAT ALL CONTROL INSTRUCTIONS WILL BE ENCODED WITH FIELD 4 SET TO 111. FIELD 11 SET TO 001, AND FIELD 12 SET TO 100 ANY OF WHICH HAY BE OVERRIDDEN DURING A MERGE REMAINDER OF.FIELDS DEFAULT TO $ AND MAY BE OVERR1DEN 101 dYW AHOW3W IViOiL i w •s w .j vJ o Z" O u o OJ CJ M dYW 0/1 (WVH) AHOW3W ivna (WVH) H3N39 WVHDOHdOHDIW (WVHDOHd) NOISNYdXa AHOW3W Hoj,iNOW 'onasa : ndw H3^ :^oHI,NO^ NO WVH WYH WVH + WOHd3 WOHd3 CO O CM (N CO CN ro 102 14 MICROPROCESSOR SOFTWARE APPLICATIONS FOR FLIGHT TRAINING SIMULATORS Wayne P. Leavy Goodyear Aerospace Corporation Akron, Ohio Microcomputer distributed processing may be the answer to modifications and improvements for overloaded computer systems of training simulators. Top down functional design is a very useful tool for software implementation, and the same concept can be applied to a multiple processor computer system. The grouping of many independent functions into one large, software module leads to confusion, overhead, and inefficiency; the same is true when many large mainframe computers are grouped into one system. G-cueing is one of the many functions of a pilot training simulator system and a unique candidate for the application of distributed computation techniques. The G-cueing system must respond to the aircraft six-degree-of-freedom (DOF) equations of motion to provide static and dynamic s.timuli to the student pilot's proprioceptive, tactile, and visual (with respect to eyepoint) sensors. The cues provided by the system must include onset cues as well as sustained acceleration cues. . : - . • • • • ' .A G-cueing system has been developed as a strap-on attachment to the.F-15 operational flight training simulator, utilizing a microprocessor computation system. Hydraulic actuators produce the onset cues while pressure control of AIRMAT pneumatic cushion cells produces seat hardness, softness, and contouring to provide for sustained cues. An active lap belt and G-suit is also provided to reproduce those sensations experienced in the actual aircraft. The interface between the G-cueing system software and the software of other simulator systems is very simple: minimal amount of data exchange. However, in itself the G-cueing system is a complex system which requires a significant amount of computer power. This paper presents the G-cueing system software design arm implementation in the dual microprocessor system of the F-15 operational flight training simulator G-cueing system. The software is structured in the two micro- computers such that one serves as a controller performing all logical functions and interface with the host computer system while the other serves as an arith- metic unit performing all mathematical functions. 103 WHY DISTRIBUTED COMPUTATION ? • OFFLOAD THE HOST COMPUTER SYSTEM REAL-TIME CONSIDERATIONS COST ADVANTAGES MODULAR HARDWARE (PLUG-IN UNIT) • INDEPENDENT DEVELOPMENT (SCHEDULE ADVANTAGES) SYSTEM TIME LAG DIAGRAM (A) PILOT INPUTS TOTAL TIME LAG SYSTEM PATH (MSEC) INSTRUMENTS ABCD GSEAT ABE 50 MSEC ANALOG TO DIGITAL CONVERTER 50 MSEC FLIGHT EQUATIONS OF MOTION (B) 155.0 144.7 50 MSEC DIGITAL INTEGRATION p.q.f p,q,r NX,N d.h.Ma,Vt (C) Y.N2 X.Y.Z Nx,Ny.Nz 16.7 MSEC G-SEAT PROCESSOR 5 MSEC INSTRUMENT DISPLAYS 28 MSEC G-SEAT SYSTEM (D) (E) 144.7 104 G-CUING A SELF CONTAINED SYSTEM HOST PROVIDES: • FRAME SYNCHRONIZATION • AERODYNAMIC STIMULI • TRAINER MODE G-CUING A SELF CONTAINED SYSTEM (CONTD) G-CUING SYSTEM PROVIDES: • ONSET CUES • SUSTAINED CUES • BUFFET/VIBRATION CUES • G-SUITCUES • SAFETY MONITORING • CUE SYNCHRONIZATION • SELF TEST 105 106 frLJ (0 (/) 0 1 FE R ST AT US _i [Z E < DC O < Q £' D O m TE M R ES ET CO >to UJ 0 2 d^ a T ST AT US • < ^5 : z LU J-^ ^ ? «« V a C c, <3 *C. < CC LL h- to > co • z ^™ ' D 0 6 r S TA TU S D^ to u u u c J » c t C ^U c/ f ) ) I) 1 » i « L h C •) 0 r L H C « C Z 0 ~s> z JJ _lJJ 3J 3. 4. _l H U Q ] C ) 2 kC K CU SH IO NS (4 «j. 00 E u o ^ 0 r u j . 5 T BU C KL ED _i 01 CO oc e j C 5 CO A T AC TU AT O R S 01 CO H < i < . a h > U CO 011- O CO CO Ol cc a. _) to 3Z 01- A T CU SH IO NS (4 Ol CO 9 3 J 3 Lr • 3 j j 9 ) C C G C 3 Z- BR AT IO N AM P (2 > C ir « 2.E V-f * CC C LU 1 LLU : 0 C o : < t B LE E D A IR A V A IL CO — \ « > Sc § Ot _l 0 cc 1- z o o 1- 01 LL LU o D i L I L 0 U > c D J LUto h fr — *•' < ""i o ^ < LU co EN G IN E( S) R PM Q LU a . 4 CR O R U N N IN G 5 - a. co Q ^ . X ~5 (^ OC ^ O < . z 01 Q CC nr C R AS H W IT H O VE UJ : u- < k 3 a. I cc gnrf N O R M AL LO AD F/ o. to h- Ol LL r>- [2 LU CC Cu ^_ CO 6 5 K A IR SP EE D O LU _i A /C A N G U LA R V E I V c( f ^ i •t- x CO LU LU O QL TR A IN E R M O D E S ^ P t"3- : j ?»?s _ t- i-fe LUto _J FR AM E ST AR T PU -j LU A 1-' _l 'z O .5 co < 1 it -la k ^ SU IT R E A D Y L CO j • u u 3- J G -S UI T O FF SE T/ G < • Uh W SE AT O N /O FF o P IL O T W EI G H T m •u-i o ; K| li -OC L X SE AT R E A D Y L a <: o ^ cc 00 > I o 1— SE AT O N /O FF SW I o LUC. 7 J I n oz L A H Z D CC 5 LU co LU LU Q (- V IB R A TI O N AM PL Q 5t- '-(. L i 1-' K _J LU CO a. < _j LL L^U U. CO T SE AT R U N SW IT CI LU ro >co L o o t >r ^ G -S UI T PR ES SU RE G -S UI T O N /O FF SV LL. O z — a co 107 cc o LJ o 5 o C3 CO o!II C3 LU ^ _ I f f — -!I < < _j -i ^ LU LU LU LU CO CO CO OQ I ST IM UL I" _J O 25 o g OT ^ 2» °- 1— uj > O o ^ P Q H S| uj O 00 < co o cc q DC D o O < LU < LL < > A s d) to i- *- X M3 M5 NO -00s f ., IK ALIZE NO /"" ^ ^ Ml NO \ TURN*1z I FETCH BI/TLP > SEIZES HARDWARE POLLING LOCKOUT PERIOD =At (NO OTHER PROCESSORS CAN ACCESS SHARED MEMORY DURING THIS TIME) • RELEASES PRIMITIVE THIS PRIMITIVE IS EXECUTED BY SLAVE PROCESSORS WHEN RELEASING SHARED MEMORY V ^ pf|IACC. NO S^ ^*^^~ < M" TUBM'X HARDWARE XX^XYES StTBI 11—*. TIMEDELA . _ OTHER PROCESSORS CAN AC- ANOTHER PROCESSOR CESS SHARED MEMORY BUT NO CAN NOW SEIZE VARIABLES CAN BE DISTURBED SHARED MEMORY UNTIL ACCESSING PROCESSOR RELEASES SHARED MEMORY BY MEANS OF THE RELEASES PRIMITIVE POLLING r 119 TASK EXECUTION CONTROL ASSUMPTIONS • UCH TASK CONSISTS OF NSUBTASKS • All SUBTASKS OF A TASK MUST BE COMPLETED BEFORE THE NOT TASK IS PROCESSED DFT APPLICATION A DFT CAN BE DEFINED IN THE FOLLOWING MATRIX FORM: G = WF IF WE LET: • n = 0,1,2 N-l = MATRIX ROW NUMBER AND FREOUENCT STEP • k = 0,1,2 k-l = MATRIX COLUMN NUMBER AND TIME STEP • N = k BUT MAINTAINING n AND k NOTATIONS TO DISTINGUISH ROWS FROM COLUMNS THEN: • W IS AN N x k MATRIX CONSISTING OF THE TERMS W.k = e(-Mj/N)(nk MOD N) = COS [ F(tk) IN EXPANDED FORM, G = WF CAN BE WRITTEN AS:k=0 WN-I.1 W"-1,K.1. ' HoTII TT K / FllT/2 IT K Ft2T/2 n K \ •\ •\FW-K-1T/2 TI SINCE: Gn.k (REAL) = COS delink MOD N)] f(tk) T/2 nk Gfl.k (IMAGINARY) =-j {$« ((^ (nk MOD N)j)F(fk) T/2 nit |Gn|= If. Gn.k (REAL)] *+ Pi' Gn.k (IMAGUURT)] * V l*=o J L4-0 J- THE AMPlirUDE/FREQUENCT VALUES CAN BE OBTAINED AS FOLLOWS: 120 INPUT/OUTPUT SLAVE PROCESSOR 1 2 3 4 5 CTC* TASK/SUBTASK COMPLETIONS TASK1 X X X X X X TASK 2 X X X X X X TASK 3 X X X X X X * CUMULATIVE TASK COUNTER £ 3s .***x,,x'X.^t ** UJ N/Z * * * *U)AH ww u>o tui (4/2 • FREQUENCY * *» • • • ul M£ F(t) = e-* SIN(OUot)«(f) DFT DECOMPOSITION FOR TASK 1 SUBTASK 1 OF N INPUT (SHARED MEMORY) PROCESS (LOCAL MEMORY p) OUTPUT (SHARED MEMORY) 121 DFT DECOMPOSITION FOR TASK 2 SHARED MEMORY LOCAL MEMORY P SHARED . MEMORY Go= Gl = 1 ~ N = K T _ f»o r W o,OFtoT/2iril W 1,0 Ft •.""• WN-l ,OFtoT /2TTK 1 4 "Co.O^ \ 1 Gl • + + \ W o "' W N- 1 < : ^' *1 % . — T — Ffl • ' Ftl T /2TTK .' Ftl T/2TTll '.'Ftl '/21TK * * * • • • T 1 F Wl,K-lF«-lT /2tTK W ".I-' FtK-1 T /2TTK WN-l,K-lF t K . ,T/2TTK Go,l / " + , • * * . + ' \I +.• ' 61,1 / ' • • • > + T\ J +,- ' '. + Gft > R = £Go(REAL) -. Go.K-1 T \ l = ZGo(IMAGINARY) 4 R = ZG1(REAL) Gl,K-l^ "i V I = ^G1(IMAGINARY) jV « -;• • -^ GH.iVi/R=ZCN-""AL' ^ j +). . . , - ) - \ I=ZGN-1(IMAGIMARY) INPUT PROCESS OUTPUT SUBTASK 1 OF K SUBTASK 2 OF K SUBTASK K OF K DFT DECOMPOSITION FOR TASK 3 SUBTASK 1 OF N X GN-l(l) ^, AMP^o) •^ AMPfwi) AMP(uiN-l) INPUT-OUTPUT OF TASK 2 (SHARED MEMORY) PROCESS (LOCAL MEMORY p) OUTPUT (SHARED MEMORY) 122 STATUS • IMPLEMENTATION • GCSS SIMULATION • LABORATORY EVALUATION • FAULT TOLERANT STUDIES - PROCESSOR - SHARED MEMORY - BUS RELIABILITY MODEL 1 OF N PROCESSOR 1 PROCESSOR 2 PROCESSOR N • TAKE ADVANTAGE OF MULTIPLE PROCESSORS • OPTIMIZE EXISTING CONTROL STRUCTURE FOR FAULT- TOLERANCE PURPOSES 1 OF 1 1 OF 1 BUS SHARED MEMORY CURRENTLY SINGLE POINT FAILURES STUDIES TO IDENTIFY FAULT TOLERANT SCHEMES POSSIBLE IMPLEMENTATION OF HIGHLY RELIABLE SHARED MEMORY WOULD BE DUPLEXED CONFIGURATION EACH WITH SINGLE ERROR CORRECTION AND DOUBLE ERROR DETECTION 123 Page Intentionally Left Blank 16 DISTRIBUTED MICROPROCESSORS IN A TACTICAL UNIVERSAL MODEM D. M. Gray, J. B. Malnar, and H. Vickers , Harris Corporation Melbourne, Florida The Wideband Signal Conversion Unit (WBSCU) for the Tactical Information Exchange System (TIES) is a four-channel software reprogrammable modem. System goals are high resource availability, growth potential, reliability, and graceful degradation. The WBSCU processes JTIDS, GPS, IFF/DABS, and TACAN waveforms simultaneously under direction of a host computer. For both complex spread spectrum and pulse-based waveforms, the WBSCU provides matched filtering, signal processing, error detection/correction and encoding/decoding, and data communication via IEEE 488 and MIL-1553 buses. Multiple embedded 8086 and 2901 microprocessors, supported by dedicated hardware modules, perform the required real-time operations for both transmit and receive functions. Commands from a host computer determine the configuration of the WBSCU via the IEEE 488 bus. Each of the four WBSCU channels is assigned to process a specified IF waveform; each channel configures its own resources and, in some cases, borrows resources from other channels. The processed waveform data is communicated from individual channels to redundant global memories. Data flow between the user community and global memories occurs via redundant 1553 buses through intelligent Bus Interface Units. Each WBSCU channel contains one 2901 bit-slice machine and one 8086 microprocessor. The 2901 provides high-speed processing capability for the most time-critical operations. Features include a 16-bit word size, 64-bit microcoded ^instruction, and 10 MHz instruction throughput. The 8086 is used for lower speed processing tasks where its high level language capability can be better exploited. Each 8086 has a global bus for wideband interprocessor communication, and a local bus for 8086/2901, master/slave communication. Software architecture consists of a control and communications structure governing mode-dependent signal processing tasks. In GPS data acquisition, the 2901 processes array correlator outputs and generates code and carrier error signals. The 8086 implements the loop filters required to achieve code lock and carrier synchronization, performs error detection and extracts message bits at a 50 b/s data rate. This data is output via the global memory. During JTIDS signal processing, the 2901 controls hardware modules to generate the acquisition strobe and time refine signals, readying the system to receive the data message. The 8086 performs message level data processing for both transmit and receive functions, data routing, and interchannel communications. 125 2g_ Sib o 2 CO U CQ A u,_trt Sis 2 X UJ K- = Z . £ 126 CO =9 00 <• 00 o cs M EM OR Y CO =)GO oo >oc S x — •" 0 00 I o(/> I (0II O O o O O) CO 3 CO 5 O U. 1 0 u £ b « c Q h r cj . o E : _ 5 si co o °f t— o u cc oc o oc o u >- EQ UE NC cc u. ^ t c c UJ C CO C — 1 U 3 (. •a. c 0 c Jk , ^ 7 u a c a L^ \ a OI CM C 3 0 0 LJ J 3 C L ( t » ( | ( i I ^OC o 5-1 a. \ M OC ES SO R ec o. I. JC JJ «• r u > e 3 J 5 3 a .? » CD •* "* ^ ' § 1 UJ a o o 3n ^ ^ ^J ^ ^^ Q ^ SI ^ zz o °- "J 0 « 5 : c « • cf . I c • c « c o _ j r Aj c j E c2j 03 _JQ. 0= H- o 127 in ooLU ce LZ oc «r >- 5a t- z S o < o i± 0) o 0) o (O 00 o 00 15 u o OQ 00 00 ^ o o o «/> O L3 U CDt t t Z CO O 3 u m co : O I o u 3-2- -•55. CD£ ls*~ 0 I ^_ o e/> f£ o z o 1 z "= z o £ i i k , H> ^§« — 1 M ' i j o\ VI CD i 1 to CO a CO UJ u UJ K- L i r * ^ i i r UJ CJ u. ae UJ Z k r a. u k ^ ™ ^ fe , O U1N03 1 IS I ^_ cc 2" S t s " PW a uj c^ S~ ^ 1 Uj _^ sMl*'s|ls- ^ oc ro .^ UJ *- >SS H- "^ I S2 *a ^ J ^ * z ' 2> Ul - • 128 2901 Bit-Slice Microprocessor 8086 WRITE/READ 8086 DATA BUS 16., 8086 ADDRESS BUS 20^ MICRO CONTROLLER WRITABLE CONTROL STORE CONTROL LOGIC PIPELINE REGISTER PROCESSING ELEMENT INPUT MUX 4 2901s FOR ALU 2902 LOOK AHEAD 8086 DATA INTERFACE CONTROL LINES TO HARDWARE MODULES T 2901 LOCAL DATA BUS t L TO/FROM MISC FUNCTIONS LOCAL DATA MEMORY (1KWORDSI MICRO CVCLE RATE: 8 MHl CONTROL RAM IS INTEL 2148 CONTROL WORD IS 64 BITS WIDE SOME OF THE CONTROL WORD FIELDS ARE: - REGISTER A SELECT |4 BITS) - REGISTER B SELECT - 2901 INSTRUCTION SELECT (9) - CARRY IN |1) - ADDRESS REGISTER TS EN |3) - SHIFT MUX CONTROL |2| (ALSO USED FOR INPUT MUX CONTROL) - PRE MUX CONTROL |2) - FLAG MUX CONTROL |2| - DISCRETE-OEVICE-OEMUX CONTROL |4| - MISCELLANEOUS DISCRETES |15| - PART OF THE NEXT MICRO MEMORY ADDRESS |9| A 12-BIT MULTI-USE BUS IS MADE UP FROM THE REGISTER FIELDS AND PART OF THE INSTRUCTION FIELDS: THE 2901 IS NO OP ed WHEN THE MULTI-USE FIELD IS USED 129 2 3 O5 o o COQ. ) C c(0 O .2 O) c 130 < ff < u o 5 S = S CO 00 o 00 o !o o o z o - a siiS o 3 uj Z LU ^_ = u zo > T aa < — ac u u — II oc — CD UJ UJ : £ «t 59 SS± CO 3 OB H- a ^ o u. U FI LT ER IN TE G RA TE D DA TA OS CI LL AT OR CI RC UI T PA SS GP S DA TA AN D W BS M EM OR IE S OC 5 _ UJ oc £ S oc o ^ ° «* Mil ilil «£ £ccSi z« "S Sz -il- z S £ gg s s s f « iV zS •- o«r o ac ._ u to z a. « < < < a a a u. u. z o o « z z z o o 2 E= P >- < < 0 z z 3 1 W UJ UJ UJ co z ac cc u s = s ± Sr x S o w o O u C7> O) a.O UJ S ac a ui «z O LW ^ H- ^~ CO OC ' ^~ >> < ac cc o CC ^T < < — ' UJ UJ * vg « CJ i I 1= 2S M Z ""' iT S B - IS 0 0 ui a S£ s ^ COtJ -J -J CC UJ L± 2S U Ck o o < UJ ^ o t- tA CO = i<1< «t a i- < z u£ a oc — UJ "i— 0? U (S s >s C/l .,0 zSt5S <2g = ^?3S C^O 0 t— — < •sioz o u 05 - . . LJ> og ui O «s -. 5gs" ' . 3. ' • a % • -1 1 S 1 x *z / 0 0 O .0 ' rf p=uj / Z uj < a. Q z oQ- « ** . '0 u -- *- ^ CO < 1— a 1 CO CO o CD 3 03 CO UJ cc •a Q 1 CO aa o CO K 0 u - C c Q e a i a ^ a « o a i i ( t 1 UJ - 3 C 3 D \ C i r rj. 0 r jj « 5- \ <+ OC t— > 3 ^ O U ^ 3 00 CO o C3 h- < a 3 a oc j fc ^ F w ^ *- ^ ^ = mz UJ U s = Sa- B§- CO 3 3 CO >-ac 0 S UJ (N S • ' * 0 Iz o «t u o s . UI ^ s • < 0 o 131 IS c O >oz " — 9 ul _i « ca uj = < z £ ro o H 2S O CD J i 1 .^ 013 K Z " £ cc o S s o oc >-£ u u. to ^_ US' c(75 . u o o ec E2 M U O uj U 0 555:5 u. O -1 (- > ec - = EE I o I- U ec 5 132 SESSION III MICROPROCESSOR SOFTWARE TECHNOLOGY 17 MICROCOMPUTER SOFTWARE DEVELOPMENT FACILITIES J. S. Gorman and C. Mathiasen Ford Aerospace . : Houston, Texas Historically, microcomputer software/firmware has been developed on a system designed to perform software development and emulation functions for a specific processor. This method proved successful during the early years of microcomputer software development. However, both the number of microcomputers used in system design, and the complexity of the microcomputer software, have increased. These changes dictate that more efficient and cost effective methods be found for developing microcomputer software. One approach is to utilize a host computer with high-speed peripheral support. Application programs such as cross assemblers, loaders, and simulators are implemented in the host computer for each of the microcomputers for which software development is a requirement. The host computer is configured to operate in a time-share mode for multi-users. The provided remote terminals, printers, and down loading capabilities are based on user requirements. With this configuration a user, either local or remote, can use the host computer for microcomputer software development. Once the software is developed (through the code and modular debug stage) it can be downloaded to the development system or emulator in a test area where hardware/software integration functions can proceed. The microcomputer software program sources reside in the host computer and can be edited, assembled, loaded, and then downloaded as required until the software development project has been completed. The use of a host computer for microcomputer software development allows greater expansion and versatility and has resulted in increased performance and improved program- mer productivity. Preceding Page Blank 133 Microcomputer Software Development History 0 Traditionally accomplished on dedicated development systems • Development systems supported one specific processor or processor sets • Minimal operating systems or monitor programs supplied for run time and development support • Standard utilities provided: assemblers and editors • Development method initially adequate The Need for Change • Increasing software complexity surfaced many problems t Single user environment time consuming, inefficient • Difficult to support more than one type of target processor § Development systems provided minimum peripheral support t Development capability relatively slow • Non-availability of development system became serious problem t Need for change eminent 134 Host Computer System Philosophy • Use of host computer system solves many problems j t Host computer can service multi-user environment t Via cross-product software, one host computer can support any number of target processors • Host computer peripheral support can be wide and varied t Host computer provides substantial, resident development tools t Host computer can support remote development facilities t Once software developed, can be downloaded to target processor • Debug and integration can continue via in-circuit emulators Implementation: Hardware Implications t Terminal, printer, and down load line selection can be determined from user requirements t Communication equipment selection can be determined by data rates, line protocol, transmission distances, and signal multiplexing t Computer interfacing equipment selection can be determined by I/O availability and user equipment interface characteristics t Remote printers and host computers must support busy/ready indication using modem circuits • Using standard host computer interface protocol in user equipment can minimize computer interface driver modifications 135 Implementation- Software Implications • First priority: selection of cross-product software • • • If local talent and experience available, software products can be developed instead of purchased • Off-the-shelf assemblers and high level language compilers will support most processors t Most vendors supply executable format software only. Some vendors provide source code t Software for simulation capability should also be purchased • Via total cross-product software package and host system development facilities, software can be checked out through software-to-software integration phase Possible Obstacle: Transferring Software to Target Processor t Use like peripherals on both host system and target processor 0 Host computer flexible disk system can simplify software transfer • Host computer flexible disk system can also provide source code archival • Flexible disk formats must be hardware and software compatible with target processor format • If host computer is remote from target processor, shuttling diskettes back and forth can lead to additional software transfer method analysis 136 Developing A Downloader Capability • Some vendors supply down loader software • Development involves minimal software effort f Downloader approach involves use of development system or emulation device t Can use dedicated development system or emulator port for host computer interface t Via download lines, can use I/O device on development system or emulator to communicate with host computer t Two down load ing philosophies — Controlled method -- Pseudo terminal method • Same environment will also support upload capability Avoiding Pitfalls § Consider many issues during planning stages t Host computer memory limitations can also limit performance and efficiency • Host computer task size limits can increase overlay needs t Cross-product software idiosyncracies can limit software transportability • Investigate symbol table and macro limitations before purchasing cross- product software • If source code purchased, additional cost factors can surface • Development facility personnel must be adequately trained in host computer use and cross-product software 137 • ^ ^^£13 i =5 0) (/) o o 138 18 MICROPROCESSOR USER SUPPORT AT LANGLEY RESEARCH CENTER Jerry H. Tucker Langley Research Center Hampton, Virginia The microprocessor is the most significant advance in electronics since the invention of the transistor. We are building systems today with microprocessors that a few years ago would have been completely impractical or extremely expensive. Microprocessors provide numerous advantages to the system designer such as lower cost, reduced development time, increased flexibility, and increased reliability. Despite these advantages, the use of microprocessors pose significant problems. These include: (1) A long learning process for proficient use of microprocessors. (2) The 'requirement for extensive support in both hardware and software. (3) The need for coordination and sharing of the creative effort to avoid unnecessary duplication. The following steps have been implemented at Langley Research Center to address these problems. (1) The establishment of a microprocessor users committee to provide an advisory interface for management and users. (2) The training of microprocessor users. (3) The publication of a newsletter to dissiminate information among microprocessor users. (4) The use of both cross~software on the central computer complex and microprocessor development systems to support the design of microprocessor based systems. This presentation provides a general overview of microprocessor user support at Langley Research Center, including a detailed review of each of the above items. Special emphasis is given to the microprocessor support available from the central computer complex. An assessment of the effectiveness of the approach being taken at Langley is given. In addition, specific hardware and software development efforts that are targeted toward enhancing the existing microprocessor support is discussed. 139 MICROPROCESSOR SUPPORT AT LANGLEY RESEARCH CENTER • MICROPROCESSOR USER'S COMMITTEE • CENTRAL COMPUTER COMPLEX SUPPORT • LOCAL MICROPROCESSOR SYSTEM DEVELOPMENT LABS MICROPROCESSOR USER'S COMMITTEE • CONSISTS OF KEY MICROPROCESSOR USERS • ADVISES MANAGEMENT AND USERS • ASSISTS IN PROVIDING USER TRAINING • ASSISTS IN DEFINING REQUIRED HARDWARE AND SOFTWARE SUPPORT • COMMUNICATES TO USER COMMUNITY VIA A "MICRO-NEWSLETTER" (sent to 200 people) 140 CENTRAL COMPUTER COMPLEX SUPPORT MAINTAINS MICROPROCESSOR SUPPORT SOFTWARE - ASSEMBLERS (14) - COMPILERS ( 4) - SIMULATORS (12) - UTILITY PROGRAMS IN-HOUSE DEVELOPMENT - ASSEMBLERS, DISASSEMBLERS - 8748 PASCAL COMPILER - 68000 HALS COMPILER - CENTRAL COMPUTER COMPLEX LINKS TO MICROPROCESSOR LABS -. HARDWARE AIDS FOR USERS MICROPROCESSOR SUPPORT MAINTAINED ON LRC's CENTRAL COMPUTER COMPLEX MICROPROCESSOR 8086 68000 9900 8080/8085 6800/6802 . . . Z-80 6809 8748/8741 1802 6502 4040 DESCRIPTION Intel 16-Bit Motorola 16-Bit Old 16-Bit 8-Bit 8- Bit 8- Bit, Super 8080 8-Bit, Super 6800 8-Bit, Single Chip 8-Bit 8-Bit 4-Bit ASSEMBLER i/ (/ (/• \s \s (/ \^ (/ \s IS* \s* SIMULATOR ^ ^ iS u^ \s- IS IS IS' HOL PASCAL (HALS) PLM MPL 8080 PLM PASCAL 141 LOCAL MICROPROCESSOR SYSTEM DEVELOPMENT LABS Typical Lab (ACD's) - Intel Development System linked to Central Computer Complex - Over a dozen users with standard procedures and documentation - Assemblers for S8080/8085, 8748/8741, 8086/8088 - PLM compilers for 8080/8085, 8086/8088 - FORTRAN for 8080/8085 - IN-CIRCUIT EMULATORS (ICE) for 8080, 8085, 8748, 8086, 3000 -' E PROM PROGRAMMER Local Microprocessor Development Systems at Langley - Intel (7) - Motorola (5) - Tektronix (2) - Texas Instruments (2) CHARACTERISTICS OF MICROPROCESSOR SOFTWARE ON'CENTRAL COMPUTER COMPLEX STRENGTHS - UNIVERSAL - SIMULTANEOUS USERS - FAST - FLEXIBLE - TAKES ADVANTAGE OF EXISTING RESOURCES WEAKNESSES - RELATIVELY DIFFICULT TO LEARN (COMPLEX OPERATING SYSTEM AND EDITOR) - LACK STATE OF THE ART SOFTWARE - CANNOT SIMULATE ENTIRE SYSTEM - FRAGMENTS DEVELOPMENT PROCESS 142 19 DEBUGGING EMBEDDED COMPUTER PROGRAMS Gilbert H. Kemp General Dynamics/Western Data Systems Center Pamona, California The debugging of embedded digital computer programs is a function that can use a wide range of support tools from essentially none to sophisticated systems. Every embedded computer program must complete its debugging cycle using some system that will allow real time debugging. A listing of many of the common items addressed during debugging is given. Several approaches to debugging are analyzed to evaluate how well they treat those items. Cost evaluations are also included in the comparison. The approaches compared are: (1) no software support, (2) embedded computer augmented with additional software for debugging purposes, (3) microprocessor development systems, (4) an environment simulation and interpretive computer simulation combination run on a large scale computer, (5) an environment simu- lation on a hybrid computer coupled with the embedded computer, (6) an environ- ment simulation on a midi-computer coupled with an emulation of the embedded computer, and (7) an environment simulation on a midi-computer coupled with a slightly modified embedded computer. The results of the comparison indicates that the best collection of capabilities to cover the common items present in the debugging task occurs in the approach where a midi-computer handles the environment simulation with an emulation of some kind representing the embedded computer. This approach can be taken at a reasonable cost. The case study chosen is an embedded computer in a tactical missile. Several choices of computer for the environment simulation are discussed as well as different approaches to the embedded computer emulator. The selected choice for computer the environment simulation is a special-purpose computer designed to rapidly solve differential equations. The Applied Dynamics International AD-10 computer is an example of this type. This appears to be capable of solving a full 6 Degree of Freedom missile simulation in real time. The proposed choice for emulating the embedded computer is to use a modified version of the embedded computer itself. It is called an "Extended" computer. The "extension" amounts to adding extra bits to the program memory. When an instruction is loaded for execution, an interrupt will occur if one of these extra bits is up. Software interrupt service routines will determine what debug- ging function is to occur, e.g., start a trace. The conclusion is that the use of the AD-10 and "Extended" embedded computer will show a debugging cost savings approaching 44 percent over the current commonly used team of Interpretive Computer Simulation used in conjunction with a hybrid/ embedded computer pair. Reference Glass, Robert L., "Real-Time: The 'Lost World1 Of Software Debugging and Testing", Comm. ACM 23, 5 (May 1980), Pages 264-271. 143 DEBUGGING EMBEDDED COMPUTER PROGRAMS FOR ANY TASK: o IMPROVED PRODUCTIVITY IS DESIRABLE o BETTER TOOLS CAN IMPROVE PRODUCTIVITY o THE TOOLS MUST BE COST EFFECTIVE APPLYING THESE THOUGHTS TO THE TASK OF DEBUGGING EMBEDDED DIGITAL COMPUTER PROGRAMS WILL BE DISCUSSED. POMONA DIVISION DESIGNED DIGITAL COMPUTERS COMPUTER A B C . D YEAR DESIGNED 1971 1975 1976 1978 NUMBER OF INSTRUCT. 24 74 102 158 NUMBER OF GEN. PURPOSE REGISTERS 2 4 8(16) 9(17) INTER- RUPTS NONE ONE VECTORED VECTORED SHORTEST INSTRUCTION TIME (MSEC.) 0.4 0.9 0.4 0.3 RELATIVE TIME OF EXECUTION 1.0 3.1 1.2 0.8 TECH- NOLOGY HARD MIRED BIT SLICE- INTEL 3000 BIT SLICE- AMD 2900 BIT SLICE- AMD 2900 MICRO- CODED NO YES YES YES 144 ITEMS IN DEBUGGING A. INPUT -- HARDWARE AND CONVERSION B. OUTPUT -- HARDWARE AND CONVERSION C. MATHEMATICAL CALCULATIONS D. LOGIC DECISIONS E. CHECK ALL PATHS OUT OF DECISIONS F. OVERFLOWS G. MAXIMUM USE OF PRECISION WITHOUT OVERFLOW H. LACK OF SIGNIFICANCE I. INITIALIZATION OF VARIABLES J. TIMING OF THE PROGRAM K. PROCESS SWITCHING DEBUG TECHNIQUES A. TRACING SELECTED SECTIONS OF THE PROGRAM AT APPROPRIATE TIMES B. ANALOG RECORDING OF SELECTED VARIABLES OF THE PROGRAM C. PRINTING SELECTED PROGRAM VARIABLES AT APPROPRIATE TIMES D. STOPPING ON BREAKPOINTS AND EXAMINING CONTENTS OF REGISTERS AND MEMORY 145 00 UJ a: o o 03 UJ O O CO • (—1— => o US EF UL NE SS IN TE ST IN G (8 ) ^ •^ —X U U. UJ a 0 00 «t fSk o UJ UJ Q. CO tn u.^ - o vt UJ t— Q. 3 >- a. H- Z «r cni^ UJ z .1 3 u. UJ CO => CA PA BI LI TI ES ' (4 ) (V ER SA TI LIT Y) u. --* °s. UJ 00 Z => 0 U. 1— o <: Sio — <_> CO CO ST OF DE VE LO PM EN T OF SI MU LA TI ON (4 ) § i 3 z CO u. 0 UJ Q. >• h- LU 1 1 1 X 1 I X CO _! OO CO z z | N ON E- -M FR . SO FT W AR E LkJ 1 1 1 1 X 1 1 H- Q£ OO -x. _J 00 OO Z oo NO NE — AD O DE BU G SO FT WA RE ^o UJ )— a. i i i t X i ' fr- ee ae _j oo CO i oo oo MI CR OP RO CE SS OR DE VE LO PM EN T SY ST EM (M DS ) UJ - o x — i UJ < h- a. X X X X X X X X X X X 00 r- H- ce * -^ Q£ -J Z X (/> £ M ID I/E M UL AT IO N (2 ) - - CL OS ED LO OP i O UJ o Z UJ • o cc «C Q£ i i — cr CO <£. r- cr **^ Xf^ *^ LU >— (— cc OO LU 0 Q oo oo s oo oo cc1 1 1 1 1 1 _j 1 1 1 1 1 1 ^^ *~ *~ "* *" *~ = i— oo o >•oo oo s: oo LU LU _J O O - >- <: z z LU o 001 >- oo oo oo LU LU O O O «=£ >- >- Z Z Z LU . Qi LU_ =3 Q. 1— S LU O OO C— C_) Q • • .^ . ^^ O Qi Z O LU O3 LUt- ^ >- z <: -3L -z. C3 OO 3 O Z - O LU Of >"H ZD O£ C_? HH CS CL. C^ *^ »^ CD O O Z _J Z Z 2 LU O. LU i— i O3 LU s £ LU Z Q 0- 1 >• Q£ ' _J t— |— _J J LU O _l _l O «t . _l 00 O £ 3 «t LU 3 «C o:S = (X. LL. LU Q. o z o •z. 00 LU C£ LU 1— 3^CL. .y OC_J t— z. LU t—00 l_^ X LU 1 Z o z £^ . z CC ** "^ ** 5^CM CO •^ Q r*«. o: a: UJ O u_ »^ (l «T"U» ^ 5, H^ ST o a O CM 2C f~ >w^ h- < LU Z 00 S h— LU H~" LO CM) Z LU e£ LU Qi O oo => o:LU (— a. CC O O «« o LL. a: ™^"» C3 00 00 UJ O CD (_> Z CC Z H-l 1— 0- *••* ^^ v^ > a z oo «C 1-1 LU Z OO CC LU O 03 3 Q-i— »- 1— <: LU 3T LU LU Z- CO 3 149 20 REAL-TIME OPERATING SYSTEM FOR SELECTED INTEL PROCESSORS W. R. Pool Ford Aerospace Houston, Texas This paper addresses development of a real-time operating system for selected Intel processors, in terms of four project phases. The first phase develops the system development rationale. Included are reasons for not using vendor supplied operating systems. The second phase deals with the system design and performance goals. While many of these goals are dictated by problems with vendor supplied systems, other goals surfaced as a result of a design for a custom system able to span multiple projects. The third phase deals with system implementation. Discussed are system development and management problems and areas that required redesign or major code changes. The final phase deals with project results. First, the relative successes of the initial projects are developed. Then, a generic description of the actual project is provided. Finally, the ongoing support requirements and future plans are discussed. preceding 151 Make/Buy: Requirements Make the Decision • First, determine what system must do — Real-time-quick response — Multi-tasking -priority scheduling — High performance, especially for I/O — Disk file system compatible with ISIS-II — Block mode CRT support t Selection: what will do the job? — Does system exist that meets requirements ? — Can a system be modified at less expense/time ? • Developing your own — Does talent exist ? — Is there time/money ? — Are development facilities available? System Design: A Real Experience Design Goals • Modification ease: add foreign devices • Modular: use only necessary parts ,.^ _ . , . , ' • Standard device interfaces to applications ;*T!tl 5;''"__!i*"" ' . - . , - • "-" if :._;r-Support any board/device configuration 152 System Design: A Real Experience (Cont'd) Control Element Components Control Program Control Block • Task Management Task Control Block (TCB) • Event Signaling Event Control Block (ECB) • I/O Control File Control Block (FCB) • Interrupt and Device Handling Device Control Block (DCB) System Design: A Real Experience (Cont'd) Utility Functions t Display support • Disk file management • Loader • Operator interface • Advisory facilities • Debug monitor Additional Services • Timer services • Dynamic memory allocation 153 Implementation: No Easy Victories The Team • Designer: control block contents, program functions 0 Programmer: program design, development The Plan • Develop task management, interrupt service, and I/O initiation first • Validate control block structure • Correct any control block and design errors • Rewrite as necessary 0 Develop device support and utilities Implementation: No Easy Victories (Cont'd) The Problems • Development systems slow and unreliable 0 Processor poorly suited for multi-tasking and re-entrant code 0 Early delivery resulted in system not fully checked out 0 Tight bindings must be replaced with loose binding to separate OS from applications 0 User documentation slow/non-existent 0 Disk support control block formats must be changed to support different densities 0 Dynamic memory support should have been included in original design 0 Needed to fund support group as user group increased 0 Configuration control problems due to different releases on projects and inadequate library facilities 0 Should have had cross software and timesharing network at beginning 154 Results Met All Requirements and Design Goals t Currently used in three systems; being implemented in four others t Being used in different hardware configurations t Interrupt processing capabilities faster than other available systems • Achieved true multi-tasking capabilities Cost Effective • Effort and budget savings via use on multiple projects t No license fees Results (Cont'd) System Characteristics • 6 months to produce first version; 1 year to produce debugged version in macro form • 4K PROM for basic system with task management, I/O support, and loader • 8K PROM adds display support, debug monitor, advisory, and full disk support • 4-12K of RAM necessary for buffers and control blocks • Normally will support CRT, line printer, and two flexible disk drives • Systems usually embedded in larger equipment systems 155 Future Plans • Recede for different processor t Change user interface to loose binding type • Augment dynamic memory support 0 Convert to higher level language • Provide support for users/projects • Redesign disk support/control block • Provide software library on host development system 156 21 A FOURIER TRANSFORM WITH SPEED IMPROVEMENTS FOR MICROPROCESSOR APPLICATIONS Donald C. Lokerson Goddard Space Flight Center Greenbelt, Maryland and Dr. Robert Rochelle University of Tennessee Knoxville, Tennessee A fast Fourier transform algorithm for the RCA 1802 microprocessor has been developed for spacecraft instrument applications. The computations have been tailored for the restrictions an eight bit machine imposes. The algorithm incorporates some aspects of Walsh function sequency to improve operational speed. This method uses a register to add a value proportional to the period of the band being processed before each computation is to be considered. If the result overflows into the "DF" register, the data sample is used in computation; otherwise computation is skipped. This opera- tion is repeated for each of the 64 data samples. This technique is used for both sine and cosine portions of the computation. The processing uses eight bit data but, because of the many computations that can increase the size of the coefficient, floating point form is used. A method to reduce the alias problem in the lower bands will also be described. 157 SOUNDER PULSE CYCLES IN I SAMPLE TIME * ' 1 I s 4 0 I 7 0 4 1 1 I 7 8 8 6 3 9 8 2 G i i r i9 . 1 i i 6 0 0 1 0 2 8 5 4 8 2 T T 1 1 2 2 1 8 6 0 1 \ \ TRANSLATED , FREQUENCY 4 (-PRESET REGISTER TO 128. AND USE COSINE VALUE IN RECURSIVE ALGORITHM I—ADD 64 COUNTS TO REGISTER -DOESN'T OVERFLOW. SO CHECK IF COSINE WOULD OVERFLOW. IT DIDN'T SO: ADD 64 COUNTS TO REGISTER -REGISTER OVERFLOWED. SO USE VALUE IN SINE RECURSIVE ALGORITHM -ADD 64 COUNTS TO REGISTER -DIDN'T OVERFLOW, SO CHECK IF COSINE WOULD OVERFLOW. IT DIDN'T SO: -ADD 64 COUNTS TO REGISTER REGISTER DIDN'T OVERFLOW. SO CHECK COSINE. IT WOULD OVERFLOW. SO USE VALUE IN COSINE RECURSIVE ALGORITHM ADO 64 COUNTS SINE OF TYPICAL BAND IDEAL COSINE OF TYPICAL BAND DATA SAMPLES ADD "N" COUNTa NO OVERFLOWS OCCURRED. SO CONTINUE ADO "N" COUNTS. OVERFLOW OCCURRED. SO MULTIPLY BY .707 FOR BOTH WAVE FORMS ADD "N" COUNTS. OVERFLOW OCCURRED. SO USE IN SINE RECURSIVE ALGORITHM 1 ADD "N" COUNTS. NO OVERFLOWS. SO CONTINUE ADD "N" COUNTS. OVERFLOW OCCURRED. SO MULTIPLY BY .707 FOR BOTH WAVE FORMS ' ADD "N" COUNTS. IF NO OVERFLOW FOR SINE. CHECK FOR COSINE PRESET REGISTER TO 1% AND USE COSINE VALUE IN RECURSIVE ALGORITHM 158 Y SINE BAND 16 SINE BAND 17 SINE BAND 18 SINE BAND 19 SINE BAND 20 SINE BAND 21 SAMPLE # 1 16 SINE BAND 10 SINE BAND 11 SINE BAND 12 SINE BAND 13 SINE BAND 14 SINE 159 22 FAME—A MICROPROCESSOR BASED FRONT-END ANALYSIS AND MODELING ENVIRONMENT Jacob D. Rosenbaum and Edward B. Kutin Higher Order Software Jericho, New York FAME, (Front-End Analysis and Modeling Environment) is a micro- processor based interactive computer aided design aid, for designers and developers of computer-based systems. FAME is especially useful in microprocessor applications where systems complexity has increased the need for more rigorous approaches to the development process. A variety of techniques and methods are being proposed by govern- ment and industry to meet the extensive need for better approaches to development, documentation and verification of systems. Some of the more widely used include; formal specification of system requirements and designs, static analysis of related models, and simulation to in- sure that the system to be developed meets the intended objective. To date, support of these activities involve large, costly computerized systems or extensive manual procedures. Higher Order Software (HOS) is a methodology for the specification and verification of large scale, complex, real-time systems. An emphasis in its development has been the aerospace environment. Typical systems applications include guidance and control, navigation, communications, radar imaging, satellite tracking and many others. The methodology integrates Functional Decomposition, Abstract Data Types, and Control Structures in accordance with a set of axioms that describe decomposition rules, nodal relationships and responsibilities. The systems models produced can be verified statically using small amounts of computer resources and time. The HOS methodology has now been implemented as FAME (Front-End Analysis and Modeling Environment), a microprocessor based system for interactively developing, analyzing and displaying system models in a low cost user-friendly environment. The nature of the model is such that when completed it can be the basis for projection to a variety of forms such as Structured Design Diagrams, Petri-Nets, Data Flow Diagrams, PSL/PSA Source Code etc. The user's interface with the analyzer is easily recognized by any current user of a structured modeling approach; therefore extensive training is unnecessary. Furthermore, when all the system capabilities are used one can check on proper usage of Data Types, Functions and Control Structures and thereby add a new dimension to the design process that will lead to better, and more easily verified soft- ware designs. . FAME is now available on a range of computer systems as well as on any Microprocessor with 64K of memory and dual floppy disks that can use the CP/M operating system. It is especially useful on Microprocessor Development Systems where one would now be able to combine the require- ments, documentation analysis, verification and code development, activities on a single device. Preceding Page Blank 161 FAME CAPABILITIES MICRO-COMPUTER FAME 0 MODELING 0 ANALYSIS 0 DOCUMENTATION 0 PROJECTIONS MAIN FRAME COMPUTER 0 CORPORATE MODELS 0 CONFIGURATION CONTROL 0 OTHER MODELING/ANALYSIS TOOLS - PSL/PSA - SREM - HIPO OPTIONAL INTERFACE BENEFITS OF HOS 0 MODELS ARE VERIFIABLE STATICALLY 0 MODELS INTEGRATE - FUNCTIONS - DATA TYPES - LIBRARIES OF OPERATIONS & STRUCTURES - RULES FOR MODEL CREATION 0 SUPPORTS ALL PHASES OF DEVELOPMENT 0 MODELS CAN SUPPORT DIRECT SIMULATION > '0 MODELS CAN PROVIDE EXTRACTS TO SATISFY OTHER METHODS 0 AN HOS ANALYSIS REQUIRES KNOWLEDGE OF ONLY A PARENT & ITS OFFSPRING 162 COST BENEFITS OF FAME ON MICRO 0 OFFLOADS MAINFRAME T/S SYSTEMS 0 PROVIDES GOOD RESPONSE 3<$1/HOUR 0 MINIMUM LINE CHARGES 0 HOS MODELING 8 ANALYSIS COSTS ESTIMATES (ON 8080 MICROCOMPUTER) MODELING PHASE f.l QCK MINUTES/NODE NODES INVOLVED DECOMPOSITION 15 MIN PARENTS ANALYSIS 1,5 MIN PARENTS DISPLAY 1,0 MIN PARENTS . CURRENT STATUS 0 PROTOTYPE (C BASIC) ON 8080 MICRO-COMPUTERS (CPM) 0 PROTOTYPE (C BASIC) ON. INTEL MDS 0 PASCAL VERSION ON MICRO (iN DEVELOPMENT) 0 PASCAL VERSION ON VAX 11/780 0 CURRENTLY REHOSTING TO: - HARRIS - CONTROL DATA (CYBERNET) - MULTICS 163 MODEL OF SATELLITE NAVIGATION SYSTEM . PARENT/OFFSPRING DIAGRAM HOG/ FRONI-END ANALYSIS AND MODELING ENVIRONMENT SATELLITE NAVIGATION SYSTEM noirEL NAME: SATNAV AUTHOR: EK PATE/TIME: 7/14 ABB PERFORM AUTOMATIC PROCESSING FUNCTIONS 0=FROC X5A1ST SSETIM LSETF'L CSTSIM : ABBC .'UPDATE SATELLITE :STATE ABBB SELECT FIRST PLACE : ARBn :COKY SET :LESS FIRST :PLACE XSATST SSETIM csrsiM LSETPL 1 LSETPL 2 LSETPL 1 LSETPL LSETPL 2 LSETPL DATA ' DATA TYPE — PART OF XSOTST YSATST SSETIM LSETPL CSTSIM > STATE OF > STATE OK > ORDERED > ORDERED SATELLITES SATELLITES SETS OF IMAGES SETS OF PLACES > ORDERED SETS OF (ORDERED SETS OF LSETPL 2 > ORDERED SET OF PLACES 2 LSETPL J > ORDERED SET OF PLACES 1 STATE STATE ORDSFT ORDSET ORDSET ORDSET ORDSET CONDITION 0=PROC > EQUAL(0.PROCEED! 164 TYPICAL-PROMPTED SCENARIO CtJRtELAIIQ HOW MAN/ OFFSPRING MO YOU WANT TO ADD? 2 FOR NODE ABECA FN NAME (0 ): d OP NAME (8 >: ._ LONG NAME (10 ) LONG NAME (10 ) LONG NAME (10 ) CONNECTOR (8 ) : _...._. INPUT < 8')' 2__ INPUT(8) 4 __„_„ INPUTO) a __.:._ INPUT(8) 6 .___^ INPUT(R) i_- _. OUTPUT (8): XSAISI-'.! FOR OUTPUT XSATST DATA TYPE(8): LONG NAME(IO) LONG NAME(10): S61ELLIIES LONG NAME (10) : *. __ OUTPUT (8) : *___ ._ CONrHTION (8 ).* _.._ __ FOR NODE ABBCE* FN NAME (8 )i OP NAME (8 ) : _ LONG NAME (10 ) LONG NAME (10 )I \ CONNECTOR (8 ).* COJOIW..._ INPUT (8): XSa'ISI.1.1 INPUT(8): 4 INPUT (8) : 1Q.;._. INPUT(S): 6 •INPUT(B): x OUTPUT (:8) : OUTPUT (8): .^_.:_ DO YOU WANT TO MAKE ANY CHANGES FILES CLOSED RUNNING UPDATE: PASSWORD RiEIR TO INPUTTED INFORMATION7N UPDATE COMPLETED 165 TREE DIAGRAM :AA :CHOOSE -JOPTIONS A SATNAV : PERFORM ! SATNAV [FUNCTIONS :ABA :CLONE(1) - :COPY OF :STATE :ABB SPERFORM :AUTOMATIC .'PROCESSING FUNCTIONS :ABC : EXECUTE :MANUAL JOVERRIDE ABBA COPY SET LESS FIRST PLACE ABBB SELECT FIRST PLACE ABBC UPDATE SATELLITE STATE ABCA OVERRIDE ABCB SATNAV 166 23 APPLICATION OF SOFTWARE TECHNOLOGY TO A FUTURE SPACECRAFT COMPUTER DESIGN Robert J. LaBaugh Martin Marietta Corporation Denver, Colorado An Independent Research and Development task* at Martin Marietta has been investigating advanced spacecraft computer systems for the past couple of years. The task objectives are to demonstrate how major im- provements in spacecraft computer systems can be obtained from recent advances in hardware** and software technology. This presentation covers the major software topics which have been addressed during the task. Investigations into integrated circuit technology performed at the beginning of the task indicated that the CMOS/SOS chip set being develop- ed for the Air Force Avionics Laboratory at Wright Patterson had the best potential for improving the performance of spaceborne computer systems. An integral part of the chip set is the bit slice arithmetic and logic unit (ALU). The flexibility allowed by microprogramming, combined with the software investigations described below, led to the specification of a baseline architecture and instruction set. *This work was conducted by the Denver Division of Martin Marietta Cor- poration under Independent Research and Development Project Authorization D-80D. **Related paper, "Application of Advanced Electronics to a Future Space- craft Computer Design", in Microprocessor Hardware Technology Session. 167 One of the goals was to design an instruction set similar to modern minicomputer instruction sets, with multiple user registers. Another goal was to provide the throughput and precision required for flight applications, and at the same time provide an instruction set which would ease the pro- gramming of such applications. Several assembly language application pro- grams, along with the necessary microcode, were written to help define the features to be included in the processor design. One of the areas this was used for was determining the number of registers in the system. An increase in the number of floating point registers from four to eight pro- vided around a 10% improvement in execution time for one of the application programs. The number of registers was limited, however, by a desire to store them in the 16 physical registers internal to the ALUs. This would avoid delays in accessing the registers and help keep the parts count down. The need for scratch registers by some of the microprograms was another limiting factor-. As a compromise between having as many registers as possible and the limits imposed by the ALUs, it was decided there should be seven floating point registers and eight general purpose registers. Partly to accommodate all the user registers desired, the system was designed to have two arithmetic processing units: one to handle floating point oper- ations and store the floating point registers; and the other to handle general purpose registers, and system registers such as stack pointers and the pro- gram counter. Only one of the two processors is active at any given time. Which processor is active during a cycle is determined by means of a bit in the microword. This was done so that the processors could share the 26 bits in the microword needed for ALU control. The precision and format of floating point operands was derived in . - • c part from the results of a study on high precision attitude computations. The main goal of the study was to characterize the drift rate of the in- tegrator as a function of operand precision and rate sampling interval. One of the conclusions was that 32 bit-floating point operands, with 24 bit mantissas, were adequate for currently envisioned projects. The study was based on data using operands with binary normalization. To remain con- sistent with this, we decided to use binary rather than hex normalization which can result in only 21 bits of significance in a 24 bit mantissa. 168 Because of the characteristics of the chip set and a desire for fairly high performance, a horizontal, rather than vertical, microword was used. There are 34 fields in the microword, which is 80 bits wide. As wide as the microword is, a fair number of fields still have to be decoded. En- coded fields are primarily used for things like selection of operand source and destination, the source for register specifications, and condition code selection. A wide microword, however, puts constraints on the number of words of control store because of the high non-recurring cost of ROMs. In an effort to keep the size of the control store within limits, and to assure adequate system performance, the microcode was .developed concurrently with the circuit design. This allowed us to make various hardware versus soft- ware trades at a time when changes to the hardware design could be accomp- lished without too much difficulty. Fairly early in the task an absolute assembler and an instruction set simulator were developed. These allowed the software development to pro- ceed while the hardware design was being completed, and the hardware was being built. Langley Research Center has recently provided Pascal and HAL compiler frontends. The Pascal system includes a compiler which produces P-code, and a P-code interpreter. The HAL system consists of a compiler which produces HALMAT, a program which translates HALMAT into H-code, and an H-code interpreter. H-code is P-code with a few extra instructions and an expanded run time library. A.program to translate from P-code/H-code to assembly language has been developed and Pascal and HAL routines have been .executed on the instruction set simulator. The translator has undergone several refinements to improve the code generated. The initial version mimicked P-code fairly closely by keeping the expression evaluation stack in memory. By redefining register usage so that the top of the stack was kept in registers wherever possible, a 50% improvement in memory usage and execution time was achieved. Floating point push and pop instructions were also added. An investigation of a one instruction lookahead in the trans- lation process indicated a further 12 to 14 percent improvement in memory usage and 7 to 30 percent improvement in execution time was possible. Future plans include continued investigation of P-code instruction look- ahead in the translation process and further examination of the impact of high order languages on the instruction set. 169 BACKGROUND OBJECTIVES:* QUANTITATIVELY DETERMINE HOW RECENT ADVANCEMENTS IN HARDWARE** AND SOFTWARE TECHNOLOGY CAN.BE USED TO OBTAIN IMPROVEMENTS IN SPACECRAFT COMPUTER CAPABILITIES, CMOS/SOS INTEGRATED CIRCUITS SEMI-CUSTOM LSI DEVICES LEADLESS CARRIER PACKAGING MICROPROGRAMMING PASCAL, HAL, ADA, HIGHER ORDER LANGUAGE *THIS WORK WAS CONDUCTED BY THE DENVER DIVISION UNDER INDEPENDENT RESEARCH AND DEVELOPMENT PROJECT AUTHORIZATION D-80D **RELATED PRESENTATION, "APPLICATION OF ADVANCED ELECTRONICS TO A FUTURE SPACECRAFT COMPUTER DESIGN", IN SESSION IV: MICROPROCESSOR HARDWARE TECHNOLOGY APPROACH PRELIMINARY REQUIREMENTS AND IMPACT S/W TO ASSIST IN ARCHITECTURE DESIGN 0 ABSOLUTE ASSEMBLER • INSTRUCTION SET SIMULATOR MICROPROGRAM DESIGN S/W DEVELOPMENT TOOLS 170 FEATURES-REQUIRED IN PROCESSOR MINICOMPUTER LIKE INSTRUCTION SET MULTIPLE FLOATING POINT AND GENERAL PURPOSE REGISTERS FLIGHT APPLICATIONS • SUFFICIENT THROUGHPUT • SUFFICIENT PRECISION • EASE OF PROGRAMMING REGISTER CONSIDERAIONS TYPES: • GENERAL FOR USER • FLOATING POINT FOR USER t SYSTEM FOR USER • SYSTEM FOR MICROPROGRAMS CONSTRAINTS: t 16 PHYSICAL REGISTERS INTERNAL TO ARITHMETIC AND LOGIC UNIT DEVICES • SEPERATE ALU DEVICES FOR FLOATING POINT TRADES: • PERFORMANCE SENSITIVITY TO SIZE OF REGISTER FILE 0 EXTERNAL REGISTER FILE - DEGRADES PERFORMANCE 171 REGISTER CONSIDERATIONS OPERAND PRECISION: LARGER OPERANDS REQUIRE MORE PARTS, LONGER CYCLE TIMES MICROCODE VS HARDWARE - SLOWER, LARGER CONTROL STORE NEEDED FLOATING POINT PRECISION - 32 BITS WITH BINARY NORMALIZATION SUPPORTED BY SPECIALIZED HARDWARE INTEGER PRECISION - 16 BIT WITH 32 BIT PERFORMED BY MICROCODE FUNCTIONAL REGISTER UTILIZATION 16 BITS 32 BITS PROGRAM COUNTER USER STACK POINTER PRIV STACK POINTER GEN GEN GEN GEN GEN GEN GEN GEN REG REG REG REG REG REG REG REG 0 1 2 3 4 5 6 7 NOTES; . • FLOATING FLOATING FLOATING FLOATING FLOATING FLOATING FLOATING POINT POINT POINT POINT POINT POINT POINT REG! REG I REG I STER STER STER REGISTER REG I REG I REG I STER STER STER 1 2 3 4 5 6 7 FLOATING POINT SIGN BIT KEPT IN UNIQUE REGISTER FILE 5 OTHER 16-BIT REGISTERS RESERVED FOR MICROPROGRAMMER 1 OTHER 32-BIT REGISTER RESERVED FOR MICROPROGRAMMER GENERAL REGISTERS 1-7 CAN BE USED AS INDEX REGISTERS 172 EXAMPLE OF PHYSICAL REGISTER UTILIZATION o i 2 3 4 5 6 7 8 9 A B C D E F FLOATING POINT PROCESSOR SCRATCH FIT FLT FLT FLT FLT FLT FLT FLT FLT "FLT" FLT FLT FTf FLT PT PT PT PT PT PT PT PT PT PT PT PT PT PT REG REG REG REG REG REG 1 2 3 4 5 6 MANTISSA MANTISSA MANTISSA MANTISSA MANTISSA MANTISSA REG 7 MANTISSA SCRATCH REG REG REG REG REG REG REG 1 2 3 4 5 6 7 EXPONENT EXPONENT EXPONENT EXPONENT EXPONENT EXPONENT EXPONENT THE FLOATING POINT SIGN BIT FILE IS EMBEDDED IN CUSTOMIZED LOGIC 24 BITS MACRO LEVEL INSTRUCTION SET 106 INSTRUCTIONS 8 CATAGORIES FIXED POINT INDEX/COUNTER REGISTER FLOATING POINT LOGICAL BRANCH STACK AND REGISTER SAVE AND RESTORE EXECUTIVE FUNCTIONS MISCELLANEOUS 10 FORMATS REGISTER-REGISTER REGISTER REGISTER-ADDRESS REGISTER-IMMEDIATE INDEX-REGISTER INDEX EXTENDED ADDRESS INDEX-ADDRESS SPECIAL SPECIAL EXTENDED 173 MICROPROGRAM DESIGN HORIZONTAL RATHER THAN VERTICAL • DECODING FIELDS DEGRADES PERFORMANCE • FORCE LOGIC TO QUIESCENT STATE WHEN NOT BEING USED • BECAUSE OF WIDE MICROWORD, NEED TO KEEP NUMBER OF WORDS OF CONTROL STORE AS SMALL AS POSSIBLE MICROPROGRAMS DEVELOPED CONCURRENTLY WITH HARDWARE DESIGN • ASSURE ADEQUATE PERFORMANCE • CONTROL STORE LIMITED BECAUSE OF HIGH NON- RECURRING COST PRIMARY SOFTWARE MODULES & STATUS REQMTS DESIGN IMPLEMENTATION ASMA-D32: ASMR-D32: LNK-D32: SIM-D32: PAS- LCI: HAL-LCI: RTEX: SSP-D32: STD-2: ABSOLUTE ASSEMBLER RELOCATABLE ASSEMBLER LINK EDITOR INSTRUCTION SET SIMULATOR PASCAL COMPILER HAL COMPILER REAL TIME EXECUTIVE SCIENTIFIC SUBROUTINE PACKAGE SELF TEST/DIAGNOSTIC ROUTINES COMPLETE COMPLETE COMPLETE COMPLETE COMPLETE COMPLETE IN PROGRESS IN PROGRESS IN PROGRESS COMPLETE COMPLETE COMPLETE COMPLETE COMPLETE COMPLETE 1981 IN PROGRESS IN PROGRESS COMPLETE COMPLETE COMPLETE COMPLETE COMPLETE COMPLETE 1981 IN PROGRESS 1981 174 COMPUTER DEMONSTRATION UNIT SET UP dZl-1 P1C-16 1J MMU-A RAM- 8 DDflM O rnUI]-o CCDI A| otK IHL I/O HIGH ORDER LANGUAGE CAPABILITIES PASCAL AND HAL COMPILERS • FROM LANGLEY RESEARCH CENTER • WRITTEN IN PASCAL PATH PASCAL COMPILATION PROCESS • PRODUCES P-CODE • INTERPRETER FOR P-CODE HAL COMPILATION PROCESS • PHASE 1 PRODUCES HALMAT • HALMAT TO H-CODE • INTERPRETER FOR H-CODE TRANSLATOR FROM P-CODE/H-CODE TO ASSEMBLY LANGUAGE 175 SOFTWARE PRODUCTS HAL Compiler 1 HALMA! HAL translator * inter 1 H-Code Translator [ Abso Assei 1 Instruction Set Simulator \ PASCAL \ } Source 1 PASCAL PASCAL 1 P-Cote Translator 1 1 ute Relocatable nbter Assembler 1 Link Editor < — 1 Engineering Development Computer \ Assembly \ JUnguage I / Source / ^ System^ -1 library 1 1 Flight Computer TRANSLATOR REFINEMENTS SAMPLE PROGRAMS • CALCULATE PI TO SIX DIGITS t BINARY SEARCH PRELIMINARY DESIGN: • STACK IN MEMORY FIRST REVISION: • TOP OF STACK KEPT IN REGISTERS • FLOATING POINT PUSH AND POP ADDED SECOND REVISION: • LOOK AT TWO P-CODE INSTRUCTIONS BEFORE GENERATING CODE 176 PROCESSOR SOFTWARE COMPARISON NUMERIC TEST PROGRAM - PI APPROXIMATION MAC-16 ASSEMBLY LANGUAGE LINES OF CODE WORDS OF MEMORY EXECUTION TIME PASCAL LANGUAGE LINES OF CODE WORDS OF MEMORY EXECUTION TIME HAL LANGUAGE LINES OF CODE WORDS OF MEMORY EXECUTION TIME 74 11969 28 243 16691 28 254 .16885 POP 11/34M 37 68 14909 28 347 ATAC-16 50 79 12412 28 157 13722 PROCESSOR SOFTWARE COMPARISON NON-NUMERIC TEST PROGRAM - BINARY SEARCH MAC-16 ASSEMBLY LANGUAGE LINES OF CODE WORDS OF MEMORY EXECUTION TIME PASCAL LANGUAGE LINES OF CODE WORDS OF MEMORY EXECUTION TIME HAL LANGUAGE LINES OF CODE WORDS OF MEMORY EXECUTION TIME 25 31 143 17 138 886 17 142 937 PDP 11/34M 26 31 170 17 107 ATAC-16 24 24 127 17 65 665 177 CODE GENERATOR IMPROVEMENT HISTORY 3 —- u_ UJ LJ_ Ctl LU WORDS OF MEMORY M n 11 it i- LULL EXECUTION TIME OPTIMIZATION CHANGE o BINARY SEARCH A PI APPROXIMATION I J- OPTIMIZATION CHANGE FUTURE PLANS TRANSLATOR: • MULTI P-CODE INSTRUCTION LOOKAHEAD • MULTI PASS - OPTIMIZE REGISTER USAGE DIRECT HALMAT TO ASSEMBLY LANGUAGE CONVERSION BASED ON HALMAT TO H-CODE PROGRAM CONTINUE EXAMINING HOL IMPACT ON INSTRUCTION SET 178 24 A TRANSLATOR WRITING SYSTEM FOR MICROCOMPUTER HIGH-LEVEL LANGUAGES AND ASSEMBLERS W. Robert Collins* Computer Sciences Corporation Hampton, Virginia • John C. Knight Langley Research Center Hampton, Virginia and Robert E. Noonan** ^ College of William and Mary Williamsburg, Virginia NASA LaRC uses many dedicated microprocessors in aerospace research. Few software tools are available for these machines, and in particular, very few have any form of high-level language facility. Since the Langley environment involves considerable experimentation, a great deal of software is experimental and may change frequently. It has to be prepared relatively quickly and at low cost. In order to implement high-level languages whenever possible, a Translator Writing System of advanced design has been developed. It is intended for routine production use by many programmers working on different projects. As well as a fairly conventional parser generator, it includes a system for the rapid generation of table driven code generators. This code generation system is the result of research performed at the College of William and Mary under NASA sponsorship. The parser generator was developed from a prototype version written at the College of William and Mary. The Translator Writing System includes various tools for the management of the source text of a compiler under construction. In addition, it supplies various "default" source code sections so that its output is always compilable and executable. The system thereby encourages iterative enhancement as a development methodology by ensuring an executable program from the earliest stages of a compiler development project. ' This presentation will describe the Translator Writing System and some of its applications. These include the PASCAL/48 compiler, three assemblers, and two compilers for a subset of HAL/S. PASCAL/48 is a Pascal-like language for the Intel-8748 microcomputer. The assemblers which have been built are for assembly language subsets for the Intel-8080, the Motorola M68000, and the NSSC-II. The HAL/S subset was implemented for the Intel-8080 and the GE 703. Detailed measure- ments of the use of the system to build the code generators for the HAL/S compilers will be given. *Work performed under NASA contract numbers NAS1-14900 and NASl-16078. **Work performed under NASA grant number NSG-1435. 179 THE PROBLEM NEED HIGH-LEVEL LANGUAGES, HENCE COMPILERS NEED ASSEMBLERS ONE SOLUTION IS A TWS TWS CRITERIA ENCOURAGE ITERATIVE ENHANCEMENT - EARLIEST POSSIBLE EXECUTION - TEXT MANAGEMENT TO RELIEVE TEDIUM FLEXIBILITY IN ITS USE TRANSPORTABLE IMPLEMENTATION TRANSLATOR WRITING SYSTEM Grammar ( E D I T O R ) / Skeleton New Compiler d.Grammar Semantics EDITOR GRAMJEREfi f I COMPILE7 Executable Compiler Old Compiler Old Compiler Old Compiler I . A __ 180 USE OF TWS . 1. IF PARSER NEEDED, RUN PARGEN, EXECUTE RESULTING COMPILER TO TEST. 2. CHANGE GRAMMAR AS NECESSARY, RERUN PARGEN. 3. ADD SEMANTICS USING EDITOR. 4. RECOVER GRAMMAR AND SEMANTICS WITH GRAMGEN IF NECESSARY TO RERUN PARGEN. 5. IF CODE GENERATION NEEDED, PREPARE CGGL SPECIFICATION AND RUN CODGEN. 6. MODIFY CGGL AS NEEDED. 7. ITERATE THROUGH ABOVE STEPS ADDING LANGUAGE FEATURES AS DESIRED. PARGEN INPUTS - GRAMMAR IN STANDARD BNF - SEMANTICS IN PASCAL - SKELETON OR OLD COMPILER OUTPUT IS AN EXECUTABLE COMPILER INCLUDING - SCANNER - LALR (1) PARSER - SEMANTICS ROUTINE • TEXT MANAGER PRESERVES PROGRAMMER'S CONTRIBUTION TO COMPILER E. G., SYMBOL TABLE ROUTINES . 181 CODGEN INPUTS - CGGL SPECIFICATION - SKELETON OR OLD COMPILER OUTPUT IS AN EXECUTABLE COMPILER INCLUDING A CODE GENERATOR. CGGL IS A NON-PROCEDURAL LANGUAGE FOR DESCRIBING THE CODE- GENERATION PROCESS. TEXT MANAGER PRESERVES PROGRAMMER'S CONTRIBUTION TO COMPILER E.G., MACHINE LANGUAGE FORMATTER. PASCAL/48 INTEL-8748 - MICROCOMPUTER - 8-BIT CPU .- 64 WORD RAM - 1024 WORD ROM - 27 I/O LINES PASCAL/48 - PASCAL DERIVATIVE FOR 8748 - EXTENSIONS TO ALLOW CONTROL OVER GENERATED CODE - RESTRICTIONS TO PROHIBIT INEFFICIENT FEATURES - COMPILER AVAILABLE ON CDC CYBERS 182 ASSEMBLERS CUSTOMIZED SKELETON FOR ASSEMBLERS - TWO PASSES - STANDARD LISTING BY DEFAULT - FLEXIBLE INPUT FORMAT CONVENTIONS - HANDLES MACROS WITHOUT PARAMETERS COMPARED TO META-ASSEMBLER, ASSEMBLER BUILT FOR NSSC-II - WAS PRODUCED MORE QUICKLY - EXECUTES 5 TIMES FASTER - USES ONE FOURTH THE SPACE EXAMPLE PASCAL/48 PROGRAM NASA/ LANGLEY RESEARCH CENTER 80/08/26. 08.91.12. PAGE 1 PASCAL 8748C VERSION 1.0.0 PROGRAM MAIN CSC/NASA 1 PROGRAM FOR_YOU5 2 3 VAR IC2I t INTEGERj 4 Atl6_300, ROM] > ARRAY [1001 OF INTEGER! 9 6 VALUE A • (99 OF 0, 1); 7 e 9 PROCEDURE GET.INPUTj 10 BEGIN 11 REPEAT 12 UNTIL PORT1 BIT 3 13 END; «* GET.INPUT *) 1* 15 16 BEGIN (* PROGRAM FOR.YOU *) 17 FOR I !• 100 OOWNTO 1 00 16 BEGIN 19 GET INPUT; 20 PORT1 «• PORT1 AND 2.11100011) 21 PORT2 «• ACI] + POPT1 XOR I 22 END (* FOR I i- 100 DOWNTO 1 00 BEGIN *) 23 END. (* PROGRAM FOR.YOU *) 183 GENERATED CODE FOR EXAMPLE PROGRAM L003t L007« L009» LOODi LOlZi 101*: JMP NOP JMP HOP NOP JMP CLR MOV JMP IN CPL JB3 RET MOV CALL ANL IN MOV MOV MOVP3 ADD XRl OUTL DJNZ L009 L003 LOOT A PSW.A Loi2 A, PI A LOOD LOOD Pl»»227 A, PI R1,A A,P2 A,JA A,R1 A,R2 P2,A LINE 9 LINE 13 LINE 13 LINE 13 LINE 14 LINE 18 LINE 21 LINE 22 LINE 22 LINE 22 ; LINE 22 ! LINE 22 ) LINE 22 ; LINE 22 i LINE 22 SEPARATE CODE GENERATION USING CGGL LANGUAGE: HAL/S INTERMEDIATE CODE LANGUAGE: HALMAT 178 OPERATORS TOTAL 30 OPERATORS IMPLEMENTED 25 GENERATE CODE BASICALLY AN INTEGER SUBSET WITH SIMPLE CONTROL STRUCTURES CODE GENERATORS ONE PASS NO PRE-OPTIMIZATION PASS NO PEEPHOLE OPTIMIZATION INTEL 8080, GE 703 184 IMPLEMENTATIONS INTEL 8080 8.BIT MACHINE SINGLE ACCUMULATOR NO INDEX REGISTER 1, 2, 3 BYTE INSTRUCTIONS HARDWARE STACK ONLY INTEGER ADD, SUBTRACT 16 BIT ADDRESSES GE 703 16 BIT MACHINE SINGLE ACCUMULATION INDEX REGISTER ONE WORD INSTRUCTIONS NO HARDWARE STACK INTEGER ADD, SUBTRACT, MULTIPLY, DIVIDE ONLY ADDRESS CURRENT PAGE, PAGE ZERO PAGE: 256 WORDS 703 CODE GENERATOR TASK ' TIME (DAYS) READING MANUAL .5 CGGL PROGRAM 1.5 WRITING PASCAL ROUTINES 1.5. DEBUGGING " 1.0 4.5 DAYS NOTES: 1. ALL PROGRAMS WERE CODED AND KEYED BY NOONAN. 2. SOME OF DEBUGGING TIME WAS USED IN CLEANUP. 3. ONE DEBUGGING RUN WAS USED TO FIX A BUG INTRODUCED BY CLEANUP. 1. A TOTAL OF 6 RUNS (EXECUTION) WERE USED. 5. ONE CGGL BUG. 185 703 IMPLEMENTATION SOURCE OF CODE 8080 IMPLE, MODIFIED 8080 NOONAN CGGL No, PROCEDURES 46 4 9 1 % LINES 58% 82 10% 24% % INSTR, STORAGE 58% 6% 10% 26% NOTES: 1, CGGL PROGRAM: 292 LINES 2, PASCAL PROGRAM: 890 LINES 3, FOR AN EARLIER NON-TABLE-DRIVEN IMPLEMENTATION, CGGL ACCOUNTED FOR 83% OF LINES AND 77% OF STORAGE, 186 SESSION IV MICROPROCESSOR HARDWARE TECHNOLOGY 25 A HIGH PERFORMANCE MULTIPLIER PROCESSOR FOR USE WITH AEROSPACE MICROCOMPUTERS P. E. Pierce Sandia National Laboratories Albuquerque, New Mexico An MC68000-based microcomputer including a hardware multiplier processor has been designed and prototyped for a re-entry vehicle navigation and control application. In this paper, the microcomputer is discussed with emphasis on the multiplier processor architecture, software control and theory of operation, The MC68000 CPU of the microcomputer cannot satisfy the real- time multiply processing requirements of a high accuracy RV navigator. The standalone CPU thru-put for multiply intensive applications is increased approximately seven times by the addition of a board level Hardware Multiplier Processor (BMP). Although the HMP was designed for the MC68000 microcomputer, it can be used with any 16 or 32 bit CPU with minimal modifications. The memory mapped HMP performs 16 and 32 bit multiplications and can optionally add or subtract the full product to previous accumulator contents. The circuitry is sufficiently fast to allow the MC68000 running at 8 MHz to write single or double precision variables to the HMP using memory to memory transfers and perform an operation with no wait states introduced or overhead time for command passing. The result of multiply and accumulate operations may be transferred in its entirety or scaled by 2*30 and rounded automatically prior to transfer to the destination location specified by the CPU. Worst case CPU wait times introduced are: 3.3 ysec for double precision scale by 2""^ * and round to single precision; and 6.3 ysec for quadruple precision scale by 2~30 ana round to double precision. i The Hardware Multiplier Processor incorporates Serial/Parallel Hardware Multiplier ICs, a translation PROM and address con- trolled logic to implement previously mentioned arithmetic functions. The use of serial arithmetic circuitry yields a processor of small physical size, low power and significant flexibility. The computation time of the HMP is shorter than most of the general memory addressing modes of the host CPU. The nine least significant CPU address bits in conjunction with the translation PROM control all HMP functions. The translation PROM provides the function related serial clock count to the clock control logic which in turn controls all HMP timing. Preceding Page Blank 1ST SANDIA AEROSPACE COMPUTER VERSION 4 CSANDAC IV) ARCHITECTURE MC68000 CPU 32 BIT DATA AND ADDRESS REGISTERS 56 INSTRUCTIONS 11 ADDRESSING MODES MEMORY MAPPED I/O 16 BIT DATA BUS 16 M BYTE ADDRESS SPACE HARDWARE MULTIPLIER PROCESSOR (HUP) VECTORED INTERRUPTS POWER REQUIREMENTS +5V 9 3A TYPICAL PHYSICAL EXPANDABLE MODULAR CONSTRUCTION STACKABLE PIN-SOCKET INTERMODULE BUS 17.8 CM x 15.9 CM x 1,27 CM MODULES SANDAC IV CPU MODULE MC68000 CPU 16K BYTE EPROM MEMORY 16K BYTE NON-VOLATILE CMOS RAM POWER MONITOR & RESET CIRCUIT SANDAC IV I/O MODULE 4 CHANNEL OPTO-ISOLATED USART SERIAL I/O 8 CHANNEL PRIORITY INTERRUPT CONTROLLER 5 CHANNEL PROGRAMMABLE 16 BIT TIMER/COUNTER 16 BIT MEMORY MAPPED «K WORD) I/O 188 SANDAC IV HMP MODULE MEMORY MAPPED REGISTERS AND FUNCTIONS SINGLE PRECISION (16 BIT) AND DOUBLE PRECISION (32 BIT) FUNCTIONS MULTIPLY WITH OPTIONAL ADD OR SUBTRACT TO PREVIOUS ACCUMULATOR CONTENTS SCALE 2±N AND ROUND OVERFLOW DETECTION RELATING TO ACCUMULATION ADDRESSING ERROR DETECTION CONTROL FUNCTIONS DERIVED FROM LATCHED ADDRESS BITS HOST CPU ALLOWED TO PROCEED IN PARALLEL WITH HMP AUTOMATIC HOLD-OFF OF HOST CPU IF HMP BUSY HARDWARE MJLTIPLIER PROCESSOR BTX>CK DIAGRAM L DPROD SPROD DPROD ACCUMULATOR OUT ROUND PULSE ERRORS 189 HARDWARE MULTIPLIER PROCESSOR CONTROL BLOCK DIAGRAM FUNCTION *• CONTROL (A4-A8) DATA TRANSFER ACKNOWLEDGE CLOCKS EXAMPLE HMP ADDRESS MAPPED FUNCTIONS ADDRESS (HEX) FUNCTION FEOO FE02 FE(M FE06 FE08 FEOA FEOC FEOE FEOE FE1E FE3E FE5E FE7E FE8E FE90 READ-CLEAR STATUS REGISTER READ/WRITE P4 READ/WRITE P3 READ/WRITE P2 READ/WRITE PI READ/WRITE fW READ/WRITE M3 WRITE M2 READ STATUS REGISTER WRITE VS., S.P. MULTIPLY & ADD CLEAR ACCUM., S.P. MULT. & ADD S.P. MULTIPLY & SUBTRACT CLEAR ACCUM., S.P. MULT. & SUB. WRITE M2, WRITE M2, WRITE M2, WRITE M2 WRITE Ml, D.P. MULTIPLY 8 ADD 190 EXAMPLE HMP ADDRESS MAPPED FUNCTIONS ADDRESS (HEX) FUNCTION FFOO D.P. P REG x 2"M & S.P, ROUND FF1A D,P. P REG x 2"1 & S.P. ROUND FF1C D.P. P REG x 2° & S.P. ROUND FF1E D.P. P REG x 21 & S.P. ROUND FF38 D.P. P REG x 214 & S.P. ROUND FF80 Q.P. P REG x 2"30 & D.P. ROUND FFBA Q.P. P REG x 2'1 & D.P. ROUND FFBC Q.P. P REG x 2° & D.P. ROUND FFBE Q.P. P REG x 21 & D.P. ROUND FFF8 Q.P. P REG x 230 & D.P. ROUND FUNCTION EXECUTION TIME FUNCTION EXECUTION TIME S.P. MULTIPLY & ACCUMULATE 2.38 //s D.P. MULTIPLY & ACCUMULATE 4,38 us D.P. SCALE 2"14 & S.P. ROUND 3.31 ,is D.P. SCALE 2° & S.P. ROUND 2M us D.P. SCALE 214 & S.P. ROUND 1.56 //s Q.P. SCALE 2"30 & D.P. ROUND 6.31 us Q.P. SCALE 2° & D.P. ROUND H.HH & Q.P. SCALE 230 & D.P. ROUND 2.56 MS 191 •SANDAC IV BENCHMARK EQUATION All= B11C11 + B12C21 + B13C31 + K NOTE: ALL TERMS ARE 32 BIT FIXED POINT, CONFIGURATION ' EXECUTION TIME MC68000 CPU 3 8 MHZ 235 (SUBROUTINE SOLUTION) MC68000 CPU a 8 MHZ + HMP 31 ps CHMP SOLUTION) 192 BENCHMARK EQUATION MACRO INSTRUCTION SOLUTION B12C21 + B13C31 SOURCE CODE: LQPP K /LOAD Q,P, CONSTANT DPMA Bn, Cu /D,P, MULTIPLY & ADD DPMA B12, C21 /D,P.'MULTIPLY & ADD .v DPMA B13, C31 /D,P, MULTIPLY & ADD DPSRM 6, An /QUAD P, SCALE, ROUND & MOVE 193 BENCHMARK EQUATION MACRO EXPANSION + B12C21 + B13C31 + K ASSEMBLER EXPANSION: MACRO LQPP #0, K DPMA Blp Cn DPMA B^, C21 DPMA B13, C31 DPSRM 0, An MC68000 MNEMONICS MOVE.L 0, FE02 MOVE.L K, FE06 MOVE.L B-Q, FEOA MOVE.L Cu, FE8E MOVE.L Bio, FEOA MOVE.L C21, FE8E MOVE.L B13, FEOA MOVE.L C31, FE8E MOVE.L FFBC, An COMMENT /LOAD Q.P. CONSTANT /D.P. MULTIPLY & ADD /D.P. MULTIPLY & ADD /D.P. MULTIPLY 8 ADD /QUAD P. SCALE, ROUND & MOVE SUMMARY EFFECTIVELY EXPANDS HOST CPU INSTRUCTION SET EASY INCORPORATION INTO ANY 16 BIT SYSTEM HIGH PERFORMANCE DUE TO SIMULTANEOUS DATA & COMMAND TRANSFER BY HOST CPU SERIAL ARITHMETIC APPROACH REDUCES COMPONENT COUNT EQUATION EXECUTION TIME PRIMARILY DEPENDENT ON CPU MEMORY ACCESS TIME STRAIGHT FORWARD SOFTWARE CONTROL SINGLE jiP CPU PLUS HHP PROVIDES PERFORMANCE COMPARABLE TO BIPOLAR BIT-SLICE DESIGNS 194 26 APPLICATION OF ADVANCED ELECTRONICS TO A FUTURE SPACECRAFT COMPUTER DESIGN Philip C. Carney Martin Marietta Corporation Denver, Colorado Over Che past two and one half years at Martin Marietta, an Independent Research and Development task* has been conducting an.extensive investigation on advanced spacecraft computer systems. The task objectives are to quantitatively determine how recent advancements in hardware and,software** technology can be used to obtain major improvements in spacecraft computer, system capabilities. This paper describes the major hardware aspects which have been investigated and what results have been obtained. * This work was conducted by the Denver Division of Martin Marietta Corporation under Independent Research and Development Project Authorization D-80D. . . ** Related paper, "Application of Software Technology to a Future Spacecraft Computer Design, in Microprocessor Software Technology Session. 195 During 1978 several architecture trade studies were conducted to arrive at a decision on what characteristics a future spacecraft computer should have. The architecture trade studies went through two phases; the implementation independent phase and the chip set dependent phase. Some of the major factors which were included during the first phase were: o Data types and precision, o Processing throughput, o Input and output, o Address space, o Instruction types, o Multiprogramming features, and o Test support equipment. In general terms, a modern minicomputer-like architecture with a 250,000 operations per second performance and the lowest possible power consumption was desired. It was noticed almost immediately that in some cases it was difficult to define certain architecture features because they appeared to be application dependent. For example, input and output (I/O) appears to vary depending on the spacecraft data bus. To allow for this variation but not impede progress it was decided to use memory mapped I/O. This approach, insures that sufficient flexibility is maintained in the architecture for most applications. In a related area a slightly different approach was taken I/O is normally handled in one of two ways, register transfers or direct memory access (DMA). If the direct memory access was imbedded in each I/O controller than each application, each would be burdened with the nonrecurring cost of DMA. To avoid this situation we incorporated a generalized Direct Memory Processor which can buffer and transfer data between a memory mapped I/O controller and main memory, Hence there is only a one time nonrecurring design cost associated with this feature of the computer. In 1978 integrated circuits technology was reviewed. Of particular interest in this area was the feasibility of using Complementary Metal Oxide Semiconductor/Silicon on Saphire (CMOS/SOS) parts. The primary reason for interest in CMOS/SOS was the favorable speed/power ratio which is important in spaceborne applications. The candidate CMOS/SOS chip sets which were 196 investigated include: custom devices developed by NASA Marshall Space Flight Center and Air Force Space Division (formerly SAMSO); parts developed under the Space Division Advanced Computer Technology program (ACT-I); 290X parts under development at Raytheon; and a microprocessor chip set being developed at RCA under contract to the Air Force Avionics Laboratory at Wright Patterson (AFWAL). We elimated the use of custom parts early in our selection process because of their high cost. The ACT and Raytheon parts were eliminated because a comprehensive family of support components was not available. It was felt, therefore, that the best potential CMOS/SOS technology for use in spaceborne applications was the AFWAL/RCA microprocessor chip set. In . addition to being a comprehensive family of LSI devices, the units are being produced in a radiation hardened process with high reliability screening. Recently the Global Positioning System (GPS) program has selected this chip set for use giving further evidence that our decision to base our design on the AFWAL/RCA chip set was appropriate. The LSI devices available in the RCA chip set are: the TCS 129 General Processing Unit (GPU), the TCS 196 Multiplier, the TCS 09X Gate Universal Array (GUA), the TCS 150 Random Access Memory (RAM), the TCS 075 Read Only Memory, and the TCS 158 Microprogram Controller Unit. The GPU forms the foundation for the entire chip set. It is an eight bit wide arithmetic and logic slice that can be cascaded to form an arbitrarily wide data word. The TCS 196, unlike other multiplier chips presently available, is also a cascadable device. All of the partial product logic is included on the TCS 196 to form an N x M multiplier without the need for supporting hardware logic. The purpose of the TCS 09X GUA is to provide the logic and circuitry which in most other chip set families is found in small and medium scale integrated circuits. These arrays are fixed regular patterns of transistors and routing paths. By defining transistor interconnection, the GUA is customized with logic in much the same way that Read Only Memory is customized with data. Some of the benefits associated with GUAs are improved speed and" real estate requirements; disadvantages include higher nonrecurring cost and greater design risk. Martin Marietta has thus far designed three Gate Universal Arrays and testing has shown that the devices are functionally correct and exceed performance expections. 197 Once the first phase of the architecture analysis was completed, the factors associated with use of the CMOS/SOS microprocessor chip set had to be taken into account. Some of these factors were: o • Number of user available registers, o High speed arithmetic support hardware, o Instruction decoding, o Data formatting and deformatting, o Memory volatility, and o Interrupt handling. ) It is important to mention at this time that software* analysis as well as circuit analysis played a significant part at this time in determining what the final characteristics of the .computer would be. For example the fact that we desired a modern minicomputer-like architecture implied that multiple general purpose registers were required. The number of registers however could only be determined by coding application programs, measuring the resulting throughput, and performing the physical circuit design to determine what the impact was'in terms of hardware cost and complexity. Throughout the first half of 1979 we performed many paper emulations in which we wrote application programs, wrote microprograms, and prepared circuit layouts. These paper emulations allowed us to determine specific advantages and disadvantages inherent in different architectures implemented with the CMOS/SOS microprocessor chip set. In midyear we chose the "best" architecture for implementation. Best is a subjective term which in some cases such as performance and power consumption can be determined quantitatively, but in other cases such as flexibility and risk it can only be measured qualitatively. After the selection process was completed, detailed design began with the goal of having an operational demonstration unit in 1980. The most challenging part of the detailed design was the many unknowns associated with using a microprocessor chip set which was still under development at that time. Our three primary concerns were internal device performance, off-chip drive * Op. Cit. 198 capability, and Gate Universal Array layout. The first concern was handled by derating devices a minimum of 100% using the limited test data available. Testing at Martin Marietta has since shown that all devices are much better than were originally anticipated. Our second concern, off-chip drive capability, was caused by the capacitance loading problems associated with CMOS technology. This problem becomes particularly severe in the area of the main memory interface. To eliminate the concern we incorporated a bulk hardened signal level converter to drive the memory bus at TTL levels. The addition of the signal level converter causes an added latency along the bus but this is a much better situation than that which would have occurred if an attempt had been made to fanout the CMOS signals. Our remaining concern, GUA design, was handled very conservatively. TTL circuit equivalents were built for each array, extensive software logic simulations were conducted, and the entire data submittal package was independently verified before shipment to RCA. As a result of this effort, no Martin Marietta caused problems have been found in any of the three designs which we have completed. There were some, issues in the testing area which arose because of Martin Marietta's and RCA's lack of experience with the chip set. These have since been resolved by modifying our software so that test vector data is automatically generated during the logic simulation. . Throughout 1980 efforts have been directed toward fabrication of a breadboard unit which demonstrates the primary computer modules: the central processor module, the priority interrupt controller, the memory bus driver/receiver, and an 8K RAM memory bank. Additionally an operator control panel, a writable control store, a programmable read only memory bank, and a serial I/O port were implemented to facilitate development. The resulting computer has been operational for several months and many of the major design goals have already been demonstrated. Functionality, performance and power consumption meet our expectations. In 1980 concurrent with our breadboard fabrication we took the first step towards producing a qualified flight unit. This step was the fabrication and testing of mockup printed circuit boards using leadless carrier packaging technology. Although the Orlando Division of Martin Marietta has over three years experience in the use of leadless carriers, we felt it was necessary to 199 perform some specific tests to eliminate the controversy surrounding the use of this technology in spaceborne applications. As a result of qualification level thermal and vibration tests, we have found that leadless carriers mounted on polyimide daughter boards which are in turn properly mounted on larger mother boards is an appropriate packaging approach. In 1981 we intend to extend our work by taking the primary hardware modules now in wire wrap form and converting these to printed circuit boards. This effort will have two major benefits. First, it will allow us to show what performance margins exist at the system level. Performance margin cannot be demonstrated on the breadboard because of the high capacitance associated with the wire wrap technique. The second major benefit to design and fabricating the printed circuit boards is that we will be able to perform thermal and • vibration qualification level testing on a unit which much more closely resembles the final flight unit. Although the AFWAL/RCA CMOS/SOS microprocessor chip set was originally considered to be a high risk item, the fact that parts have been produced, tested and used in our computer system and the GPS program indicate that these parts will have a favorable future. The results we have obtained show that a CMOS/SOS computer can obtain the same performance levels as presently available bipolar spacecraft computer but at approximately 15% of their power consumption. 200 BACKGROUND OBJECTIVES:* QUANTITATIVELY DETERMINE HOW RECENT ADVANCEMENTS IN HARDWARE AND SOFTWARE" TECHNOLOGY CAN BE USED TO OBTAIN IMPROVEMENTS IN SPACECRAFT COMPUTER CAPABILITIES. CMOS/SOS INTEGRATED CIRCUITS SENI-CUSTOM LSI DEVICES LEADLESS CARRIER PACKAGING MICROPROGRAMMING PASCAL, HAL, ADA, HIGER ORDER LANGUAGE *THIS WORK WAS CONDUCTED BY THE DENVER DIVISION UNDER INDEPENDENT RESEARCH AND DEVELOPMENT PROJECT AUTHORIZATION D-80D '•RELATED PRESENTATION, "APPLICATION OF SOFTWARE TECHNOLOGY TO A FUTURE. SPACECRAFT COMPUTER DESIGN", IN SESSION III: MICROPROCESSOR SOFTWARE TECHNOLOGY . BACKGROUND APPROACH: 1978 REVIEW AVAILABLE STATE OF THE ART TECHNOLOGY DEFINE CANDIDATE ARCHITECTURES 1979 PERFORM DESIGN OF ARCHITECTURES AND USE "PAPER EMULATION" TO OBTAIN QUANTITATIVE RESULTS SELECT "BEST" ARCHITECTURE 1980 DEMONSTRATE SYSTEM USING BREADBOARD 1981 BUILD AND TEST BRASSBOARD 201 AVAILABLE CMOS/SOS INTEGRATED CIRCUITS MSFC AND SAMAO CUSTOM DEVICES SAMSO ADVANCED COMPUTER TECHNOLOGY PROGRAM RAYTHEON 290X RESEARCH PROGRAM AIR FORCE MATERIALS LAB/RCA.MICROPROCESSOR CHIP SET CONCLUSION: OF AVAILABLE CMOS/SOS TECHNOLOGY AFML/RCA MICROPROCESSOR CHIP SET HAS BEST POTENTIAL FOR USE IN SPACEBORNE APPLICATIONS AFML/RCA CMOS/SOS MICROPROCESSOR CHIP SET GPU TCS 129 - GENERAL PROCESSING UNIT - 8-BiT PARALLEL SLICE - CONCATENATABLE - FULLY STATIC - <125-NS REGISTER-TO-REGISTER ADD RAM TCS 150 - RANDOM-ACCESS MEMORY - 256x4-BiT ORGANIZATION - <125-NS ACCESS TIME ROM TCS 075 - READ-ONLY MEMORY - FULLY STATIC 1024 BITS - MASK-PROGRAMMABLE - <100-NS CYCLE TIME MUL TCS 196 - 8x8-BiT MULTIPLIER - EXPANDABLE - COMPLETELY ASYNCHRONOUS - LATCHED INPUT OPERANDS GUA TCS 093 - GATE UNIVERSAL ARRAY •- CUSTOMIZED LOGIC - 632 GATE-LEVEL COMPLEXITY - 64 PADS - PROVEN CELL LIBRARY - 100-MHZ HIGH-SPEED DIVIDER - 452, 300 AND 182 GUAs ALSO AVAILABLE "2910" CONTROLLER TCS 158 - MICROPROGRAM CONTROLLER - FUNCTIONAL EQUIVALENT TO AM2910 202 GATE UNIVERSAL ARRAYS FIXED REGULAR PATTERN OF TRANSISTORS AND ROUTING PATHS, BY DEFINING INTERCONNECTIONS AMONG DEVICES, GUAs MAY BE CUSTOMIZED WITH LOGIC VERY SIMILAR TO THE WAY READ ONLY MEMORY IS CUSTOMIZED WITH DATA, MARTIN MARIETTA HAS DESIGNED THREE GUAs: TCS 092-843, G.PU CONTROLLER TCS 092-844, MEMORY CONTROLLER TCS 093-845, SSI FUNCTIONS TCS 092-843 FUNCTION: GPU CONTROLLER UTILIZATION: 368 INTERNAL CELLS 62 I/O CELLS 2 LOW Z CELLS CIRCUITS: A - REGISTER ADDRESS DECODE/ENCODE B - SIGN BIT FILE C - CONDITION CODE MUX 203 CD Q CD OQ ooi CNJ GT> CD CO * — 1 I 1 K» -» >-» -» u rnL£J v, -| i • — >i M '^T i xnw ' 4_ Aim +- < isao *1 aojnos H r^TA f t I 204 MAC-16 COMPUTER DESIGN GOALS LOW POWER C< 20 WATTS) HIGH PERFORMANCE O250KOPS) MINICOMPUTER-LIKE INSTRUCTION SET ARCHITECTURE FIXED POINT AND FLOATING POINT ARITHMETIC PRIVILEGED AND USER MODE EXECUTION MULTIPLE LEVEL INTERRUPT HANDLING MEMORY MAPPED INPUT AND OUTPUT DIRECT MEMORY ACCESS MAC-16 COMPUTER PRIMARY HARDWARE MODULES SP-D32: CENTRAL PROCESSOR MODULE PIC-16: PRIORITY INTERRUPT CONTROLLER MMU-A: MEMORY BUS DRIVER/RECEIVER MMU-B: BASIC MEMORY MANAGEMENT UNIT MMU-C: EXTENDED MEMORY MANAGEMENT UNIT RAM-8E: HIGH SPEED 8K RANDOM ACCESS MEMORY .RAM-16E: 16K RANDOM ACCESS MEMORY PROM-8: 8K PROGRAMMABLE READ ONLY MEMORY DMP-8: DIRECT MEMORY PROCESSOR 205 MAC-16 COMPUTER ARCHITECTURE SP-D32 CENTRAL PROCESSOR PRINCIPLE ELEMENTS FIXED POINT PROCESSOR FLOATING POINT PROCESSOR MICROPROGRAM CONTROL LOGIC MULTIPLIER CIRCUIT HIGH SPEED SHIFTER DATA FORMAT AND DEFORMAT LOGIC MEMORY INTERFACE 206 SP-D32 CENTRAL PROCESSOR MODULE OVERVIEW IK ^>3r * Saquanear * Stora Pipeline Reg I L Control t Data \ r Muuggmgnt ' HUn" i L_ I SPACECRAFT CENTRAL PROCESSOR COMPARISON FIXED POINT ADD (uS) FIXED POINT MUL (uS) FLOATING POINT ADD (uS) FLOATING POINT MUL (uS) TECHNOLOGY POWER (WATTS) . 1C COMPONENT COUNT REMARKS AUTONETICS LITTON TELEDYNE IBM DF224 ITEK MARTIN 6.1 4516E MECA-43 NSSC-II • ATAC-16 MAC-16 2.0 1.6 1.7 . 1.25 2.0 5.1 1.6 7.8 5.5 3.5 - - PMOS 15,5 50 21 BIT FIXED POINT 12.1 23.0 TTL 22 107 9.9 18.1 TTL 25.5 5 HYBRID PC KG 20.8 33.8 TTL 100 81 6.75 17,0 TTL 21 7 JPL MEMORY 16,5 . 11.5 CMOS/SOS 2 89 207 MAC-16 HARDWARE STATUS REQMTS DESIGN BREADBOARD SP-D32: CENTRAL PROCESSOR MODULE PIC-16: PRIORITY INTERRUPT CONTROLLER - MMU-A: MEMORY BUS DRIVER/RECEIVER MMU-B: BASIC MEMORY MANAGEMENT UNIT MMU-C: EXTENDED MEMORY MANAGEMENT UNIT RAM-8E: HIGH SPEED 8K RANDOM ACCESS MEMORY RAM-16E: 16K RANDOM ACCESS MEMORY PROM-8: 8K PROGRAMMABLE READ ONLY MEMORY DMP-8: DIRECT MEMORY PROCESSOR COMPLETE COMPLETE IN PROGRESS COMPLETE IN PROGRESS 1981 COMPLETE COMPLETE IN PROGRESS COMPLETE IN PROGRESS NOT SCHEDULED COMPLETE NOT SCHEDULED NOT SCHEDULED COMPLETE COMPLETE IN PROGRESS COMPLETE IN PROGRESS 1981 COMPLETE COMPLETE IN PROGRESS COMPLETE 1981 NOT SCHEDULED DEMONSTRATION UNIT PRIMARY ELEMENTS MAC-16 COMPUTER ENGINEERING DEVELOPMENT UNIT SP-D32 CENTRAL PROCESSOR MODULE PIC-16 PRIORITY INTERRUPT CONTROLLER MMU-A MEMORY BUS DRIVER/RECEIVER RAM-8E RANDOM ACCESS MEMORY PROM-8 PROGRAMMABLE READ ONLY MEMORY SUPPORT EQUIPMENT SERIAL I/O MODULE OPERATOR CONTROL PANEL WRITABLE CONTROL STORE GUA TTL CIRCUIT EQUIVALENTS MICROCOMPUTER - HARDWARE INTERFACE VAX 11/780 - SHOFTWARE HOST 208 IFADLESS CHIP CARRIER L2 Internal Bond Pad Base-External Contact Chip-Carrier SP-D32 CENTRAL PROCESSOR MODULE FLIGHT UNIT -8.5 in. r- 7.5 in. 0 0 DDnnnnnn aDDDDDDDDDnnaanD nnDDDDDC nanDDnan Olnl n h r . 0 o II ODD € II » O|i O p.. —O h rl Quantity 43 1 5 16 4 1 19 2 1 2 Part TCS 075 TCS158 TCS 129 TCS 196 TCS 092-843 TCS 092-844 TCS 093-845 Resistor Pack E34 TCXO 110 Lead Connectors Capacitors Package 24 HCC 48HCC 48 HCC 64 HCC 64 HCC 64 HCC 64 HCC 16 FP Hybrid - 209 1981 HARDWARE^OBJECTIVES BUILD AND FUNCTIONAL TEST OF PRINTED CIRCUIT BOARDS FOR PROCESSOR MODULE, MEMORY MANAGEMENT UNIT, PRIORITY INTERRUPT CONTROLLER/ AND 8K MEMORY MODULE FUNCTIONAL TEST OF 4K RAMs (TCS 1/16) FOR AIR FORCE MATERIALS LAB PERFORM PACKAGING MINI-QUALIFICATION TEST MAC-16 COMPUTER TEST SET UP VAX 11/780 V- J- — CD n7Oor Uj£ PIC-16 MMU-A RAM-8E PROM-8 SERIAL I/O — _ i — — CONTROL PANEL WRITABLE rnMTDfiiLull 1 KUL . STORE niA riDfiiiTbUH L1KLU1 1 EQUIVALENTS 210 I CD I oo OO - CNJ I •cr i CXI CNI CL. 00 oo >- CO CO ca UD LU UD ooi 0- U3i— ii CO CO 3 1= CO LU COGC o u Q U o OC Q. < < O COllO ui EC O Oo 85 ^ co CO Ul u O cc o e o CO o Ul m O CC o P Z Ul (XL PR O CE SS IN G o G AM M A CI RC U 1 O PE AK D ET EC TI 1 O CS O R ES O LU TI 1 O _l CO LO R CO RR E 1 C AL IB R AT IO N 1 «i Ul e K 8 SC AN -T O -S CA N 1 IT IO N AL u u. AC Q UI SI TI O N 1 § P < i I 5 i D ES IG NA TI O N TR AC K 1 1 230 HIGH LEVEL PROCESSOR STRUCTURE OBJECTS SAMPLED DATA STREAM TOTAL DP LOAD IS COMPOSED OF MANY SMALL, INDEPENDENT LOADS tOO IK IOK 100K 1M 10M IOOM 1000M i I I . . I I I IHSTPERSEC CURRENT MICROPROCESSOR STATE-OF-ART 231 MODULAR MISSILE-BORNE COMPUTERS OBJECTIVE: INVESTIGATE ADVANCED PREPROCESSING TECHNOLOGY & THE APPLICATION OF MODULAR, FLEXIBLE, EXTENDABLE MICROCOMPUTER ARRAYS TO PERFORM THE REAL TIME DATA PROCESSING NECESSARY ON BOARD A BMD INTERCEPTOR. IDS/DP 3GP'S 1GNC GP ^ MOSAIC SENSOR 4 ARITHMETICALLY ENHANCED GP'S HARDWIRE FOCAL PLANE PROCESSOR RATIONALE: PREPROCESSING & BULK FILTERING PULSE MATCH TRACKING & DISCRIMINATION GUIDANCE NAVIGATION & CONTROL ADVANCES IN INTERCEPTOR & TECHNOLOGY AS WELL AS INCREASING COMPUTATION OF BMD FUNCTIONS ON BOARD IMPOSE REQUIREMENTS ON THE DATA PROCESSOR THAT CANNOT BE MET BY CONVENTIONAL COMPUTER ARCHI- TECTURES. MODULAR, FLEXIBLE, AND EXTENDABLE COMPUTER STRUCTURES ARE REQUIRED TO MEET THE NEEDS OF THE FLUID AND RAPIDLY EVOLVING BMD SYSTEMS. BENEFITS OF MICROPROCESSORS ALLOW MAXIMUM USE OF LSIC HARDWARE - MINIMIZES SIZE/WEIGHT/POWER/INTERCONNECTS SPECIAL PURPOSE OPERATION CAN BE ACHIEVED THROUGH MICROPROGRAMMING SIMULTANEOUS OPERATION OF MANY REAL TIME HARDWARE UNITS DRASTICALLY REDUCES NEED FOR MULTIPROGRAMMING - REDUCED SOFTWARE COST - REDUCED OVERHEAD TIME ALLOWS MAXIMUM MODULARITY TO BE ACHIEVED WHICH IMPROVES - FAULT TOLERANCE - FLEXIBILITY/ALTERABILITY 232 APPROXIMATE CAPABILITIES AND REQUIREMENTS PROCESSING SECTION PREPROCESSING AND BULK FILTERING DMX TO PULSE MATCH PULSE MATCH TRACKING AND DISCRIMINATION GUIDANCE NAVIGATION AND CONTROL PROCESSOR CONFIGURATION 14 SIMD (1 TO 3 MIPS EA) 4GPW/SPECIAL ARITHMETIC (15 MIPS FOR PULSE MATCH; 1 MIPS OTHERWISE) 3GP (1 MIPS EACH) 1GP (500 KIPS) REQUIREMENT 22 MIPS 43 MIPS 151 KIPS 185 KIPS CAPABILITY -40 MIPS* 45 MIPS 3 MIPS 500 KIPS TOTAL CAPACITY 88.5 MIPS •HIGH THROUGHOUT REQUIRED TO ABSORB OVERHEAD AND SATISFY REAL-TIME RESPONSE REQUIREMENT. EACH COMPUTER IN MMBC IS "TUNED" TO PERFORM WELL IN ITS AREA OF APPLICATION. E.G., MULTIPLE DATA STREAM PROCESSORS IN BULK FILTERING; PIPELINED, FAST ARITHMETIC UNIT IN PULSE MATCH. CHARACTERISTICS OF HARDWARE MODULES GENERAL PROCESSING ELEMENT (16 BITS) 1 MIPS SIMDPE(3ALUS) 3 MIPS VOA PROCESSOR 15 MIPS/5 MIPS LOCAL MEMORY (3 PORT RAM) READ ACCESS TIME 270 ni WRITE ACCESS TIME 75ns COMMON BULK MEMORY READ 375ns WRITE 140 ns CYCLE 425 n$ GLOBAL BUS (3 BUSES) TRANSFER RATE 1 MWOROS/S 1MWORDS/S CAN HANDLE 40 K TRACKS/SEC/GLOBAL BUS UTILIZATION 60% 233 CD CO £o o o oc o X QC h- 0- DC CC < LLI X g CO S N CO £ 9 > •4 L. oo CM oo CM NO CM CM ^ CM P O = CM Q- OO O rj o a: CM OO CM O OO \O ^~CM i—I I—I i—I CM OO CM 234 LU LU s1 a - • ,—L 3 s JS CO CO LU —' .J " 2 < C/> s «> S £2 iE tt S "j o "i fe>- ec S ^ LU QC O QC < g ^ UJ $* i a. S LUS = a: o t < -» F Ul Js Uls_ i^ z « £ 5£ | 1 i f£ I 8 t g . J 1 SP EC IA L i§ 1 >- V [a- PH j^ 3NI13SVB VJ.VQ - IS 1 s, i 1 r~ 938 iSNI " I | r 2 1s II / K x x oQ U U C9£ < < -i UJ LU LU < LU • • 00 Eoc 3 e> LU K BC < 2 LU (- DC Z Q O S « ss z r: <£> cf ^^ ce x z s >o . OC X z z vo ^ r-. QC X Z 1 JL| 1 1 I 1 l 1 | 1 1 1 1 | 1 1 | 1 L — >— * • _ * i"i,J tiiI 1ii i J ^ o. — > \^i"2 a. vc J3 <£> CL. ^ c c ba < J 'J3b iSNI | —. _L' 1- O — Of Z ^ a o 235 LU DC D O 01 O DC < LUGC O CO 236 -I < < LU II LU Z J- CC — LU < H Z < l§ -J O 111 [TDC ^ ^ O o 237 V/ V / m (/) C^D _J 1 ca V, En ! f> S _l ! y \ y \ 238 o o CO UJ a.(D 239 0. O LU LU CD LU O O cc Q. C/33 s LU LU -t t- 3 CO a. u CO II tt « cc o a. rz °< 5 S jJ o co o CC «/> =L co H- LJJ r-U CJ i-iSS S§C3 CO UJ CO LU CC .ft i__ O Z IM o 8 z ^ o > _. ^ - ~ Q o^ < LU CO eH 1 -j g a P f= LU C; CO uj CJ 5 _l Q =» Q. => ^ _j O O O. oc S CO 0. cc o O =s cc cc g • — co * o n cc I j 2 2 t 3 z ° S Hf 5 °° ^ >• ^ ^ co * co LO co UJ < >. *- «- co < 5 —J co 00 < CO cc O O o 240 ALTERNATIVE CONFIGURATIONS OF MMBC MODULES 4K ALTERNATIVE CONFIGURATIONS OF MMBC MODULES s IClOBAlj BUSMS ClOBAl BUS«S 241 ALTERNATIVE CONFIGURATIONS OF MMBC MODULES LM n LAI u n CPE IOC BIU MOS | GLOBAL I BUSSES 242 cc O CO CO LLJ CJ O cc Q_ CO LU _J CO cc o o cc Q. LU t X~-j- 5 K Ul I f t t IM31SAS UOSN3S CO o z 3 u. 243 LJJ CO CO o CC ' CC o 00 CO LU O O DC a. C/J •3 CD _J LU0 o CC Z ca CO 5 t 244 CO CO LJJ O o DC Q. < G CO D^C LLJ h- DC < LU 1 t 245 CO CO ULJ CJ o cc Q_ 246 CO z o Q. O o o h- Q_ O o LU fC. Q CC 247 QC O u. z 2co Q UJ LU N CO X UJ a. o CO 2 O H Q. O LLJ _l Z>~ Q LLJ OQ to TJ "k_ n x" co £ " ro CD O o- > ,co Q 0 CO O OQ. o in ^ CO c i- •* *( -JO co £ o r: p- t -D CO U- CO CO Q CT ^ CO"OO o co o O .Q.Q. 05 O ^ CO-C C i-05 » _lO O OQ^S-co uuCL O QC Q. CD o o ^ w j- oo oo co Q- to co •«- in u_ O CO ,7,_8 (195J< WORDS) I i Nl_ CBM BOOKS 9, 10, 11 (195K WORDS) T 29' ,PMPE_#1 ~f PMP ~~ \ PMPE 3 DISCRIMINATION P.E. DISCRIMINATION, Q ACQUISITION & CLOUD TRACK P.E TRACKING AND JAfiGElTaACJINJ! CJ. I 4.5 GNC | TRACK FILE MEMORY _GN& CP.E^ NLJ I/O FUNCTIONS POWER CONVERTER #1 (1KW DELIVERED POWER) POWER CONVERTER #2 (1KW) POWER CONVERTER #3 (1KW) POWER CONVERTER #4 (1KW) 8.0" 250 CO cc UJ oo UJ 2 QC OQQ UJ -J CO CO O o UJ LJJ _J CD 251 Q LU CO £5 LU J- 00 o ta u a g00 O §SE u m a C9 ec oc o iti > co > ce V o to — a —i 3 oe —i o eo a ta o —i cos, cc OC LU O C9 e ta K O I /I ocO LU 2S SS «/> s1 LU S i UJ 0ta O LU S x u LU J 252 2 LU LU ^ LU CO O CD CO LLJ CL. -I LU QQ UJ QC < QQ — CC >• o1 m cc £|23 SS- £ + 2u7 ^Sgs! ct < < >• CD QQ -2LZ i- CO O^ LU Q UJ LU Q- QC LU -3 O h- U LU co H LU CO O > o QQ Q 1 *- — s l o w < HE UJ h- 0-022 X CC ID "J LU LL. I— S a. QC CC CO CO CO — LU 2 55 . 2 < i- -P LU S O — _ uj LU r—Is-s< -c O Q- 2 2 = -1SF — •" = *tna cc ^ < uu < f o = =i £ co 3 =3 X LUi— a LU er " o rJ =; L_ g O UJ CO CO CJ QC CO LU CO CC h-3 —I S2 £ t PO E G CO LU Q < QC — CD CO uj co a s> o -J > -! -i cj CO < < QC LU CD CC CO LU O > I O I- H- > CO -J O —I ^S.r CO O t— LU 2 CL UJ CO Si£ "Hco LU CO 2 ~ O ^ P H- P LU U ^ ^ QC 2 g CC < =) S = g U. O CD Q Q I— U_ QC < LU 2 < LU Z3 O I I O CJ £ £it s 5 § o s* ^ LU 00'Q- a. O • O CM o LU ^ O LU CC LU _J CD CO O < QC LU LU CD CO J- •SL 1 2gS ^ >55a CC u. J 2 O i_ u_ _j CO I- T- o_ < 0 0 CO 0 O a ^ I- 3W g ^D I'' ^** > g - £ < ll LU LU ^ CC g 2 S "J CO LU o > 3» CD Q. O E 253 254 X o n a w ra 3 m u • to 3> 255 Page intentionally left blank Page intentionally left blank 30 MICROPROCESSOR-CONTROLLED TELEMETRY SYSTEM Paul Holtzman and Stephen D. Hawkins RCA Princeton, New Jersey A spacecraft telemetry unit completely controlled by a microprocessor was developed at RCA Astro-Electronics. This unit, the Programmable Information Processor (PIP), must sample 650 sources of analog and discrete house- keeping information plus dig i t a l data generated by space- craft computers. The data must be formatted for serial transmission to spacecraft data storage devices or direct transmission to the ground via a telemetry beacon l i n k . The choice of microprocessor to accomplish these tasks was influenced by requirements for 1) low power, 2) survival in radiation environment, and 3) instruction ex- ecution time of 6 microseconds. The RCA CDP1802 CMOS microprocessor was ultimately selected. The entire hard- ware system i n c l u d i n g ROM and RAM memories utilizes CMOS technology and dissipates only 5 watts of power. Many commandable modes of operation are possible with the PIP. Four major modes have differing format structure, sampl- ing rates and output data rates. Submodes enable selected data channels to be uniformly sampled at higher s a m p l i n g rates for diagnostic purposes and also enable a dump of memory data from various spacecraft computers and of the PIP itself. The s a m p l i n g sequences for housekeep- ing telemetry points are determined by preassigned tables w i t h i n the PIP software. An a d d i t i o n a l feature is the capabi l i t y to restructure these tables by a memory load. Complete dual redundancy is employed in the PIP such that no sing l e failure may compromise the mission requirements. .257 Page intentionally left blank Page intentionally left blank 31 MICROCOMPUTER ARRAY PROCESSOR SYSTEM Kenneth D. Slezak Goodyear Aerospace Corporation Akron, Ohio The Microcomputer Array Processor System (MAPS) is a program- mable multiprocessor computer system designed for Electronic Warfare applications for the Air Force Avionics Laboratory (AFAL). The system architecture retains many of the classic multiprocessor design concepts including a master-slave relationship among its microprocessors under the control of a single operating system in a tightly coupled structure. Each processor is a 32-bit programmable computer with its own dedicated memory and a capability to execute approximately 4 million instructions a second. In addition to the dedicated memory, each processor can communicate with numerous banks of common memory (referred to as global memory). The various global memory modules and their communication structure serve to tie the individual processors together in a symmetrical multi- processor computer architecture. The multiprocessor system is modular and can contain as few as 2 and as many as 8 processors coupled with from 1 to 16 banks of global memory and executes 32 million instructions per second. Expansions beyond these limits are possible if every processor does not have to have access to every global memory module. Currently, a 4 processor system (with 3 banks of global memory) is installed at Wright Patterson Air Force Base for use by AFAL. This system will be expanded to 6 processors during 1980. This multiprocessor subsystem is approximately 1.6 cubic feet and consumes under 400 watts of power. 259 *»^3^^ MICROCOMPUTER ARRAY P«*» . _& \\L& ltie j^»"»;e:, &7aK*j&iieK]&iiiKis ^^ MULTIPROCESSOR SYSTEf-1 ATTRIBUTES I TASK I SYMMETRY I COMMUNICATION I PROCESSOR INTELLIGENCE 260 GLOBAL MEMORY r ,--•- «>-» MEMORY PORT CONTROLLER PORT I MEMORY PORT CONTROLLER R E Q U E S T L O G I C MEMORY . PORT CONTROLLER i 1 M I C R O P R O C E S S O R MICROPROCESSOR 2 MICROPROCESSOR 3 261 _JUI CO 0» 00 \ V -. OllVtf 262 FAULT TOLERANT NAP ARCHITECTURE MICROPROCESSOR.! P R O G R A M MEMORY * * ^BllCPU 1 « 1 1 y : PROGRAM MEMORY CPU MEMORY CPU PROGRAM MEMORY POAT »0»T GLOBAL MEMORY B A N K - 1 2Kx32 PORT PORT B A K K - 2 263 FAULT TOLERANT-' MAP ARCHITECTURE MICROPROCESSOR-! §•1 1 11 u r ii I «• 1 1 ...«__.. ..«.__. . PROGRAM MEMORY ^ i> ro PROGRAM MEMORY CPt * ^ * * ^1 J 1 PROGRAM MEMORY PROGRAM MEMORY ^ *. PROGRAM 1 MEMORY f • CPU CPU * CPU SPARES PROGRAM „ MEMORY ' P CPU I I . i u i < f Y POAT J^ >* JL PORT i >| >^ Y PORT .-^ i GLOBAL MEMORY BANK-1 2Kx32 X i ^ ' \ /* PORT X J ». *^*~* >-» PORT A ' I •_! *~ -A >* PORT > 1 BANK- 2 |j 2Kx32 g •_i^ H -^ -\ •^ • PORT PORT • • PORT SPARE MEMORY BANK-3 264 MAP PROCESSING FUNCTIONS ESTABLISHES FILE OF ACTIVE EMITTERS . DETERMINES PRI . REPORTS PRESENCE OF NEW EMITTERS. TRACKS ESTABLISHED EMITTERS . TRACKS IN TIME AND ANGLE DELETES INACTIVE EMITTERS CAPABILITY FOR : .. SCAN RATE DETERMINATION . EMITTER TYPE IDENTIFICATION . RECEIVER CONTROL . POWER MANAGEMENT PDS SYSTEM- 0.1 - 19 GHz PROCESSING SYSTEM V RECEIVER t I fc D I G I T I Z E R 1 1 1 , 1 PRE PROCESSOR > , 1 INTERCEPT I PROCESSING 1 MAP EMITTER ESTABLISHMENT DISPLAY CONTROL SYSTEM PROCESSIM RECEIVER CONTROL ,n* \~s DISPLAY 265 cxZ o CO CO § Q_ ^_ x^ ^ e «• c. c i • 1 1 I 1 1 1 1 ae 3k . _) C I c c c I L C 4d c c c t. »- 3 ._ O2: UI ca >- a: a£ * Xjj ^ i_. . E: D D E _> -4 f £ >- Z o: i o ^ 2: z Ul <3 2T0 >- r- o ^2:2 Ul =a 2To: >- C 0 it 2: -2. 1 1 1 c 2: a Ul " S * C 3 • * Q_ •- Ul O Q: cc u 1 Ul U : h- u I j-i g i— Q- C Ul 3 00 ce u i. Ul Lt : i- u c z =3 >-• a. \ o CO Ul 1 1 1 1 1 »» CM roj - ^. I_CM_ 3 CM : co J _ X J CM — 1 5 1 « », ^ k. »- •Ui »— 1 o h- 00 Ul ID o- Ul C£ a: O 2: Ul 2: 00 o i— a: a_ o 0 ^ ^ ^ k. k. k. k. — 9 z a. CM a. i Q- 13. « ? - ' S O- -^ o: CrC Ul i— t— >— 1 Ul t , — , Ul >- > _i a: _ J t_> 21 CO CD Ul — ' —12: 1 • 1 > I _i on 1 " 1 )- 1 4 266 MAP ARCHITECTURE M I C R O P R O C E S S O R - ] P R O G R A M MEMORY CPU 1 i. EXPANSION POSP MINI- COMPUTER PROGRAM MEMORY PROGRAM MEMORY : .^ k. CPU rpii l^ J r r r u i PORT i PROGRAM MEMORY CPU ) (* -^ • nr PORT PORT GLOBAL MEMORY BANK-1 I BANK-2 BANK-3 I I (EXPANSION! i_ J L. I 267 PROCESSOR TIMING & CONTROL INTERRUPTS \ r PM P t J PDP11 PCU INTERRUPTS PC STACK PGM CTR PI-1AR NEXT INSTRUCTION CONTROL REPEAT COUNTER CONDITION DECODE! OPCODE DECODE , BRANCH ADDRESS j PIPELINE INTERRUPT CONTROL UNIT STATUS REGISTER. T MASK REGISTER 7 -BUS- PCU (PROGRAM CONTROL UNIT) T* PM ADDR 268 MICROPROGRAM SEQUENCER BLOCK DIAGRAM PUSH/POP Y OE 269 PIPELINE INSTRUCTION- FROM PROGRAM MEMORY P R I E P G E I L S I T N E E R rKUbKAI'l 1 " " .CONTROL S * BRANCH J\DDRESS ALU CONTROL REG A & B ADDRESSES OPCOCE DECODE BUS CONTROL EXF LOGIC CONDITION DECODE DEVICE ADDRESS IMMEDIATE VALUE - 1 REGISTER SELECT ALU STATUS * . REGISTER * LXIhRNAL DEVICES ALU PIPELINE ALV CONTROL PIPELINE REGISTER SELECT ALU (ARITHMETIC LOGIC UNIT) 16 GENERAL PURPOSE REGISTERS R0-R15 Q REGISTER STATUS STACK STATUS REGISTER PIPELINE CONDITION -*- DECODE -BUS- 270 CLOCK A ADDRESS • ADDRESS DIRECT INfUT MICROPROCESSOR SLICE BLOCK DIAGRAM LO/RI RO/LI > RAM SHIFT V MtCRO-COOl MICRO- INSTRUCTION DECODE OUTPUT CONTROL 16X4 RAM READ A&B WFUTE B 0 0 SHIFT O REGISTER SELECTOR •IN ALU OVR F-0 MULTIPLEXER OUTPUT < RO/LI < LO/RI 271 INSTRUCTION EXECUTION SPEED TYPE 0 1 2 3 5 6 INSTRUCTION REGISTER/REGISTER INPUT/OUTPUT REGISTER/IMMEDIATE READ/WRITE PROGRAM MEMORY EXTERNAL FUNCTION CONTROL INTERRUPT CONTROL PC STACK CONTROL CONDITIONAL BRANCH EXECUTION (NSEC) 250 OR 325 350 OUTPUT 400 INPUT 350 525 READ 650 WRITE 350 400 300 200 NO BRANCH 300 BRANCH 272 COMPARISON OF/iPROCESSORS Slice Width Cycle Time (Register to register; Read, Modify, Write) Power Dissipation (4 bits) Addressable Registers Register Addressing Mode Nuaber of Microcode Control Inputs Primary Arithmetic Functions Primary Logic Functions Possible Source operand Combina- tion to ALU Possible ALU Destination Registers Flags AMD AM2901 4 bits 100ns 0.92W 16 Two- Address 9 R + S R - S S - R 5 203 17 0 Carry Overflow Zero Negative NMI MM6701 4-bits 200ns 1.12W 16 TWO- Ad dress 8 R + S R - S S - R 3 203* 17 Carry Overflow Zero F-llll Intel 3002 ' 2-bits 150ns 1.45W (2 x 0.73) 11 Single- Address 7 Rc+ S 3 24* 12 Carry TI SBP0400 4-bits 1000ns 0.13W 8 Single- Address 9 R + S R - S S - R 8 33* 10 Carry Motorola M10800 4-bits 55ns 1.3W 1 (External 4-256) Single- Address 16 R + S R - S S - R 6 - BCD 8 - Binary 6-262 2 - 258 Carry Overflow Zero *Not all functions can be performed on all operand pairs, 273 DISTINCTIVE CHARACTERISTICS Two-address architecture - Independent simultaneous access to two working registers saves machine cycles. Eight-function ALU — Performs addition, two subtraction operations, and five logic functions on two source operands. Flexible data source selection - ALU data is selected from five source ports for a total of 203 source operand pairs for every ALU function. Left/right shift independent of ALU — Add and shift operations take only one cycle. Four status flags — Carry, overflow, zero, and negative. Expandable — Connect any number of Am2901 's together for longer word lengths. Microprogrammable — Three groups of three bits each for source operand, ALU function, and destination control. 100 90 80 <_> UJ £ 70 UJ S 60 I— CD ~ 50 CO l/> UJ 40 30 20 10 o C£ . Q. O\ HAP PERFORMANCE (12 EMITTER ENVIRONMENT) PULSE RATE = 31,800 N. — o o 3 4 5 6 NUMBER OF SLAVE PROCESSORS 274

Aerospace Applications of Microprocessors

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server