Microwave Engineering Europe - March 2009 - (Page 27) MODELLING 27 Noise can be introduced in the simulated radio channel, and errors are counted and stored for display and analysis. The model simulates multi-path propagation with two radio channels simulated as well as two receiver heads for spatial diversity exploitation. External libraries are used by the initial C++ model: the ATLAS library, used for linear algebra functions, and the FFTW library, which implements Fast Fourier Transforms. The headers for these libraries and the binary libraries are added as external files to the CoFluent model. A private library is introduced as a number of source files. It describes a C++ matrix data type, with most classical matrix operation (inversion, diagonalization, product, etc.). This commonly-used THALES internal code is directly copied and pasted into the algorithm description of CoFluent operations. Also included as external source files are subroutines used for OFDM, modulation and puncture algorithms. The System C library is needed by the imported code, and is included in CoFluent Studio. A template is used by CoFluent Studio to generate a makefile for each project. SoC simulation The SoC simulation stage simulates the implementation of the modem in a twoprocessor hardware architecture, loosely derived from the TI OMAP 5910-5912. The testbench, composed of a random data generator, two radio channel simulations and sent/received data comparison, is described as hardware. It reflects the environment of a real modem. The various software elements have been given execution times to allow the following performance tests. If the projected hardware is complex (multiprocessor, intelligent data links, etc.) it is necessary to use a different set of values according to the projection of the architecture on hardware parts. An operation executes at a different pace based on the processor running it. Once the platform is described, the links between blocks are known. This is the critical part where it is necessary to use previously recorded performance data for the diverse functional blocks and for the links. Accurate timing data entered here is the obvious key for a useful simulation in the next step. During the evaluation, the modem was mapped in three different ways to the architecture: • Data enters through FIFOs towards the DSP, is exchanged between DSP and GGP via the internal bus, and then is sent to the radio via the same bus. This was the first tested configuration. • The data goes from the general purpose processor to radio via another set of FIFOs, and software blocks are dispatched differently between DSP and GPP. This test shows that changing the dispatching of elementary operations can get better results in term of throughput. • All data exchanges go through the interprocessor bus. This is the simplest, in terms of hardware, configuration. It puts a higher burden on the bus timings and is likely to increase the complexity of neighboring hardware for the time-shift of data frames due to bus contentions. To simulate the data path delays, the user defines the delay for every data transfer in the simulated system. For standard data types (byte, int, float …) the size of the data is known and the transfer duration can be defined from it: the DATASIZE macro allows calculating the number of bytes circulating through an interface. The delay is a function of it. For user-defined data types, the interfaces in the model transport a pointer to the object transported. The USERDATASIZE macro can be used to obtain the value of a user-defined field representing the data size. As the physical interfaces transport the full data and not a pointer, CoFluent Studio has a mechanism to calculate the real delay introduced. It uses a macro called FCTCOMPUTETIME. This calls a user-defined function to get the time required for the transfer. The pointer matrix object used in the modem is made up using a two-dimensional size and contains exclusively double elements. From these characteristics, the function for FCTCOMPUTETIME is written and introduced as seen in the following figure. Using the above elements, the read/write times for a link transporting matrix objects can be defined as functions of the matrix size, as it’s the case in a real system. Varying the parameters of the model and changing between different block dispatching and data path possibilities clearly shows the executable model created with CoFluent Studio is an efficient aid in determining both hardware/software tradeoff and module distribution between processors. Although initial training is highly recommended to maximize the benefits of the new methodology, most design teams find the tool beneficial within a matter of weeks. The tool is efficient in comparing hardware/software tradeoffs and board or SoC design options. The level of confidence expected depends mainly on the quality of the performance data the user inputs. CoFluent Studio in itself allows a large range of possibilities to define the performance data. About the authors Thierry Saunier is head of the modelling engineering laboratory at THALES. Vincent Perrier is co-founder and director of CoFluent Design. MICROWAVE ENGINEERING EUROPE Free subscription at: www.mwee.com/subscribe Microwave Engineering Europe ● March 2009 ● www.mwee.com http://www.mwee.com/subscribe http://www.mwee.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.