Leveraging Waveform Description Language for System Specification Challenges

1. The Waveform Description Language (Technical Overview) E.D.Willink, Thales Research Limited,Ed.Willink@thalesresearch.com, http://www.thalesresearch.com/projects/wdl/wdl.html MIT Laboratory for Computer ScienceSoftware Design Group,20 March 2001

2. Overview • Specification challenges and WDL approach • Hierarchy - high level principles • FM3TR Example • Constraints - low level principles • Implementation • New opportunities • Summary • UK Programmable Digital Radio (PDR) Phase 1, • Waveform Description Language (WDL) programme • (DERA contract CU009-0000002745) • Raytheon, Communication Systems Division, Fort Wayne, Indiana, • Racal, Racal Research Limited, England

3. ‘Waveform’ • Conventional engineering parlance: • continuous signal • sinewave, square wave • Radio system terminology: • complete communication protocol • low level modulation scheme • blocking strategy • data encoding • end-to-end synchronisation • retransmission handshakes • ‘Waveform’ Description Language • not just waveforms • any synchronous reactive system

4. The system specification problem • Complex systems are • costly • late • mis-functional • inflexible • Complex system specifications are • large • ambiguous • contradictory

5. The system implementation problem • Implementation practices do not support re-use • porting - old code on new platform • copying - old code in new context • sharing - pre-written generic code • Re-use • code already written • bugs already removed • requires a well defined functionality • inhibited by implementation details

6. ‘Lego’ Bricks • Software Defined Radio - JTRS • assemble arbitrary waveform from pre-defined library blocks • new waveforms incur minimal costs and delays • UK Programmable Digital Radio (phase 1) • script for assembling ‘Lego’ bricks • identify the ‘Lego’ bricks and their parameters • System defined by composition of sub-systems • composition rules must be defined • subsystem behaviour must be defined • Need a meaningful specification - WDL

7. Implementation practices re-applied in the specification domain message flow diagrams state machines WDL Antecedents

8. Specification or Implementation • Implementation • How it can be done • Implicit assumptions • Non-portable constraints • Specification • What needs to be done • Ignore inconvenient details • Waveform Description Language (WDL) • Implementation practices re-applied in the specification domain • One specification • Many alternate implementations

9. Hierarchy,High Level Principles

10. Hierarchy • Divide and Conquer • tackle an unmanageable problem in manageable pieces • Subsystems exist at many scales • telecomms - international / national / regional / local / internal • equipment - cabinet / rack / module / board / component • CORBA components support two scales • inside / outside • WDL • fully encapsulated • same approach at all scales

11. Hierarchical Specification • External perspective • strong encapsulation • strict interface • Internal perspective • composition of nestedexternal perspectives

12. Composition • Decomposed entity has • extra communication • same external messages • same policy internally as externally • extra entities • same policy internally as externally • entities are self-scheduling

13. Communication in practice • High level systems • sporadic control events • Low level systems • intensive calculation • ‘continuous’ communication • WDL • sporadic and continuous flows are supported • continuous and discrete time are interchangeable

14. Static Hierarchical Decomposition • Entity • module of specified behaviour • not necessarily an implementation object • Static heterogeneous composition • behaviour-A OR behaviour-B • statechart (non-concurrent) • behaviour-A AND behaviour-B • WDL - message flow diagrams • UML - statechart (concurrent) • Leaf specification • mathematical definition of leaf behaviour

15. (UML) Statechart • State1 OR State2 • WDL ‘extension’ to UML: • state behaviour may be a message flow

16. Message Flow Diagram • Entity1 AND Entity2 • WDL Message Flow Diagram • each arc has defined data and flow type, connecting at ports • each entity is self-scheduling - rendezvous of relevant ports • external ports to define hierarchy

17. UML Comparison • UML Collaboration Diagram • no hierarchical ports • no arc semantics • no multi-input handling • external scheduling • UML Concurrent State Machine • ‘solid’ AND semantics • no hierarchical ports • arcs connect by name • no multi-input handling

18. CORBA Components • Extension of Object Oriented Concepts • Objects can provide data encapsulation • Object provide no synchronisation • Components add synchronisation • Components remove hierarchy • just two scales • outside component - disciplined • inside component - anarchic • WDL Entities add synchronisation • WDL Entities support hierarchy

19. Dynamic Hierarchical Decomposition • Static composition • adequate for simple applications • WDL could/should handle all applications • Dynamic composition • necessary for sophisticated applications • 13 active communication channels • ... a parse tree • Dynamic homogeneous composition • one-of a dynamic set of behaviours • all-of a dynamic set of behaviours • some-of is all-of many one-of’s

20. FM3TR Example • Future Multi-band Multi-waveform Modular Tactical Radio • FM3TR Technical Working Group (Fr-Ge-UK-US) • 30 - 400 MHz • 25 kHz channels • 25 kbits CPFSK • 250 - 2000 hops/second • 16 kbits transparent (voice) • 9.6 kbits coded (data)

21. FM3TR Protocol Layers

22. FM3TR Physical Layer

23. FM3TR Physical Layer State Machine

24. Hop Modulator

25. Hop Rise Time • constraint: shift.out = 0; • constraint: freq.out = hop.frequency; • constraint: amp.out = range { • minimum 0; value 0.5 * (1 - cos(2*pi*t/config.rise_time)); maximum 1; };

26. Constraints,Low Level Principles

27. Language for specification • need expressions for • configuration constraints, state machine guards • need statements for • state machine actions, leaf behaviour • need types for • messages • need a language • implementation languages do not specify • specification languages are unapproachable • specification languages have unhelpful focus • new language is new

28. WDL leafspecification • entity Subtractor {in minuend;in subtrahend;out difference;response minuend subtrahend // Whenever a rendezvous of { // minuend and subtrahend existsspecification { // receive minuend and subtrahend difference(minuend - subtrahend); // subtract values }; // send to difference }; }; • Polymorphic • type, shape, flow, language

29. Anatomy of a Class • Encapsulation • internal data • informal • message data • fragmented • single source • synchronisation • none • Monitors • local mechanism

30. Anatomy of an Entity • Encapsulation • internal data • writes internal • reads internal/external • message data • single quantum • data type • multi-source • flow type • synchronisation • extended rendezvous

31. Scheduling Flow Types • token - data flow semantics • tokens are processed in combination • AND semantics • event - synchronous reactive semantics • no two events are concurrent • OR semantics • signal - continuous or discrete time • value - unscheduled • Consistency of flow guides implementation strategy • SDF or DE or CT ...

32. Type Composition • Array, Record • AND composition • Union • Unsafe - ad hoc OR composition • Discriminated Union • Embedded discriminator identifies content • Safe OR composition

33. Practical Type Constraints • Implementation perspective imposes a specific type • octet in IDL but int in C • Specification defines a minimum behaviour • systems generally work better with extra precision • type InputSignal : real{minimum -1.0; // Values range from -1 to maximum 1.0; // +1 with at leastepsilon 0.01; // 0.01 resolutionoverflow clip; // Overflows are clippedround nearest; // Underflows are rounded};

34. Bit-truth Constraints • Specifications mandate specific bit patterns • traditionally embedded in the implementation code • Re-use may require a different bit-truth • Concepts a little untidy at present • simple refinement • add extra constraint to mandate e.g. 8 bits • more detailed refinement • an overlay type provides bit true view(s) • marshalling and unmarshalling • a layout type maps abstract to concrete type • type defines conversion to bit/byte stream • type defines reconstruction and discovery from bit/byte stream

35. Behavioural Constraints • Calculation (forwards) • define post-outputs with respect to pre-inputs • output(input); • state := input; • Transformation (bi-directional) • constrain output to input • constraint output = input; • Functional behaviour • no side effects • static single assignment • Specify required behaviour • don’t mandate a particular implementation

36. Complete specification (Low Level) • Amplifier - relatively easy • want vout = 10 * vin • WDL constraint v_out = 10 * v_in; • In practice need constraints • frequency < 1 GHz • load impedance 50 Ω ± 10% • third harmonic ... • Some constraints can be specified mathematically • Arbitrary constraintsneed an assertion

37. Specifying a sort • entity sort{generic DataType : type;generic Shape : shape = natural[1];in inputs : DataType[Shape];out outputs : DataType[Shape];// No output value is greater than its predecessor.constraint in_order : for no j in Shape where (j < Shape[0]-1) { outputs[j] > outputs[j+1]; };// Output is a permutation of the input.constraint is_permutation : for all j in Shape {let matchingInputs = collect i in Shapewhere (!(inputs[i] > outputs[j]) & !(outputs[j] > inputs[i])) { i; };let matchingOutputs = collect i in Shapewhere (!(outputs[i] > outputs[j]) & !(outputs[j] > outputs[i])) { i; }; matchingInputs.shape = matchingOutputs.shape; };};

38. Continuous Time Implementation • Practical systems • necessarily analogue - antenna signals • necessarily digital - protocol messages • analogue or digital - signal paths • Implementation locates ADC and DAC exactly • resolves analogue/digital choice

39. Continuous Time Specification • Specification must not restrict implementation • WDL signal flow type may be analogue or digital • Operations on signals must be polymorphic • array of 10ms, not 100 element array sampled at 10kHz

40. Implementation

41. Specification in WDL • Progressive decomposition • systems - subsystems - components - building blocks • Single hierarchical perspective • clear readable specification • removes ambiguities, avoids contradictions • Implementation in WDL • Progressive refinement of specification • further decomposition • practical constraints • recomposition • Minimal refinement • executable reference model

42. WDL Refinement • Progressive • decomposition • Progressive • refinement • Specification • preserved

43. WDL Refinement

44. New Opportunities

45. One specification Many alternate implementations WDL Products

46. New programming paradigm • Only specification • eliminates the implementation problems • refinable to any target • Behavioural parameterisation • inner behaviour passed in from outside • dead specification elimination • Parallel computing • entity/actor parallelism • array parallelism • Re-use at last • Real or bogus panacea?

47. Status • Phase 1 (4 months: December 1999 to April 2000) • Initial consideration of language concepts • Example decomposition of FM3TR (1 month) • clearer, many anomalies reported back • Phase 2 (2 years: April 2001 to April 2003) • Based on Ptolemy II • Preliminary Editor - October 2001 • Preliminary Simulator - April 2002 • Preliminary Code Generator - October 2002 • Open source, IPR free on web.

48. Summary • WDL specifies a determinate behaviour • Decomposition with single perspective • Refinement to a reference model • Refinement to product implementations • Polymorphism to exploit generic libraries • Realistic scheduling models • Type-oriented code generation for flexibility

49. Status • Waveform Description Language • practical, familiar, potentially formal • genuine re-use and portability • Open, free • collaboration and contribution needed and welcome • Industry standard needed • Better quality specifications • sponsor provides reference model • Semi-automated code generation • months rather than years