1. MoBIES PI-Meeting, 16-18 July 2001, Jackson Hole Controller Design Using Multiple Models of Computation Edward Lee Johan Eker with thanks to Paul Griffiths, Jie Liu, Xiaojun Liu, Steve Neuendorffer, and Yuhong Xiong

2. Eker & Lee, UC Berkeley 2 Overview Mixed signal control systems The throttle control system by Paul Griffith Modal controllers Extended throttle controller by Johan Eker Design patterns The use of domains and hierarchy Mixed signal models Modal models Code generation co-compilation

3. Eker & Lee, UC Berkeley 3 A Throttle Control System Throttle controller by Paul Griffiths (Mobies Phase II, UC Berkeley) Top-level model Continuous-time (CT) domain in Ptolemy II Input: desired throttle angle (and derivatives) discrete-time controller throttle model

4. Eker & Lee, UC Berkeley 4 A Throttle Control System Result of executing the model shows intial convergence phase followed by tracking with a slight phase lag. The control signal chatters to overcome friction.

5. Eker & Lee, UC Berkeley 5 Design Pattern: Discrete Time in Continuous Time Synchronous dataflow director indicates a new model of computation. No director indicates no new model of computation.

6. Eker & Lee, UC Berkeley 6 Control Engineer View plant dynamics in continuous time controller in discrete time focus on stability, phase margins, rise time... assume ideal sampling with no or little latency

7. Eker & Lee, UC Berkeley 7 Embedded System Engineer View dynamics modeled with RK-4, variable-step solver controller modeled in synthesizable SDF, FRP, … focus on scheduling, memory, communication... assume fixed controller design

8. Eker & Lee, UC Berkeley 8 A More Integrated Approach controller design informed by software issues domain-oriented modeling language modeling = implementation latency and jitter are part of the model software design informed by controller issues expressing timing constraints correct-by-construction synthesis heterogeneous modeling

9. Eker & Lee, UC Berkeley 9 Elaborated Throttle Control System

10. Eker & Lee, UC Berkeley 10 Design Pattern: Modal Discrete-Time Controller in Continuous Time continuous time finite-state machine discrete time Hierarchical, heterogeneous model

11. Eker & Lee, UC Berkeley 11 This is Still An Idealized Model No jitter, no delays

12. Eker & Lee, UC Berkeley 12 Extend the ideal model Influence from implementation: Jitter Control delay Execution: Multitasking environment Incorporate the behavior of the RTOS Communication: Shared communication links Behavior of the network

13. Eker & Lee, UC Berkeley 13 A more accurate model

14. Eker & Lee, UC Berkeley 14 Software Realism Express timing constraints sample rates latency jitter tolerances Build models in appropriate abstractions Giotto: time-triggered HPM: hierarhical preemptive multitasking FRP: functional-reactive programming … These facilitate correct-by-construction implementation

15. Eker & Lee, UC Berkeley 15 The Next Problem: Synthesizing an Implementation

16. Eker & Lee, UC Berkeley 16 Outline of our Approach Model of Computation semantics defines communication, flow of control Ptolemy II model scheduler Schedule: - fire Gaussian0 - fire Ramp1 - fire Sine2 - fire AddSubtract5 - fire SequenceScope10 parser method call if block method call block … for (int i = 0; i < plus.getWidth(); i++) { if (plus.hasToken(i)) { if (sum == null) { sum = plus.get(i); } else { sum = sum.add(plus.get(i)); } … All actors are given in Java, then translated to embedded Java, C, VHDL, etc. target code abstract syntax tree Jeff Tsay, Christopher Hylands, Steve Neuendorffer

17. Eker & Lee, UC Berkeley 17 Division of Responsibility MoC semantics defines flow of control across actors communication protocols between actors Actors define: functionality of components Actors are compiled by a MoC-aware compiler generate specialized code for actors in context Hierarchy: Code generation at a level of the hierarchy produces a new actor definition We call this co-compilation. Multiple domains may be used in the same model

18. Eker & Lee, UC Berkeley 18 Software Progress Build on: First version on Titanium (UC Berkeley) Second version on Soot (McGill) Targeting: Simulation acceleration Embedded software synthesis Maryland subcontract Configurable hardware synthesis delegated to Brigham Young

19. Eker & Lee, UC Berkeley 19 Our Generator Approach Actor libraries are built and maintained in Java more maintainable, easier to write polymorphic libraries are rich and small Java + MoC translates to target language concurrent and imperative semantics Efficiency gotten through code transformations specialization of polymorphic types code substitution using MoC semantics removal of unnecessary code

20. Eker & Lee, UC Berkeley 20 Code transformations (data types) // Original actor source Token t1 = in.get(0); Token t2 = in.get(1); out.send(0, t1.multiply(t2)); specialization of Token declarations // With specialized types IntMatrixToken t1 = in.get(0); IntMatrixToken t2 = in.get(1); out.send(0, t1.multiply(t2)); The Ptolemy II type system supports polymorphic actors with propagating type constraints and static type resolution. The resolved types can be used in optimized generated code. See Jeff Tsay, A Code Generation Framework for Ptolemy II

21. Eker & Lee, UC Berkeley 21 Type System Output of type general - pure event with no value Input of general type - anything will do Polymorphic output - type depends on the parameters double general int general double Polymorphic actor uses late binding in Java to determine implementation of addition. Opaque port - types propagated from inside double Lossless runtime type conversion Type system by Yuhong Xiong

22. Eker & Lee, UC Berkeley 22 Type System Extensible type lattice Knowledgeable users can add full-featured types Unification infrastructure Finds a least fixed point Composite types records, arrays, matrices Higher-order types planned model = data Experiments with dependent types encoding MoC constraints

23. Eker & Lee, UC Berkeley 23 Code transformations (MoC-informed) transformation using MoC semantics // With specialized types IntMatrixToken t1 = in.get(0); IntMatrixToken t2 = in.get(1); out.send(0, t1.multiply(t2)); MoC-polymorphic code is replaced with specialized code. // Extended Java with specialized communication int[][] t1 = _inbuf[0][_inOffset = (_inOffset+1)%5]; int[][] t2 = _inbuf[1][_inOffset = (_inOffset+1)%5]; _outbuf[_outOffset = (_outOffset+1)%8] = t1 * t2; See Jeff Tsay, A Code Generation Framework for Ptolemy II

24. Eker & Lee, UC Berkeley 24 Synchronous Dataflow (SDF) Domain Balance equations (one for each channel): F A N = F B M Scheduled statically Decidable resource requirements Available optimizations: eliminate checks for input data statically allocate communication buffers statically sequence actor invocations (and inline?) send(0,t) get(0) token t NM A B

25. Eker & Lee, UC Berkeley 25 Synchronous/Reactive Domain A discrete model of time progresses as a sequence of “ticks.” At a tick, the signals are defined by a fixed point equation: A C B Available optimizations: Statically sequence fixed-point iteration Communication via registers

26. Eker & Lee, UC Berkeley 26 Other Domains with Useful Properties for Code Generation Strong static analyzability Giotto (time triggered) HPM (hierarchical preemptive multitasking) FRP (functional reactive programming – Yale) Finite state machines Discrete time Good for hardware descriptions Discrete events Process networks Continuous time (analog hardware)

27. Eker & Lee, UC Berkeley 27 Hierarchical Heterogeneity P6 P3 P2 P5 P1 E1 E2 E4 E0 M: Manager D1: local director D2: local director P4 P7 E3 E5 Opaque Composite Actor Transparent Composite Actor Ptolemy II composes domains hierarchically, where components in a model can be refined into subcomponents where the component interactions follow distinct semantics.

28. Eker & Lee, UC Berkeley 28 Conclusions Hierarchically heterogenous modeling matches the applications well… Hierarchically heterogenous modeling appears to be suited to high-quality sythesis