1 / 49

The Waveform Description Language (Technical Overview)

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 Science Software Design Group , 20 March 2001. Overview.

mhesson
Télécharger la présentation

The Waveform Description Language (Technical Overview)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related