WDL semantics are based on the Esterel synchrony hypothesis [1] that no two events occur
at the same time and that all event processing is instantaneous. The defined behavior is
therefore deterministic and, as noted in [1], deterministic systems are an order of magnitude
easier to specify. However, this defines an ideal behavior that cannot be achieved by any
practical implementation, and a WDL specification must therefore incorporate tolerances as
annotations that bound the practical degradations of an implementation.
Since the specification defines an ideal behavior, the tolerances are unidirectional; the
practical implementation is worse. This avoids complexities that arise from a ‘gold standard’
practical implementation, against which an arguably superior implementation might have to
be considered inferior.
The above example decomposes a system into a subsystem. It is, of course, possible to
decompose the environment into more manageable subenvironments. It is also possible to
decompose a connection to insert a nominally transparent composition of entities such as a
coder and decoder.
13.2.3 Influences
The concepts used by WDL are drawn from a variety of language domains as indicated in
Figure 13.3. A few examples of each language domain are also identified.
The utility of WDL arises through the use of hierarchical block and state diagrams,
supporting data-driven interaction as in tools such as Cossap, and event-driven interaction
as in specification and definition language (SDL) [10]. Successful coexistence of these
The Waveform Description Language 369
Figure 13.3 WDL antecedents
alternate forms of interaction relies on the analysis presented as *charts (starcharts) in [3].
Effective communication and flexible computation is supported by applying object oriented
principles to declare data types.
WDL provides a deterministic specification through adoption of the synchrony hypothesis
from synchronous languages such as Esterel [1].
Detailed mathematical specifications as embodied by Z or VDM are powerful but unap-
proachable, while the capabilities of operator control language (OCL) in universal markup
language UML [12] are limited. WDL therefore follows Alloy [5] and SDL in the search for a
more acceptable mathematical presentation. The discipline of functional languages is
followed to ensure referential transparency and consequently ease the code generation
task. Further flexibility is provided by exploiting data parallel concepts to extend scalar
activities to arrays.
A WDL specification is a hierarchical decomposition of behavior only. Since there is just
this one dimension for decomposition, there are no conflicts of perspective corresponding to
those between class inheritance, static object relationships, dynamic message interactions,
and module partitioning that arise when using UML at the implementation level.
Languages such as SDL [10] and Ptolemy [2] already embody many of the WDL concepts.
SDL comprises specification constraints, types, and hierarchical block diagrams as well as
state machines. Research by the Ptolemy group into using data flow for DSP within a more
general computing context has used synchronous reactive principles for a block diagram tool
that supports arbitrary hierarchical use of state machines and data flow, with user-defined
types.
WDL incorporates concepts available in other approaches but provides sufficient breadth
to cover the full range of specification problems, and powerful parameterization facilities to
support genuinely reusable specification libraries. The concept of a flow type is fundamental
to supporting analog specification, computational data flow, and event-driven protocols. The
concept of refinement is fundamental to evolving the specification into, rather than rewriting
as, the implementation during the development lifecycle.
In comparison to SDL, with which WDL has many philosophical similarities, the addition
of support for arbitrary hierarchy, data flow, and multiple inputs leads to a major change of
perspective. All nodes on all WDL diagrams are behavioral entities. SDL diagrams are
confused by the use of a rich graphical notation to provide support for low level computa-
tional data flow.
In comparison with a simple block diagram tool such as Cossap, the addition of event
handling and state machines resolves the higher level specification issues concerned with
alternate behaviors. The addition of data types supports specification of low level intent and
high level message complexity.
In comparison with the more substantive Ptolemy, WDL provides the required abstraction
to support use as a specification rather than an implementation tool [15].
In comparison with Esterel, WDL provides the same fundamental semantics but provides
the missing algorithmic capabilities to accompany the scheduling framework.
The presentation in this chapter uses graphics for the hierarchical diagrams and text for
details. The underlying representation uses an extensible markup language (XML) dialect for
both graphical and textual elements. The graphical aspects can therefore also be edited using
extensions of the textual dialects. (Any form of editing can of course be performed using
XML tools.)
Software Defined Radio: Enabling Technologies370
13.2.4 Hierarchical Diagrams
A large WDL specification for a system entity is progressively decomposed into the smaller
more manageable sub-specifications of sub-system entities using one of two forms of hier-
archy diagram.
13.2.4.1 Interfaces
At each level of decomposition, the external behavior of an entity is defined by its interface,
which comprises a number of ports, each of which has a name, direction (input or output) a
data type, and flow type.
The data and flow type may be explicitly defined. However, leaving data and flow types
undefined or only partially defined provides for reuse, since WDL defines how types can be
deduced along interconnections and across entities. A reusable entity may therefore adapt to
use the types appropriate to the reusing context.
WDL does not impose detailed graphical stylistic rules, and so the diagrams in this chapter
are examples rather than definitions of a graphical style. The rather bland icon of Figure 13.4
only uses names. It can be replaced by a more meaningful icon, as in Figure 13.5 in order to
make a flow diagram more understandable.
13.2.4.2 Message Flows
A message flow diagram defines the internal behavior of an entity by composition. The nodes
of the diagram define partial behaviors, all of which are exhibited concurrently. The arcs
express the communication between entities.
The Waveform Description Language 371
Figure 13.4 Example entity interface
Figure 13.5 Example flow diagram
Figure 13.5 provides a simple example of a fixed tuned long wave receiver. The diagram is
equally intelligible to valve, transistor, application specific integrated circuit (ASIC), or
digital signal processing (DSP) practitioners, since it decomposes the system into a number
of potentially parallel behavioral entities with designated directional communication paths
between them, without imposing any particular implementation approach.
Communication between entities occurs through the interchange of messages subject to an
appropriate flow type (or scheduling protocol), which, in the example, requires continuous
one-way signals (or an emulation thereof).
Additional annotation is required to convert the above diagram from an informal intuitive
interpretation to a specification with formal semantics. The WDL flow diagram is therefore
annotated to define signal as the flow type of each communication path, together with
constraints on the maximum latency and an appropriate ‘fidelity’ over a specified frequency
range. More detail than just a center frequency is also needed to pin down the filters.
An implementation using valves will indeed use continuous signals, whereas a DSP
implementation will sample some of the signals at a sufficiently high rate to simulate the
required continuity. Practical implementations will presumably distribute the initial amplifi-
cation over a variety of isolation and gain stages.
A simple fidelity specification such as within 1% can be directly specified in WDL; a rather
more challenging specification involving a signal to integrated spurious energy ratio, or a
colored phase noise characteristic, cannot. It is impossible for WDL to have every test
measurement criterion built-in.
Difficult fidelity specifications are therefore resolved as in Figure 13.6 by specifying the
behavior of a test harness and asserting that the test harness output satisfies some criterion.
constraint: assert.in , 100‘ms;
A library of reusable test harnesses will include the specifications for a variety of distortion
analyzers. A test harness with a necessarily true output is easily recognized as a redundant
part of the specification and can be omitted from an implementation, although it may be
retained by a simulation. Ensuring that the test harness output is always true is not generally
provable, although there are many practical cases where a proof tool may be successful.
Where proof fails, a tool can at least enumerate all the unproven specifications so that
engineering judgment and directed testing may be applied.
13.2.4.3 Statecharts
A statechart defines the internal behavior of an entity as a finite state machine. The outer
nodes of the diagram define the alternative behaviors, exactly one of which is exhibited. The
outer arcs of the diagram express the transitions between behaviors.
Software Defined Radio: Enabling Technologies372
Figure 13.6 Use of test harness
A WDL statechart follows the conventions of a UML statechart; the internal behavior of a
state is defined using an application specific language, which is a nested message flow
diagram in the case of WDL. The concurrent state machine concepts of UML are therefore
unnecessary in WDL, since a message flow diagram expresses conjunction of behavior more
clearly.
The interface of a receiver mode control entity RxMode is shown in Figure 13.7. It is
defined in exactly the same way as for a message flow diagram, and so does not reveal that a
statechart is used for the internal decomposition shown in Figure 13.8.
The control entity may be in either ACQUIRE or TRACK mode. It starts in ACQUIRE mode
making a transition to TRACK mode when the Acquire activity terminates. It then remains
in TRACK mode until an instruction to reacquire is detected.
The Waveform Description Language 373
Figure 13.7 Example statechart interface
Figure 13.8 Example statechart
13.3 FM3TR Example
An indication of the style of a WDL specification may be obtained by considering a simple
example. The following example shows part of the respecification of the future multiband
multiwaveform modular tactical radio (FM3TR) using WDL in place of a more traditional
verbal specification. The full decomposition may be found in [14].
The FM3TR waveform is the result of a four-power initiative to provide an unclassified
waveform with some similarities to Saturn. It provides 16-kbit/s voice or 9.6-kbit/s data
communication at between 250 and 2000 hops/s in 25 kHz channels from 30 to 400 MHz.
Figure 13.9 shows the interface of the radio together with a decomposition of its operating
environment into a data terminal, voice terminal, and the ether. (The connection to the ether
provides a rare instance of a fully bidirectional connection.)
13.3.1 Protocol Layers
The FM3TR specification defines a layered behavior corresponding to the physical, data link,
and network layers of the OSI model. In order to better accommodate the characteristics of a
radio channel, the specification defines a physical (Phl), medium access (Mac), data link
control (Dlc) and network (Nwk) layers.
These layers and the communication between them are shown in Figure 13.10 together
with a human computer interface (Hci) to stub out all the unspecified control interfaces.
Voice communication involves only the physical layer and so the communication path is
from voice_in to antenna, and from antenna to voice_out. Data transmission uses
all layers with data_in flowing down to antenna and then back up to data_out.
The extra carrier_detect signal supports the persistent carrier sense multiple access
(pCSMA) collision avoidance algorithm in the Mac layer.
A master-slave connection is necessary for the Hci connections to support dispatch of a
command message and an associated response. A master-slave connection is also required
between Dlc and Mac to ensure that the Dlc does not choose the next message while a
previous message awaits transmission.
Software Defined Radio: Enabling Technologies374
Figure 13.9 FM3TR interface
13.3.2 Physical Layer Modules
The major mode changes in the physical layer between transmit and receive are resolved by
specification of alternate behaviors using a state machine in the next section. Before that
machine can be defined, the specification must also identify all the physical layer behaviors
that are not affected by the state changes. The outer perspective of the physical layer, shown
in Figure 13.11 therefore uses a message flow diagram to express the conjunction of beha-
viors that consist largely of signal conditioning for the main state machine.
The Ptt entity debounces the push to talk input, and the Rx and Tx entities generate
increments for some statistics counters in the Hci. The Hci makes these available for
external interrogation as well as controlling attack and decay time constants for carrier
detection in the Cd entity, and maintaining a set of configuration parameters for the Fsm.
The TranSec sources cryptographic information.
The Radio provides the conversion between the antenna signal and rf_in/rf_out
The Waveform Description Language 375
Figure 13.10 FM3TR layers
signals centered on an rf_freq. There are many alternate implementations of this func-
tionality and so the Radio entity is not decomposed further in order to avoid a specification
bias to a particular approach. The abstract capabilities of a radio are therefore expressed
directly as a leaf specification.
13.3.3 Physical Layer Finite State Machine
The main physical layer FSM is responsible for selecting the major behavior: whether to
receive or transmit, and in the case of transmit, whether to transmit voice or data. The state
machine shown in Figure 13.12 expresses this alternation of behaviors.
The physical layer starts in, and is normally in, the receive (RX) state but switches to one of
two alternate transmit states (VOICE_TX or DATA_TX) when a ptt (push to talk) activation
occurs on the voice_input, or a tx message is available. The simplicity of the state
machine clearly shows that the behavior is half-duplex and that exit from transmission occurs
on completion of the transmission; there is no preemption.
The behavior within each of the three states is defined by a simple flow diagram. The two
transmit states share a common TxModulator behavior but require distinct VoiceTxFsm
and DataTxFsm state machines to sequence the various synchronization and information
hops. In either case the relevant TxFsm supervises the integration of tx or voice_in data
with the tran_sec keystream in accordance with the prevailing configuration parameters
to produce a modulation control signal that is then modulated to produce an rf_out
signal at an rf_freq.
The behavior of the three states is exclusive, and well defined at transitions, so an imple-
mentation may share the same hardware resources for RxModulator and TxModulator.
Software Defined Radio: Enabling Technologies376
Figure 13.11 Physical layer components
With the exception of the Sink entity, all other entities require further decomposition.
Sink is a standard library utility that discards its inputs. The usage in RX and DATA_TX
states requires that voice_input be discarded. The lack of a Sink on tx requires that tx
messages are buffered until they can be transmitted. The voice input is therefore only active
while connected, whereas all data packets are transmitted.
13.3.4 Voice and Data Finite State Machines
The continued decomposition requires more space than can be justified here. It may be found
in [14]. The decomposition so far has decomposed the behavior first into the static layers and
then into the dynamic state that handles a complete message. Decomposition proceeds by
breaking a message transmission into its preamble, then body, then postamble phases. Each of
those phases comprises a conversion between source data and source frames that are encoded,
interleaved, and resequenced as hops. This example continues with the conversion of the
composite information packet, defining the behavior of a hop into a continuous time wave-
form.
The Waveform Description Language 377
Figure 13.12 Main FM3TR physical layer state machine
13.3.5 Hop Modulator
Encoding and interleaving of the information for each hop are subject to two timing
constraints; they cannot be started before source information is available and must be
completed prior to the start of the hop. Causality imposes the early bound, a real-time
specification applied to the hop in Figure 13.13 imposes the late bound.
Precise timing information is imposed for each hop by synchronizing the dynamic hop
content with the static configuration. The thick bar is a library entity that performs the
synchronization. The clock source is constrained to operate at the hop rate by the annotation:
constraint: clk.period ¼ config.hop_period;
13.3.6 Hop Waveform
A frequency hopper normally changes frequency between hops, and in order to avoid undue
spectral splatter must modulate its amplitude as shown in Figure 13.14. The amplitude is
reduced while the frequency synthesizers retune, and is adjusted smoothly to full amplitude
before and after information transmission.
The requirement for these four phases is easily specified using a state machine that
sequences the four distinct operational behaviors within the hop. Each state has a behavior
that combines the relatively static configuration parameters with the dynamic hop infor-
mation to produce a modulation control signal for a modulator (Figure 13.15).
Transition between three of the states occurs after fixed time delays. The remaining
transition from the INFORMATION state occurs when the InfoModulator exits after
processing all the information bits.
Software Defined Radio: Enabling Technologies378
Figure 13.13 Hop modulator
Figure 13.14 Hop amplitude
Không có nhận xét nào:
Đăng nhận xét