2. Computers as Components Principles of Embedded Computing System Design Dr. Prof. Huang Tingle Group of IIPI Guilin University of Electronic Technology

3. Embedded Computing2 Outline zThe embedded computing space. zPlatforms: system-on-chip, networks. zArchitectures, applications, methodologies. zStandards-based design. y Multiple standards. Ch1-1

4. Embedded Computing3 Example embedded computing systems Motorola Siemens BMW Apple

5. Embedded Computing4 Early history zLate 1940’s: MIT Whirlwind computer was designed for real-time operations. y Originally designed to control an aircraft simulator. zFirst microprocessor was Intel 4004 in early 1970’s. zHP-35 calculator used several chips to implement a microprocessor in 1972.

6. Embedded Computing5 Early history, cont’d. zAutomobiles used microprocessor-based engine controllers starting in 1970’s. y Control fuel/air mixture, engine timing, etc. y Multiple modes of operation: warm-up, cruise, hill climbing, etc. y Provides lower emissions, better fuel efficiency.

7. Embedded Computing6 Multiprocessor systems-on- chips zRoughly speaking, system-on-chip with at least two processors. zUsually heterogeneous multiprocessor: y CPUs, DSPs, etc. y Hardwired accelerators. y Mixed-signal front end.

8. Embedded Computing7 Consumer electronics categories 2001200220032004 Satellite TV $1.18$1.12$1.48$1.89 DVR (40E6) 0.140.570.180.54 DVD 2.12.432.72.46 Set-top Internet 0.200.120.630.341 PC (120E6) 12.9612.6115.5817.2 Wall Street Journal/EIA

9. Embedded Computing8 Consumer electronics prices Best Buy November 2003:

10. Embedded Computing9 Characteristics of embedded systems zVery high performance. y Vision + compression + speech + networking all on the same platform. zMultiple task, heterogeneous. zReal-time. zOften low power. zHighly reliable. y I reboot my piano every 4 months, my PC every day.

11. Embedded Computing10 Mudge et al: Mobile supercomputing zFuture mobile platform: y Speech recognition. y Cryptography. y Augmented reality. y Typical applications (email, etc.). zRequires 16x 2 GHz Pentium 4. zPeak power must not exceed 75 mW. y Assumes 5% battery improvement per year.

12. Embedded Computing11 Mudge et al: Performance trends for desktop processors © 2004 IEEE Computer Society

13. Embedded Computing12 Mudge et al: Power trends for desktop processors © 2004 IEEE Computer Society

14. Embedded Computing13 Platforms zAn architecture that is designed for an application domain: y Can be used in several products. y Allows customization. zPlatforms are often customized for their target audience. zPlatforms spread out development costs over more products. zSome people hope for a single universal platform…

15. Embedded Computing14 Why multiple platforms? zPeople still care about cost. zPeople care about power consumption. zSufficiently general solutions don’t fit on one chip.

16. Embedded Computing15 Intel IXP2850 network processor zPacket processing, control processing, security. zSoftware development environment includes simulator. Xscale Security processor … … 16 microengines

17. Embedded Computing16 TI OMAP zTargets communications, multimedia. zMultiprocessor with DSP, RISC. C55x DSP OMAP 5910: ARM9 MMU Memory ctrl MPU interface System DMA control bridge I/O

18. Embedded Computing17 ST Nomadik zTargets mobile multimedia. zA multiprocessor- of-multiprocessors. ARM9 Memory system I/O bridges Audio accelerator Video accelerator heterogeneous multiprocessors

19. Embedded Computing18 ST MMDSP+ zEmbedded processor core used in multiple chips: y Runs at 175 MHz. y 1 cycle per instruction. y 2-level instruction cache. y 16/24-bit fixed point. y 32-bit floating point. y C programmed y Fully synthesizable.

20. Embedded Computing19 Nomadik video accelerator MMDSP+ data RAM instr RAM Xbus Interrupt controller Picture post processing Video codec Picture input processing Local data bus Master AHB DMA

21. Embedded Computing20 Automotive embedded systems zToday’s high-end automobile may have 100 microprocessors: y 4-bit microcontroller checks seat belt; y microcontrollers run dashboard devices; y 16/32-bit microprocessor controls engine.

22. Embedded Computing21 BMW 850i brake and stability control system zAnti-lock brake system (ABS): pumps brakes to reduce skidding. zAutomatic stability control (ASC+T): controls engine to improve stability. zABS and ASC+T communicate. y ABS was introduced first---needed to interface to existing ABS module.

23. Embedded Computing22 BMW 850i, cont’d. brake sensor brake sensor brake sensor brake sensor ABS hydraulic pump

24. Embedded Computing23 The eternal triangle zHardware and software architectures determine capabilities. zApplications guide design decisions. zMethodologies allow repeatable, predictable design. architectures applications methodologies

25. Embedded Computing24 Observations and implications zA little domain knowledge helps a lot. zThe architectural design space is large and chunky. y Less synthesis, more analysis. zIP components must be adapted to play together. y Configurable IP, wrappers. y Supporting tools (compilers, etc.) must be adaptable.

26. Embedded Computing25 Software in consumer devices (ST) zModern audio standards (Dolby, MP3, etc.): zModern video standards (MPEG- 2, DV, etc.): z1 million lines of code. z2 million lines of code and counting.

27. Embedded Computing26 Software and MPSoC design zThe MPSoC must run the application. y Design verification must include the software running on the hardware. zMay not know all possible code at design time. y Limits design characterization. y Must provide programming environment.

28. Embedded Computing27 MPSoCs and standards zStandards enable large markets. y MPSoCs need large markets to justify chip development costs, reduce manufacturing overhead. zMPSoCs provide benefits: y Low power. y High performance. zMeeting the standard requires effort: y Platform must allow multiple implementations. y Standard is complex and hard to implement.

29. Embedded Computing28 Design challenges in standards-driven markets zDesign and verify methods within the standard. y Standards allow differentiation. zDesign and verify methods outside the standard’s scope. y User interface, etc. zDesign and verify interfaces. y Within standard, connection to extra-standard elements.

30. Embedded Computing29 Standards-based systems zReference implementation forms a basis for product. y Port to platform. y Enhance performance, features. zWant to minimize unnecessary changes to the software. zMust make some changes to the software.

31. Embedded Computing30 Characteristics of reference implementations zThe specification does not describe hardware or software. y The spec is in the domain of signal processing, etc. zDesigned for and tested on workstations. y Infinite memory. y Poor cache behavior. y Single process. y Limited real-time behavior. zThe executable spec misrepresents some system properties: y Error handling. y Buffer management.

32. Embedded Computing31 H.264 motion estimation, cont’d. zMultiple reference frames increases accuracy. y Handles occlusion. zOnce again, receiver is more complex.

33. Embedded Computing32 Why are standards so complex? zAlgorithm designers like to design algorithms. y Standards are complex. zStandards bodies must embody competing interests, ideas in their standards. MPEG Tampere meeting

34. Embedded Computing33 Design refinement zBad news: y hard to learn the platform in order to change it. zGood news: y an existing design can be measured, analyzed, and refined. Worldwide shipping by UPS... roughly US$ 50 for CD and US$ 100 for paper copy (1500 pages, heavy!) Bluetooth.com

35. Embedded Computing34 Four types of people zAlgorithms people. y Don’t like programming. y Don’t know that hardware exists. zSoftware people. y Don’t like hardware. zHardware people. y Tolerate software. y Don’t know applications exist. zManagers. y Don’t know anything. y Don’t do anything.

36. Embedded Computing35 Example: MPEG-2 codec zOne of the reference MPEG-2 codecs. y Simple algorithms. zDesigned for workstation operation. zImplementers must port to chosen platform. y Limited memory. y Limited CPU.

37. Embedded Computing36 MPEG-2 porting challenges zCodec uses a mixture of buffering strategies. y Some buffers are statically allocated. y Some buffers are allocated from the heap. zMay need to change number representation. y Integer, double-precision, etc. zError messages use Unix methods.

38. Embedded Computing37 Example: H.264 codec zReference encoder is 700,000 lines of C code. y Uses simple algorithms. zSupports a wide range of: y Display sizes. y Features.

39. Embedded Computing38 H.264 porting challenges zFigure out what code is of interest. y Large call graph. zMay need to change number representation. y Integer, double-precision, etc. zBuffer management. y Buffer allocation takes up over 50% of CPU time.

40. Embedded Computing39 Multiple standards zMany MPSoCs must implement multiple standards: y Communications. y Networking. y Multimedia. y Security. zRequires running a lot of different types of algorithms. y Good case for specialization, co-design, configurable CPUs, etc. y Need some general-purpose computers for load sharing, compatibility.

41. Embedded Computing40 Platforms, standards, and MPSoCs zA platform allows multiple variations of a system. y Well-suited to standards. zProgrammability is key to platform-based design.

42. Embedded Computing41 The design productivity gap

43. Embedded Computing42 Two phases of platform- based design zSemiconductor house designs the platform. y Requirements may come from standards, systems houses. zSystems house uses the platform. y May need to start design before chip is available. requirementspast designs platform user needs product

44. Embedded Computing43 Challenges in platform-based design zDon’t have the full application. y Must estimate characteristics of part of the application. zMust determine the appropriate level of programmability. y Programmability often costs in area, power. zMust provide programming tools along with the chip.

45. Embedded Computing44 Transaction-level modeling is not enough zThe MPSoC must run the complete application. y Implementing transactions is necessary but not sufficient. zTransactions are relatively short term. zSoCs have a lot of state in memory. y Need to thoroughly exercise that state over a long period.

46. Embedded Computing45 Summary zChip designers are now system designers. y Must deal with hardware and software. zToday’s applications are complex. y Reference implementations must be optimized, extended. zPlatforms present challenges for: y Hardware designers---characterization, optimization. y Software designers---performance/power evaluation, debugging.

47. CD-PLAYER CH1-2

48. 47 Compact disc players zDevice characteristics. zHardware architectures. zSoftware.

49. 48 CD audio z44.1 kHz sample rate. z16 bit samples. zStereo. zAdditional data tracks.

50. 49 Compact disc zData stored on bottom of disc: substrate aluminum coating plastic coating

51. 50 CD medium zRotational speed: 1.2-1.4 m/s (CLV). zTrack pitch: 1.6 microns. zDiameter: 120 mm. zPit length: 0.8 -3 microns. zPit depth:.11 microns. zPit width: 0.5 microns. zLaser wavelength: 780 nm.

52. 51 CD layout zData stored in spiral, not concentric circle:

53. 52 CD mechanism zLaser, lens, sled: laser CD detectors diffraction grating sled track focus

54. 53 Laser focus zFocus controlled by vertical position of lens. zUnfocused beam causes irregular spot: In focusOut of focus

55. 54 Laser pickup A B C D F E Side spot detectors Level: A+B+C+D Focus error: (A+C)-(B+D) Tracking error: E-F

56. 55 Servo control zFour main signals: yfocus (laser) @ 245 kHz; ytracking (laser) @ 245 kHz; ysled (motor): @ 800 Hz; yDisc motor. Optical pickup

57. 56 EFM zEight-to-fourteen modulation: yFourteen-bit code guarantees a maximum distance between transitions. 0000001100100100000000

58. 57 Error correction zCD capacity: 6.99 GB raw, 700 MB formatted. zReed-Solomon code:  g(x) = (x-  ) (x-  2 ) … (x-  n-k-1 ) (x-  n-k ) zProduces data, erasure bits. zTime to solve varies greatly depending on noise. zCD interleaves Reed-Solomon blocks to reduce effects of large data gaps.

59. 58 CIRC encoding zCross-interleaved Reed-Solomon coding. yInterleaves to reduce burst errors. zEach 16-bit sample split into two 8-bit symbols. zSpecs: yMax correctable burst: 4000 bits = 2.5 mm yMax interpolatable burst: 12,300 bits = 7.7 mm

60. 59 CIRC algorithm zSample split into two symbols. zSix samples from each channel (=24 symbols) are chosen. zSamples are delayed and scrambled. zParity symbols (Q symbols) are generated. zValues are delayed by various amounts. zP parity symbols are generated. zEven words delayed by one symbol, P and Q words are inverted. zFrame = 32 8-bit symbols.

61. 60 Control word z8-bit control word for every 32-symbol block: yP: 1 during music/lead-in, 0 at start of selection. yQ: track number, time, etc (spread over 98 bits). yR, S, T, U, V, W: reserved.

62. 61 Control and error correction zSkips caused by physical disturbance. yWait for disturbance to subside. yRetry. zRead errors caused by disc/servo problems. yDetect error. yChoose location for retry. yRetry. yFail and interpolate.

63. 62 Retry problems zData is stored in a spiral. yCan’t seek track as on magnetic disc. ySled servo is very coarse. zData is only weakly addressed. yMust read data to know where to go.

64. 63 Audio playback zAudio CD needs no audio processing. zTasks: yconvert to analog; yamplify.

65. 64 Digital/analog conversion z1-bit MASH conversion: interpolation noise shaping PWMintegrator

66. 65 MP3 zDecoding is easier than encoding, but requires: ydecompression; yfiltering. zBasic CD standard for data discs. zNo standards for MP3 disc file structure: player must understand Windows, Mac, Unix discs.

67. 66 Jog/skip memory zRead samples into RAM, play back from RAM. zModern RAMs are larger than needed for reasonable jog/skip. zJog memory saves some power.

68. 67 CD/MP3 player Audio CPU amp Jog memory Error corrector Servo CPU Analog in Analog out FE, TE, amp focus, tracking, sled, motor head drive memory display DAC I2SI2S

69. 68 DVD format zSimilar to CD, but: yshorter wavelength laser; ytighter pits; ytwo layers of data.

70. 69 Audio on DVD zAlternatives: yMP3 on data DVD (stereo). yAudio track of video DVD (5.1). yDVD audio (5.1). ySACD (5.1).

71. UML CH1-3

72. © 2000 Morgan Kaufman71 Introduction zObject-oriented design. zUnified Modeling Language (UML).

73. © 2000 Morgan Kaufman72 System modeling zNeed languages to describe systems: yuseful across several levels of abstraction; yunderstandable within and between organizations. zBlock diagrams are a start, but don’t cover everything.

74. © 2000 Morgan Kaufman73 Object-oriented design zObject-oriented (OO) design: A generalization of object-oriented programming. zObject = state + methods. yState provides each object with its own identity. yMethods provide an abstract interface to the object.

75. © 2000 Morgan Kaufman74 OO implementation in C++ class display { pixels : pixeltype[IMAX,JMAX]; public: display() { } pixeltype pixel(int i, int j) { return pixels[i,j]; } void set_pixel(pixeltype val, int i, int j) { pixels[i,j] = val; } }

76. © 2000 Morgan Kaufman75 OO implementation in C typedef struct { pixels: pixeltype[IMAX,JMAX]; } display; display d1; pixeltype pixelval(pixel *px, int i, int j) { return px[i,j]; }

77. © 2000 Morgan Kaufman76 Objects and classes zClass: object type. zClass defines the object’s state elements but state values may change over time. zClass defines the methods used to interact with all objects of that type. yEach object has its own state.

78. © 2000 Morgan Kaufman77 OO design principles zSome objects will closely correspond to real-world objects. ySome objects may be useful only for description or implementation. zObjects provide interfaces to read/write state, hiding the object’s implementation from the rest of the system.

79. © 2000 Morgan Kaufman78 UML zDeveloped by Booch et al. zGoals: yobject-oriented; yvisual; yuseful at many levels of abstraction; yusable for all aspects of design.

80. © 2000 Morgan Kaufman79 UML object d1: Display pixels: array[] of pixels elements menu_items pixels is a 2-D array comment object name class name attributes

81. © 2000 Morgan Kaufman80 UML class Display pixels elements menu_items mouse_click() draw_box operationsclass name

82. © 2000 Morgan Kaufman81 The class interface zThe operations provide the abstract interface between the class’s implementation and other classes. zOperations may have arguments, return values. zAn operation can examine and/or modify the object’s state.

83. © 2000 Morgan Kaufman82 Choose your interface properly zIf the interface is too small/specialized: yobject is hard to use for even one application; yeven harder to reuse. zIf the interface is too large: yclass becomes too cumbersome for designers to understand; yimplementation may be too slow; yspec and implementation are probably buggy.

84. © 2000 Morgan Kaufman83 Relationships between objects and classes zAssociation: objects communicate but one does not own the other. zAggregation: a complex object is made of several smaller objects. zComposition: aggregation in which owner does not allow access to its components. zGeneralization: define one class in terms of another.

85. © 2000 Morgan Kaufman84 Class derivation zMay want to define one class in terms of another. yDerived class inherits attributes, operations of base class. Derived_class Base_class UML generalization

86. © 2000 Morgan Kaufman85 Class derivation example Display pixels elements menu_items pixel() set_pixel() mouse_click() draw_box BW_displayColor_map_display base class derived class

87. © 2000 Morgan Kaufman86 Multiple inheritance SpeakerDisplay Multimedia_display base classes derived class

88. © 2000 Morgan Kaufman87 Links and associations zLink: describes relationships between objects. zAssociation: describes relationship between classes.

89. © 2000 Morgan Kaufman88 Link example zLink defines the contains relationship: message msg = msg1 length = 1102 message msg = msg2 length = 2114 message set count = 2

90. © 2000 Morgan Kaufman89 Association example message msg: ADPCM_stream length : integer message set count : integer 0..*1 contains # contained messages # containing message sets

91. © 2000 Morgan Kaufman90 Stereotypes zStereotype: recurring combination of elements in an object or class. zExample: y >

92. © 2000 Morgan Kaufman91 Behavioral description zSeveral ways to describe behavior: yinternal view; yexternal view.

93. © 2000 Morgan Kaufman92 State machines ab state state name transition

94. © 2000 Morgan Kaufman93 Event-driven state machines zBehavioral descriptions are written as event-driven state machines. yMachine changes state when receiving an input. zAn event may come from inside or outside of the system.

95. © 2000 Morgan Kaufman94 Types of events zSignal: asynchronous event. zCall: synchronized communication. zTimer: activated by time.

96. © 2000 Morgan Kaufman95 Signal event > mouse_click leftorright: button x, y: position declaration a b mouse_click(x,y,button) event description

97. © 2000 Morgan Kaufman96 Call event cd draw_box(10,5,3,2,blue)

98. © 2000 Morgan Kaufman97 Timer event ef tm(time-value)

99. © 2000 Morgan Kaufman98 Example state machine region found got menu item called menu item found object highlighted start finish mouse_click(x,y,button)/ find_region(region) input/output region = menu/ which_menu(i) call_menu(I) region = drawing/ find_object(objid) highlight(objid)

100. © 2000 Morgan Kaufman99 Sequence diagram zShows sequence of operations over time. zRelates behaviors of multiple objects.

101. © 2000 Morgan Kaufman100 Sequence diagram example m: Moused1: Displayu: Menu mouse_click(x,y,button) which_menu(x,y,i) call_menu(i) time

102. © 2000 Morgan Kaufman101 Summary zObject-oriented design helps us organize a design. zUML is a transportable system design language. yProvides structural and behavioral description primitives.

103. Models of Computation CH1-4

104. 103 Topics Why models of computation? Structural models. Finite-state machines. Turing machines. Petri nets. Control flow graphs. Data flow models. Task graphs. Control flow models.

105. 104 Models of computation Models of computation affect programming style. No one model of computation is good for all algorithms. Large systems may require different models of computation for different parts.  Models must communicate compatibly.

106. 105 Processor graph M1M1 L1L1 M2M2 M3M3 M4M4 L2L2 L3L3

107. 106 Finite state machine State transition graph and table are equivalent: s3 s1s2 0/0 0/1 1/0 0/0 1/1 1/0 0s1s20 1s1 0 0s2 1 1 s30 0 0 1 s11

108. 107 Finite state machine properties Finite state. Nondeterministic variant.

109. 108 Nondeterministic FSM Several transitions out of a state for a given input.  Equivalent to executing all alternatives in parallel. Can allow  moves--- goes to next state without input. s1s2 a a

110. 109 Deterministic FSM from nondeterministic FSM Add states for the various combinations of nondeterminism. s1s2 a a s3 nondeterministic b s4 c s1s12 a s3 b s4 c c deterministic

111. 110 10101010110110 Turing machine General model of computing: program head tape state

112. 111 Turing machine step 1. Read current square. 2. Erase current square. 3. Take state-dependent action: 1. Print new value. 2. Move to adjacent cell. 3. Set machine to next state.

113. 112 Turing machine properties Example program:  If (state = 2 and cell = 0): print 0, move left, state = 4.  If (state = 2 and cell = 1): print 1, move left, state = 3. Can be implemented on many physical devices. Turing machine is a general model of computability. Can be extended to probabilistic behavior.

114. 113 Turing machine properties Infinite tape = infinite state machine. Basic model of computability.  Lambda calculus is alternative model.  Other models of computing can be shown to be equivalent/proper subset of Turing machine.

115. 114 Control flow graph Commonly used to model program structure. x = a - b i = 0? y = c + d x = a

116. 115 CDFG properties Finite state model. Single thread of control. Can handle subroutines.

117. 116 Petri net Parallel model of computation. place arc token transition

118. 117 Firing rule A transition is enabled if each place at its inputs have at least one token.  A transition doesn’t have to fire right away. Firing a transition removes tokens from inputs and adds a token to each output place. In general, may require multiple tokens to enable.

119. 118 Properties of Petri nets Turing complete. Arbitrary number of tokens.  Nondeterministic behavior.  Naturally model parallelism.

120. 119 Task graph Used to model multi-rate systems. 11 22 P1P1 P2P2 P3P3 P4P4 P5P5

121. 120 Task graph properties Not a Turning machine.  No branching behavior.  May be extended to provide conditionals. Possible models of execution time:  Constant.  Min-max bounds.  Statistical. Can model late arrivals, early departures by adding dummy processes.

122. 121 Data flow graph Partially-ordered computations: +- * + -, * +, -, * -, +, *

123. 122 Data flow streams Captures sequence but not time. Totally-ordered set of values.  New values are appended at the end as they appear. May be infinite. + 88 -23 7 44 9 -28 -44 88 -23 7 44 9

124. 123 Firing rules A node may have one or more firing rules. Firing rules determine when tokens are consumed and produced.  Firing consumes a set of tokens at inputs, generates token at output.

125. 124 Example firing rules Basic rule fires when tokens are available at all inputs: Conditional firing rule depends on control input: + a b c a b T

126. 125 Data flow graph properties Finite state model. Basic data flow graph is acyclic. Scheduling provides a total ordering of operations.

127. 126 Synchronous data flow Lee/Messerschmitt: Relate data flow graph properties to schedulability.  Synchronous communication between data flow nodes.  Nodes may communicate at multiple rates.

128. 127 SDF notation Nodes may have rates at which data are produced nor consumed. Edges may have delays. +- 1 2 5

129. 128 SDF example This graph has consistent sample rates: ++ 2 1 + 1 12 1 separate outputs

130. 129 Delays in SDF graphs Delays do not change rates, only the amount of data stored in the system. Changes system start-up. +- 1 2 5 0

131. 130 Kahn process network Process has unbounded FIFO at each input: Each channel carries a possibly infinite sequence or stream. A process maps one or more input sequences to one or more output sequences. processchannel

132. 131 Properties of processes Processes are usually required to be continuous: least upper boundedness can be moved across function boundary. Monotonicity:  X in X’ => F(X) in F(X’)

133. 132 Networks of processes A network of processes relates the streams of several processes. If I = input sequences, X = internal sequences + outputs, then network behavior fixed point is  X = F(X,I)

134. 133 Network properties A network of monotonic processes is a monotonic process.  Even in the presence of feedback loops. Can add nondeterminism in several ways:  allow process to test for emptiness;  allow process to be internally nondeterminate;  allow more than one process to consume data from a channel;  etc.

135. 134 Statecharts Ancestor of UML state diagrams. Provided composite states:  OR states;  AND states. Composite states reduce the size of the state transition graph.

136. 135 Statechart OR state S1 S2 S3 S4 i1 i2 traditional S1 S2 S3 S4 i1 i2 OR state s123

137. 136 Statechart AND state S1-3S1-4 S2-3S2-4 S5 traditional c d b a r c d b a S1S3 S2S4 S5 AND state c d r b a sab r

138. 137 TCAS II specification TCAS II: aircraft collision avoidance system. Monitors aircraft and air traffic info. Provides audio warnings and directives to avoid collisions. Leveson et al used RMSL language to capture the TCAS specification.

139. 138 RMSL State description: Transition bus for transitions between many states: state1 inputs state description outputs a b c d

140. 139 TCAS top-level description CAS power-off power-on Inputs: TCAS-operational-status {operational,not-operational} fully-operational C standby own-aircraft other-aircraft i:[1..30] mode-s-ground-station i:[1..15]

141. 140 Own-Aircraft AND state CAS Inputs: own-alt-radio: integer standby-discrete-input: {true,false} own-alt-barometric:integer, etc. Effective-SLAlt-SLAlt-layer Climb-inibitDescend-inibit Increase-climb-inibit Increase-Descend-inibit Advisory-Status... 1 2 7 1 2 7 Outputs: sound-aural-alarm: {true,false} aural-alarm-inhibit: {true, false} combined-control-out: enumerated, etc.