Implementation of a Digital Radio Frequency Memory in a Xilinx Virtex-4 FPGA

Examensarbete utfrt i elektroniksystem vid Tekniska hgskolan i Linkping av Kristian Gustafsson LITH-ISY-EX--05/3742--SE
Linkping 2005

Implementation of a Digital Radio Frequency Memory in a Xilinx Virtex-4 FPGA

Examensarbete utfrt i elektroniksystem vid Tekniska hgskolan i Linkping av

Kristian Gustafsson LITH-ISY-EX--05/3742--SE

Handledare:

Anna Goman
Saab Bofors Dynamics AB

Anders Nyhln
Saab Bofors Dynamics AB

Examinator:

Kent Palmkvist
isy, Linkpings Universitet

Linkping, 22 December, 2005

Avdelning, Institution Division, Department Division of Electronics Systems Department of Electrical Engineering Linkpings universitet S-581 83 Linkping, Sweden Sprk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats vrig rapport ISBN ISRN

Datum Date

2005-12-22

LITH-ISY-EX--05/3742--SE Serietitel och serienummer ISSN Title of series, numbering

URL fr elektronisk version http://www.es.isy.liu.se http://www.ep.liu.se/2005/3742

Titel Title

Implementation av ett digitalt radiofrekvent minne fr en Xilin Virtex-4 FPGA Implementation of a Digital Radio Frequency Memory in a Xilinx Virtex-4 FPGA

Frfattare Kristian Gustafsson Author

Sammanfattning Abstract Digital Radio Frequency Memory (DRFM) is a technique widely used by the defense industry in, for example, electronic countermeasure equipment for generating false radar targets. The purpose of the DRFM technique is to use high-speed sampling to digitally store and recreate radio frequency and microwave signals. At Saab Bofors Dynamics AB the technique is used, among others, in the Electronic Warfare Simulator (ELSI). The DRFM technique is implemented in a full-custom ASIC circuit that has been mounted on circuit boards in ELSI. Today, the progress in the programmable hardware eld has made it possible to implement the DRFM design in a Field Programmable Gate Array (FPGA). The FPGA technology has many advantages over a full custom ASIC design. Hence, the purpose of this masters thesis has been to develop a new DRFM design that can be implemented in an FPGA, using a hardware description language called VHDL. The method for this masters thesis has been to rst establish a time plan and a requirement specication. After that, a design specication has been worked out based on the requirement specication. The two specications have served as a basis for the development of the DRFM circuit. One of the requirements on the design was that the circuit should be able to communicate through an external Ethernet interface. A part of the work has, thus, been to review available external Ethernet modules on the market. The result is a DRFM design that has been tested through simulations. The tests shows that the design works as described in the design specication.

Nyckelord Keywords FPGA, DRFM, VHDL, Xilinx, Saab Bofors Dynamics, Mentor Graphics, Virtex-4, Ethernet, VMEbus

Abstract
Digital Radio Frequency Memory (DRFM) is a technique widely used by the defense industry in, for example, electronic countermeasure equipment for generating false radar targets. The purpose of the DRFM technique is to use high-speed sampling to digitally store and recreate radio frequency and microwave signals. At Saab Bofors Dynamics AB the technique is used, among others, in the Electronic Warfare Simulator (ELSI). The DRFM technique is implemented in a full-custom ASIC circuit that has been mounted on circuit boards in ELSI. Today, the progress in the programmable hardware eld has made it possible to implement the DRFM design in a Field Programmable Gate Array (FPGA). The FPGA technology has many advantages over a full custom ASIC design. Hence, the purpose of this masters thesis has been to develop a new DRFM design that can be implemented in an FPGA, using a hardware description language called VHDL. The method for this masters thesis has been to rst establish a time plan and a requirement specication. After that, a design specication has been worked out based on the requirement specication. The two specications have served as a basis for the development of the DRFM circuit. One of the requirements on the design was that the circuit should be able to communicate through an external Ethernet interface. A part of the work has, thus, been to review available external Ethernet modules on the market. The result is a DRFM design that has been tested through simulations. The tests shows that the design works as described in the design specication.

Acknowledgements
This masters thesis work has been carried out at Saab Bofors Dynamics AB in Linkping as a part of a Master of Science in Applied Physics and Electrical Engineering. The result will hopefully be of great use in the Electronic Warfare Simulator at SBD. I would like to thank everyone that have helped and encouraged me during the work with this thesis. Especially, I would like to thank the following people: Ulf Malmqvist at SBD, for giving me the opportunity to do my masters thesis at SBD and for all help and support during my time at the company. My supervisor Anna Goman at SBD, for all help with the computer resources, software and the VHDL coding. Anders Nyhln, my second supervisor at SBD, for all the time he has spent on explaining the complex systems in ELSI for me and for all support given. Sture Carlson at SBD, for the detailed review of my thesis report and for all help with litterateurs used for the technology chapter of this report. Leif Tranell at SBD, for all the support with troublesome software. My opponent Oskar Sthl for his valuable comments and feedback on my thesis report. My examiner Kent Palmkvist at the Division of Electronics Systems, Depertment of Electrical Engineering at Linkping University for valuable comments on the report.

vii

List of Acronyms
A/D ADC ASIC ASMBL BRAM CLB CMOS CSMA/CD CW D/A DAC DCM DIX DRFM DSP ECM ELSI FPGA FSM GPIO HSD HSDE HWIL IC IF IEEE IOB IP IP LAN/MAN LiU LUT LVDS Analog to Digital A/D Converter Application Specic Circuit Advanced Silicon Modular Block Block RAM Congurable Logic Block Complementary Metal-Oxide Semiconductor Carrier Sense Multiple Access with Collision Detection Continuous Wave Digital to Analog D/A Converter Digital Clock Manager Digital Intel Xerox Digital Radio Frequency Memory Digital Signal Processing Electronic Countermeasure Electronic Warfare Simulator Field Programmable Gate Array Finite State Machine General Purpose Input/Output High-Speed Data High-Speed Data Enhanced Hardware-in-the-loop Integrated Circuit Intermediate Frequency Institute of Electrical and Electronics Engineers Input/Output Block Intellectual Property Internet Protocol Local and Metropolitan Area Network Linkping University Look-Up Table Low Voltage Dierential Signaling

x MAC MDI MII OUI PAR PHY PRF RAM RF SBD SLOS SoC TCP TEG UDP UUT VHDL VHSIC VME Media Access Control Media Dependent Interface Media Independent Interface Organizationally Unique Identier Place and Route Physical Layer Pulse Repetition Frequency Random-Access Memory Radio Frequency Saab Bofors Dynamics AB Synthetic Line of Sight Software-on-Chip Transmission Protocol Target Echo Generator User Datagram Protocol Unit Under Test VHSIC Hardware Description Language Very High Speed Integrated Circuit VersaModule Eurocard

Contents
1 Introduction 1.1 Background . 1.2 Purpose . . . 1.3 Method . . . 1.4 Limitations . 1.5 Thesis outline 1 1 2 2 3 3 5 5 6 6 7 7 10 10 11 13 14 15 15 16 19 20 20 21 21 23 23 24 26 29 29 29

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2 Technology & Background 2.1 Saab Bofors Dynamics AB . . . . . . . . . 2.2 Radar seekers . . . . . . . . . . . . . . . . 2.3 Electronic countermeasures . . . . . . . . 2.4 Digital Radio Frequency Memory . . . . . 2.5 The Electronic Warfare Simulator . . . . . 2.6 The Target Echo Generator . . . . . . . . 2.7 The current DRFM circuit . . . . . . . . . 2.7.1 The function of the DRFM . . . . 2.8 The new DRFM circuit . . . . . . . . . . 2.9 Field Programmable Gate Array . . . . . 2.10 Choosing the FPGA circuit . . . . . . . . 2.11 The Virtex-4 family . . . . . . . . . . . . 2.11.1 Hardware resources in Virtex-4 . . 2.11.2 Intellectual Property blocks . . . . 2.11.3 Xilinx CORE generator . . . . . . 2.12 Communication . . . . . . . . . . . . . . . 2.12.1 VMEbus . . . . . . . . . . . . . . . 2.12.2 Ethernet . . . . . . . . . . . . . . . 2.12.3 The Internet protocol suite . . . . 2.12.4 Choosing communication interface 2.13 Choosing Ethernet interface . . . . . . . . 2.13.1 The choice of Ethernet module . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

3 Implementation & Testing 3.1 Layout decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 The memory . . . . . . . . . . . . . . . . . . . . . . . . . . xi

xii 3.1.2 The interface . . . . . The design ow . . . . . . . . Tools . . . . . . . . . . . . . . The DRFM design . . . . . . 3.4.1 Inputs and outputs . . 3.4.2 The control logic block 3.4.3 The DRFM memory . 3.4.4 The external interface 3.4.5 Other resources . . . . Testing methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 30 32 33 34 35 38 38 40 40 43 43 43 45 45 47 47 48 48 48 51 53 54 63 77

3.2 3.3 3.4

3.5

4 Results & Discussion 4.1 Results . . . . . . . . . . . . 4.1.1 Cases tested through 4.2 Performance . . . . . . . . . 4.3 Diculties . . . . . . . . . .

. . . . . . . simulation . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5 Conclusions & Future work 5.1 Conclusions . . . . . . . . . . . . . 5.2 Future work . . . . . . . . . . . . . 5.2.1 Improvement of the design 5.2.2 The DRFM circuit board . Bibliography A Time Plan B Requirement Specication C Design Specication D Test Wave Forms

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Contents

xiii

List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 3.1 3.2 3.3 3.4 3.5 3.6 3.7 D.1 D.2 D.3 D.4 D.5 D.6 D.7 The Electronic Warfare Simulator . The interior of ELSI . . . . . . . . The ight motion simulator . . . . The current DRFM . . . . . . . . . Mode A, Trigged mode . . . . . . . Mode B, Delay line . . . . . . . . . Mode C, CW mode . . . . . . . . . Arrangement Slices . . . . . . . . . The DSP48 slice . . . . . . . . . . Screen shot from Coregen . . . . . The VHDL design ow . . . The DRFM circuit . . . . . Control logic . . . . . . . . Signals . . . . . . . . . . . . The four-phase protocol . . Test bench . . . . . . . . . Simulation using ModelSim Test Test Test Test Test Test Test of of of of of of of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 9 11 12 12 13 17 18 20 31 33 35 37 39 41 42 77 78 79 80 81 82 83

writing and reading the memory. . . . . . . . writing to the registers. . . . . . . . . . . . . reading from the registers. . . . . . . . . . . mode A. . . . . . . . . . . . . . . . . . . . . . mode B. . . . . . . . . . . . . . . . . . . . . . mode C. . . . . . . . . . . . . . . . . . . . . . updating the registers in real-time (Mode A).

List of Tables
3.1 3.2 4.1 Ports in the new design . . . . . . . . . . . . . . . . . . . . . . . . Table over the registers in the design . . . . . . . . . . . . . . . . . The register settings. . . . . . . . . . . . . . . . . . . . . . . . . . . 34 36 44

xiv

Contents

Chapter 1

Introduction
This chapter serves as an introduction to this masters thesis. It starts with describing the background to why this project was initiated. After that the purpose of the masters thesis is described and the chapter ends with a description of the method used and the limitations of the thesis.

1.1

Background

The Electronic Warfare Simulator, ELSI, is situated at Saab Bofors Dynamics AB (SBD) in Linkping. ELSI is used to test and verify radar seekers capabilities against simulated scenarios of targets and countermeasures [1] . The simulator is depending on a huge amount of advanced hardware. To be able to broaden the type of seekers that can be tested and to meet upcoming new demands the facility is undergoing a constant upgrading. One part of the equipment needed to be upgraded is a Digital Radio Frequency Memory (DRFM) circuit. The original DRFM circuit is a full custom Application Specic Integrated Circuit (ASIC) design developed at SBD in the early 90s. The circuit is running at 200 MHz, a very fast circuit at the time. Due to the technical development in programmable hardware eld, a new DRFM circuit should be possible to develop using FPGA technology instead of ASIC. Field Programmable Gate Arrays (FPGAs) have undergone a major transition the last few years: From being small basic programmable logic hardware, to the newest FPGAs, being large circuits, with transistor count equivalent to the newest PC processors and having advanced integrated logic such as embedded processors and Ethernet capabilities. Designs, earlier only possible to implement as an ASIC, can now be implemented in a single FPGA. There are still benets of developing ASICs due to the small chip size, low power consumption and very low chip costs per unit when a large amount of units have to be manufactured. The disadvantages are the long design time of ASICs, the diculty to alter the design after manufacturing and the expensive development cost when only a small series of chips are needed. Using FPGAs on the other hand, the design can quickly be altered and tested during the development. When only a few chips are needed an 1

Introduction

FPGA solution will be very cheap, both in time and cost, in comparison to an ASIC solution. This is why a solution using an FPGA has been chosen by SBD. This masters degree thesis has been performed in the form of a project, i.e. setting up a time plan and writing a requirement specication as well as a design specication. The idea was to use a working method similar to the methods used at high-tech companies such as SBD. Essential was to secure control of the cost, i.e. spent time, of the project and to be able to supervise the progress of the development of the DRFM circuit. The thesis work has been carried out in accordance with the requirements of the Master of Science degree at Linkping University (LiU) in Sweden. The examination has been done by assistant professor Kent Palmkvist at the division of Electronics Systems, a part of the Department of Electrical Engineering at LiU.

1.2

Purpose

The main objective of the project was to develop a DRFM circuit to be used in the ELSI simulator. The DRFM functions should be implemented in an FPGA using VHDL as the hardware description language for programming the logic. The DRFM should be controlled by a computer. The interface was at rst chosen by SBD to be a standard VMEbus interface but during the project the interface was changed to be an Ethernet interface instead, see Section 2.12. No requirements regarding the component cost of the FPGA were made. To be able to fulll the objectives above, the folowing tasks had to be accomplished: A survey of FPGAs suitable for the project. Study of the design of the VMEbus. Study of the Ethernet standard and a market survey of available Ethernet modules. Review of the available development tools at SBD to be able choose the best tools for the development of the circuit. Development of the DRFM circuit using VHDL.

1.3

Method

The rst task of this project was to establish a time plan for the entire project. The time plan can be found in Appendix A. The time plan was used to estimate the time needed for the dierent phases of the project. The second task was to study the documentation of the DRFM circuit used today. After having established an overview of the function and capability of the present circuit a design requirement specication was composed in collaboration with the ELSI sta at SBD. The specication can be viewed in Appendix B.

1.4 Limitations

The third task was to study design alternatives in more detail, i.e. the choice of the FPGA circuit, the layout of the design, the development tools to be used etc. This ended up in a design specication, available as Appendix C. After the three rst steps of the project the actual development started. This included learning the chosen development tools, VHDL programming, behavioral simulation of the design, synthesis, design implementation and testing the design through timing simulation. This step was the major part of the project in terms of time. After the functionality of the design had been veried the circuit was considered complete. No test in hardware was performed, as the hardware platform to be used for the DRFM circuit had not been developed at the time for this thesis project. Hence, hardware tests had not been included in the time plan.

1.4

Limitations

This thesis project was completed in accordance with the regulation of thesis projects at Linkping University. Due to the limitation in time, the goal of this project has been to develop the architecture and functions of the new DRFM circuit. The communication interface and testing of the logic in hardware have not been part of the project.

1.5

Thesis outline

Chapter 2, Technology & Background, is intended to give the reader the background information needed to understand the implementation of the DRFM design. Chapter 3, Implementation & Testing, describes layout decisions made, the implementation ow used and the implemented design. A discussion is also held around the testing methods. Chapter 4, Results & Discussion, presents the result of the masters thesis and a discussion around the diculties that have come up during the thesis work. Chapter 5, Conclusions & Future work, discusses the conclusions that can be made and future improvements that can be done. The appendices contains the time plan, the requirement specication, the design specication and wave forms from simulations of the design.

Introduction

Chapter 2

Technology & Background

This chapter is intended to give the reader the background information required to understand the implementation of the DRFM circuit. The chapter starts with a description of the company where this thesis project has been performed. It continues with a short technology background of radar seekers, electronic countermeasures and the DRFM technology. After that, the simulator ELSI will be described in more detail. In particular the DRFM circuit used today and the requirements of the new architecture will be explained. Furthermore the dierent technologies and logic blocks needed to implement the design will be described. The chapter ends with a description and a discussion of the communication interface of the DRFM circuit.

2.1

Saab Bofors Dynamics AB

Saab Bofors Dynamics AB (SBD) is a business unit within Saab AB having approximately 1200 employees. The head quarter is located in Karlskoga, but local divisions are also situated in Linkping, Eskilstuna, Gothenburg and Stockholm. SBD develops, markets and produces missile systems and man-portable support weapons. The products are aimed for use at both land, air and above and under water. SBD has customers all over the world, approximately 80% of the companys turnover comes from export, but the Swedish market is still an important base for the company. SBD participates in a number of international collaborations and has also developed own defense products. Well-know, entirely own-developed, products are the anti-ship missile RBS 15, the anti-aircraft missile system BAMSE and the recoilless gun system Carl Gustaf1 .

1 Carl Gustaf is well-known for its appearance in the Steven Spielberg Hollywood movie War of the Worlds in 2005

Technology & Background

2.2

Radar seekers

In the Electronic Warfare Simulator, ELSI, the accuracy and performance of radar seekers in guided missiles are tested. A guided missile is made up of a series of dierent parts. These are used in applications such as propulsion, control and guidance. The guidance of the missile is controlled by the guidance computer. It maneuvers the missile during the ight towards the target pointed out by the radar seeker. A basic radar consists of a radio transmitter, a radio receiver, two antennas and signal-processing circuitry. The radio transmitter sends radio waves, i.e. electromagnetic waves, which radiates from the transmitter antenna. The receiver uses the other antenna to pick up echoes of the waves that have been reected on, hopefully, the wanted target. These echoes are forwarded to the signal-processing circuitry that calculates for example the distance and the direction to the target. As the radio waves travel at constant speed, the speed of light, the distance is possible to calculate according to the formula in example 2.1. Example 2.1: Target distance formula. 1 Tc 2

R= R is the target distance in meters T is the round-trip time in seconds c is the speed of light in m/s [2]

To avoid the transmitter from interfering with the receiver the transmitter usually sends the radio waves in pulses and the receiver is turned o during transmission. The rate at which the transmitter sends pulses is called pulse repetition frequency, PRF. In practice the radar seeker uses only one antenna for both transmitting and receiving waves. In this case the antenna is shared by time multiplexing. The antenna concentrates the energy dissipated in a narrow beam to be able to more precisely detect targets. Due to the narrow area of detection, the beam has to be swept over the region of interest to be able to nd the wanted targets.[2]

2.3

Electronic countermeasures

To avoid being hit by a missile the target, e.g. a ghter jet, can use electronic countermeasures (ECM) to trick the missile. There is a wide variety of ECM techniques that can be used depending on the situation. The simplest example is when an airborne target deploys cha in the air to confuse the missile. Cha are small strips of metal or metal-coated dielectric bers with an optimal length of half of that of the radar signal wave length. A huge amount of these are deployed in the air and can stay there for a long time producing strong radar echoes hopefully

2.4 Digital Radio Frequency Memory

misleading the missile. Other examples are noise jamming and false targets. Noise jamming is intended to increase the background noise making it more dicult to locate the targets. False targets can be generated in dierent ways. The simplest way is to use a transponder which receives the pulse, waits for a certain delay, corresponding to the additional target range, and transmits the pulse back to the seeker. The transmitted false target pulse is hopefully interpreted by the radar seeker as target situated on a certain distance from the real target. To produce more realistic false targets a repeater can be used. The repeater is similar to the transponder but is also equipped with a memory. The memory can be used to store the intercepted radar pulses and using them to display multiple and moving targets on dierent ranges and velocities for the seeker. To be able to fully exploit this principle a digital radio frequency memory (DRFM) could be used.[2]

2.4

Digital Radio Frequency Memory

Digital radio frequency memory, DRFM, is a technique used for storing and recreating radio frequency (RF) and microwave signals. The principle of the DRFM was invented in 1974 at EMI Electronics Ltd in Britain. The basic task is to input an RF signal that has been converted to a frequency low enough to be sampled by a high-speed A/D converter (ADC). The sampled signal is stored in a high-speed memory and can be retrieved and converted back to the original signal using a D/A converter (DAC). A simplication of the DRFM function is to see the DRFM as a variable delay line for radio frequency signals. The technique is often used in electronic warfare applications. In particular DRFMs are widely used in ECM products to generate false radar echoes. SBD markets military products using the DRFM technique, but the technique is also used in the Electronic Warfare Simulator at SBD.[3]

2.5

The Electronic Warfare Simulator

The Electronic Warfare Simulator (ELSI) is a hardware-in-the-loop, HWIL, simulator used to test radar seekers. An HWIL simulator uses an actual individual of the seeker that is presented with a complete simulated target scenario. This is used to verify and test the radar seeker capabilities against simulated scenarios of targets and countermeasures. By using ELSI, dierent conditions and properties of the environment can be simulated (e.g. weather conditions, seeker primings, target behavior, ECM)[1] ELSI is situated in a stand-alone building at the Saab area in Linkping. The test facility was inaugurated in 1994 and the rst tests were carried out in 1995 [1]. The simulator consists of an anechoic chamber, an antenna wall, the ight motion simulator, signal generators and a data and control room, see Figure 2.1. The anechoic chamber is a room with the dimension of 14 m 13 m 10.5 m. The room is electromagnetically shielded and the walls are covered with radar absorbing materials, see Figure 2.2. The material makes the attenuation of the chamber walls at least 50 dB. This is equivalent to reducing a signal to a level 100,000 times

Technology & Background

Figure 2.1. Overview of the Electronic Warfare Simulator.

Figure 2.2. The interior of the anechoic chamber of ELSI.

2.5 The Electronic Warfare Simulator

weaker than its original strength. The high attenuation is a requirement to make the walls invisible to the seeker, instead it just sees the target scenario presented by the simulator. On one of the walls of the chamber 16 radar antennas and transmitters are situated. These are used by the simulator to simulate and present the target scenario for the seeker. The antenna wall is mounted on a framework which is mounted on a concrete foundation. The antennas are placed on a horizontal row with one degrees spacing on a segment of a circle with a radius of 13 meters. The circle has the origin at the axis intersection of the gimbals of the ight motion simulator which is situated on the opposite wall. Normally the radar seeker sweeps its radar beam over a certain angle of the horizon. In the simulator, however, this would not be possible because of the limited width of the antenna wall. Widening the antenna wall by installing more antennas are not feasible because of the huge cost associated with lling the room with antennas. Instead the radar seeker is attached to the ight motion simulator, see Figure 2.3, which during simulations moves the seeker at the same rate as the radar beam so that the beam is always centered to the middle of the antenna wall. To make this solution work the whole target scenario presented by the antenna wall also moves, at the same rate as the radar beam. This way of presenting the simulated scenario is called synthetic line of sight, SLOS.

Figure 2.3. The ight motion simulator in ELSI.

The ight motion simulator, weighing approximately 11 tonnes, is attached to a concrete foundation weighing about 500 tonnes, see Figure 2.1. The concrete foundations for both the antenna wall and the ight motion simulator has been placed on geological stable sand to minimize vibrations. The further minimize the vibrations of the ight motion simulator its foundation is in no way in contact with the rest of the building. Minimizing vibrations are essential to have the radar antennas and the seeker perfectly aligned at all times. Otherwise the simulated scenarios presented by the antennas will not be accurate enough. The control of the simulator and the data collection are handled in the control and data room of the simulator building. The central parts are the two Power-

10

Technology & Background

Hawk 740 computers developed by the American company Concurrent Computer Corporation2 . The two simulation computers updates the hardware with data in real-time during test runs. The last part of ELSI is the signal generators. These contain dierent equipment which handles the transmission of the complete simulation scenario to the antennas. For this masters thesis the most interesting equipment of the signal generators are the Target Echo Generator (TEG).[1]

2.6

The Target Echo Generator

The TEG is the part of the signal generators that this thesis is all about. More precisely, focus is on the DRFM circuits situated on four circuit boards in the TEG. These circuit boards have two main functions: 1. Store target echoes. 2. Control the delay of the echoes during run-time. The delays of the echoes are introduced to be able to simulate the distance to a target. Normally the distance to the target can be several kilometers but in the anechoic chamber of ELSI there is merely 13 meters between the seeker and the antennas. Therefore the echoes are delayed to simulate the distance. This is possible since the delay is equivalent to distance according to the formula in example 2.1. The four DRFM circuit boards are mounted in a VME chassie together with other circuit boards used for generation of dierent trigger signals. The VME chassie, see Section 2.12.1, has a custom made backplane that has been developed at Saab. The backplane is used for external communication and power. The DRFM circuit boards consist mainly of a DRFM circuit and an A/D converter. Each of them generates echoes for one target during simulation. Hence, four targets can be displayed at the same time during run-time. The function of the DRFM circuits will be described in more detail in Section 2.7. The circuit boards are controlled through an interface called High-Speed Data Enhanced (HSDE) interface. The HSD bus is an industry de facto standard developed by Encore 3 . This interface is used to load pulses to the memory in the DRFM circuits and to control the delays during run-time.

2.7

The current DRFM circuit

There are several dierent architectures that could be used to implement a DRFM chip [3]. The architecture used in the current ELSI DRFM is illustrated in Figure 2.4. It consists of a high-speed memory, DSP logic and an integrated DAC. A
2 Concurrent Computer Corporation is a company specialized in real-time computer systems for industry and government, see http://www.ccur.com 3 Encore is a real-time computing company which was acquired by Compro in 2002, see http://www.encore.com

2.7 The current DRFM circuit

11

Figure 2.4. A simplied gure showing the layout of the DRFM circuit used in ELSI today.

controller is also contained in the chip. It can is used for control of the behavior during run-time and for the access to the circuit via the HSDE interface. The basic function of the DRFM circuit is as follows: The original radio signal (RF) is converted to a lower, intermediate frequency (IF) that can be A/D converted and stored, temporary, in the high-speed memory in the DRFM chip. The memory is dual-ported so that reading and writing can be done independently and at the same time. Therefore the stored radio signal can be read at the same time as it is recorded. Optional advanced DSP functions can be applied on the output of the memory. The output can also be connected directly to the DAC. The DAC, inside the chip, converts the signal back to the IF. The RF signal is then restored by converting the IF signal to the original frequency. This analog output is used by the signal generators in ELSI to generate the radar echoes sent back to the radar seeker. The DRFM circuit used in ELSI today is a full custom ASIC design4 developed at Saab in the early 90s. Several newer versions of the design have been developed. Used today in the TEG is the second version5 of the DRFM circuit which was developed in 1994. In the used DRFM circuit there is also a parameter server which can be used in ECM applications. This parameter server places functionality in the DRFM circuit instead of in the simulation software which makes the DRFM circuit more independent.

2.7.1

The function of the DRFM

The current DRFM circuit can be set to work in three dierent modes. All three modes will also be available in the new DRFM circuit. The three modes are used in three dierent contexts. The rst mode, trigged mode or mode A, is used when the pulse from the radar seeker is known. The equivalent of the mode described in the previous section is called delay line mode or mode B. The third mode, CW mode or mode C, is not intended to be used during simulations. Instead it is used for calibration and testing of equipment.
4 The 5 DRFM

manufacturing process used is 0.8 micron BiCMOS process version 2b is used in ELSI today. Up to version 4 has been developed.

12

Technology & Background Next follows a more detailed description of the function of each mode:

Mode A, Trigged mode The trigged mode is used when the waveform of the pulse is known and if the tested radar seeker is able to deliver a trigger signal for every radar pulse it transmits. In Figure 2.5 the trigger signal, PRF, is used as input to the circuit instead of the seeker pulse. When using this mode the pulse is loaded into the memory of the DRFM circuit before the simulation starts. For every trigger signal, the stored pulse is transmitted via RFout after the corresponding delay. The time the wave form is delay after the trigg pulse corresponds to a distance according to example 2.1.

Figure 2.5. A simplied gure showing mode A, trigged mode.

Mode B, Delay line During this mode the DRFM circuit is used as a delay line, meaning that the radar echo is stored in the memory for a specied time and after that transmitted back. In Figure 2.6 the radar echo is loaded to the memory via the RFin port. The echo is delayed according to the variable delay applied and then transmitted via RFout.

Figure 2.6. A simplied gure showing mode B, delay line.

Mode C, CW mode The third and last mode of the DRFM is used during test and calibration. This mode is called CW mode, where CW is an acronym for continuous wave. No input is used during this mode, instead a wave form, often a sine wave, is loaded to the memory. During run-time the wave form is transmitted repeatedly again to form a continuous wave that can easily be measured, see Figure 2.7.

2.8 The new DRFM circuit

13

Figure 2.7. A simplied gure showing mode C, CW mode.

2.8

The new DRFM circuit

The version of the DRFM circuits used today was developed in the middle of the 90s. Today the design is obsolete and because of this support on the circuits would be very expensive, should any of the circuits fail. This has made SBD taken the decision to develop a new DRFM circuit and, thus, new DRFM circuit boards. In the end the meaning is that the entire TEG, were the circuit boards are situated, shall be replaced with a new one. Below, the most important reasons for SBD to develop a new circuit and new circuit boards are listed: The old design is obsolete. The control of the old circuit is too complex. Maintenance of the circuit boards are extremely expensive. No standardized backplane in the TEG. A desire to have a design that is easy to upgrade and that is future proof. New demands on the simulator due to requirements of future test runs: Increased maximum target distance. Support for up to ve digital outputs used for triggering ECM equipment. New digital outputs. The items above resulted in a collection of requirements for the new design. The requirements was put together in a requirement specication, see Appendix B. The requirement specication served as a basis when a design specication was written. In the design specication the layout of the circuit and the functions to be implemented was specied as well as other characteristics of the circuit. The complete design specication can be found in Appendix C, but here follows a short summary of the new design: The circuit will be implemented in an FPGA using VHDL code. The functional modes (A, B and C) will be the same. The parameter server will not be implemented, instead this functionality is placed in software in the simulation computers.

14

Technology & Background The communication interface will be an Ethernet interface instead of the HSDE interface. The new demands on the simulator, see above, will be fullled.

A description of the implementation of the circuit can be found in Section 3.4.

2.9

Field Programmable Gate Array

FPGA is short for Field Programmable Gate Array and is a technology for implementing advanced hardware without having to do an expensive and time consuming full custom design. An FPGA is a chip which consists of complex logic cells containing e.g. look-up tables (LUTs) and multiplexers. The cells are connected to each other via interconnections. Both the cells and the interconnections are programmable by the designer which makes FPGAs an easy and economic way to implement logic in hardware.[4] The connection between the logic cells in an FPGA is managed by programmable switches. These can be based on dierent technologies. The three most common technologies are RAM-based technology, ash-based technology and antifuse technology. The former two are similar in the way that they are both reprogrammable whereas the anti-fuse technology has one-time programmable switches. The dierences between RAM-based and ash-based FPGAs, on the other hand, is that the rst is a volatile technology. Volatile means that if power fails to the circuit the content is lost. Therefore, when using RAM based technology a nonvolatile memory chip, such as a ash chip, is needed outside the FPGA circuit to store the logic implementation. The content of the non-volatile chip is loaded to the FPGA on power-on which means that some extra start-up time is needed for RAM-based FPGAs. Flash-based FPGAs does not need an external ash chip, as RAM-based FPGAs does. Instead programmable, non-volatile ash cells, which controls the switches, are integrated in the chip. The advantage of this solution, apart from that no external memory chip is needed, is that the circuit is live directly at start-up because of the non-volatile property of the ash cells. The disadvantage is that the speed of the circuits is lower in comparison to RAM-based FPGAs. The anti-fuse technology instead uses a dielectric material in the switches. Normally this material has high impedance but when a high enough voltage is applied over the switch the material is altered to have low impedance which means that the switch closes. This process can not be undone but on the other hand no extra circuit or start-up time is needed as with RAM-based FPGAs.[4, 5] The logic in the FPGA is implemented using a hardware description language (HDL). The two most common languages are VHDL and Verilog. The HDL source code for the implementation is translated to a bit-le using a set of software tools that the FPGA manufacturer supplies. The bit-le is used to program the FPGA according to the HDL design. A more detailed description of the VHDL design ow can be found in Section 3.2.

2.10 Choosing the FPGA circuit

15

2.10

Choosing the FPGA circuit

The prerequisite of this project was that the design should be possible to implement in an FPGA. This was a demand by SBD and the reason for that was that SBD wanted to be able to more easily change the design if needed in the future. The rst task was thus to choose an FPGA for the implementation. The division of SBD where this project has been carried out has a lot of experience of using the Actel FPGAs. Hence it would have been a natural decision to use one of their circuits. The disadvantage with the Actel FPGAs is that Actel uses the anti-fuse switch technology in their FPGAs, a technology that does not match the demand of a design that is easy to update. The author of this report, however, has a lot of experience of Xilinx FPGAs, which has a RAM-based switch technology. Therefore the Xilinx FGPAs were more closely studied to be able to dierentiate the FPGA needed. First of all a decision had to be made as of what classication the FPGA should have. There are dierent circuit classications which specify the condition of the environment (temperature, radiation etc.) that the circuit can be used in. Due to the fact that the circuit will be used in a computer server room that is air conditioned, no circuit with special classication was needed. That means that all Xilinx FPGAs could be used for the design. The Xilinx FPGAs are divided into dierent families depending on the circuit generation they belong to. The latest and most advanced generation is the Virtex4 family and this was also the family chosen for the project. The choice was based on several facts: The Xilinx design ow is well-known by the author of this thesis. The Virtex-4 family is state-of-the-art technology, meaning that high performance can be expected from the design. The Virtex-4 family is in the beginning of its life span, meaning that support for the products will be given for a long time. The larger circuits in the Virtex-4 family has enough integrated memory to be used for the dual-port memory needed for the design. This means no external memory would be needed.

2.11

The Virtex-4 family

Introduced in 2004 the Virtex-4 family is Xilinx latest and most advanced FPGA family. The product family is based on the older generation Virtex-II Pro FPGAs but in contrast to the .13 micron6 process used when manufacturing the VirtexII circuits a .09 micron process is used for the Virtex-4 family. To better target dierent segments of the market the family is divided into three platforms: the LX, SX and FX platforms. The three platforms aim at four dierent application
6 Micron is another term for a micrometer, i.e. a millionth of a meter. In this case it refers to the width of the smallest patterned transistor gate.

16

Technology & Background

domains: a logic domain, a DSP domain, a connectivity domain and an embedded domain. To meet these domain requirements the platforms are optimized in dierent ways. The LX platform is optimized towards highest performance and logic density, SX towards highest performance signal processing applications and FX towards Software-on-Chip (SoC) designs and high speed serial connectivity. In total the three platforms consists of 17 circuits.[6][7] To be able to more easily develop these rather dierent platforms of FPGAs Xilinx has developed an architecture called Advanced Silicon Modular BLock (ASMBL, pronounced assemble). This architecture was developed to address the problem that in the past an FPGA designer could only choose between small or large and slower or faster FPGAs within the same family. Earlier larger FPGAs had more special features and smaller had less of the same features [8]. The new ASMBL architecture makes it possible for Xilinx to develop FPGAs with a mix of the various special features and hardware blocks available that does not depend on the size of the FPGA. Thus the three platforms could become reality.[6][7]

2.11.1

Hardware resources in Virtex-4

This section gives a brief description of the hardware resources, interesting for this project, in the Virtex-4 FPGAs. It starts with a description of the main logic resource, the Congurable Logic Blocks, and a memory resource called BlockRAM. After that the XtremeDSP slice which has been introduced with the Virtex-4 family will be described. All FPGAs also have Digital Clock Managers which is used for managing the dierent clocks available in the design. The FX platform, which is aimed at embedded processing and serial connectivity, is equipped with another three hardware resources. From the older FPGA generation comes an embedded PowerPC405 core which was introduced with the Virtex-4 successor Virtex-II Pro. New for the Virtex-4 generation is the introduction of the integrated tri-mode Ethernet MAC block, for Ethernet capabilities, and the RocketIO transceivers, for fast communication. These FX specic hardware resources will not be described in more detail, though, as this thesis will only lightly touch the use of them.[6, 7] Congurable Logic Blocks The main logic resource in the Virtex-4 FPGA is the Congurable Logic Blocks (CLBs). The CLBs can be connected to each other via programmable interconnections and switching matrices, see Figure 2.8. Each CLB is made up of four slices. There are two dierent kinds of slices in each CLB. The two kinds are called SLICEM and SLICEL. Common to both of the slices are: two function generators (or look-up tables) two storage elements arithmetic logic gates large multiplexers

2.11 The Virtex-4 family fast carry look-ahead chain

17

Figure 2.8. The gure shows the arrangement of the slices within the CLB. [9]

SLICEM also has the ability to support two additional functions: storing data using distributed RAM and shifting data with 16-bit registers.[9] BlockRAM Apart from the Distributed RAM situated in the CLBs the Virtex-4 FPGA also has what Xilinx calls BlockRAM (short BRAM). These are integrated blocks of memory placed in columns over the entire Virtex-4 chips. Each BlockRAM primitive is 16 Kbit (18 Kbit if parity bits are included) and is a true dual-port memory7 . The circuits comes with varying amounts of BlockRAM, from 864 Kbits in the smallest one up to 9,936 Kbits in the largest FPGA. The primitives can be combined together to form larger memory areas and can be congured to have dierent widths and depths. The best and easiest way to combine them is to use Xilinx CORE Generator which is used for customizing hardware resources in the FPGAs, see Section 2.11.3.[9] XtremeDSP slice The XtremeDSP slice, or DSP48 slice, was introduced with the Virtex-4 family. This block, as the name indicates, was developed to accelerate DSP designs, a very common application for FPGAs nowadays. The slices are fast enough to be clocked in up to 500 MHz according to Xilinx[9]. The XtremeDSP slice is available in varying quantities in all Virtex-4 circuits, from 32 slices in the smallest
7 As mentioned in Section 2.7, dual-port means that the memory has two dierent I/O ports that can be used independently.

18

Technology & Background

circuits to 512 in the largest FPGA. In short the DSP block can be described as an 18x18 multiplier followed by a 3-input adder with a 48-bit output. The block can be congured to do various common DSP tasks such as add, multiply, MACC (multiply and accumulate) etc, see Figure 2.9.

Figure 2.9. The gure shows a simplied view of the XtremeDSP slice. The A and B inputs are 18 bits wide and the C input is 48 bits wide. PCIN is an input from a cascaded DSP48 slice. The arrows indicates a wire right shift by 17 bits. [10]

Digital Clock Managers The Digital Clock Managers, DCMs, are advanced logic circuitry for managing clock signals in the design. There are four main features that the DCMs provide in a design: Clock Deskew Frequency Synthesis Phase Shifting Dynamic Reconguration For the implementation of the DRFM design the second feature is the most interesting one. With the help of the frequency synthesis hardware in the DCM, an external input clock can be used to synthesize a new internal clock. The outputs from the DCM provide dierent new clock frequencies derived from the input clock. New frequencies provided is a double frequency, a specied fraction of the

2.11 The Virtex-4 family

19

frequency and an output frequency that is derived from the input frequency by simultaneous division and multiplication. The rst and last feature are also available as 180 phase shifted signals.[9] SelectIO SelectIO is the Virtex-4 technology for supporting a wide variety of I/O standards. The FPGAs provides up to 960 user I/Os that can be congured in up to 20 dierent electrical I/O standards. The SelectIO drivers and receivers are divided into blocks called input/output blocks, IOBs. Each IOB contains both input, output and a 3-state drivers which make them easy to congure for dierent data directions. The IOB is connected to a pair of logical blocks called ILOGIC and OLOGIC. These blocks provide logical resources for the IOB such as output and input registers.[9]

2.11.2

Intellectual Property blocks

To speed up the development of FPGA designs custom Intellectual Property blocks, IP blocks (also called IP cores), can be used. The IP blocks can be of two dierent kinds: hard IP blocks and soft IP blocks. Hard IP blocks are physical blocks of logic in the circuit that are designed for specic purposes, for example the Virtex-4 has hard IP blocks for Ethernet communication and DSP operation, se Section 2.11.1 above. Soft IP blocks uses the available logic resources, CLBs, in the FPGA to create logical functions (e.g. adders, counters and accumulators) and system-level building blocks (e.g. bus interfaces and processors). Next follows a description of the two soft IP blocks interesting for this implementation, a counter and a comparator. Binary Counter The binary counter is a soft IP core from Xilinx which can be used to implement an up to 256 bits wide up/down counter. The counter has a load input which can be used to load values. The version used in the project is version 8, which is the rst version supporting Virtex-4 FPGAs. This IP core can be customized using Xilinx CORE Generator, see 2.11.3 below.[11] Comparator The comparator is also a soft IP core from Xilinx. It can be used to implement ecient comparison logic that can perform the following functions: =, <>, , <, , >. The comparator has two input ports which can be up to 256 bits wide. To improve performance, which was necessary in this design, a pipelined version of the comparator can be implemented. The number of pipeline stages depends on the function to be implemented and the bit width. At the most 4 pipeline stages can be implemented but in the design it was only possible to implement one stage. The output port can both be asynchronous and synchronous. A synchronous output port means one extra latency cycle.[12]

20

Technology & Background

2.11.3

Xilinx CORE generator

Xilinx CORE generator (Coregen) is used to customize the dierent hardware resources in the FPGA or to generate IP blocks to be used in the design. Together with Coregen a catalogue of dierent functions and building blocks (cores) are included. In the Coregen interface, parameters can be specied which controls the behavior of the chosen core, see Figure 2.10. The implementation les needed are then generated by Coregen so that the core easily can be implemented in the design.

Figure 2.10. Screen shot from Coregen showing the interface were the parameters for the resources, in this case a dual-port memory, are specied.

2.12

Communication

The DRFM circuit has to be controlled by the simulation computers through a communication interface during run-time. A requirement of the communication interface was that it has to be fast enough for the control commands to be transmitted to the circuit. The simulation updating frequency is 100 Hz which means that the time between every update is 10 ms. Measurements have showed that the time available for sending control commands to the circuit is approximately 5 ms. Another requirement on the interface was that it should be a wide-spread well know standard. This section will describe the two communication alternatives, the VMEbus and the Ethernet standard, that have been reviewed during this thesis. After that the Internet protocol suite used in conjunction with the

2.12 Communication

21

Ethernet standard is described. The section ends with a discussion of the choice of communication interface.

2.12.1

VMEbus

VMEbus is an industry standard dened in 1981 by Motorola, Mostek and Signetics. VMEbus is based on the older VERSAbus standard dened by Motorola in 1979. This standard never became popular in Europe. The reason was mainly because of dissatisfaction with the connectors used to connect the board into the backplane and the large form factor boards. The VMEbus, instead, uses the Eurocard form factor8 which already was popular in Europe at the time of VMEbus introduction. This is also the origin of the name; VME stands for VersaModule Eurocard even though sometimes the E in VME also is referred to as Europe or European.[13][14] After the initial version of VMEbus in 1981 several newer and extended versions have emerged which has made it possible for the VMEbus to survive until today. No proprietary rights have been assigned to the standard which makes it possible for anyone to develop VMEbus products without paying any royalty fees or licenses. This property of the VMEbus standard is yet another important factor that made the standard so successful. Nowadays the VMEbus is used in a wide variety of elds such as in military and aerospace applications and in simulators as in ELSI at SBD.[13][14][15] The VMEbus is an asynchronous bus, which means that it does not have a clock that synchronizes the transfers. Instead this is done by handshaking signals and the signaling speed is set by the slowest module connected to the bus. The VMEbus also has a master-slave architecture. This means that master modules that are connected to the bus is the ones which initiates transfers from other masters or slaves. All transfers are supervised by a special module called the system controller. There can be several masters on the same bus, which is why the VMEbus is called a multi-processing bus. The VMEbus has an address bus and a data bus which both can be up to 64-bit wide and can handle data transfer speeds of up to 80 MB/s.[13]

2.12.2

Ethernet

The Ethernet network system was invented by Bob Metcalfe in 1973 at the Xerox Palo Alto Research Center, PARC, in California. But it was not until 1980 that the original Ethernet standard was published by the DEC-Intel-Xerox vendor consortium. This standard is known as the DIX standard (based on the rst letter in the company names). The DIX standard was then used as basis by IEEE9 when the IEEE Local and Metropolitan Networks (LAN/MAN) Standards Committee developed the IEEE 802.3 standard. The 802.3 standard is the ocial Ethernet standard which has been complemented several times with new media systems and
8 The Eurocard form factor is a more compact form factor and has better connectors than that used by the VERSAbus. 9 Institute of Electrical and Electronics Engineers, Inc. See http://www.ieee.org.

22

Technology & Background

capabilities to form the Ethernet of today. The Ethernet standard contains, for example, dierent standards of transfer speeds of which 100 Mbps over twist-pair cables (100BASE-TX) is the most used standard in households and companies today. This standard is also the standard interesting for this thesis, hence the focus will be on the 100BASE-TX standard.[16] To be able to connect to an Ethernet network, an Ethernet interface is needed. The interface is a physical hardware that has all the circuits needed to communicate over the network. It can both be free-standing hardware or parts of it could be integrated in another circuit, as the integrated Virtex-4 Ethernet MAC. Every Ethernet interface has a unique 48-bit address which is hard coded to the physical interface. The 48-bit address is divided into two 24-bit parts. The rst half is called the OUI, which stands for Organizationally Unique Identier. The OUI is a unique 24-bit number assigned by IEEE to every Ethernet vendor. The second half of the 48-bit address is assigned by the vendor and has to be a unique number. The two halves combined makes up the unique 48-bit Ethernet address which every Ethernet interface is equipped with. [16] Data sent over an Ethernet based network is transmitted in Ethernet frames. A frame is a standardized set of bits used to carry data over the Ethernet system. In short the Ethernet frame consists of a header, a data eld and a frame check sequence for error detection. The header is 14 byte long and contains the source address, the destination address and type. The addresses sent in the Ethernet frame are the 48-bit Ethernet addresses. The data to be sent is encapsulated inside the data part of the frame which can be from 46 bytes up to 1500 bytes. The data part must be at least 46 bytes; otherwise padding data is used to make the data eld 46 bytes. For a more detailed description of Ethernet and the Ethernet frame see [16]. When wanting to network enable a device using o-the-shelf Ethernet products usually three parts are needed: An Ethernet Media Access Controller, a Physical Layer Device and a Registered Jack type 45. Media Access Controller. The sending and receiving of frames is controlled by the Media Access Control (MAC) protocol (therefore the Ethernet address, mentioned above, is also called a MAC address). The protocol used by the MAC is called Carrier Sense Multiple Access Collision Detection (CSMA/CD). Carrier sense means that the protocol listens for activity and sends only if there is no activity on the channel used. Multiple access means that multiple nodes can share the same channel. If two nodes are trying to use the channel at the same time it is detected by the collision detection. The mode when using the CSMA/CD protocol is also called half-duplex mode. If two nodes are connected to each other via a dedicated channel full-duplex mode could be used. Dedicated channels are used between, for example, a node and switch. In this case the CSMA/CD protocol is not needed. The benet of full-duplex mode is that both nodes can send at the same time doubling the transfer speed.[16] Physical Layer Device. The physical layer device, PHY, is the part of the Ethernet interface that handles the physical signaling on the physical medium

2.12 Communication

23

used, e.g. twisted-pair or ber cable. The PHY is often called a transceiver. The name comes from that it transmits and receives signals. The EMAC and the PHY are often connected to each other via a Media Independent Interface (MII). The MII is a standardized interface between the transceiver and the EMAC used by the 100BASE-TX standard. This makes it possible to connect dierent media systems to the Ethernet interface.[16] Registered Jack type 45. The RJ-45 jack is the connector for the twisted-pair cable mentioned earlier. It is connected to the PHY and can be referred to as the Media Dependent Interface (MDI) in opposite to the MII.

2.12.3

The Internet protocol suite

When using higher level protocols these are carried inside the data eld of the Ethernet frame. The protocols interesting for this thesis are the protocols which are parts of the Internet protocol suite. The suite is also often referred to as the TCP/IP protocol suite after the two most important protocols: the Internet Protocol (IP) and the Transmission Control Protocol (TCP). The job of the IP protocol is to move packets of data from a source to a destination. To be able to do that, every interface on an IP network, such as the Internet, is identied by a 32-bit binary number called an IP address. IP carries data for several dierent higher level protocols which are parts of the Internet protocol suite. If reliable transport over the network is needed, the TCP protocol has to be used. Several dierent functions is included in the TCP protocol to supervise the transport of data packets. For that reason TCP is able to discover lost packets and resend them if needed. Another protocol often used is the User Datagram Protocol (UDP). UDP sends and receives datagrams10 but, unlike TCP, UDP has no control of reliability11 . UDP is most often used for sending streaming media, such as audio and video, were on-time arrival is more important than reliability. Even though there are a lot more protocols in the Internet protocol suite, the ones previous mentioned are the most interesting one for the DRFM application. Therefore no deeper description of the others will be conducted in this report and the reader is referred to [17] if more information about the protocol suite is wanted.

2.12.4

Choosing communication interface

The most important reason to use the VMEbus for communication was that it is an industry standard and that it already is well-known at SBD. Other important advantages of using the VME interface was the speed, the simplicity and the fact that a VMEbus VHDL IP core already had been developed at SBD. The disadvantage of VMEbus was the high cost of new hardware if the system would have to be increased in size. Furthermore, more DRFM circuit boards in the new system means that the length of the bus had to be increased using so called bus
10 Units 11 I.e.

of information. if the datagram reaches its destination or not

24

Technology & Background

repeaters. Not only does this mean a considerably high cost, it also means that the speed goes down signicantly. Therefore a new cheaper, high speed and wellspread communication standard was of interest. The choice fell on the Ethernet interface. Ethernet is a very wide spread industry standard for high speed data communication. The communication protocol to be used in the simulator can be chosen from a variety of protocols, for example, raw Ethernet, UDP or TCP could be used, see Section 2.12.2. The actual choice of protocol is not made during this thesis, instead it is up to the sta at ELSI to decide, depending on resources and the speed required.

2.13

Choosing Ethernet interface

As the needed Ethernet and Internet protocol technology and acronyms have been discussed we are ready to go into the choice of Ethernet interface. The rst alternative to look into was the new Virtex-4 FX family which comes with integrated Ethernet MAC (EMAC) and PowerPC processor cores. The idea was to use the EMAC for communication and to use the PowerPC for handling the TCP/IP stack. A TCP/IP stack for the PowerPC integrated in the Virtex-4 is available from a company called Treck Inc.12 . The TCP/IP stack from Treck is designed in cooperation with Xilinx and can be used in the Virtex-4 with the PowerPC processor. When tested on a Virtex-II Pro system a through-put of 785 Mb/s [18] has been achieved which is well enough for the requirements of this project. The disadvantage of this solution is that much more development time would have been needed, time which was assumed not available. Because of the limitations of the project, that is, only the DRFM function was to be implemented in the FPGA during the given time, a free-standing Ethernet module had to be used. Hence, the second alternative was to scan the market for ready-to-use Ethernet modules. The market scan resulted in a review of the modules found. The review will serve as a future basis for deciding the Ethernet module needed. Before the review, requirements was set up that the module had to fulll. Five requirements were identied: High enough data transfer speed Available TCP/IP stack Small enough to t on a circuit board Preferably both TP port, PHY and MAC available on the module Availability on the market These requirements are used in Section 2.13 to make a preliminary choice of Ethernet module. But rst, the module reviews:
12 Treck Inc. is a company that has been designing real-time embedded internet protocols since 1997, see http://www.treck.com/

2.13 Choosing Ethernet interface Rabbit RCM3200

25

Rabbit Semiconductors 13 is a fabless semiconductor company that is specialized in high-performance 8-bit microprocessors. They have also developed several dierent Ethernet modules that uses their microprocessors. The most interesting module, which best suits this projects requirements, is the Rabbit RCM3200 module. This is a small Ethernet module which consists of a Rabbit 3000 microprocessor, an Ethernet controller, memory and a 10/100 Ethernet port. The Rabbit 3000 is an 8-bit microprocessor and runs at up to 44.2 MHz. It can be programmed using a development system called Dynamic C. Together with the development system comes a royalty-free TCP/IP stack (and the source code). According to the RCM3200 FAQ [19] the current maximum receive speed is approximately 3 Mbps using TCP/IP on the RCM3200.[20] Netburner Mod5282 Netburner14 is a company that provides embedded Ethernet for quick network enabling of products. The Netburner Mod5282 is a small Ethernet module based on the Coldre MCF5282 processor from Freescale Semiconductor (former Motorola). The MCF5282 is a 32-bit processor, runs at up to 66 MHz and has a built in 10/100 Ethernet MAC. No throughput information is available for the Mod5282 module. A good guess is that the throughput will be better then the RCM3200 module because of the more powerful processor handling the communication protocols.[21] Epson S1S60000 The Epson15 S1S60000 is a network controller with built-in TCP/IP protocol (rmware). It is a single chip, thus it has to be complemented with a PHY chip and a RJ-45 port. The controller can be controlled through GPIOs. According to the manual for the circuit the maximum eective transfer rate (over UDP) is approximately 5.5 Mbps for the S1S60000 circuit [22]. Worth to notice is that a new chip called S1S60020 based on the S1S60000 is under development. The preliminary data sheet for the chip claims that a throughput of 20 Mbps or more could be achieved [23]. The primary reason for the boost in throughput over the older chip is the hard-wiring of some portions of the processing. WizNet NM7010B WizNet16 is a Korean company that has developed completely hard wired TCP/IP and Ethernet MAC chip. The most recent is called W3150. WIZnet has combined this chip together with a 10/100 Ethernet PHY and an Ethernet port to the NM7010B module. The data sheet for the NM7010B was not available at the WIZnet home page during the writing of this review. Hence no speed information for the module is available. Information on the home page for the W3150
13 http://www.rabbitsemiconductor.com 14 http://www.netburner.com 15 http://www.epson-electronics.de 16 http://www.wiznet.co.kr

26

Technology & Background

chip, on the other hand, claims that the throughput of the chip can be up to 11 Mbps depending heavily on the CPU controlling the chip. The real throughput is somewhat unclear due to the fact that the maximum throughput according to the W3150 Brochure is claimed to be up to 25 Mbps [24].

2.13.1

The choice of Ethernet module

The rst thing to be said is that no real component selection will be done during this thesis. The nal selection will not be done until the DRFM circuit board will be designed. This review and choice of Ethernet module is more of a proposal and serves as basic data for decision-making. Three important properties of the wanted modules have been identied. The three properties are data transfer speed the easiness of implementing the interface the documentation of the interface Starting with the speed issue a simple estimation of the needed data transfer speed is approximately 4.5 Mbps, see Example 2.2. Except the Netburner module (which has no speed data) and the Rabbit module (having only 3 Mbps receiving speed) the two other modules could live up to the requirement. As always with performance measures of computer products values of speed can not be taken too serious. E.g. it is hard to tell under what conditions the throughput values have been measured and what protocols have been used. The WIZNet, Netburner and Rabbit modules are all complete with PHY chip and RJ-45 port whereas the Epson chip has to be completed with the PHY chip and port. This makes the rst three modules easier to handle and to connect to the DRFM circuit board. All modules except WIZNets has good or very good documentation. The problem with WIZNets documentation is the lack of correct (and understandable) English and the slow and hard navigated home page. Summing up the properties wanted neither of the modules could live up to all of the requirements. A decision had to be made anyway and the choice fell on the Netburner module. This module has good documentation and is easy to implement in a design. It lacks specication of data transfer speed but as the processor equipped on the module is rather powerful a good guess is that the speed requirement will be easy to live up to. Another advantage is that the CPU on the module could be used for other calculations and not only for the communication. Hence a development kit for the Mod5282 and an extra Mod5282 has been bought by SBD and speed measurements will be done after this thesis has come to an end. Example 2.2: Calculation of data transfer speed This example is intended to give an approximate calculation of the transfer speed needed to update the DRFM circuit with control data during run-time.

2.13 Choosing Ethernet interface

27

An overestimation is that forty 24 bit commands have to be sent to the Ethernet module every cycle during run-time. This makes a total of 40 24 bit = 960 bit to be sent to every DRFM circuit connected to the Ethernet module. At the most four DRFM circuits will be connected to the same Ethernet module which makes a total of 960 4 bit = 3840 bit that has to be sent every simulation cycle. To be able to calculate the correct data transfer speed the header of the used communication protocols also needs to be taken into account. Dierent protocols could be used for communication, the nal decision of protocol is not made during the work of this thesis, but a good guess is that the UDP or the TCP protocol will be used. Of these two protocols, TCP has the largest header. The TCP header can be up to 60 bytes. The TCP frame is encapsulated inside an IP frame which header also can be up to 60 bytes. This makes a total of 3840 bytes + 2 60 bytes = 600 bytes 8 The IP frame in its turn is encapsulated inside the data part of an Ethernet frame. The Ethernet header is always 14 bytes. Therefore totally 600 bytes + 14 bytes = 614 bytes have to be sent every simulation cycle. The simulator is updated at 100 Hz which makes every cycle 10 ms. Unfortunately the whole cycle cannot be used to send data though. A part of it will be used for other processes on the CPU controlling the DRFM circuits. A low estimation is that 1 ms can be used for sending control data17 . This nally makes the data transfer speed needed 614 M B/s = 614 kB/s 4.9 Mbps 1 10 3 [17]

17 Measurements of the processes have showed that half of the cycle, 5 ms, is available for sending control data to the DRFM circuits. In this case, 1 ms is used to approximate the result in the right direction.

28

Technology & Background

Chapter 3

Implementation & Testing

This chapter starts with a description of the layout decisions made and the implementation ow used. A short discussion is held around the tools used for the implementation of the design. After that the resulting layout of the design is described in detail. The chapter ends with a discussion of the method used for validating the design.

3.1

Layout decisions

Several layout decisions of the DRFM design had to be made. The rst was to study the old design to gure out the purpose of the dierent logical blocks used. This was done to better understand how the new circuit should work and to be able to reuse some of the design ideas in the new implementation. Even though no code was reused this made the development of the design faster. After having studied the old design and the requirements of the new design, three major building blocks were identied: 1. A dual-port memory to be used for storing the wave forms. 2. An interface used for communication with the simulator computer. 3. A control logic block which controls the behavior of the DRFM circuit during run-time.

3.1.1

The memory

A decision that had to be made was how to implement the memory needed to store the wave forms. One alternative was to use an external memory. This would have meant that a memory interface had to be implemented in the FPGA. The disadvantage with and external memory is that an extra physical component had to be connected to the circuit board. A more interesting alternative was instead to implement the memory using the integrated memory blocks in the Virtex-4 circuit. Using these blocks no external component was required and the design would also 29

30

Implementation & Testing

be easier to alter. Consequently BlockRAM was decided to be used in the DRFM as the memory resource.

3.1.2

The interface

An interface communicating with the simulation computer was also needed. From the beginning the requisite from SBD was that the interface should be a VMEbus interface. As discussed in Section 2.12, the reason for that was that the VMEbus was well known by the ELSI sta, for example, the simulation computers uses VMEbus. A VHDL implementation of the VMEbus was also already available at SBD making it a lot faster to implement. The drawback of using the VMEbus was the cost of the VME equipment needed for the new DRFM circuit boards. Another important disadvantage is the fact that if more slots for the new circuit boards will be needed, a bus repeater has to be used, which makes the speed of the VMEbus drop signicantly. Another high speed, cheap, industry standard was required. The choice fell on the Ethernet standard and more precisely the 100BASETX standard1 . The Ethernet standard is a widely used local area networking technology. The standard is rather complex to implement in an FPGA but instead of implementing it, an external Ethernet module could be purchased to quickly Ethernet-enable a product. There are several dierent Ethernet chips and modules available on the market. In this case these could be used to apply an Ethernet interface to the DRFM circuit.

3.2

The design ow

The design was implemented using VHDL code. VHDL is an acronym for VHSIC Hardware Description Language. VHSIC, in its turn, is an acronym for Very High Speed Integrated Circuit. The use of VHDL was a demand by SBD due to the fact that VHDL is the most commonly used hardware description language at SBD. A hardware description language is used to describe the logic to be implemented in an FPGA. The design phase starts with describing the most primitive parts of the system such as counters and registers. These are combined and connected to each other to form larger, more complex, building blocks of logic. At the end all the logic blocks are combined to form the nal design. When designing logic to be implemented in an FPGA a certain design ow is followed. This ow goes through the dierent phases of the implementation and must be followed to be able to complete the design. Normally the design ow is not a straight road to the end goal: the nal design. Instead the functional behavior of the design is veried at dierent stages in the ow. Should the function fail for some reason an attempt to correct the mistake has to be made in the VHDL code. Thus, the designer often goes through several iterations of the design ow before the nal circuit is ready. In Figure 3.1 on page 31 the design ow followed during the implementation of the DRFM circuit is visualized. The arrows going
1 100

Mbit over twisted-pair cables

3.2 The design ow

31

from left to right in the gure symbolizes steps in the ow to validate the function of the design. The arrow going from right to left symbolizes the measures taken in the design entry if the validation encounters a fault in the design. The device programming phase as well as the in-circuit validation have not been performed during this project and are for that reason symbolized by broken lines in the gure. So what does the dierent phases in the ow involve? The rst phase is the design

Figure 3.1. The design ow followed during the implementation of the DRFM circuit.

entry phase. This phase starts with devising a design solution that handles the function to be implemented. The solution is then transferred to a specic layout of logic. The logic is described using VDHL. The logic can also be described by other in-data les, such as IP core les and constraint les. Each time a description of a certain hardware is ready2 the function is tested by doing a behavioral simulation. This simulation is intended to show if the function of the design is the intended, that is if the right outputs are given for a certain set of inputs. If the outputs are dierent to what is expected, a change in the code or in the design have to be
2 This applies both to the complete design as well as the dierent parts that makes up the design

32

Implementation & Testing

made after which a new behavioral simulation is done to verify the functionality. When a correct functional design has been completed it is time to synthesize the design. During synthesis the source code les are translated into a netlist le. This le contains the gate-level description of the design, which means that the design is described using logical gates and black-boxes for hardware dependent logic. The next phase is called design implementation. It consist of three processes used to translate the design so that it, after each step, more closely matches the hardware in the FPGA. Translate. This process translates the netlist to logical elements available in the FPGA, e.g. CLBs, BRAM etc. Mapping. This process assigns the logical elements in the design to physical elements in the target FPGA. Place and route. The place and route (PAR) process places the allocated resources to specic locations in the FPGA after which it connects the resources to each other. This is the most time consuming part of the design implementation. After the design implementation phase the timing of the circuit is tested through static timing analysis. The static timing analysis is used to check if the placed and routed design can live up to the timing constraints, for example clock constraints (clock frequency). The path delays are calculated and compared to the timing constraints. If the timing constraints are not met the design has to be modied or higher eort has to be used during place and route.[4] After the synthesis as well as after each process in the design implementation phase an optional simulation can be done to verify the design. Normally when implementing logic in FPGAs non of these simulations are performed, instead the logic is tested in hardware to verify the functionality. Due to the fact that no hardware was available during this project, a timing simulation, as indicated in Figure 3.1, has instead been performed. This simulation uses the placed and routed design to generate a very accurate timing model of the design. This model is then used when simulating the design to verify the functionality as close as possible to real hardware. During this simulation the delays in the interconnections as well as in the logic are used during simulation to achieve a trustworthy result. The design ow described in this chapter is applicable when using Xilinx FPGAs. Using FPGAs from a dierent manufacturer, the design ow could be somewhat dierent.

3.3

Tools

To be able to design the DRFM circuit, using the design ow above, several different tools have been used: HDL Designer by Mentor Graphics for VHDL programming and schematics.

3.4 The DRFM design ModelSim by Mentor Graphics for simulations. Precision Synthesis by Mentor Graphics for synthesizing the design.

33

Project Navigator by Xilinx for translate, mapping and place and route of the design. Xilinx CORE Generator by Xilinx for generating IP cores and conguring integrated hardware resources. In the beginning of the project it was not a matter of course to use the tools listed above. They were instead chosen by testing the dierent tools available at SBD and by recommendation of Xilinx. The choice fell on the Mentor Graphics3 program suite due to the simple usage of the tools and the fast developing that could be done by using the HDL Designers ability to program the code graphically. Xilinx recommendation of Precision instead of Xilinx own synthesis tool was also a reason for the choice. The reason for using CORE Generator and Project Navigator are that these processes are hardware dependent and, thus, the programs from the manufacturer of the FPGA had to be used.

3.4

The DRFM design

In this section the layout of the design is described as well as the functions of the dierent parts. The section starts with a description of the inputs and outputs of the design. After that the DRFM design and the three logic blocks that it consists of are described: the control logic, the memory and the external interface block. An overview of the design can be seen in Figure 3.2.

Figure 3.2. The gure shows an overview of the DRFM design consisting of three blocks.
3 http://www.mentor.com

34

Implementation & Testing

3.4.1

Inputs and outputs

A list of the inputs and outputs in the design can be viewed in Table 3.1. Some ports are left out in the table and in Figure 3.2. These are ports used by the external interface, located in the bottom left corner of the gure. These will be explained in more detail later in this chapter. Some ports existed already in the old design, see Section 2.7, but some are new. Therefore the meaning of some of the ports must be explained. The RFpresent port is a 1-bit port used in mode A to output an envelop signal. The envelop signal is high when a stored wave form is transmitted on the RFout port. There are two outputs in the design called RFgating1 and RFgating2. These are used to control two pin diode switches. The pin diode switches have been mounted in the signal path of the radar echo to reduce background noise to a minimum. The switches cut the signal path when no pulse is transmitted. To do this the RFpresent signal could have been used, but the problem is that there are dierences in signal path between the pulse and the control signals. The switches may also have a long switch time which means that the control signal has to be longer than the pulse. Hence two gating signals have been implemented which are adjustable in both time and length. The Markers output is a 5-bit port used for outputting triggering pulses for ECM equipment. The marker pulses are high during approximately 100 ns. See Figure 3.4 in Section 3.4.2, below, to understand the behavior of the signals on the output ports.
Table 3.1. The ports in the new design. The ports associated with the external interface have been left out.

Port PRF RFin RFout RFpresent RFgating1 RFgating2 Marker

Description Trig pulses from the radar seeker. Sampled radar pulse from the A/D converter. Sampled radar pulse, connected to the D/A converter. Envelop signal. Gating signal used for pin diode switches. Gating signal used for pin diode switches. Marker signals for ECM.

Direction IN IN OUT OUT OUT OUT OUT

Width 1 [16:0] [16:0] 1 1 1 [4:0]

Mode A, B B A, B, C A A A A

3.4 The DRFM design

35

3.4.2

The control logic block

The control logic block handles the output of signals from the circuit and controls the memory during run-time. It is controlled by programmable registers that are updated from the external interface, see Section 3.1.2. The control logic block is composed of a nite state machine (FSM), three counters, control registers and signal generators, see Figure 3.3. The central part of the control logic is the FSM. The FSM controls how the circuit

Figure 3.3. The gure shows an overview of the layout of the control logic.

shall act under the dierent programmable modes. In reality the FSM controls the counters and the signal generators to perform the dierent tasks. The three counters are called in counter (IC), out counter (OC) and time counter (TC). IC and OC addresses the memory during run-time, which means when the circuit is active during simulations. IC addresses memory positions where data shall be written from the RFin port. Since writing to the memory from the RFin port only takes place during mode B, IC is only active during this mode. OC addresses the data to be read from memory to RFout and is hence used in all modes. The memory can also be accessed via the external interface, see Section 3.4.3. TC is used by the FSM to synchronize all generated signals during run-time. TC is compared against the control registers to determine when the dierent outputs shall be generated. It is activated by a pulse on the PRF port and counts until all signals have been generated. After the signal generation is complete it resets to zero. In this design, the DSP48 slice, available in the Virtex-4 circuits, was intended to be used for implementation of the counters. The reason to use a DSP48 slice congured as a counter was the performance requirements of the design, see the requirement specication in Appendix B. According to Xilinx specication of

36

Implementation & Testing

the DSP48 block it should be possible to implement a 48-bit counter running in 500 MHz. Even though, at the most, 350 MHz was required, see Appendix B, it would have been easy to implement, having a relatively large timing margin. Unfortunately a bug in the software made the counter fail to count up during post-PAR simulations. This made the function of the design impossible to test. The bug was hard to locate, see Section 4.3, hence a decision was made to use a counter in the form of an IP block from Xilinx instead. The IP block is called Binary Counter, see Section 2.11.2, and does not use the DSP48 blocks. The counter was congured in CORE Generator as an up-counter. Luckily the counter was fast enough to be able to meet the timing requirements.[10] The control logic block also contains control registers in which all the data needed to control the circuit are stored. The contents of these registers are constantly updated from the registers in the interface block, see Section 3.4.4, so that the contents of the two set of registers are the same. The dierence between the two sets are that the registers in the control logic block are not updated when output signals depending on the contents of the registers are generated. This is to prevent errors in the generated signals. Table 3.2 shows the 18 registers used for controlling the behavior of the circuit.
Table 3.2. The 18 control registers in the design.

Register Command register Status register Delay register Pulse start register Pulse end register Marker register x 5 Gating start register x 2 Gating end register x2 Version register

Name CMDR SR DR PSR PER MPRx GSRx GERx VER

Type read/write read read/write read/write read/write read/write read/write read/write read

Description Storing control commands. Status of the circuit. Length of the delay. Start address in memory for the stored pulse. End address in memory for the stored pulse. Point in time for marker generation. Point in time for start of RFgating signals. Point in time for stop of RFgating signals. Version number of the design.

To better understand the relation between the contents of the registers and the outputs, Figure 3.4 can be viewed. The gure shows the wave forms for the outputs and the registers controlling the appearance. When the circuit is active, after having received a PRF, the value of TC is constantly compared to the values in the control registers. The comparators are

3.4 The DRFM design

37

Figure 3.4. The gure shows how the outputs are dened from the contents of the registers in the circuit.

38

Implementation & Testing

used for enabling the dierent output signals in the design, see Figure 3.4. To be able to compare the values fast enough an IP block from Xilinx called Comparator has been used, see Section 2.11.2. The Comparator block has been instantiated into dierent kinds of comparators using Coregen. The comparators have also been congured to have a pipe-line stage to achieve maximum performance.

3.4.3

The DRFM memory

The DRFM memory is used for storing radar echoes. The echoes can be loaded to the memory both, o-line, through the external interface and, during simulation, through the 16-bit RFin port. Requirements in the requirement specication, see Appendix B, on the maximum length of radar pulses and the frequency of the circuit determines the length of the memory. The width was set to 16 bit instead of the specied 14. The extra two bits, in comparison to the requirement, does not aect the performance noticeably and can be used for other functions in ELSI. Due to the fact that both reading and writing was to be done at the same time during mode B another, indirect, demand was that the memory should be of dual-port type. Hence the memory was implemented using BlockRAM which is integrated in the Virtex-4 family circuits. According to Xilinx, BlockRAM blocks should be able to run in up to 500 MHz which was perfect for the design. Unfortunately, the BlockRAM did not manage to deliver the claimed speed and, thus, the clock frequency had to be 200 MHz. The speed problem will be discussed in Section 4.3. The implementation of the memory has been made by using the Coregen tool. The memory has been implemented as a dual-port memory with a 16 bit data and address ports using BlockRAM blocks. An extra pipe-line stage has been introduced in the memory to speed up the design as much as possible. The memory has two independent ports, A and B. Port A is used for writing to the memory both during run-time (mode B) and o-line via the external computer interface. Reading from the memory o-line is also done using port A. Port B, on the other hand, has been congured as a read-only port. It is used for outputting the pulse during run-time.

3.4.4

The external interface

The external interface is used for storing the control commands, which control the behavior of the circuit, and for loading stored radar echoes to the memory. To be able to do this the external interface will be connected to an Ethernet module that communicates with a simulation computer. The external interface has been implemented as three logic blocks: Interface FSM. A nite state machine (FSM) controlling the handshaking protocol during read and write. The FSM is also controlling the memory access during read and write. Interface registers. The registers where the control commands are stored. These are the same type of registers as in Table 3.2.

3.4 The DRFM design

39

Address decoder. This is a simple address decoder which decodes the address on the address port to access memory or registers. In practice the external interface is a simple parallel interface serving as a bridge between the Ethernet module and the control logic of the DRFM circuit. The interface could be due for changes because of the fact that the decision of which Ethernet module to be used is not yet nal. Also, the program, running on the CPU, located on the Ethernet module that should handle the communication between the module and the FPGA has not yet been developed. As of now the basic idea is to have a program running on the module handling the TCP/IP communication as well as the reading and writing of the FPGA. The interface has been implemented having a data port and a address port. The address port is used for addressing the memory and the registers in the interface. A chip-address port has also been implemented. It is a 2-bit input that is used to hard code an address to the circuit. This input is used in the cases of several DRFM circuits sharing the same Ethernet module. The circuits can then be hard coded to dierent chip addresses to be able to dierentiate them from each others. A 2-bit address means that up to four chips can be connected to one Ethernet module. The read and writes of the FPGA are performed by a four-way handshake protocol. The protocol uses two handshaking signals ACK (acknowledge) and REQ (request) and a write signal, WRITE. The REQ and WRITE signal are controlled by the module whereas the ACK signal is controlled by the FPGA. During a write cycle, WRITE is set high to indicate a write cycle. At the same

Figure 3.5. The wave forms show the four-phase protocol used for communication between the external interface and the ethernet module.

time valid address and data are put on the address and data port. After that the

40

Implementation & Testing

module sets REQ to high and starts monitoring the ACK signal. When the REQ signal goes high the FPGA writes the data on the data port to the position in the memory indicated by the address. When the data has been written ACK is set to high. The ACK signal triggers the module to set REQ to low. The transmission ends with ACK set to low by the FPGA. The read cycle is similar to the write cycle. The dierence is that the WRITE signal is low, indicating a read cycle, and that no data is put on the data port by the module, see Figure 3.5.

3.4.5

Other resources

The chip will be provided with an external clock on the circuit board that will run in 50 MHz. The frequency of the internal clock has to be 200 MHz. To be able to synthesize a new, higher, frequency a Digital Clock Manager (DCM) has been used. The DCM has been congured to take the external clock as an input and multiply it with a factor 4 to generate an internal 200 MHz clock. The DCM has been congured using Corgen and can easily be altered if another frequency is wanted in the future. The high-speed input and output of the RFin and RFout ports can not use the ordinary digital standard on the FPGA. To be able to properly deliver these high frequency signals, the inputs and outputs have been congured to use the Low Voltage Dierential Signaling, LVDS, standard. LVDS uses the dierential in voltage between to wires to signal the information which reduces the noise and, thus, enabling a higher transfer speed.. Therefore, every bit in RFin and RFout uses two IOBs, see Section 2.11.1.

3.5

Testing methodology

The complete design has now been described in the previous section. As mentioned in Section 3.2 the testing of the design has been performed in three steps: 1. Functional verication through behavioral simulation. 2. Static timing analysis. 3. Verication of the design through timing simulations. The functional simulation has been performed to verify the function of both logical blocks and sub blocks as well as the complete design. The timing analysis has been conducted to verify that the design meets the clock constraints. After the design implementation phase an in-circuit validation is normally performed to validate the function in hardware. Due to the fact that no hardware was available during this thesis, the design had to be tested through simulations. The type of simulation that tests the design closest to the hardware is the timing simulation. Thus, timing simulation has been performed to test the various functions of the DRFM design. Timing simulations have only been performed at the end of the project on the complete design in order to verify the design as close as possible to hardware.

3.5 Testing methodology

41

To be able to perform timing simulations, as well as behavioral simulations, a test bench has to be created. A test bench is written in VHDL and provides the stimulus to the tested logic. In Figure 3.6 an overview of the structure of a test bench can be seen. The test bench contains the block to be tested, also called unit under test (UUT), and a tester block. The tester block is a VHDL le providing all the stimulus needed for testing the UUT. The stimuli stimulates the logic with signals resembling the commands and inputs that should have been given to the circuit if it would have been a part of the TEG. A simulation program, in this

Figure 3.6. The gure shows how the tester is connected to the unit under test (UUT) in the test bench.

case ModelSim, is used to simulate the logic using the test bench stimulus. From ModelSim dierent wave forms for the inputs and outputs can be retrieved to discover whether or not the design is functioning properly, see Figure 3.7. When doing a behavioral simulation, internal signal can also be retrieved to better understand the behavior of the circuit. This is very useful when the design does not behave as intended. The internal signals can then be used to locate where in the design the fault is situated. During timing simulation, on the other hand, the internal signals are harder to locate because of the fact that the logic has been optimized and adapted to t the hardware. The simulations of the complete design have been used for conducting dierent tests on the design in order to verify a correct behavior according to the requirements in the requirement specication and the design specication, see Appendix B and C. Especially, the following cases have been simulated: Read and write of memory. Read and write of all registers. Correct behavior during mode A, B and C. Updating the registers in real-time.

42

Implementation & Testing

Figure 3.7. The gure shows a screen shot from the wave form window of ModelSim.

The results of these simulations will be discussed in the next chapter.

Chapter 4

Results & Discussion

This chapter presents the results of this masters thesis: a DRFM design that can be implemented in an FPGA and used in ELSI. Simulations of the functionality of the design are reviewed. The simulations are presented in forms of wave forms generated by ModelSim. The chapter ends with a discussion about the diculties which came up during the project.

4.1

Results

This project has resulted in a DRFM design to be used in the ELSI simulator. The design has been tested according to the test methodology in Section 3.5. All relevant requirements in the requirement specication as well as the design specication have been tested. This has showed that the design lives up to all priority 1 requirements from the requirement specication, see Appendix B. The design also complies with all but two of the priority 2 requirements. The rst is Req. No. 9, regarding a clock frequency of 350 MHz. This requirement and the circumstances around it are discussed in Section 4.2. The second is Req. No. 28, regarding an extended design for radar seekers of high PRF type. This requirement was not possible to meet, mainly due to lack of time. This extended design is instead proposed as future work in Section 5.2. In the next section, timing simulations of the most interesting functions of the design are presented.

4.1.1

Cases tested through simulation

Next follows a more detailed description of the timing simulations listed in Section 3.5, as well as references to gures in Appendix D showing the resulting wave forms from ModelSim. Read and write of memory This test was intended to show that the memory can be read and written, see Figure D.1. It also shows that when a memory position is read that has not previously been written to, the output from the memory is 43

44

Results & Discussion

zero. This simulation, as well as the next, also shows the signals associated with the external computer interface in action. Read and write of all registers This test has been divided into two gures, see Figure D.2 and D.3. The test is intended to show that all registers can be written and read. It also shows that if a read-only register is written the content of that register does not change. And if an invalid register address is written or read nothing happens1 , see Table 4.1 for the register addresses. Correct behavior during mode A, B and C These simulations shows the behavior of the circuit when loaded with the values according to Table 4.1 in the three modes, see Figure D.4, D.5 and D.6. Earlier in the simulations of mode A and C (not shown in the gures) a wave form has been loaded to the memory. All markers have been set active which corresponds to the marker signals of the gures of mode A and B. Even though no exact measurements of the delays can be performed in the wave form gures, the distance between the PRF signal and the outputs are in accordance with the contents of the corresponding registers. The strange appearance of the wave form on RFout is due to glitches on the outputs. This will however not aect external equipments as RFout will be clocked into a DAC before leaving the DRFM circuit board.
Table 4.1. Table over the register settings during the timing simulations of the complete design.

Register Command register Status register (read-only) Delay register Pulse start register Pulse end register Marker register 1 Marker register 2 Marker register 3 Marker register 4 Marker register 5 Gating start register 1 Gating end register 1 Gating start register 2 Gating end register 2 Version register (read-only)

Address 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Value Depending on mode Depending on mode 100 52 100 100 200 150 300 190 190 390 220 450 1

Updating registers in real-time This simulation shows both that the registers can be updated in real-time as well as updating them will not eect on-going outputs (in accordance with Req. No. 23 and 24). During the update two of the
1 Reading

of such a register address outputs a zero on the data port

4.2 Performance

45

markers are turned o. The delay of the outputs are also changed in comparison to the values in Table 4.1. The wave forms can be seen in Figure D.7.

4.2

Performance

The goal was to meet the priority 2 performance requirement, see Req. No. 8 and 9 in Appendix B, of running the circuit in 350 MHz. Unfortunately, even though a considerably amount of time was put into trying to meet the requirement, this goal was impossible to reach. The main reason for not being able to reach it was the integrated memory used for the DRFM. The blocks that the memory consists of are specied for up to 500 MHz each. But when combining several of them the actual performance was much less then that. This is due to that when combining several blocks, a large amount of overhead logic, connecting the blocks to each other are needed which, due to delays, slows down the performance of the logic. The nal solution in the design was to only meet the priority 1 requirement of 200 MHz, thus reducing the amount of blocks needed. Another solution to this problem could be to use an external memory, this is suggested in Section 5.2 Future work.

4.3

Diculties

Several diculties came up during the project delaying the development of the circuit. The diculties have mainly been related to the software used for developing the FPGA logic. The Virtex-4 family is a rather new family of FPGAs. This means that the software and the hardware specic conguration les for this family have not been properly tested yet. This means that some bugs still are available in the software and les. A bug that has caused a lot of extra work was a bug in the simulation les for the DSP48 block, mentioned in Section 3.4.2. The DSP48 block was intended to be used for implementing fast counters in the control block. Due to the bug, the counters did not count up during post-PAR simulations, which is the last verication step of the design ow used during this project, see Section 3.2. This, together with the fact that Xilinx VHDL example of a DSP48 counter2 also had a bug, made the debugging more dicult than it would have been if the example counter hade been correct from the beginning. Instead the rst thought was that the DSP48 counter for the DRFM design had been congured in the wrong way. A lot of hard work was, thus, made to congure the DSP48 block correct. After having contacted both Xilinx Swedish FAE3 , a Xilinx VHDL programmer visiting SBD and having opened a webcase at Xilinx home page the bug was located and a solution to the bug was introduced. This made the original design of the DSP48 counter work correctly, but at that time the design had already been nished using an IP block (Binary Counter) from Xilinx.
2 This VHDL le can be downloaded from Xilinx home page http://www.xilinx.com, under the documentation for the DSP48 block 3 Field Application Engineer

46

Results & Discussion

Bugs have also been discovered in HDL Designer from Mentor Graphics. Before the start of the project HDL Designer had an major update, from version 2004 to 2005. This probably made the software unstable, for example, the program was often shut down without a cause and without being able to save the progress done. This instability disappeared with a new update, but other bugs in the software have remained during the whole project. Bugs have not been the only cause of diculties during the development. As the Virtex-4 family is a new FPGA family, no one else at SBD has had any experience of the FPGA family. Therefore there has been no one to ask for help when Virtex-4 specic problems have come up during the implementation. Instead the Xilinx Swedish FAE has been contacted several times and the Xilinx webcase function has been used when such issues have arisen.

Chapter 5

Conclusions & Future work

This chapter will discuss the conclusions that can be made from this project as well as future work that can be conducted after this thesis has ended.

5.1

Conclusions

The purpose of this masters thesis was to implement a Digital Radio Frequency Memory, DRFM, in an FPGA using VHDL. This circuit was to be used in a simulator, testing radar seekers. The masters thesis work was performed in the form of a project which included setting up a time plan, a requirement specication and a design specication. The purpose was also to evaluate dierent alternatives of computer interfaces that could be used for communication with the circuit. The conclusion is that the DRFM design, with a few exceptions, complies with all requirements in the requirements specication. The design has been tested thoroughly to show that it works as intended. Another, important, conclusion is that when developing hardware and, especially, when the hardware is of a new generation, much time will be used for troubleshooting bugs in the development tools and software. This is a typical problem in high-tech companies, as SBD, where the daily activity is based on using cutting-edge technology. Nonetheless, this has made the development time longer. The main conclusions that can be drawn from working in project form is that a time plan is very hard to establish. The problem is a kind of catch-22 problem: The time plan has to be established when the knowledge of the time needed for every phase is at its minimum. And when the knowledge of the time consumption is maximized, at the end of the project, the time plan is obsolete. The time plan for this project would have been, to some extent, dierent if the time consuming problems and bugs in the tools and software had been anticipated. The requirement and design specications have been of great importance, partly used as basis for the design implementation and testing, and partly used to limit the extent of the project. 47

48

Conclusions & Future work

The evaluation of Ethernet interface modules showed that these have high enough speed to be used as computer interface for DRFM circuit and that the evaluation can be used as basic data for decision-making.

5.2

Future work

The DRFM design works perfectly as it is but there are several things that can be improved in the design. To be able to implement the DRFM circuit in ELSI a circuit board also has to be developed. Thus, this section has been divided into two parts: improvement on the design and development of the new DRFM circuit board.

5.2.1

Improvement of the design

As mentioned earlier in this thesis, the main reason for not being able to improve some parts of the design has been the lack of time due to problems with the development tools and the FPGA family used. Two requirements was not fullled from the specication. The rst was the development of the extended design that can handle radar seekers of high pulse repetition type. This is a requirement that with not too much eort can be implemented in the DRFM design in the future. More important are the improvements regarding the clock frequency. To be able to reach a clock frequency of 350 MHz the integrated memory has to be heavily pipe-lined. This is very hard to do if the versatility of the design has to be kept. Another solution is instead to use an external memory chip instead of the integrated memory blocks. This can relatively easy be implemented due to the modular design and that Xilinx provides several dierent memory interfaces as IP cores. A suggestion is therefore to have this in mind when developing the DRFM circuit board. Another thing that probably will have to be altered is the external interface block. As this interface has only been implemented as a general parallel interface it may have to be changed depending on the Ethernet module chosen. During the project the ELSI sta has presented desires of new functions in the DRFM circuit. There has not been enough time for the implementation of these function during this project. Due to the modular design, though, the functions can easily be implemented in the future. The last improvement of the design is to assign the FPGA package pins to the outputs and input ports of the design. This has already been done in this design, but probably the assignments have to be changed depending on the layout of the circuit board.

5.2.2

The DRFM circuit board

To be able to integrate the DRFM circuit in ELSI, a circuit board has to be developed which the DRFM circuit is attached to. As of now, the plan is that

5.2 Future work

49

another master student shall perform the layout of the circuit board. This also includes choosing the components to be attached as, for example, the ADC and the DAC. After the circuit board has been developed and a test board has been produced, in-circuit validations of the DRFM circuit has to be performed. When the functionality has been veried in hardware the last step will be to insert the circuit board in ELSI for the completing tests and calibration of the equipment.

50

Conclusions & Future work

Bibliography
[1] A. Nyhln, G. Karlsson, J-O Olsson, and P-J Sllberg. ELSI presentation. Saab Bofors Dynamics AB, 2004. [2] George W. Stimson. Introduction to Airborne Radar. SciTech Publishing Inc., second edition, 1998. [3] S. J. Roome. Digital radio frequency memory. Electronic & Communication Engineering Journal, 2(4):147153, August 1990. [4] James R. Armstrong and F. Gail Gray. VHDL design - representation and synthesis. Prentice Hall PTR, second edition, 2000. [5] Actel Corporation. Flash FPGAs in the Value-Based Market, Januari 2005. http://www.actel.com/documents/ValueFPGA_WP.pdf. [6] Xilinx, Inc. Virtex-4 Multi-Platform FPGA, August 2005. http://www.xilinx.com/virtex4. [7] TechOnLine, Inc. Xilinx virtex-4 revolutionizes platform fpgas, 2004. http://www.xilinx.com/company/press/kits/v4_arch /v4_finalwhitepaper4.pdf. [8] Kevin Morris. Xilinx details its next generation. FPGA and Programmable Logic Journal, June 2004. http://www.fpgajournal.com/articles/20040608_virtex4.htm. [9] Xilinx, Inc. Virtex-4 User Guide, April 2005. http://direct.xilinx.com/bvdocs/userguides/ug070.pdf. [10] Xilinx, Inc. XtremeDSP Design Considerations User Guide, February 2005. http://direct.xilinx.com/bvdocs/userguides/ug073.pdf. [11] Xilinx, Inc. Binary Counter v8.0, April 2005. http://www.xilinx.com/ipcenter/catalog/logicore/docs /binary_counter.pdf. [12] Xilinx, Inc. Comparator v8.0, April 2005. http://www.xilinx.com/ipcenter/catalog/logicore/docs/compare.pdf. 51

52

Bibliography

[13] Wade D. Peterson. The VMEbus Handbook. VFEA International Trade Association, second edition, 1991. [14] Steve Heath. VMEbus Users Handbook. CRC Press, Inc., 1989. [15] VITA. VMEbus International Trade Association, August 2005. http://www.vita.com/. [16] Charles E. Spurgeon. Ethernet: The Denitive Guide. OReilly & Associate, Inc., 2000. [17] W. Richard Stevens. TCP/IP Illustrated: the protocols, volume 1. Addison Wesley, 1994. [18] Satish Narayanaswamy. High Performance TCP/IP on Xilinx FPGA Devices Using the Treck Embedded TCP/IP Stack. Xilinx, Inc., December 2004. http://www.xilinx.com/bvdocs/appnotes/xapp546.pdf. [19] Z-World/Rabbit Bulletin Board, August 2005. http://www.zworld.com/support/bb. [20] Rabbit Semiconductor. RCM3200 RabbitCore Data Sheet, January 2005. http://www.rabbitsemiconductor.com/products/rcm3200/rcm3200.pdf. [21] Netburner, Inc. Mod5272/5282 10/100 Processor Modules Data Sheet, 2004. http://www.netburner.com/products/processors/Mod5282.htm. [22] Seiko Epson Corporation. S1S60000 Technical Manual, March 2005. http://www.epson-electronics.de/upload/PresidioIndustries/product /Semiconductors/InterfaceICs/IntelligentNetworkControllers /S1S60000_TM_404513905.pdf. [23] Seiko Epson Corporation. S1S60020 Data Sheet, June 2005. http://www.epson-electronics.de/upload/PresidioIndustries/product /Semiconductors/InterfaceICs/IntelligentNetworkControllers /s1s60020ds_e_050622.pdf. [24] WIZnet Co., Ltd. W3150 Brochure, May 2005. http://www.wiznet.co.kr.

TIME PLAN

Appendix A

Time Plan

Master's thesis:

Implementation of an DRFM-circuit in an FPGA

53

Thesis student: Kristian Gustafsson Date: 2005-04-04 Company: Saab Bofors Dynamics AB Version: 1.0 Supervisors: Anna Goman & Anders Nyhln ACTIVITIES TIME PLAN, week no. 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 Description Problem definition V V V V 15/4 Requirement specification A A A A 1/5 Arcitectures/Design specification C C C C Choice of components 1/5 Implementation 30/6 A A A A T T T T Functional verification I I I I Synthesis/Place&Route 31/8 O O O O Performance verification N N N N Writing the report Presentation of the master's thesis

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date

2 (9)

Kristian Gustafsson, RTEAD

2005-04-22 1.1
Antal bilagor No. of appendices

Utgva Issue ID

Dokumentnummer Document ID

Appendix B
2 ABBREVIATIONS

Godknd av Approved by

Informationsklass Classification

Requirement Specication

CW Continuous Wave DRFM Digital Radio Frequency Memory ECM Electronic Countermeasure ELSI Electronic Warfare Simulator REQUIREMENT SPECIFICATION 1 (9) Saab Bofors Dynamics AB Utfrdare, tjnstestlle, telefon Issued by, department, telephone Datum Date Utgva Dokumentnummer Document ID FPGA Field Programmable Gate Array Issue ID JTAG Gustafsson, RTEAD Group Joint Test Action Kristian 2005-04-22 1.1 TEG Target Echo Generator Antal bilagor Godknd av Approved by Informationsklass Classification No. PRF Pulse Repetition Frequency of appendices RF Radio Frequency VHDL VHSIC Hardware Description Language VHSIC Very High Speed Integrated Circuit
Mottagare Addressee(s)

Anders Nyln Sture Carlson Anna Goman BACKGROUND 3 Ulf Malmqvist The DRFM circuit is a part of the TEG in the simulator ELSI. The main task of the circuit is sending radar echoes, using the radar equipments in ELSI, to the radar seeker with a delay equivalent to the distance to a simulated target. The current circuit is not able to meetspecification for the DRFM circuit in the TEG.to ELSI. Requirement the new technical requirements which the simulator has be able to handle in the future. Also, the functions in the current design have never been fully used and a desire of new functions have arisen. These are the reasons for developing a new DRFM circuit. 1 INTRODUCTION Control and memory access of the circuit will be using an external computer This requirement specification defines the be done on the DRFM circuit developed interface. The choice of the interface will demands later on, during this thesis, or it as a part of after the development of the circuit has finished. The specification is will be done a masters thesis at Saab Bofors Dynamics AB.This result in that the intended to limit in extent of the will only be general parallel interface. interface specifiedthe this documentthesis so thataresults can be achieved within the time planned for the thesis according to the time plan. After implementation of the circuits they will be assembled on a circuit board which In this used in the simulator. will be specification all the requirements will be defined in table row according to the row belov: In this specification it is only the DRFM functions, the interface to the computer and Req. No. X Description for requirement that are Priority the communication between the two blocksNo. X specified. Column 1 The circuit shall be controlled through an external Req. No. one states the number of the specific requirement. In column two the 1 description of computer interface. be found. In the third column the priority of the the requirement can requirement is found. Priority 1 is hard requirements that have to be fulfilled before the development of the DRFM circuit is considered finished. Priority 2 is requirements that will be fulfilled only if extra time is available when the priority 1 requirements have been fulfilled.
Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5 This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

54

55

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date

2 (9)

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1

Utgva Issue ID

Dokumentnummer Document ID

Informationsklass Classification

2 CW DRFM ECM ELSI FPGA JTAG TEG PRF RF VHDL VHSIC

ABBREVIATIONS Continuous Wave Digital Radio Frequency Memory Electronic Countermeasure Electronic Warfare Simulator Field Programmable Gate Array Joint Test Action Group Target Echo Generator Pulse Repetition Frequency Radio Frequency VHSIC Hardware Description Language Very High Speed Integrated Circuit

BACKGROUND

The DRFM circuit is a part of the TEG in the simulator ELSI. The main task of the circuit is sending radar echoes, using the radar equipments in ELSI, to the radar seeker with a delay equivalent to the distance to a simulated target. The current circuit is not able to meet the new technical requirements which the simulator has to be able to handle in the future. Also, the functions in the current design have never been fully used and a desire of new functions have arisen. These are the reasons for developing a new DRFM circuit. Control and memory access of the circuit will be using an external computer interface. The choice of the interface will be done later on, during this thesis, or it will be done after the development of the circuit has finished. This result in that the interface specified in this document will only be a general parallel interface. After implementation of the circuits they will be assembled on a circuit board which will be used in the simulator. In this specification it is only the DRFM functions, the interface to the computer and the communication between the two blocks that are specified. Req. No. 1 The circuit shall be controlled through an external computer interface. 1

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

56

Requirement Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date

3 (9)

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1

Utgva Issue ID

Dokumentnummer Document ID

Informationsklass Classification

PERFORMANCE REQUIREMENTS

Below are requirements on the performance that the circuit has to fulfill. Req. No. 2 Req. No. 3 Maximum target distance shall be at least XX. Minimum target distance shall be at most 200 meter. 1 1

(XX is used for the maximum target distance due to that it is a confidential parameter.) The target distance is defined, showed in Figure 4.1 below, as the distance between the radar seeker and the target. When the distance is translated to a delay time, the distance has to be doubled due to the fact that the radar pulse travels twice the distance: from the radar seeker to the target and back.

Target distance

Figure 4.1 The maximum and minimum target distance between seeker and target are defined in Req. No. 2 and Req. No. 3.

Req. No. 4

Maximum hardware delay through the circuit when the target distance is set to zero shall be 100 ns (PRF to RFout).

It should be possible to place targets in the simulator scenarios with an accuracy of 1 meter. Req. No. 5 The resolution shall be less than or equal to 1 meter. 1

To be able to generate ECM, markers are needed to trig the ECM equipments. The markers are TTL outputs that are logically high during approximately 100 ns. Req. No. 6 Req. No. 7 The circuit shall have 5 markers. The marker signals shall be logically high for 90 ns t 110 ns. 1 1

The following are demands on the speed at which echoes are recorded/replayed by the DRFM circuit.
Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5 This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

57

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date Utgva Issue ID

4 (9)

Dokumentnummer Document ID

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1
Informationsklass Classification

Req. No. 8 Req. No. 9

The high frequency part of the circuit shall work in at least 200 MHz. The high frequency part of the circuit shall work in 350 MHz.

1 2

Saab Bofors Dynamics has good experience of fast 14-bit D/A and A/D converters (for converting the pulse from the radar seeker), hence the high frequency part of the circuits shall use a bit width of 14 bits. Req. No. 10 The bit width of the high frequency part of the circuit shall be 14 bits. 1

INPUTS AND OUTPUTS 1

Req. No. 11 The circuit shall have inputs and outputs according to Table 5.1 (the signals of the external interface has been left out).

Table 5.1 Inputs and outputs of the circuit.

Name RFin RFout RFpresent RFgating1 RFgating2 PRF Marker

Direction In Out Out Out Out In Out

Width [13:0] [13:0] 1 1 1 1 [4:0]

Description Sampled radar pulse, in Sampled radar pulse, out Envelope signal Signal for controlling diode switches Signal for controlling diode switches Trigger pulse from the radar seeker Marker signals for ECM

THE DRFM FUNCTION

The circuit has different modes of function depending on the situation. Below follows the description of the different modes and the requirements of them.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

58

Requirement Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date Utgva Issue ID

5 (9)

Dokumentnummer Document ID

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1
Informationsklass Classification

6.1

The modes of the circuit

The circuit shall have three different modes of usage: Mode A Trigged mode Mode B Delay line Mode C CW mode Mode A Trigged mode

6.1.1

In mode A a wave form is stored in the memory of the circuit. For every received PRF the circuit is activated and the stored wave form is transmitted via RFout after a variable delay, see figure 6.1. The variable delay is equivalent to the distance to the target.

DRFM RFout

PRF

Delay

Figure 6.1 Block diagram showing mode A.

During the time the wave form is transmitted, RFpresent is high. When the circuit is active the signals RFgating1 and RFgating2 can be set high during a chosen time. If needed up to five markers could be used. Req. No. 12 A stored wave form shall be able to be loaded into the memory of the DRFM circuit via the external interface. Req. No. 13 The delay of the wave form shall be able to be set according to req. no. 2 and req. no. 3. Req. No. 14 Data shall be able to be read from the memory to RFout according to, respectively, req. no. 8 and req. no. 9. Req. No. 15 RFpresent shall only be high during the time the wave form is transmitted. Req. No. 16 RFgating1 and RFgating2 shall be able to be placed according to req. no. 2 and req. no. 3. 1 1 1 1 1

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

59

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date Utgva Issue ID

6 (9)

Dokumentnummer Document ID

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1
Informationsklass Classification

Req. No. 17 The length of RFgating1 and RFgating2 shall be adjustable and independent of each other. Req. No. 18 Every marker shall be able to be independently turned on or off. Req. No. 19 The markers shall be able to be place, in terms of time, according to req. no. 2 and req. no. 3.

1 1 1

6.1.2

Mod B Delay line

During mode B data is read via RFin to the memory of the circuit and is output via RFout after an adjustable delay, see figure 6.2.

DRFM RFin PRF Delay RFout

Figure 6.2 Block diagram showing mode B.

Req. No. 20 Data shall be able to be read via RFin to the memory according to req. no. 8 resp. req. no. 9. 6.1.3 Mod C CW mode

During mode C a wave form is stored in the memory of the circuit. The stored wave form is then repeatedly transmitted via RFout to form a continuous wave, CW, see figure 6.3).

DRFM RFout
Figure 6.3 Block diagram showing mode C.

6.2

Commands

The circuit shall mainly have to states: HOLD and RUN. When the circuit receives a command (except RUN) the circuit goes into HOLD. When the command RUN is received the circuit starts in the chosen mode.
Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5 This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

60

Requirement Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date Utgva Issue ID

7 (9)

Dokumentnummer Document ID

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1
Informationsklass Classification

Req. No. 21 The following commands shall be recognized by the circuit: MODE A, B, C, HOLD and RUN. Req. No. 22 When the circuit goes to HOLD all outputs shall be set to zero. 6.3 Other functions

1 1

Req. No. 23 The delay, position of markers and active markers shall be able to be updated in real-time. Req. No. 24 Ongoing outputs of the circuit shall not be disturbed when the delay, marker positions and the set of active markers are updated. Req. No. 25 The version number of the circuit design shall be able to be read from the circuit. Req. No. 26 Every circuit shall have a unique number to be able to differentiate them from each other.

1 1

2 1

During functional test of the circuit, it is an advantage to be able to read out status information from the circuit to be used as feedback. Req. No. 27 The following status shall be able to be read from the circuit: chosen mode, run/hold state and number of received trigger pulses. 6.4 Extended functions 1

During future test runs of radar seeker it is possible that the seekers are of high pulse repetition frequency type. This means that several pulses can be propagating in the air between the seeker and the target at the same time. This problem can not be addressed with the functions above. The following is a proposal of solution to the problem.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

61

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date Utgva Issue ID

8 (9)

Dokumentnummer Document ID

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1
Informationsklass Classification

DRFM1 (mod A) RFout

DRFM2 (mod B) PRF

Delay1 Trigger signal

Delay2
Figure 6.4 Block diagram showing a solution that can handle several pulses propagating in the air at the same time.

In this set-up large parts of the logic in the circuit have to be doubled so that two DRFM units are implemented in the same circuit, see Figure 6.4. The function is as follows: The memory of DRFM1 is loaded with a target echo. The PRF signal is delayed in DRFM2, working in mode B. The delayed PRF signal is connected to the PRF input on DRFM1, working in mode A. Thus, the delayed PRF signal from DRFM2 act as trigger signal to DRFM1. The delays to both DRFM blocks are adjustable, but normally the delay to DRFM1 is set to zero. Only DRFM1 has the markers enabled. As for the rest the requirements on the modes defined earlier applies also to this function. Req. No. 28 The function according to the description above shall be available in the circuit. 2

Control interface

The circuit is meant to be controlled via an external computer interface. This interface shall also be used for accessing the memory. Req. No. 29 The whole address space of the circuit shall be able to be 1 written to and read from without any occurrence of faults. As the DRFM circuit is controlled from a real-time OS, there is a restriction on the time that can be spent on sending the control data to all circuits. Req. No. 30 The sending of new control data to all circuits shall not take more than 5 ms. Req. No. 31 The sending of new control data to all circuits shall not take more than 1 ms. 1 2

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

62

Requirement Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

REQUIREMENT SPECIFICATION
Datum Date Utgva Issue ID

9 (9)

Dokumentnummer Document ID

Kristian Gustafsson, RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-04-22 1.1
Informationsklass Classification

IMPLEMENTATION 1 1 1

Req. No. 32 The circuit shall be implemented in an FPGA from Xilinx. Req. No. 33 The FPGA shall be able to be updated via JTAG. Req. No. 34 VHDL shall be used as the hardware description language.

VERIFICATION 1

Req. No. 35 After implementation the design shall be able to meet all priority 1 requirements in a post-Place&Route simulation.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

1 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

Mottagare Addressee(s)

Appendix C

Anna Goman Ulf Malmqvist Anders Nyhln Sture Carlsson

Design Specication
Saab Bofors Dynamics AB
Kristian Gustafsson [xkrgu], RTEAD
Godknd av Approved by Antal bilagor No. of appendices

ELSI. Design specification for the DRFM circuit in the TEG.

Utfrdare, tjnstestlle, telefon Issued by, department, telephone Datum Date Utgva Issue ID

DESIGN SPECIFICATION 2005-05-02 1.1

1 (14)

Dokumentnummer Document ID

Informationsklass Classification

Mottagare Addressee(s)

Anna Goman Ulf Malmqvist Anders Nyhln Sture Carlsson

ELSI. Design specification for the DRFM circuit in the TEG.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

63

64

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

2 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

INTRODUCTION...........................................................................................................3

ABBREVIATIONS .........................................................................................................3

BACKGROUND .............................................................................................................3

FUNCTION .....................................................................................................................4

4.1 INPUTS AND OUTPUTS ...................................................................................................4 4.1.1 MODE A TRIGGED MODE ..........................................................................................4 4.1.2 MODE B DELAY LINE ...............................................................................................5 4.1.3 MODE C CW MODE ..................................................................................................5 5 OVERVIEW ....................................................................................................................6

6 6.1 6.2 7

BLOCK 1: DUAL-PORT MEMORY ...........................................................................6 BLOCKRAM..................................................................................................................7 THE IMPLEMENTATION OF THE MEMORY ...................................................................7 BLOCK 2: CONTROL LOGIC ....................................................................................8

7.1 THE CONTENTS OF THE CONTROL LOGIC ...................................................................8 7.1.1 REGISTERS ...................................................................................................................9 7.1.2 THE COUNTERS ..........................................................................................................12 7.2 OPERATION DURING THE RESPECTIVE MODE ...........................................................12 7.2.1 MODE A.....................................................................................................................13 7.2.2 MODE B.....................................................................................................................13 7.2.3 MODE C.....................................................................................................................14 8 BLOCK 3: EXTERNAL COMPUTER INTERFACE ..............................................14

HARDWARE ................................................................................................................14

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

65

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

3 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

INTRODUCTION

A DRFM circuit is to be developed as a part of a masters thesis at Saab Bofors Dynamics AB in Linkping. This document specifies the design of the circuit. 2 CW DRFM ELSI LVDS TEG VME 3 ABBREVIATIONS Continuous Wave Digital Radio Frequency Memory Electronic warfare simulator Low Voltage Differential Signaling Target Echo Generator Versa Module Europe BACKGROUND

The DRFM circuit is a part of the TEG in ELSI. The main function of the circuit is to send target radar echoes, via radar equipments, to the radar seeker under test in the simulator. The radar echoes are delayed in the circuit for a period of time corresponding to the distance to the target. The present circuit can not handle new technical requirements on the simulator, see the requirement specification. Also, the functions in the current design have never been fully used and a desire of new functions has arisen. These are the reasons for developing a new DRFM circuit. Control and memory access of the circuit will be using an external computer interface. The choice of the interface will be done later on, during this thesis, or it will be done after the development of the circuit has finished. This result in that the interface specified in this document will only be a general parallel interface. In this specification it is only the DRFM functions, the interface to the computer and the communication between the two blocks that are specified.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

66

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

4 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

FUNCTION

The circuit has three different functions, working modes. These three are: Mode A Trigged mode Mode B Delay line Mode C CW mode

For every mode, different inputs and output are associated. These are described in detail in the next section. 4.1 Inputs and outputs

The following inputs and outputs are implemented in the circuit. (The ports associated to the computer interface are excluded.)
Table 4.1 Inputs and outputs.

Name RFin RFout RFpresent RFgating1 RFgating2 PRF Marker

Direction Width In Out Out Out Out In Out [13:0] [13:0] 1 1 1 1 [4:0]

Description Sampled radar pulse, in Sampled radar pulse, out Envelope signal Signal for controlling diode switches Signal for controlling diode switches Trigger pulse from radar seeker Marker signals for ECM

Mode B A, B, C A A A A, B A

4.1.1

Mode A Trigged mode

In mode A a wave form is stored in the memory of the circuit. For every received PRF the circuit is activated and the stored wave form is transmitted via RFout after a variable delay, see figure 4.1. The variable delay is equivalent to the distance to the target.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

67

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

5 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

DRFM RFout

PRF

Delay

Figure 4.1 Blocks diagram showing mode A.

During the time the wave form is transmitted, RFpresent is high. When the circuit is active the signals RFgating1 and RFgating2 can be set high during a chosen time. If needed up to five markers could be used. The distance in time between the markers and the PRF-signal corresponds to the distance between the radar seeker under test and ECM targets. 4.1.2 Mode B Delay line

During mode B data is read via RFin to the memory of the circuit and is output via RFout after an adjustable delay, see figure 4.2.

DRFM RFin PRF Delay RFout

Figure 4.2 Block diagram showing mode B.

4.1.3

Mode C CW mode

During mode C a wave form is stored in the memory of the circuit. The stored wave form is then repeatedly transmitted via RFout to form a continuous wave, CW, see figure 4.3.

DRFM RFout
Figure 4.3 Block diagram showing mode C.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

68

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

6 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

OVERVIEW

The DRFM circuit can, in its most simple form, be seen as a memory or a shiftregister where a wave form is loaded, either in advance or in real-time, and transmitted after a variable delay. Below is a block diagram showing the main building blocks of the DRFM design.

Dual-port memory

RFin [15:0]

RFout [15:0] PRF

External interface Control logic

RFpresent RFgating2 RFgating1 Markers [4:0]

Figure 5.1 Block diagram showing the design of the DRFM circuit in the FPGA.

In large, the circuit consists of three functional blocks: A dual-port memory The control logic An external interface

The three functional blocks are discussed in Chapter 6, 7 and 8 respectively. 6 BLOCK 1: DUAL-PORT MEMORY

In the memory, wave forms are stored. These can be loaded to the memory both offline, by the use of the external interface, and on-line during high frequency mode, by the use of the RFin port. The content of the memory can be retrieved either off-line, via the external interface, or on-line, via the RFout port.
Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5 This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

69

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

7 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

Because of the fact that the memory has to work as a delay line and, thus, has to be able to be written to and read from at the same time, a dual-port memory is needed. A dual-port memory has two memory ports that can access the memory at the same time and independently from each other. Xilinx has hardware support for dual-port memory in the Virtex-4 FPGAs. These integrated memory blocks are called BlockRAM, or short BRAM. 6.1 BlockRAM

A BRAM is only 18 Kbit, but several blocks can be combined to form larger memory areas. To aid the design of such larger memory areas Xilinx provides a tool called Xilinx CORE Generator (Coregen). Coregen takes parameters as inputs to generate the wanted memory. The BRAMs are possible to clock in up to 500 MHz. 6.2 The implementation of the memory

With the aid of Coregen, a memory is generated with two 14-bit memory ports. The length of the memory is set according to the requirement specification. The data input of port A is connected to RFin and the data output of port B is connected to RFout. This way the memory can be both read and written to at the same time. The port A output and the port B output is used for connecting the memory to the control logic so that the memory can be read and written from the external interface. The memory is clocked according to the requirement specification to be able to meet the requirements on precision needed.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

70

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

8 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

BLOCK 2: CONTROL LOGIC

The control logic is used for controlling the memory, generating the outputs and for communication with the external computer interface. 7.1 The contents of the control logic

The control logic contains registers, counters and remaining control logic, see Figure 7.1.

DRFM Control logic

In counter Out counter

Registers Control unit External interface

Figure 7.1 A block diagram showing the layout of the control logic.

Outputs

Time counter

PRF

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

71

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

9 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

7.1.1

Registers

The function of the circuit is controlled by registers. Control commands can be written to these by the use of the external computer interface. Even though some registers are implemented as read-only registers, all registers can be both read from and written to without errors. In Table 7.1 the registers to be implemented in the circuit can be found.
Table 7.1 Control registers in the DRFM circuit.

Register Command register Status register Delay register Pulse start register Pulse end register Marker position register x 5 Gating start register x 2 Gating end register x 2 Version register

Name CMDR SR DR PSR PER MPRx GSRx GERx VER

Type read/write read read/write read/write read/write read/write read/write read/write read

Function Control commands for the circuit. Status of the circuit. Length of the delay. Start address for loaded wave form. End address for loaded wave form. Point in time for marker generation. Start position for Rfgating1 and 2. End position for Rfgating1 and 2. Version number of the design.

Most of the registers define when, in time, different outputs appear. To be able visualize this better Figure 7.2 can be seen. This figure describes how the outputs are defined by the contents of the registers.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

72

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

10 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

PRF
DR

RFout
DR

RFpresent
GSR1

RFgating1
GSR2

GER1

RFgating2
MPRx

GER2

Markers

Figure 7.2 Diagram decscribing how the registers defines the outputs.

In the next few sections follows detailed descriptions of the contents of the registers. 7.1.1.1 Bit 0-2 Command register, CMDR Mode 000 001 Mode A 010 Mode B 011 100 Mode C 101 110 Hold 111 Run Not used States which markers to be active during run-time 0 Disabled 1 Enabled
This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

Bit 3-4 Bit 5-9

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

73

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

11 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

Bit 10-16

Not used

7.1.1.2 Bit 0-2

Status register, SR Chosen mode 000 001 Mode A 010 Mode B 011 100 Mode C 101 110 111 State of circuit 0 Run 1 Hold State of the finite state machine in the control logic block 00 Wait 01 Active 10 Load 11 Update PRF counter The number of PRF pulses received by the circuit since last reset.

Bit 3

Bit 4-5

Bit 4-16

7.1.1.3

Delay register, DR The number of clock periods to delay the signal.

7.1.1.4

Pulse start register, PSR The start address of the wave form stored in the memory.

7.1.1.5

Pulse end register, PER The end address of the wave form stored in the memory.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

74

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

12 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

7.1.1.6

Marker register, MPR1 MPR5 The number of clock periods after the PRF to wait before generation of the marker signal.

7.1.1.7

Gating start register, GSR1 and GSR2 The start position of the gating signals in terms of clock periods after the PRF pulse.

7.1.1.8

Gating end register, GER1 and GER2 The end position of the gating signals in terms of clock periods after the PRF pulse.

7.1.1.9

Version register, VER The version number of the DRFM design.

7.1.2

The counters

The time counter (TC) is an up counter, clocked with the same clock as the memory, that is activated by the PRF pulse after which it counts up continuously until all outputs have been generated. The in counter (IC) and out counter (OC) are up-counters addressing the memory. IC addresses where data on the RFin port should be written to and OC addresses where data should be read from to the RFout port. The counters are loaded with the appropriate values, depending on mode, and are clocked with the same clock as the memory. 7.2 Operation during the respective mode

The circuit should behave differently in the different modes, therefore the control logic also has to behave different depending on mode. Below follows a description of how the logic should act in the respective modes.
Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5 This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

75

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

13 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

7.2.1

Mode A

A wave form is loaded to the memory via the external interface, see Chapter 8. Mode A and active markers are set in CMDR. The delay is set in DR. PSR and PER are loaded with the start and end memory address of the pulse. MPRx are loaded with the values corresponding to the distance in time between the PRF pulse and the markers. GSRx and GERx are set to the start and end time for the respective gating signals. The circuit is activated by setting the RUN command in CMDR. The read-out is performed in the following way: The external PRF pulse activates the high frequency part of the circuit. OC is loaded with the content of PSR. TC is starting to count up from zero. During the count up, TC is compared with the register contents resulting in: When TC becomes equal to the content in DR, the memory and OC are activated. OC counts up and addresses data in the memory which is outputted by the RFout port. During the time data is outputted RFpresent is high. When OC becomes greater then PER, all bits in RFout goes low, the memory is deactivated and RFpresent goes low. When TC is in the interval between GSRx and GERx, the corresponding gating signals are high. When TC becomes equal to MPRx maker pulses are outputted from the specified makrer ports (chosen in CMDR). When TC becomes greater than the register with the highest value, TC stops counting, the high frequency part of the design goes into idle state and awaits a new PRF pulse. 7.2.2 Mode B

Mode B and active markers are set in CMDR. DR, MPRx, GSRx and GERx is loaded in the same way as in mode A. The circuit is activated by the RUN command in CMDR. IC and TC are set to zero. OC is loaded with DR, i.e. the negative delay. This results in that the delay is defined as the difference between the contens of IC and OC. IC addresses the write position in the memory for data on the RFin port and OC addresses read position in the memory for data to be outputted on the RFout port. Both counters are counting up. When the counters come to the highest position in the memory they are restarted at zero again. For every received PRF, TC is set to zero and OC is loaded with the value of IC minus the content of DR. This causes the delay to be defined as the difference between IC and OC. TC is compared to the registers in the same way as in mode A to be able to generate the remaining outputs.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

76

Design Specication

Saab Bofors Dynamics AB

Utfrdare, tjnstestlle, telefon Issued by, department, telephone

DESIGN SPECIFICATION
Datum Date Utgva Issue ID

14 (14)

Dokumentnummer Document ID

Kristian Gustafsson [xkrgu], RTEAD

Godknd av Approved by Antal bilagor No. of appendices

2005-05-02 1.1
Informationsklass Classification

7.2.3

Mode C

A wave form is loaded to the memory via the external computer interface. Mode C is set in CMDR. PSR and PER is loaded in the same way as in mode A. The circuit is activated by the RUN command in CMDR. After the circuit has been activated, OC is loaded with the content in PSR and starts to count up with the specified frequency. OC addresses data in the memory and outputs it through the RFout port. When OC is equal to the content of PER OC is loaded with PSR again and starts counting up again. The result is a continuous wave form. 8 BLOCK 3: EXTERNAL COMPUTER INTERFACE

The external computer interface is used for communication with the communication interface that will be chosen to accompany the circuit. Until the interface has been chosen, which will be done after this project has ended, the interface in the FPGA is implemented as a black box with a general parallel interface to the external world. This is done so that the external interface can be chosen later. 9 HARDWARE

The DRFM design will be implemented in a Virtex-4 FPGA developed by the American company Xilinx. The circuit will be attached on a VME circuit board and mounted in a VME rack in the TEG in ELSI. The Virtex-4 circuit has support for LVDS signaling. This standard will be used for the ports associated with the high frequency part of the circuit, i.e. the RFin and RFout ports. The rest of the ports will be standard TTL level ports.

Denna handling och informationen hri r Saab Bofors Dynamics AB egendom och fr ej anvndas, delges obehriga eller ndras utan Saab Bofors Dynamics AB skriftliga medgivande. p16/allmnblankett.dot/utg5

This document and the information contained herein is the property of Saab Bofors Dynamics AB and must not be used, disclosed or altered without Saab Bofors Dynamics AB prior written consent.

Ext. CLK & RST

CLK_EXT

Appendix D

RST_EXT

Int. CLK & RST

CLKFX_OUT

Interface signals

Test Wave Forms

Figure D.1. Test of writing and reading the memory.

77
2000 3333
9999 3333

REQ

ACK

WRITE

Inputs

mem_reg 1000 2000 3000 0 0 5089 1 112 2 100 3 52

addr 0 1000

data 0 9999

78

Ext. CLK & RST

CLK_EXT

RST_EXT

Int. CLK & RST

CLKFX_OUT

Interface signals

REQ

ACK

WRITE

Inputs

mem_reg 3 52 100 200 150 300 190 4 5 6 7 8 9 10 11 390 12 220 13 450 14 112 15

addr 3000

Figure D.2. Test of writing to the registers.

data

5089

112

100

Test Wave Forms

Ext. CLK & RST

CLK_EXT

RST_EXT

Int. CLK & RST

CLKFX_OUT

Interface signals

REQ

ACK

WRITE

Inputs

mem_reg 3 52
100 100 200 150 300 190

addr 15

10
190

11
390

12
220

13
450

14 1

15 0

Figure D.3. Test of reading from the registers.

data 112

5089

100

79

80

Ext. CLK & RST

CLK_EXT

RST_EXT

Int. CLK

CLKFX_OUT

DRFM inputs

PRF

DRFM Outputs

RFout_O

RFpresent

RFgating1

RFgating2 00001 00000

10000 10010 00010

Marker 00000

00100 00000

00000

01000 00000

Figure D.4. Test of mode A.

(5)

(4)

(3)

(2)

Test Wave Forms

(1)

Ext. CLK & RST

CLK_EXT

RST_EXT

Int. CLK & RST

CLKFX_OUT

DRFM inputs

PRF

RFin_I

Outputs

RFout_O

RFpresent

RFgating1

RFgating2
01000

Marker 00000

00001

00000

00100

00000

00000

00000

00001

00000

00100

00000

00000

01000

00000

Figure D.5. Test of mode B.

(5)

(4)

(3)

(2)

(1)

81

82

Ext. CLK & RST

CLK_EXT

RST_EXT

Int. CLK & RST

CLKFX_OUT

Outputs

RFout_O

RFpresent

RFgating1

RFgating2

Marker 00000

(5)

(4)

Figure D.6. Test of mode C.

(3)

(2)

(1)

Test Wave Forms

Ext. CLK & RST

CLK_EXT

RST_EXT

Int. CLK & RST

CLKFX_OUT

Interface signals

REQ

ACK

WRITE

Inputs

mem_reg

addr 0
75
225
679

2 3 4 5 6 7 8 9 10 11 12 13 0

data

5095

200

50

100 200

50

250

30 50

100 150

DRFM inputs

PRF

Outputs

RFout_O

RFpresent

RFgating1

RFgating2
00000

Marker 00000
01000

00001

00000

00100

00000

00000

10000

00000

00001

00000

00100

00000

(5)

(4)

(3)

Figure D.7. Test of updating the registers in real-time (Mode A).

22 us 23 us 24 us 25 us 26 us

(2)

(1)

83

21 us

Entity:top_chip_tb Architecture:struct Date: Fri Oct 14 14:43:27 HDT 2005 Row: 1 Page: 1

P svenska Detta dokument hlls tillgngligt p Internet eller dess framtida ersttare under en lngre tid frn publiceringsdatum under frutsttning att inga extraordinra omstndigheter uppstr. Tillgng till dokumentet innebr tillstnd fr var och en att lsa, ladda ner, skriva ut enstaka kopior fr enskilt bruk och att anvnda det ofrndrat fr ickekommersiell forskning och fr undervisning. verfring av upphovsrtten vid en senare tidpunkt kan inte upphva detta tillstnd. All annan anvndning av dokumentet krver upphovsmannens medgivande. Fr att garantera ktheten, skerheten och tillgngligheten nns det lsningar av teknisk och administrativ art. Upphovsmannens ideella rtt innefattar rtt att bli nmnd som upphovsman i den omfattning som god sed krver vid anvndning av dokumentet p ovan beskrivna stt samt skydd mot att dokumentet ndras eller presenteras i sdan form eller i sdant sammanhang som r krnkande fr upphovsmannens litterra eller konstnrliga anseende eller egenart. Fr ytterligare information om Linkping University Electronic Press se frlagets hemsida http://www.ep.liu.se/ In English The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linkping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/ Kristian Gustafsson