%  dpplang.tex from ObjectProDSP 0.2
%  Copyright (C) 1994 1995, Mountain Math Software. All rights reserved.
%  
%  This file is part of ObjectProDSP, a tool for Digital Signal
%  Processing design, development and implementation. It is free
%  software provided you use and distribute it under the terms of
%  version 2 of the GNU General Public License as published
%  by the Free Software Foundation. You may NOT distribute it or
%  works derived from it or code that it generates under ANY
%  OTHER terms.  In particular NONE of the ObjectProDSP system is
%  licensed for use under the GNU General Public LIBRARY License.
%  Mountain Math Software plans to offer a commercial version of
%  ObjectProDSP for a fee. That version will allow redistribution
%  of generated code under standard commercial terms.
%  
%  This program is distributed in the hope that it will be useful,
%  but WITHOUT ANY WARRANTY; without even the implied warranty of
%  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
%  GNU General Public License for more details.
%  
%  You should have received a copy of version 2 of the GNU General
%  Public License along with this program. See file COPYING. If not
%  or if you wish information on commercial versions and licensing
%  write Mountain Math Software, P. O. Box 2124, Saratoga, CA 95070,
%  USA, or send us e-mail at: support@mtnmath.com.
%  
%  You may also obtain the GNU General Public License by writing the
%  Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
%  USA.  However if you received a copy of this program without the
%  file COPYING or without a copyright notice attached to all text
%  files, libraries and executables please inform Mountain Math Software.
%  
%  ObjectProDSP is a trademark of Mountain Math Software.
%  
\section{The \dpp{} language}
\label{Sec:DppLanguage}


Development of Digital Signal Processing (DSP) applications
is a labor intensive time consuming process. Each implementation
is a custom product that makes little use of previous
work and has little that can be reused in future projects.
This is not unlike the state of programming in the early fifties
when all programs were custom products written in assembly language.

Things are changing slowly. \C{} compilers are becoming available for
many DSP processors. While these generally do not provide the
efficiency required for the kernel DSP algorithms they do allow
prototyping in \C{} and limiting assembly code to the kernel routines.

It is generally the case that any DSP system implementation is
preceded by the construction of high level model. This is required
because of the complexity of DSP algorithms and the many issues and
tradeoffs involved in their implementation. Thus every system is
implemented twice. The first is a functional implementation
in a development environment that supports analysis and
debugging of the algorithms. The second is a custom assembly language
implementation on DSP processors.

\dpp{} is a language and a methodology to dramatically improve
the efficiency of DSP system implementation. It uses the
object oriented methodology of \cpp{} and the universality of \C{} to
provide a practical approach to the problems of DSP system
implementation.


The \dpp{} language itself is a restricted subset of \Cpp{}.
Classes for signal processing objects form the core of the
\dpp{} language. These include signal processing nodes, signal generation
and input nodes and signal output or display nodes. There are additional
objects for defining DSP network, controlling DSP networks and controlling
buffer allocation.

\input{ddspintr.tex}

\subsection{The \dpp{} interactive interpreter}

The interpreter works similarly to the language SmallTalk.
Instead of a C main program you defines and manipulates
objects. The objects are DSP processing nodes that
are built into networks. The networks are then executed and the
output displayed. The simulation results may be 
graphical or numeric. They can be
viewed interactively and saved to a disk file.

Although you can enter statements directly it is easier and quicker to
have most statements written for you.
As you graphically editing a DSP
network \dpp{} statements are generated to implement the actions
you request. You can create nodes by a single mouse click (when the default
parameters are adequate) and connect nodes in the network with
two mouse clicks.

\subsection{DSP networks}

\dpp{} allows you to define an arbitrary network of DSP processing
nodes. This network can include feedback loops and resampling. 
Input can be from either signal generation nodes or disk files.
Output can be to plot windows, text windows, disk files or any combination of
these. The same data output can be sent to multiple destinations.

Analysis routines determine the completeness and consistency
of the network and insure that all feedback loops have enough delay
to prevent deadlock. A  timing analysis routine determines
the timing relationship of all data streams. The data is displayed
with timing labels that reflect the effect of DSP processing.
For example, the correct time of the output sample of a symmetric FIR filter
is the time of the midpoint of the filter impulse response. \dpp{} understands
and accounts for such timing relationships.

Networks can be controlled interactively. You may specify how many
input samples are created and display the output generated. He may then
vary some of the parameters and execute the network again,
to see the effect of these 
changes. Networks can be edited interactively. Display nodes
may be added at any point in the network.

\subsubsection{\Cpp{} language extensions for networks}

The operators \verb"+" and \verb">>" used in defining DSP networks is an
example of an internal \Cpp{} language extension.
One specifies the addition of a new thread to a network as \verb"Net + Signal"
where Net is a network and Signal is signal source node. To connect a new node
to a node already in a network one writes \verb"Net >> Node_A".
One can write the whole thing as a single statement:
\verb"Net + Signal >> Node_A". 

The language extension capabilities of \Cpp{} allow the definition of
a high level DSP language while maintaining conformance to
the industry standard programming language \Cpp{}.

\subsubsection{Modeling DSP processor arithmetic}

The arithmetic in the \Dpp{} processing nodes is done on two defined
classes: \DppNm{MachWord} and \DppNm{AccMachWord}. These classes correspond
to the basic word size (\DppNm{MachWord}) and the accumulator word size
(\DppNm{AccMachWord})
of target systems. Doing this allows us take our existing
library of DSP processing nodes and model the arithmetic of
virtually any target DSP processor. There is no need to modify
the processing node code. We merely need to define the arithmetic operators
in these two classes to correspond to the arithmetic in the target DSP
processor.

Currently \Dpp{} has two arithmetic models. The first
uses all single precision floating point arithmetic. The second
model assumes a 16 bit word size and a 32 bit accumulator.
It is possible to do both 32 bit integer and 32 bit floating point
operations in the floating point simulator.

\subsection{A language for DSP?}

The world is not in need of more programming languages. It can
benefit from extending languages to more effectively deal with
applications. \cpp{} and object oriented languages in general
recognize this. They are designed to be the bottom level of a
hierarchy of object libraries for different application areas.

The traditional method of extending languages is via subroutine
libraries. This method is effective and useful.
It works well for low level
routines such as those in the standard library provided
with most \C{} compilers. It is also useful for providing high level
functions that are used frequently such as Digital Signal Processing
kernel operations.

Subroutine libraries have limitations:
\begin{itemize}
\item{Subroutine calls with more than a few parameters are awkward.}
\item{It is difficult to construct libraries that are both general
and easy to use.}
\item{Libraries do not support use of natural mathematical notation
such as arithmetic operators in matrix and vector expressions.}
\end{itemize}

Good engineering practice aims at building complex systems in
a modular layered way. No tools will insure that a project
is implemented in this manner. Good tools can make it easier
and less labor intensive to do so. Subroutine libraries is an
important but limited step in this direction.

\dpp{} will support the creation of DSP programs that can
be ported to a 
variety of architectures. The idea is to allow the expression of 
a DSP algorithm at as high a level of abstraction as possible. 
The algorithm is designed, developed, debugged and verified
at that level. It can then be directly ported to any target
architecture that supports a standard \C{} compiler.

\Dpp{} uses both \Cpp{} facilities such as class hierarchies
and a language preprocessor to allow a single program to
be suitable for both interactive execution and use in
a dedicated DSP processor.


Use of \dpp{} provides
critical advantages to the creator of DSP products.
\begin{enumerate}
\item{Time to market will improve significantly: The algorithm
will be expressed and validated at a high level and then
rapidly ported to the target architecture.}

\item{Porting of existing products to new or 
more cost effective hardware architectures will be a relatively
easy task.}

\item{The same application can be supported on a variety of
architectures.}

\item{The overall cost of 
software development and maintenance will be reduced.}
\end{enumerate}

\subsection{Data flow model}
\label{Sec:DataFlow}

Virtually all computer processes fit a data flow model at least to the
extent of having input and output. In the absence of output,
there is no point to the program. In the absence of input,
the program only needs to be run once. DSP processes are
frequently, but not always, blessed with regular and
predictable data flow. We need to fully exploit this predictability
without limiting \dpp{} to only support regular data flow.

\subsubsection{Data input/output model}
\label{Sec:IOModel}

A general mechanism for modeling such data flow and using the
model to schedule process execution is described in \cite{Lee:DataFlow}.
We incorporate some of these ides in
our data flow model. We support processes that have one
or more input and one or more output nodes and consume and emit data
as follows. Input channel $i$ for node $j$ needs to have available in its
input buffer $B_i^j+XC_i^j$ samples to output on channel $k$
 $XD_k^j$ output samples. $X$ is a parameter that can
be set to any integer value. 

There are many examples that fit this model. A FIR filter of length
$L$ with output resampling of $r$ must have $L-r+rk$ inputs to
generate $k$ outputs. An FFT of size $F$ with an overlap factor
of $v$ requires $F-vF+vFk$ inputs to generate $Fk$ outputs.
Many DSP processes have a fixed relationship
between input and output samples that fit this model.

\subsubsection{Processing nodes}

Node definitions must satisfy generic and process
specific requirements.
For example a FIR filter will contain a pointer
to the filter coefficients and the
filter length.
It will also contain generic data flow
model parameters that relate input data consumption
to output data generation. To support both generic and
specific requirements we use \cpp{} derived classes.
We define a generic base class for all processing nodes
that fit the data flow model and then construct derived classes
for specific functions such as FIR filters. 


