1 / 42

The Waveform Description Language (and its application to reactive systems)

The Waveform Description Language (and its application to reactive systems). E.D.Willink, Thales Research Limited, Ed.Willink@rrl.co.uk, http://www.ee.surrey.ac.uk/Personal/E.Willink/wdl/wdl.html SMi Software Radio Conference , 4 April 2001. Overview. Motivation a little background

arthurn
Download Presentation

The Waveform Description Language (and its application to reactive systems)

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(and its application to reactive systems) E.D.Willink, Thales Research Limited,Ed.Willink@rrl.co.uk, http://www.ee.surrey.ac.uk/Personal/E.Willink/wdl/wdl.html SMi Software Radio Conference,4 April 2001

  2. Overview • Motivation • a little background • Specification • problems and challenges • WDL solutions • Example • WDL in use, practical, familiar • Implementation • transformation from specification to implementation • New Opportunities • re-use, portability • Summary

  3. Sponsors • 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

  4. Motivation

  5. Reactive Systems • Calculator: press equals => result displayed • Petrol pump: press lever => petrol flows • Radio: push-to-talk => communication established

  6. Software Radio • General Purpose Programmable Radio Hardware • ‘IBM PC’ model => 8086 • impressive platforms, all different • Portable Radio Software, JTRS • ‘Lego’ brick model • assemble arbitrary waveform from pre-defined library blocks • waveform == radio protocol • new waveforms incur minimal costs and delays

  7. UK Programmable Digital Radio • Phase 1 December 1999 to April 2000. • Plan • define a scripting language (WDL) for assembling ‘Lego’ bricks • identify the ‘Lego’ bricks and their parameters • QamModulator • Symbol rate • 8/16/... point constellation • Inter symbol phase rotation • Inter symbol transition

  8. What are the ‘Lego’ bricks? • Low level brick functionality definable • Adder • Latch • Higher level bricks are harder to define • GmskModulator • Reed-Solomon Encoder • High level bricks are specific, very hard to define • X25 Protocol Stack? • Should high level bricks be • defined absolutely? • built out of lower level bricks?

  9. What are the parameters? • QamModulator • Functional parameters • Symbol rate, 8/16/... point constellation, ... • Other perspectives • red/black compliance, processor allocation • maximum power consumption, execution time • Closed parameter list for pre-defined library • extra parameter requires total library redevelopment • Open parameterisation for specified behaviour • extra parameter automatically incorporated • behavioural parameterisation and true re-use

  10. Specifications

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

  12. Complete specification (High Level) • System specifications - very challenging • large, unreadable • Informal specification • terse - omissions lead to ambiguities • verbose - duplications lead to contradictions • Formal specification • good in principle • impractical for real applications • unapproachable for most practitioners • WDL • pragmatic compromise • formalisable, modular, familiar, practical, acceptable

  13. 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

  14. JTRS ‘Lego’ bricks • Each brick (SCA Resource) is a CORBA component • portable interface • potentially significant communication overheads • Early JTRS demonstrations use wrappers - 1 brick! • No new portability • More compliant demonstrations up to 10 bricks! • Bricks must therefore be very large (very high level) • SATURN receive signal processing unit • SATURN receive protocol unit • This is interoperability, not portability • reimplementation for distinct hardware • accidental compliance with a sub-specification

  15. UK PDR Phase 1 Analysis • Big bricks are highly bespoke • Big bricks are not directly specifiable • Big bricks should be built from medium bricks • Medium bricks built from small bricks • Small bricks can be specified • Divide and Conquer • Direct system specification too hard

  16. UK PDR Phase 1 Solution • Define a scripting language (WDL) for assembling ‘Lego’ bricks • composition rules must be defined • subsystem behaviour must be defined • Identify the ‘Lego’ bricks and their parameters • large bricks can be built from smaller bricks • parameterisation intrinsic to behavioural specification • identification of a unique set of bricks not necessary • Need a meaningful specification - WDL

  17. 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

  18. Why a new language? • Existing approaches are good in their narrow field • SDL good for states, poor for computation • COSSAP ok for computation, unusable for states • Few approaches support hierarchical decomposition • Many approaches lack a solid semantics • Complete system specification must tackle all fields • Existing narrow approaches are increasingly mature • WDL combines their many good characteristics

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

  20. Example

  21. (UML) Statechart Internal External • Behaviour of : • State1 OR State2 • WDL ‘extension’ to UML: • state behaviour may be a message flow

  22. Message Flow Diagram External • Behaviour of : 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 Internal

  23. 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

  24. 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

  25. 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)

  26. FM3TR Protocol Layers Internal External OSI layers

  27. External FM3TR Physical Layer Internal

  28. Internal Example State Machine External

  29. Internal Hop Modulator External Amplitude Waveform

  30. Hop Rise Time Internal (picture) • 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; }; External Internal (text)

  31. WDL leafspecification External • 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 Internal (text)

  32. Implementation

  33. 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

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

  35. WDL libraries re-use Standard interfaces bit truth Standard libraries pre-existing code WDLCompilation

  36. WDL Refinement

  37. Realising WDL • Reuse/adapt COTS • Ptolemy II most appropriate • Original perception • WDL-specific Vergil extensions • WDL to Ptolemy translator embedded in Vergil • Simpler perception • WDL is just a new abstract domain • translates itself to other domains • WDL-enabling Vergil extensions • Port/Parameter configuration form • UML statechart • Nested flow chart

  38. WDL Opportunities

  39. One specification Many alternate implementations WDL Products

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

  41. 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) • Using Ptolemy II • Preliminary Editor - October 2001 • Preliminary Simulator - April 2002 • Preliminary Code Generator - October 2002 • Open source, IPR free on web. • Awarded to BAE, Raytheon, Rohde & Schwarz

  42. Summary • Software Radio - good • Software ‘Lego’ bricks • need specifying • need hierarchical composition • need a language • Waveform Description Language • practical, familiar, potentially formal • genuine re-use and portability • open, free, collaboration and contribution needed and welcome • better quality specifications : sponsor provides reference model • semi-automated code generation : months rather than years

More Related