HurricaneFactory: an attempt to create a comprehensive toolchain for softradio design.

by Karl-Max Wagner & Ikuo Oka

1   Introduction

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 must be

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

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 another experiment.

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 the rest.

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[1]. 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 [2]as well as TI's 4 processor application boards[3], both using the TMS320C40[4], are to be used. The advantage of this processor is that there exists a GCC target as well as a good simulator[5]. 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 signal processing.

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

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[6] 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[7]. 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.

3   Conclusion

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[8] 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.

References

[1]
http://www.hamradio.si/notune.html
http://www.hamradio.si/psk23cm.html
http://lea.hamradio.si/s53rm/S5-PSK.htm
[2]
http://www.hema.de
[3]
ftp://ftp.ti.com/pub/tms320bbs/c4xfiles/c40ppdsg.exe
ftp://ftp.ti.com/pub/tms320bbs/c4xfiles/c40ppdso.exe
[4]
http://www.ti.com/sc/docs/products/dsp/tms320c40.html
[5]
http://www.elec.canterbury.ac.nz/c4x
http://gcc.gnu.org
[6]
http://xcircuit.sourceforge.net
[7]
http://www.itu.int
[8]
http://www.gnu.org/copyleft/gpl.txt
http://www.gnu.org/copyleft/lesser.txt

This document was translated from LATEX by HEVEA.