rapid prototyping of radar signal processing algorithms · rapid prototyping of radar signal...

Rapid Prototyping of Radar Signal ProcessingAlgorithms

Hans Schurer and Jan J. HuninkSIGNAAL B.V.

Zuidelijke Havenweg 40PO Box 42, 7550 GD Hengelo

the NetherlandsPhone: +31 (0)74 2484269 Fax: +31 (0)74 2484018

Email: [email protected]

Abstract: In the last few years, the field of electronicsproducts driven by the commercial market is expanding atsuch a rapid rate that is now possible to design signalprocessing products with a much higher degree ofintegration and at a much lower cost. In the meantime, thesignal processing equipment used for military applicationshave been developed in a specific dedicated way. The costsof these developments are very high and all thetechnologies used (hardware and software) are quickly out-of-date, which leads to extensive obsolescence ofcomponents.

The ESPADON (Environment for Signal ProcessingApplications Development & prOtotypiNg) program is aEuropean research programme in the Eurofinderframework financed by the Ministry of Defence of France,the United Kingdom and the Netherlands. The companiesinvolved are THOMSON-CSF (through its subsidiaries:THOMSON-CSF DETEXIS, THOMSON-CSF AIRSYS,THOMSON-CSF COMMUNICATIONS, THOMSON-CSF OPTRONIQUE, THOMSON MARCONI SONARand SIGNAAL), MARCONI ELECTRONIC SYSTEMS(through the Marconi Research Centre) and Matra BAeDynamics France.

The goal of ESPADON is to develop a new methodology tosignificantly improve the process by which complexmilitary digital systems are designed, manufactured andsupported. The main objective is to reduce productdevelopment time, leading to a similar reduction of productand life cycle costs. ESPADON meets these objectivesthrough a combination of advanced design methodologyemphasising risk analysis, rapid and virtual prototyping,concurrent engineering, and design reuse.

In this paper we will elaborate on the benchmarking of aradar signal processing application using the rapidprototyping technique. The main objective of thisbenchmarking activity is to demonstrate the improvementsof the ESPADON methodology. The implementation of thisapplication will be performed on a high-end CommercialOf The Shelf (COTS) platform using crossbar interconnectbetween processing nodes. Improvement of themethodology will be measured by obtaining metrics during

this benchmarking process, which are compared to thecurrent practice metrics.

Keywords: Design environments and frameworks,Embedded systems, Signal processing.

I. Introduction

Over the last few years, the military equipmentmanufacturers had to face the rapid and exponentialgrowth in technology and of the market in thecommercial electronics business. In the past, until thelate 80s, the advances in electronics technologies wereprimarily driven by and pulled forward by the militaryindustry. The military equipment manufacturers couldafford the technology pull and ensure access to and longterm supply of, albeit expensive but also efficient andrelatively durable, military components.

By the end of the cold war, the reduction in militarybudget world-wide and the increase of investment costsof this industry, coupled to the rapid growth of thecommercial electronics market, has led the majorelectronics companies away from the military componentmarket. This trend has been accentuated by the USDepartment of Defence (Perry directive) thatrecommends a decrease in military material cost by usingCommercial Of The Shelf (COTS) products.Consequently, the military equipment manufacturers arebeing increasingly forced towards utilising COTStechnologies.

However, there is a significant disparity between theproduction life cycle of military equipment and COTStechnologies:Military equipment life cycle: At present, thedevelopment time of a complex military equipment, suchas RADAR, may last 5 to 10 years and be in operation,maintained and supported, for a further decade or more.Electronic component life cycle: The digital electronicmarket is now driven by the short life cycle of civilapplications (wireless telecommunications, PC,

ISBN: 90-73461-18-9 405 c©STW, 1999 10 19-01:063

consumer electronics,...) which are driving the advancesin the technology and have to adopt the advances quicklyto remain competitive. Computing power and the numberof transistors per chip has grown on average over the lasttwo decades by a factor of 2 every 2 years (Moore’sLaw) and the actual curve is exponential.

The short life cycles mean that even digital computersare becoming obsolete over their original plannedoperational life cycle. Hence the problem ofobsolescence is acute for military systems where the lifecycles are considerably longer. At present, two methodsexist to handle the problems of obsolete components:

− The lifetime buy and storage of components that aregoing to become obsolete,

− An equipment retrofit with the latest components onthe market.

The lifetime buy and storage implies a capital outlay upfront based on exiting sales and estimated sales in thefuture. Hence the capital is not only depreciating butmay be a large loss if the predicted orders do notmaterialise. The probability of this occurring is highsince the equipment will by definition be out of datewhen fielded and hence compete unfavourably with moreup to date products. Hence lifetime buys and storage isnot a viable solution.

The retrofit of a signal processing system is another wayto mitigate the obsolescence of components.Theoretically, the cost of a retrofit should be appreciablylower than the cost of the initial development of thesystem. It can be at the same level or even higher if theretrofit requires a complete system architecture redesignor system revalidation (flight tests, etc. ).

Also, the reduction of the retrofit costs and developmenttime is the main element for an effective mitigation ofobsolescence of components. New methodologies andtechniques of development should achieve this reductionof costs. Under the current development practices, thereduction in retrofit costs and development time is notachievable because it is not integral to the designmethodology.

II. Research initiatives in the area of developmentmethodology

Some research programmes have been initiated todecrease development cost and to cope with theobsolescence problems faced by the military industry.

A. RASSP Programme

The American research program RASSP (Rapidprototyping of Application Specific Signal Processors)was carried out between 1994 and 1997 with a $150Mfunding of the American DoD [1].

Within the RASSP program, a new developmentmethodology was defined. A design environment forsignal processing equipment was also developed tosupport this method. With this new methodology and theassociated design environment RASSP claims to haveachieved a four times reduction in the development cost.

B. ESPADON Programme

The ESPADON programme [2],[3] is a new EuropeanEurofinder research programme funded jointly by thecollaborating companies and by the Ministry of Defenceof France, the United Kingdom and the Netherlands.

Over the life of the programme, the programme aims toachieve the following:

− Understand the technical basis of the emergingmethodologies and achieve a synthesis of anadvanced design methodology to develop the nextgeneration of real-time signal processing systems,

− Obtain a detailed understanding of the technologydeveloped to date and harness existing developmentsand tools in order to provide a complete environmentfor signal processing application development andprototyping for military applications,

− Demonstrate the programme objectives through tworealistic and representative benchmarks:

· An adaptive beamforming application for amultibeam naval RADAR,

· A SONAR benchmark.

In this paper we consider the RADAR applicationonly.

− Analyse productivity gains obtained in relation tomethods of traditional development and disseminatethe results of the study through the military industrycommunity.

The ESPADON programme started in July 1998 and willlast just under 3 years. The ESPADON programme does not intend to developnew tools but to use existing tools to implement the newmethodology and techniques of development.

III. ESPADON Methodology requirements

The definition of the ESPADON methodology hasstarted with an analysis of the state-of-the-art of thedevelopment methodologies through existing survey

406 Hans Schurer and Jan J. Hunink

STW/SAFE99

documents [4], or relevant research programmes ([5], [6]and [7]). It has resulted in a definition of an ESPADONmethodology based on the following requirements: − A Risk driven development life cycle,− a “ Model Year ” approach,− Capitalisation and Reuse.

A. Risk driven lifecycle

The traditional development methodology implements a“ Waterfall ” development lifecycle. There are a numberof deficiencies in the “ Waterfall ” lifecycle model,which have been identified since the end of the 80’s. Themain criticisms are:

− A very late validation of the system requirements,− Difficulties to accept changes,− No emphasise on reuse between phases.

Therefore, in ESPADON we favour a Risk Drivendevelopment lifecycle.

B. “ Model Year ” approach

The concept of “ Model Year ” is one of the primaryconcepts of the RASSP program methodology.The “ Model Year ” mitigates the risks of thedevelopment of equipment by rapidly validating itsrequirements through a succession of prototypes (Rapidprototyping). The implementation of a “ Model Year ” ofthe signal processing application uses the availabledigital technology.

Indeed, instead of developing expensive and rapidlyobsolete custom computers, the Rapid Prototypeintegrates available commercial technologies based onCOTS boards or COTS computers. On the other hand,the final equipment, taking into account the constantdigital component improvement, is developed with thelatest technology.

With the “ Model Year ” a retrofit of the equipment dueto obsolescence of components is only another iterationin the life cycle of the equipment. This approach hassome advantages such as:

− In the conventional approach, the digital technologyimprovement entails obsolescence of components andtherefore considerable additional costs,

− In the “ Model Year ” approach the improvement ofthe commercial components technology makes itpossible to decrease:

· The risks and costs during the development phaseof the equipment,

· The manufacturing costs during the productionphase of the equipment.

C. Reuse and capitalisation

Reuse and capitalisation are the other elements of themethodology implemented to decrease development timeand cost. The ESPADON Methodology facilitates: − The identification of redundant activities throughout

the iterative development lifecycle.− The Reuse of existing constituent parts (SP

algorithms, components, hardware architectures,PCBs, etc.). This consists of using in-housecomponents already developed or commercially-available components for the development of eachiteration within the development cycle.

− The capitalisation of the developments for otherfuture developments.

IV. Definition of the methodology

The development of one Signal Processingimplementation is an iterative approach. The diagramFigure 1 shows the top-level structure of the abstractiterative development lifecycle. It shows thedevelopment-planning step, the four developmentprocesses, the artefacts involved, a control point, theconnection with the overall system development lifecycleand the relationships between them all.

A. Development stages

The different stages of refinement identified to cover thesignal processing subsystems development stem from theMethodology MCSE (Méthodologie de Conception de

Plan SP Development

Functional Design

Architectural Design

SpecificationRisk

Register

Requirements

Development

Plan

Implementation

To System Development

From SystemDevelopment

System Review

Information Flow

Key: Process Artefact Development Control

Process Flow

Figure 1: Abstract Iterative Development Lifecycle

Rapid Prototyping of Radar Signal Processing Algorithms 407

IEEE/ProRISC99

Systèmes Electroniques) from IRESTE, Nantes [6]. Theabstract iterative development lifecycle contains thefollowing development stages:− Specification: during specification the raw

requirements from system development are refinedand turned into an engineering specification for thesignal processing component. This specification mustcontain the salient functionality and system interfacesdefinitions as wells as physical attributes andperformance and cost criteria.

− Functional Design: The functional parts of thecomponent specification are modelled by assigningthe appropriate algorithmic and control processingblocks, functional libraries and description models ofcomputation, to a functional model. This functionalmodel should be independent of the hardware andsoftware technologies to be used for the component’simplementation. The functional model is thenevaluated by simulation. The result obtained, withrespect to the required performance levels, is verifiedagainst functional evaluation criteria. Severaliterations will be required to obtain the desiredfunctional model. In the event of difficulties, a changeto the specification may be required to ensure thefeasibility of the requirements.

− Architecture Design: The critical characteristics ofthe reference functional model (computing power,rate, etc.) and the non-functional requirements (costs,volume, etc.) are identified. A risk analysis isperformed to determine the critical characteristics tobe taken into account. Candidate architectures aredefined, taking into account: the criticalcharacteristics defined from the risk analysis and theavailable hardware resources. Development costestimations and performance analysis are carried outand the most effective architecture is chosen. If noappropriate solution can found, then the functionalmodel or the system requirements will need to bereworked.

− Implementation: The result of the current designiteration. This could be a Rapid Prototype, a VirtualPrototype or a Production Component. This processincludes (automatic) production and test of hardwareand software, integration of the software on the targethardware and validation of the component. Co-design,Hardware/Software synthesis and co-verification areessential techniques to use in this process.

The other nodes shown in the diagram are to control thedevelopment lifecycle. These are the planning step, thecontrol point (system review) and the developmentcontrol artefacts. The development lifecycle is controlledby:

− Plan Development: plan the development of thesignal processing sub-system using as input the

requirements and outputting the initial risk registerand the development plan.

− System Review: at the end of each complete cyclethrough the design processes a review needs to takeplace. It is essential that this is a system level reviewrather than component one. That is, this review mustinclude all the system design authorities, who have aninterest in the signal processing component. This doesnot mean that a complete review is needed for eachiteration through the processes, but that at the least thesystem design authorities should be informed ofprogress at this point. The conditions to determine thescope of each review should be laid out in thedevelopment plan, the scope will of course depend onthe stage of component development.

The artefacts needed for this control are:

− Requirements: the signal processing requirementshanded down form the overall system design process.

− Risk Register: a list of all the current identified risksalong with their severity and priority order.

− Development Plan: a plan for the development of thesignal processing component giving all the processesand estimates of the number of iterations required andthe time allowed.

At the end of a cycle through the processes the state ofthe development is reviewed, by considering the status ofthe risks in the risk register. A decision is then made asto the completeness of the development. If not completeand it is within the current development plan thenanother iteration is made. If it is not in the plan, then theplan must be reviewed and updated as necessary. If thedevelopment is complete, then the results (theappropriate artefacts) are passed to the overall systemdevelopment team for integration into the system.

B. Anatomy of Iterative Processes

Each of the processes described in the previous sectioncan be represented as a set of activities, required artefactsand the relationships between them (cf. Figure 2).Although the activities of, real concrete, processes willvary according to the particular process and the type ofdevelopment being undertaken, it is possible to representthe overall structure in an abstract manner by a series ofgeneric activities. The figure shows these activities andthe control artefacts involved, the connection to otherprocesses in the component development lifecycle andthe relationships between them all.

The nodes in the diagram above either represent genericactivities, which are described below, or controlartefacts, which were described in the previous section.


STW/SAFE99

Requirements

Risk Register

Risk Analysis Definition Development Validation

Development Plan

From Previous Process

To Next/PreviousProcess

Review

In fo rm a tio n F lo wA ctiv ity F lo w

K ey : A ctiv ity A rtefa ct

Figure 2: Anatomy of an Iterative Process

These generic activities are:

− Risk Analysis: analyse the requirements, anyavailable process artefacts, the risk register and thedevelopment plan to determine what should beachieved in the current pass through this process.

− Definition: the definition and documentation of theobjectives for this iteration. This will include creatingor updating any design and test documents and/or datainvolved.

− Development: develop the object(s) (one or more ofthe design artefacts) of this iteration according to thedefinition made in the previous activity.

− Validation: validate the object(s) produced by thisiteration against the objectives and the componentrequirements using the defined tests. Analyse theresults and update the risk register.

− Review: review the requirements, any availabledesign artefacts, the risk register and the developmentplan to determine what course of action needs totaken next. Possible actions are: a new iteration of thesame process (introducing new requirements orrefining existing ones) or move onto the next process.If a new iteration of the process is required and this isnot compatible with the current development plan,then a Development Review must be initiated and theplan updated.

The design artefacts are not shown in the diagram. Theywill be produced and modified by the activities as thedevelopment iterations proceed. As the iterative processproceeds these artefacts will grow in content and becomemore refined. At the end of the development lifecyclethese artefacts along with the control artefacts will be thesignal processing components complete design archivewhich can be reused for the development of similarcomponents and mid-life technology updates.

C. Spiral View of the Development Lifecycle

A spiral (cf. Figure 3) can also represent the iterativedevelopment process described above. Each turn of the

spiral corresponds to one process. For each process thesame types of activities are carried out. The enlargementof the spiral at each process represents the refinementand the increase of the artefacts production.

ACTIVITY 1:Analysis and Selection of the requirementsallocated to SP Subsystem

ACTIVITY 5 : Review

ACTIVITY 2:Definition of SP Subsystem

ACTIVITY 4:Validation of SPSubsystem

ACTIVITY 3:Developmentof SP Subsystem

FUNCTIONAL DESIGN

SPECIFICATION

ARCHITECTURE DESIGN

IMPLEMENTATION

HIGH LEVEL OF REFINEMENT

LOW LEVEL OF REFINEMENT

Figure 3: Spiral view of the development lifecycle

V. Benchmarking of a RADAR application

A. Benchmark objectives

The objectives of the benchmark program is to measurethe performance of the ESPADON signal processingdesign environment with respect to the basic ESPADONgoals: reduction in the product lifecycle cost, lifecycletime, and improvement of the product quality. In additionto this, metrics are also required for the productdevelopment with the ESPADON design environment.Examples of product performance metrics include cost todesign, cost to manufacture and conformance torequirements.

The benchmark program is structured to accomplish fourmajor goals:

1. Evaluation of the ESPADON Design Environmentdevelopment process.

2. Evaluation of the ESPADON tool integration andutilisation.

3. Evaluation of the Signal Processing product producedwith ESPADON.

4. Dissemination and evaluation of the results.

The improvements of the ESPADON methodology andtools are to be measured relative to the industrial currentpractice. This provides a basis for evaluating theESPADON goals of reduced design time, reduced cost,and improved quality.


IEEE/ProRISC99

B. Adaptive digital beamformer application

The ESPADON objectives will be demonstrated bybenchmarking an adaptive digital Beamformer (BF)application for multibeam radar, see Figure 4.

Plane waveimpinging R

eceivers, A/D

, BF

1

8

1 stripline antenna

Output beam

sFigure 4: Multi stripline receiver antenna array signals are

transformed into a beam pattern in elevation

The function beamformer is part of the functional chainof an X-(H new NATO) band air surveillance radar. Theantenna of the radar comprises a vertical array of, forexample, 8 elements each of which is a horizontal linearstripline array of dipoles. The array is used as a transmitantenna as well as a receive antenna. As a transmitantenna the power splitter distributes the RF poweramong the elements (linear arrays) via phase shifters andcirculators. This results in a transmit beam whichilluminates targets within the desired elevation coverageenvelope. As a receive antenna each of the 8 arrayelements is connected directly to an individual receiverand an A/D converter. Each array element is sensitiveover the desired elevation coverage. Elevation beams areformed by the digital beamformer that performs an 8point FFT or FIR algorithm on the outputs of the 8receiver channels (cf. [8]). In this way a multibeamreceive system is formed (see Figure 5). The benchmarkconcerns only the receiver beamforming function, thetransmit beamforming function is implemented by ananalogue system.

The beamformer is adaptive with respect to the shipscourse and speed, and the ships roll and pitch movement.This results in a phase correction that is applied to thecomplex data stream prior to the beamforming, togetherwith windowing and calibration correction.

The application contains all aspects of a radar signal-processing element as it is found in modern radar

systems nowadays. This includes mode switching,synchronous/asynchronous data and control flow.

6 simultaneousreceived beams

Transmit pattern

Beam 6

Elevation

Ground range

Receive pattern(after beamforming)

Beam 5

Beam 4

Beam 3

Beam 2

Beam 1

Figure 5: Example of resulting multi beam pattern in elevation for aneight channel to six beam beamformer

Adaptive beamforming is characterised by high datarates (up to 20 Mbytes/sec for each channel/beam) andcorner turn processes. The signal processing architectureon which the algorithm will be implemented thereforeasks for high-end multi-processor machines with high-speed crossbar interconnect between processing nodes.The selected crossbar interconnect has a peak throughputof 267 MB/s per crossbar connection and also gives thedesired flexibility needed for rapid prototyping in thesense of ESPADON. For the processing element the 4th

generation Motorola PowerPC processor is selected: theAltiVec processor. This processor is similar to theprevious version of the PowerPC with a 128-bit vector-processing unit added, which is well suited for signalprocessing algorithms.

In Figure 6 the set-up of the benchmarking environmentin visualised. The ESPADON design methodology willbe applied to the beamformer application. Of coursevarious other functionality needs to be implemented totest the application. Stimuli signals are generated off-lineand stored into memory for real-time play back.Resulting output or intermediate data is stored inmemory for off-line evaluation and comparison with thefunctional reference model.

Generate & storesignals

Play back storedsignals from memory

in real-time

PerformBeamforming

function

Store (partial) resultsin real-time in

memory

Parameter/modedefinition via MMI

Result comparison to(pre-) defined

outcome

Stimuli generator Test bench

SimulateBeamforming

function

Functional reference model

Figure 6: Benchmarking environment and test-bed set-up


STW/SAFE99

VI. Metrics

ESPADON benchmarking metrics are quantifiablemeasures of either the ESPADON process or products.The principal goal of the benchmark measurements is toaccumulate data to substantiate improvements in theprimary ESPADON goals of reduced design cycle time,reduced cost, and improved quality. These are allexamples of performance related metrics and do notexplicitly require measures of complexity.

However, metrics, such as design cycle time, clearlydepend on the complexity of the design undertaken.Therefore, in order to compare ESPADON performanceimprovements over successive benchmarks, complexitymeasures are essential. As a simple example, the totalnumber of non-commented source lines of code(NCSLOC) is a measure of software complexity. Sincethe time required to develop a software application isrelated to complexity, design cycle time will generallyincrease as the amount of required code increases,although not necessarily linearly. Without some form ofnormalisation, measures of how long it took to developsoftware for a benchmark are meaningful only in thenarrow context of the benchmark application. However,by dividing complexity (NCSLOC) by implementationeffort (man-days) a normalised metric, lines of code perman-day is obtained which can be compared to otherbenchmarks, as well as to industry standard practice. Onemust recognise, however, that even normalised metricssuch as "lines of code per man-day," are non-linearfunctions of the number of programmers and the size ofthe problem. Since the benchmarks are similar in termsof duration and level of effort, comparison of normalisedmetrics across benchmarks should be feasible.

A. Parametric cost estimation

Parametric Cost Estimation (PCE) tools are a goodalternative approach to handle the problems sketched.The PCE tools use a cost estimating relationship(equations, table of graph) to predict cost as a function ofsize, performance variables, applicable technology andother parameters. The PCE tools are to be considered forat least three reasons:

1. Their parameters (the cost drivers) are useful fordefining the ESPADON metrics.

2. The product life-cycle cost reduction can not bemeasured within the ESPADON benchmarkingproject but could be estimated from the benchmarkdevelopment metrics, using the PCE tools andmethods.

3. To compare the complexity of one benchmark taskrelative to another benchmark task.

There are at least 18 commercial companies that providePCE products for software development, in addition tovarious tools from research institutes. The PCE toolsrequire a variety of inputs to perform the cost estimationfunction. These inputs form a basic set of metrics thatcan be used to track the progress of ESPADON. Inaddition, the cost estimates can be used to identify areasin which progress is being made (e.g., a measured costwhich is less than the standard practice-based predictivecost estimates indicates potential achievement of aESPADON goal in a particular area).

An alternative approach in PCE tooling is the use offunction points. Function point analysis is an alternativeto counting lines of code for software size. It is astructured method of problem solving. It is a technique tobreak data processing systems into smaller components,so they can be better understood and analysed. Thesoftware size is measured by quantifying its functionalityprovided to the user based primarily on the logicaldesign. It is therefore based on logical functionality fromuser view rather than physical files, screens andprograms. The objectives of function point analysis areto:

1. Measure functionality2. Independent of technology3. Simple enough to minimise the cost4. Consistent

The basic function types available are transactionfunction types and data function types. The first consistsof the transaction types external inputs, external outputsand external inquiries. The second comprises internallogical files and external interface files.

In the following a first set of metrics, and groups ofmetrics will be presented. The most important ones arethe principle metrics which relate directly to the maingoals of ESPADON.

B. Principle metrics

Principle metrics are directly related to the performanceof both the ESPADON process and products: reducedlife-cycle time, reduced cost, and improved quality:

1. Design cycle Metrics: related to the reduction indevelopment time, like: software and hardware reuse,productivity, and cost of tool usage.

2. Product costs: These metrics are related to thereduction of the development costs. These costs aredefined by cost to produce a unit and supportingcosts.

3. Product quality: The improvement of the productquality is measured by metrics like: hardware andsoftware defects, time to repair, and MTBF.


IEEE/ProRISC99

C. Additional metrics

Next to the principal metrics there are four other groupsof metrics that will be monitored:

1. Tool oriented metrics: Metrics related to theintegration of tools and the ease of use and uniformityof the design environment.

2. Application complexity metrics: Applicationcomplexity metrics endeavour to capture thebenchmark application complexity, independent ofhardware and software implementation.

3. Product complexity metrics: For each product, forexample, software, hardware, and documentation,complexity metrics are required to weight the productefficiency against the implementation difficulty.

4. Product performance metrics: Performance of theproducts produced is not synonymous with theESPADON performance itself. Important is thatappropriate metrics are collected and analysed.

VII. Conclusions

In this paper we have presented a developmentmethodology that should significantly decrease thedevelopment cost of signal processing militaryequipment. This methodology emphasises a risk drivenlife cycle, iterative developments, reuse andcapitalisation.

A realistic radar signal processing application, i.e. theadaptive beamformer, is selected to benchmark theESPADON methodology and design environment. Thisapplication will be implemented, using the rapidprototyping tools (automatic code generation) in theESPADON design environment, on a high-end COTSsignal processing platform using high-speed cross-barinterconnection technology.

During the benchmarking process a limited number ofmetrics will be collected to measure the improvement ofthe new methodology with respect to the current practiceof military system design. Parametric cost estimationtools will be used to predict the improvement of theproduct life-cycle costs.

The ESPADON consortium will disseminate the finalresults to the military industry community.

VIII. Acknowledgements

The authors would like to gratefully acknowledge thesignificant improvements of the ESPADONmethodology brought by Mr. Ian Alston and Mr. IanPowell of the Marconi Research Centre. We would also

acknowledge the valuable contributions of the othermembers of the ESPADON consortium.

IX. References

[1] M.A. Richards, A.J. Gadient, G.A. Frank, “RapidPrototyping of Application Specific SignalProcessors”, Kluwer Academic Publisher, February1997.

[2] D. Aulagnier, B. Saget, “The ESPADONProgramme: Environment for Signal ProcessingApplications Development & prOtotypiNg”,Proceedings Conférence Adéquation AlgorithmeArchitecture, 23-24 March 1999, Lille France.

[3] D. Aulagnier, J.J. Hunink, D. Muller, “TheESPADON Programme”, Proceedings of RADAR'99International Conference on Radar Systems, Brest,17-21 May 1999.

[4] MCC/OMI Report, “Hardware/Software Co-Designstudy report”, 1997.

[5] J.S. Pridmore and W.B. Schaming; “RASSPMethodology Overview”, Proceedings 1st AnnualRASSP Conference, Arlington VA, USA, August15-18, 1994.

[6] J.P. Calvez, “Spécification et Conception desSystèmes”, Ed. Masson, 1991.

[7] E.A. Lee, “Heterogeneous Modelling and Design”,PTOLEMY Annual Report 18/11/96-15/11/97, UCBerkeley, 1997.

[8] H. Krim, M. Viberg, “Two Decades of Array SignalProcessing Research”, IEEE Signal ProcessingMagazine, pp. 67-94, July 1996.


STW/SAFE99

rapid prototyping of radar signal processing algorithms · rapid prototyping of radar signal...

Documents