The Waveform Description Language. Overview

Transcription

1 1 The Waveform Description Language Moving from Implementation to Specification in Ptolemy II E.D.Willink, Thales Research Limited, Ptolemy Mini-conference, 22 March Overview The system specification problem better implementations Waveform Description Language solutions Comparison of and Ptolemy characteristics as an abstract Ptolemy domain Summary UK Programmable Digital Radio (PDR) Phase 1, Waveform Description Language () programme (DERA contract CU ) Raytheon, Communication Systems Division, Fort Wayne, Indiana, Racal, Racal Research Limited, England 1

2 3 The system specification problem Complex systems are costly late mis-functional inflexible Complex system specifications are large ambiguous contradictory Complete specification (High Level) 4 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 pragmatic compromise formalisable, modular, familiar, practical, acceptable 2

3 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 waveform == radio protocol 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 - 3

4 7 Specification not Implementation Implementation - how it can be done Full of non-portable constraints Specification - what must be done Ignore all the inconvenient details Modern tools support an increasingly generalised implementation Ptolemy better than most Ptolemy also an implementation abstracts Ptolemy to a specification 8 Antecedents Implementation practices re-applied in the specification domain Object Oriented Languages Block Diagram Languages State Machine Languages Functional Languages classes types hierarchy data flow events states expressions Waveform Description Language message flow diagrams state machines Reactive Languages semantics Specification Languages constraints 4

5 9 Comparison of and Ptolemy Ptolemy simulates a generalised implementation cross code-generates the same implementation more abstract than Ptolemy defines an abstract specification refines to simulate a reference model refines further to generate a production implementation more abstract scheduling more abstract type system more abstract leaf specification 10 Scheduling Abstraction Ptolemy scheduling - one domain per diagram uniform policy is convenient uniform policy is restrictive chosen policy is restrictive each domain is a scheduling implementation input ADC overflow samples Ptolemy does not support input as Continuous Time overflow as Discrete Event samples as Synchronous Data Flow 5

6 11 Flow Types Ptolemy - one domain per diagram BDF, CT, DDF, DE, DT, HDF, PN, SDF, SR,... - one flow type per message path event - (Synchronous Reactive semantics - one at a time - OR) token - (Data Flow semantics - all at once - AND) value - (asynchronous - breaks sender/receiver coherence) signal - ( continuous flow - CT or SDF) does support input as a signal flow overflow as an event flow input ADC overflow samples samples as a token flow 12 Flow Deductions Ptolemy domain restricts an implementation flows specify a behaviour is an abstract specification domain translator to specific implementation domains regions of consistent flow smart policies for region boundaries automatically exploits the EvenBetterDataFlow domain 6

7 13 (UML) Statechart StateChartEntity event out guard State1 OR State2 extension to UML: state behaviour may be a message flow State1 State2 event[guard] /out(...) Message Flow Diagram MessageFlowEntity in1 out in2 14 in1 in2 Entity2 in out Entity1 in1 out in2 out Entity1 AND Entity2 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 7

8 15 UML Comparison UML Collaboration Diagram 1. no hierarchical ports in1 no arc semantics 2. no multi-input handling in2 external scheduling UML Concurrent State Machine solid AND semantics no hierarchical ports arcs connect by name no multi-input handling Entity2 Entity1 in2 /... ; out internal /... ; out 3. Entity1 CompoundEntity 4. Entity2 in1 /... ; internal out 16 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 Entities add synchronisation Entities support hierarchy 8

9 17 VOICE_TX Example State Machine config voice_in tran_sec VoiceTxFsm config amplitude voice phase_change tran_sec rf_freq RX entry / reset() TxModulator amplitude rf_out phase_change rf_freq_out rf_freq_in carrier voice_in[ptt] rf_out rf_freq carrier_detect tx voice_in rf_in config tran_sec Fsm rx carrier rf_out rf_freq voice_out reset config rf_in tran_sec voice_in config packet tx tran_sec voice_in Sink in Sink in RxModulator tran_sec rf_out rf_freq DATA_TX DataTxFsm config amplitude data phase_change tran_sec rf_freq RxFsm config rx rf_in voice rf_freq carrier tx TxModulator amplitude rf_out phase_change rf_freq_out rf_freq_in carrier rx voice_out carrier_detect rf_out rf_freq rf_out rf_freq carrier_detect 18 Constructed Type Abstraction Simplistic systems double and may be int too array is a sequential accident Useful systems record and array type constructors Ptolemy deduces type from values deduces or declares types has discriminated union as well record expresses AND of fields within a message union expresses OR of alternate messages discriminated union ensures type safety 9

10 19 Bit-true Type Abstraction Simplistic systems just int Implementation perspective octet or char fix<13,5> Specification perspective any type with at least 40 db dynamic range defines minimum requirements of types translator selects/synthesises implementation type 20 Bit-true Type Overlay Implementation approach embed bit-true declarations But: a re-use may require a different bit-truth Specification approach A bit-true layout is overlaid onto abstract type A pattern matching layin construct supports type discovery 10

11 21 Leaf Behaviour Abstraction Ptolemy Classic one template per actor per domain per target template per domain led to domain inconsistencies SDF without corresponding CGC support Ptolemy II one (Pt)Java template per actor (simulation) one template per language per AST node (code generation) 22 (Pt)Java is not a specification language Precision is implemented not specified ok for 32 bit RISC bad for 24 bit DSP really bad for FPGA Statement scheduling is sequential not parallel ok for single CPU bad for FPGA Code is over-specified loop counters must be analysed away Overloading is limited C++ better but not a solution 11

12 leaf specification minuend subtrahend Subtractor difference entity Subtractor { in minuend; in subtrahend; out difference; response minuend subtrahend // Whenever a rendezvous of { // minuend and subtrahend exists specification { // receive minuend and subtrahend difference(minuend - subtrahend); // subtract values }; // send to difference }; }; 23 Polymorphic type, shape, flow, language Specification in Progressive decomposition systems - subsystems - components - building blocks Single hierarchical perspective clear readable specification removes ambiguities, avoids contradictions 24 Implementation in Progressive refinement of specification further decomposition practical constraints recomposition Minimal refinement executable reference model 12

13 Refinement Specification Program Refinement Refinement 25 Progressive decomposition Progressive refinement Specification preserved Sponsor Refinement Implementer 26 Abstract Specification layers coders modulators Actual Specification algorithms parameters bit-truth Specification Reference Model bit precisions acquisition algorithms Reference Model System Design filter algorithms acquisition algorithms minimum precisions System Configuration filter coefficients decimation ratios Hardware Mapping partitioning library matching Component Configuration parameterisation actual precisions bit-truth Product 13

14 27 Realising Reuse/adapt COTS Ptolemy II most appropriate Original perception -specific Vergil extensions to Ptolemy translator embedded in Vergil Simpler perception is just a new abstract domain translates itself to other domains -enabling Vergil extensions Port/Parameter configuration form UML statechart Nested flow chart Compilation Program 28 libraries re-use Standard interfaces bit truth Libraries Standard Interfaces Translator C, VHDL,... source code Compiler Standard libraries pre-existing code Standard Libraries Standard Compilers Executables 'Waveform Bundle' Interfaces, Configurations 14

15 29 Ptolemy II Translations hierarchy MoML AST leaf PtJava Java C Translations leaf Wdl hierarchy MoML AST PtJava Java C... 15

16 31 Ptolemy extension for Ptolemy II 1.0 Text Editor MoML MoML Design Library Vergil (GUI) Vergil Extensions tool-set Leaf Library Translation Actors Text MoML PtJava Leaf Library Ptolemy II (Simulator) Ptolemy Extensions Domain PtJava Files Java Files C Files VHDL Files Configuration Files Interface Files 32 Products One specification Many alternate implementations Simulation Environments HLA, Ptolemy,... Execution Environments Application, Process, CORBA Component, FPGA, Analogue hardware,... 16

17 33 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? 34 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) Preliminary Editor - October 2001 Preliminary Simulator - April 2002 Preliminary Code Generator - October 2002 Open source, IPR free on web. 17

18 35 Summary of Language 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 Free 36 Summary of Comparison Ptolemy Classic - most powerful/versatile (fast) Ptolemy II - most powerful/versatile (flexible) Ptolemy encourages implementation perspective domains, exact types, (Pt)Java leaves (domain) abstracts to a specification flows, constrained types, constraint language refines specification to an implementation refinement to reference model part of a specification 18

19 37 Summary of Goals is an open program collaboration welcome and needed? industry standard via SDR Forum and OMG? Better quality specifications sponsor provides reference model Semi-automated code generation months rather than years 19