HurricaneFactory: an attempt to create a comprehensive toolchain for softradio
by Karl-Max Wagner & Ikuo Oka
1.1 The situation today
Softradio design today is in a strange situation: on the hardware side the prerequisites
to create phantastic designs are already here in the form of ultra performant
digital signal processors, fast A/D and D/A converters and hardware DSP chips.
On the other hand, those phantastic designs just aren't happening because the
requirements for a good softradio designer are extremely tough. Such a person
It is rather obvious that such ubergeeks are extremely rare to say the least.
If we could get rid of the first two of the above requirements things would
look a lot better. If we could weaken the last requirement it would be even
a seasoned rf / microwave expert
- an expert in advanced programming techniques with particular emphasis on ultra
efficient programming techniques
- an expert in communications systems design
1.2 A possible solution
Now let's dream a bit - what would we need to make the above wishful thinking
into a reality ?
The solution to the first point is pretty obvious: if we are serious about softradios
then we definitely do all the signal processing in software. The hardware is
just to provide the computing prerequisites we need and to get the signal in
and out. In other words: whatever the softradio is going to do in the end, the
hardware will always be the same. Thus, we could provide a proven hardware design
and make a few of these boxes just sitting on the shelf and waiting to be provided
with some software to tell it what it has to do. These boxes even can be reused:
once an experiment has been run, they may go back into the rack and wait for
The second of the above points is a little bit harder. However, we know that
in softradio design certain function blocks occur very frequently. Actually,
many of them are functional equivalents of the functional blocks used in conventional
hardware radio design.
In fact this means nothing else than providing a set of function libraries that
can be used for program generation. The functions in those libraries can be
highly optimized and adapted to different target architectures. In the ideal
case, the user doesn't have to care about the programming details: he / she
creates a design using those libraries. That's it. The system takes care of
Now for weakening the last requirement: being an expert communications system
designer. Let's face it: even the best may provide a bad design because they
overlooked a showstopper lurking within. In our speculative design system we
actually may provide a two pronged approach: we provide a simulation system
that evaluates the design against a ( hopefully sufficiently realistic ) simulation
of a typical environment. If this works out satisfactorily, we can generate
software for our test hardware boxes and play with them. This is as real as
you can get - and it sure will turn up some bugs the simulation missed ( and
this knowledge can be use to improve the simulation system ).
2 A Short Glimpse at HurricaneFactory's System Architecture
2.1 The Hardware
It is somewhat of a philosophical question whether the hardware architecture
planned at present belongs to the system or not - in the end HurricaneFactory
should support as much hardware as possible, in this sense being ``hardware
independent''. However, we aren't so far yet - so a short description of
what is used makes sense.
As a radio front end the well known transceivers designed by Prof. Matjaz Vidmar
of the University of Ljubljana (Slovenia) will be used. These transceivers
are pretty much ideal for DSP use as they output / input an I/Q baseband signal
to be transposed directly to the RF signal band. They also are well tried and
tested for wideband BPSK packet radio use as well as SSB use using the Weaver
method. This provides us with a good working solution for the moment.
As a DSP solution hema's DSP1 and DSP2 as well as TI's 4 processor
application boards, both using the TMS320C40, are to be used.
The advantage of this processor is that there exists a GCC target as well as
a good simulator. The GCC port is very important because for the moment
most of the software will be written in C and debugging is a helluva lot easier
if you can simulate the target architecture in software.
2.2 The Library System
It now goes without much saying that the library system is at the core of HurricaneFactory.
Initially the idea was to make it into a conventional library as usual under
C ( and other languages ). However, practical implementation work quickly showed
that this wasn't a very good idea due to the peculiarities of softradio digital
2.2.1 Function splitting
A typical situation in a typical DSP system is that you have a limited amount
of internal memory and a larger amount of external memory. If a function in
the library is defined, it normally is defined for a wide range of input / output
data array sizes. As soon as those arrays are bigger that the available internal
memory it is required to split the function into subparts working on smaller
arrays which are swapped in / out from / to external memory via hidden DMA.
The whole point of this is to prevent slowing down by explicit external memory
2.2.2 Static and dynamic functions
An interesting - and from hindsight obvious - problem is the fact that there
are functions ( or even parts of functions ) that are only used once to create
a data array that subsequently is never changed ( for example the calculation
of filter coefficients from an impulse response and suchlike ) and functions
that do the actual computations in the signal chain. Let's call the former ``static''
and the latter ``dynamic'' functions. Things are simple as long as fuctions
are either completely static or completely dynamic. Calculate the static functions
when generating the target code and integrate the results as dataset therein.
It is a lot less simple if functions contain dynamic and static parts. We are
still studying ways in which to handle that in a practical way.
2.2.3 Dynamic function generation
From all this it follows immediately that the library has to be generated dynamically
according to what is needed in the design for generating target code from it.
Thus, the library is provided as a generic set of library functions that are
adapted to actual needs at target code generation time ( we avoid the term ``compile
time'' because although this all resembles compilation it is not a compilation
in the strict sense ).
2.3 The Front End
So far the front end is standard C with some preprocessor additions ( which
are handled by a program that spits out standard C code ). However, as xcircuit
now has facilities of providing netlists as used for pcb design checking, it
would not be a big deal to provide block diagram symbols in xcircuit representing
HurricaneFactory library elements and parsing the ensuing netlist to chain the
functions together. This is an easy way of testing the practicability of graphical
programming. We are looking into ways how this might be achieved. Even if we
think of conventional text mode programming and if we consider doing it all
with high level fuctions keeping C as a language makes not much sense. We see
a new, specialized language evolving here.
2.4 The Path Simulation Subsystem
In its simplest form the path simulator just adds noise to the signal to be
transferred. This is already highly useful in order to study weak signal behaviour
of a system. However, you can go a lot further. So we plan to implement the
standard path simulation specs of the ITU. In fact, HurricaneFactory
here has a big advantage: as it is to go right down to the hardware level test
systems can be built and checked out in reality and the resulting data can be
used to build additional simulation algorithms.
In the above we have shown a plan for building a comprehensive communications
system development system, capable of accompanying development from the initial
idea to an actual prototype. Due to the fact that standard hardware can be used,
once the design has been decided upon, actual prototypes can be configured and
tested with very little effort. This is useful for education and research, where
ideas can be rapidly realized and tested and thus it is possible to get a ``feeling''
for things, as well as allowing the rapid prototyping and deployment of specialized
communications systems for particular purposes.
This project will eventually go ``Open Source'', being licensed under
the GNU / GPL as soon as we get a server up and running ( and we have
stabilized the code a bit more ). Much of what has been set out in the above
is still in the planning phase, so consider this paper as a ``white paper''
for an ongoing project.
This document was translated from LATEX by