Design of an Emulation Platform for the Test and ...ingo/MasterThesis/Hernandez.pdf · In this thesis an Emulation Platform for VHDL IP cores dedicated to ... RF-based embedded systems

Design of an Emulation Platform for the Test and

Validation of Communication Enhancement IP

Cores using VHDL

Pedro Antonio Hernandez Fernandez

June 22, 2004

1

To my grandfather. . .

Abstract

In this thesis an Emulation Platform for VHDL IP cores dedicated toprocessing tasks and communication enhancement in a wireless system hasbeen designed. The non-deterministic nature of the wireless medium andits harming effect on the communication signals make emulation a betterfitting tool for test and validation than simulation. This platform is alsoexpected to anticipate most of the results of the field tests that, in followingstages, would be performed in order to estimate the benefits of the aforementioned IP cores, which will result in a decreasing time to market for theapplications within the scope.

To deal with the validation and test of the IP modules, a complete andversatile test vehicle has been designed using VHDL. With the aim of porta-bility and reusability, this test vehicle, in which those communication en-hancement IPs perform their processing functions on the provided data,permits the easy implementation of different architectures. It also addsthe capability of observing the behaviour of each block of any architecturethrough diverse debugging mechanisms.

Specific software has also been developed for the control and automationof the test process, for the generation and storage of the obtained statisticsand for their graphical representation and analysis.

Acknowledgements

This thesis and what it means wouldn’t have come out if some people, actu-ally a lot of people, hadn’t crossed my way, starting with that person thatgot into my head the not-at-all good idea of studying TelecommunicationsEngineering and all the people that I met while doing so, ”telecos” andnon-”telecos”.

Special thanks to the whole NPI & Design Services department of Ce-lestica Valencia. There I have learnt some unexpected things that Universitydoesn’t teach you. And to the IMIT and the SoC Master Program at KTHfor supposing an important part in my formation.

Of course, thanks to all the people that suffered Kista-Ghetto ’02-’03 andsurroundings with me, for easing the Swedish winter with lessons from Proff.Martin Simlastik (no, here I won’t call you bu....) and the special bottles ofhis roommate. Ondrej, I will always beat you playing darts. To Juan (”elatrapao”) and his multiple roommates, the one that left us alone when thewinter was coming, Nacho that sold him for a Polish, and the last one, yes,Gustavo, they will always be ”mean and selfish”...

To Carlos and his fabulous tequila, Santiago, Blas, their ”chingada” andtheir ”uey”. To the Frenchs, those football (and frisby) matches and that or-ganization, it was nice to see you in Valencia. It was also really nice to haveyou here, Andre, and to hear you in Spanish. To the Russians and the Rus-sian parties where you could see things like Scrabby drinking vodka (thanksPasha for that guided tour through St. Petersburg and Moscow)...But thebest vodka was mixed with apple juice and was brought by Magda and Izafrom Poland.

1

2

Ariel, you deserve a new paragraph, thanks for so many coffees, cakes,dinners... and helps. And you, Sam... you would deserve this whole report.Yes, I will always be to blame, and I hope you can put the blame on me lotsof more times, I will just need to know it to smile.

Congratulations to Mr. Gompacho, a new language that was able to bearme during ten months within the same 25 square meters.

There were also Swedish people that had to put up with me, yes, a KTHvolleyball team that didn’t have anything to do with KTH. They were quiteold but they could already ”hit the fucking ball”, and they introduced mein the beer-after-the-training culture. Thanks Jori, Josef, Beng, P.J., Jim,Ingve,... and thanks Wilco, for everything.

Thanks Joel, for everything you have had to do for this thesis, withoutyou it wouldn’t be as it is (not only the thesis).

And thanks grandpa, but not for this thesis...

Contents

1 Introduction 9

2 Objectives 13

3 State of the Art 153.1 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 KNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Analyst’s Review . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Architectural Overview 244.1 IPs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 802.15.4 Differential Codec IP . . . . . . . . . . . . . . 254.1.2 Manchester Codec . . . . . . . . . . . . . . . . . . . . 274.1.3 Convolutional Coding & Viterbi Decoding . . . . . . . 274.1.4 Reed Solomon (11,15) . . . . . . . . . . . . . . . . . . 294.1.5 Interleaver / Deinterleaver . . . . . . . . . . . . . . . . 304.1.6 802.15.4 CRC / KONNEX CRC . . . . . . . . . . . . 314.1.7 Additional IPs . . . . . . . . . . . . . . . . . . . . . . 31

5 FPGA1 Test Vehicle 335.1 Host Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Storage & Control . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Signal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Clock Generator . . . . . . . . . . . . . . . . . . . . . . . . . 385.5 Configuration & Debug . . . . . . . . . . . . . . . . . . . . . 395.6 FEC & Encoding-Spread Spectrum Stages . . . . . . . . . . . 40

3

CONTENTS 4

6 Emulation Platform: Hardware 426.1 Host Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Transceiver Emulator . . . . . . . . . . . . . . . . . . . . . . . 446.3 Wireless Transmission Model (WTM) . . . . . . . . . . . . . 44

7 Emulation Platform: Controller Software 48

8 Emulation Results 56

9 Future Lines of Action 60

10 Conclusion 62

A Target Technology, the Actel ProAsicPLUS Family 63

B Software Tools & Design Flow 66

List of Figures

3.1 ZigBee/IEEE 802.15.4 Relationship . . . . . . . . . . . . . . . 20

4.1 General System Architecture . . . . . . . . . . . . . . . . . . 254.2 VIPERS Digital IP Blocks interconnect capabilities . . . . . . 264.3 Manchester Coding . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Convolutional Coder . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 FPGA1 interface . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 FPGA1 Internal Block Diagram . . . . . . . . . . . . . . . . . 355.3 Host Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4 Storage & Control . . . . . . . . . . . . . . . . . . . . . . . . 375.5 Signal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 385.6 Configuration & Debug Module . . . . . . . . . . . . . . . . . 39

6.1 Host Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Transceiver Emulator . . . . . . . . . . . . . . . . . . . . . . . 456.3 Emulation Platform Hardware . . . . . . . . . . . . . . . . . 47

7.1 Start-up Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2 Starting Session . . . . . . . . . . . . . . . . . . . . . . . . . . 507.3 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.4 IPs tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.5 WTM tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.6 Test tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.7 Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.8 Graphical Results Viewer . . . . . . . . . . . . . . . . . . . . 55

8.1 Frame Loss vs. BER results . . . . . . . . . . . . . . . . . . . 588.2 Frame Loss vs.Frame Length results . . . . . . . . . . . . . . 59

A.1 ProAsicPLUS Core Logic Tile . . . . . . . . . . . . . . . . . . 64

5

LIST OF FIGURES 6

A.2 ProAsicPlus APA1000 Evaluation Board . . . . . . . . . . . . 65

B.1 Libero IDE Design Flow . . . . . . . . . . . . . . . . . . . . . 67

LIST OF TABLES 7

List of Tables

4.1 Irreducible Polynomials of Galois Field . . . . . . . . . . . . . 30

5.1 Available Frequencies at Clock Generator output . . . . . . . 39

8.1 Emulation Parameters . . . . . . . . . . . . . . . . . . . . . . 57

LIST OF TABLES 8

List of Abreviations

• ASIC: Application Specific Integrated Circuit

• BER: Bit Error Rate

• CRC: Cyclic Redundancy Code

• CSMA/CA: Carrier Sense Medium Access with Collision Avoidance

• DSSS: Direct Sequence Spread Spectrum

• FEC: Forward Error Correction

• FIFO: First In First Out

• FPGA: Field Programmable Gate Array

• IP: Intellectual Property

• IST: Information Society Technologies

• KNX: Abreviation for Konnex

• MAC: Medium Access Control. One of the layers in the stack of acommunication system

• NLOS: Non Line of Sight

• RF: Radio Frequency

• RS: Reed Solomon

• SoC: System on Chip

• SS: Spread Spectrum

• VIPERS: Virtual IP Environment for Rapid Silicon

• WTM: Wireless Transmission Model

Chapter 1

Introduction

This thesis is framed by the European Information Society Technologies(IST) Programme project called VIPERS, standing for ”Virtual IP En-vironment for Rapid Silicon”. VIPERS aims to develop new solutions forRF-based embedded systems for control applications, built on a set of ASICmacrocells for RF links and a novel virtual prototyping environment forrapid design and IP reuse, and driven by final user needs in the home au-tomation area (domotics).

Data-oriented communication applications, specially for short range, arenowadays well covered by solutions like Bluetooth. However there is noalternative for smaller bandwith, smaller cost and wider range control ori-ented communication applications. There is still a gap in the technologicaldevelopment status of RF devices for medium distance, control orientedcommunication systems.

These products require medium bandwith and secure transfers rather thanhigh bandwith data intensive ones. Hence, they do not need a high comput-ing power but a high level of integration, so the final system includes RFmacrocells, microprocessor core, memory and other periphery on a singlechip. But above all, they must be low cost, low power operating devices.

Most of the products available on the market are based on discrete solu-tions. The reason for this is that there are no easy, powerful and flexibletools to develop custom devices. One of the intentions of VIPERS is toovercome this problem and try to propose standards available for a largercommunity.

9

CHAPTER 1. INTRODUCTION 10

The industrial partners of the VIPERS consortium have their interest inthe development of new products for device control and intercommunicationin home and industrial environments. Around this field there has been alot of work in progress in the direction of supporting high bit rates formultimedia applications, requiring complex and silicon-consuming deviceswhich results in off-the-self solutions. When VIPERS started that was thedominant tendency, and what VIPERS proposed was a totally innovativesolution. Nowadays some other groups are also making a great effort in thislow cost, low power way.

As we are saying, the approach taken in VIPERS is different. It is consid-ering simpler applications where integration, cost and power are the mainissues due to size and market constrains, so a SoC is required as the keyelement of a low-cost long range and low power embedded applications.

The basic elements in this SoC are the small low power RF macrocells andtheir companions, the digital IP blocks that provide some communicationfunctions to be performed either by hardware or by software, i.e. ForwardError Correction, Encryption, etc.

The RF macrocells cover both the 433 MHz and 868-915 MHz ISM bands.This transmission bands are chosen in comparison to the 2.4 GHz ”Blue-tooth” band for reasons of range and cost. However they present somedrawbacks that have to be overriden, as for example, 900 MHz is definitelythe noisiest band of them all, with cordless telephones and hundreds ofconsumer devices occupying this small sliver of spectrum. The biggest ad-vantage of the 900 MHz band is its ability to achieve true and consistentNLOS (non-line-of-sight) connectivity.

There is also a methodological effort within VIPERS. It is dedicated toovercome the difficulties laid by the combination of specific characteristicsof embedded systems together with radio communications, integrated on apackaged microelectronic product, and also to perform the intensive vali-dation required to avoid extra non-recurring costs and to meet the time tomarket requirements.

Therefore, a virtual prototyping environment is intended to support con-ceptual modelling, enabling a VIPERS technology customer to rapidly visu-


alise a proposed product and incorporate high-level behavioural models ofpreviously designed IP blocks (both hardware and software).

This methodology support issues related to virtual modelling tools withthe main objective of validating the system at a functional level, rapid pro-totyping tools through emulation on configurable FPGA-based prototypes,estimation tools for power and quality assessment, and remote configuration,diagnosis and testing tools.

The resulting high-level model will constitute an executable specificationof the candidate application. The high-level modelling environment will linkto other stages in the embedded system development toolchain, includingsystem hardware emulation, assessment of design features such as imple-mentation reusability, power consumption, gate count, etc. Refined designswill be suitable for System-on-a-Chip ASIC or FPGA plus RF componentsimplementation.

With this combination of IP Library, Methodology and Tools one of themain objectives within VIPERS is to shorten and optimize the developmentof the afore mentioned applications, resulting in a wide range of imple-mentations supported from board-level based on FPGAs to a fully inte-grated System-on-Chip reducing time to market and development invest-ment through IP reuse.

Among all aspects described above, this thesis will be focused on thedevelopment of an emulation and test platform for different hardware IPblocks for communications. Emulation is a key procedure in the developmentof these systems due to the non-deterministic characteristics of the physicalmedium that make simulation just useful at a functional level but not as atest and validation tool.

The next chapter describes the specific Objectives that this thesis is deal-ing with, giving an idea of what was expected to obtain at its end. Then, abrief exposition of the State of the Art is presented in chapter 3, and togetherwith this Introduction, concisely frames this thesis within its environment.Chapter 4 introduces the IP cores to be the object of test and validation, forthe FPGA1 Test Vehicle section to start the description of the developedhardware. Afterwards the top module of this thesis, the emulation platform


is exposed in chapters 6 and 7. Finally, the first obtained Emulation Resultsand the Future Lines of Action are explained through sections 8 and 9.

Chapter 2

Objectives

As it was said before, within the VIPERS project, this thesis focuses onthe development of an emulation and test platform for different hardwareIP or building blocks for communications. Through the use of this plat-form design, validation of those digital IPs will be achieved and their designrefined.

Consequently our work will participate in the development of a librarythat will contain the foresaid IPs for RF communications and networking.This work comprises the development of some VHDL module descriptions,some of which may be synthesised on either FPGAs or custom silicon.

Some of this hardware and software modules are complementary, it is,they perform the same basic functions, allowing different architectural im-plementations for a given application. A performance-cost and power-areatrade-off analysis, derived from the results of the system modelling will givethe capability to select the best suited solution.

Also, a common feature of all the designed IPs will be the reusability,what requires independence of implementation technologies and building acomplete and accessible documentation.

Following what has been stated before, the next objectives are to be met:

• Design of a subsystem that will implement the communication tasksbetween a RF-transceiver and a host. This subsystem will containdifferent IP blocks to perform basic functions and will act as a testvehicle for the emulation and test of those IP blocks.

13

CHAPTER 2. OBJECTIVES 14

• Synthesis, validation and test of the foresaid test vehicle.

• Implementation on the chosen FPGA, validation and test of the pre-viously designed IP blocks. Characterization.

• Development of an Emulation Platform on a unique FPGA usingVHDL and a Wireless Transmission Model (WTM) for the standard900 MHz ISM band also developed in VHDL.

• Test of different combinations (architectures) of IP blocks under dif-ferent conditions (BER, collision rate . . . ) using the afore mentionedEmulation Environment. Extracting results and statistics from thedifferent tests.

Upon completion of these tasks we will have:

• A library of IPs totally validated and characterized.

• Valuation of the performance (area, power consumption, timing...) ofthose IPs as a function of communication characteristics.

• An emulation and test platform that will allow the easy and rapidvalidation and characterization of different architectures for differentcommunication parameters.

Chapter 3

State of the Art

Traditionally, research in the field of wireless communications have beendevoted to the development of high data rates, and multimedia orientedapplications. In the beginning of VIPERS, its field of application was almostunexplored. Just a few of standardization initiatives, such as RF-Lite orHome-RF, had came up by then. And none of them succeeded.

However, nowadays, the situation is not even similar. According to recentstudies, market volumes for the low cost, low data rate wireless applicationswould enter in an enormous growth process, reaching almost the 600 millionof units by the 20051. Is for that reason that different organizations, pushedby the big companies, are trying to present a standard and interoperablesolution.

The main work groups and standard protocol initiatives for the homeautomation area are:

• ZigBee

• KNX

• HomeRF-SWAP

• CEBus

• IEEE P802.15.1Source: Dataquest

15

CHAPTER 3. STATE OF THE ART 16

Other proprietary solution exist: Easy-Radio (Low Power Radio SolutionInc.), HomeConnex (Peracom Networks), No New Wires (Intellon Corp.),Sharewave (Sharewave Inc.), SoapBox (VTT Electronics) or Z-wave (Zen-sys), however when interoperability is pursued a standard approach wouldbe the option of preference.

The 900 MHz ISM band is currently the most popular choice for ”com-modity” wireless transceivers, largely because of the ready availability ofattractively priced products. These systems typically operate at very lowdata-rates, and often use relatively simple high-frequency electronics. Exam-ples include wireless data modems, intrusion alarms, remote light switching,remote meter reading,

But this is certainly also the noisiest band, with cordless telephones andhundreds of consumer devices occupying this part of spectrum. The biggestadvantage of the 900 MHz band is its ability to achieve true and consistentNLOS (non-line-of-sight) connectivity.

The most common transmitter architecture for this band is either a mod-ulated VCO (e.g. FM) or a simple digital scheme with frequency shift keying(FSK) or bi-phase shift keying (BPSK) modulation. The simple nature ofthese architectures results in functionality at a low price. High performancediscrete transistors are the components of choice, plus a few cost-effectiveintegrated circuits or ASICs for higher-level functions.

It is in the aim of the project to be as general as possible by takingadvantage of the work already done by the different standardization bodies,usually with different and strong companies beyond them. In that senseZigbee appeared as an interesting and powerful trend, and Konnex could beimportant as well, taking into account the final user in the VIPERS project.HomeRF is restricted to 2,4 Ghz and CEBUS is an american 915 Mhz band.

Thus, the two protocol stacks to be analyzed are Konnex and Zigbee, andthey are the ones that have been considered when the different IP blocksthat will constitute the architecture were designed. They differ basically inthe power requirements. While Konnex is mainly oriented to mains poweredapplications, as for example white goods, Zigbee is much more oriented tolow power consumption battery powered devices.


Zigbee implements IEEE 802.15.4’s lower layers that are where we shouldconcentrate our work in the VIPERS development in a first stage. It hasthe advantage of be an open/free standard, due to IEEE 802 group policyof giving its standards for free after six months of its publication. Konnex(KNX) however is a proprietary solution. Nevertheless the cost is not veryhigh and they are contributing to the CENELEC TC-205 technical body.KNX has the advantage of being more aligned with the final user partnerin the VIPERS Consortium product type in the sense that it’s born inthe niche of Home Automation products, for non-mobile AC plug devices.802.15.4 have a wider scope (low cost, low power short range devices forindoor applications). Knx interoperability will be restricted probably towhite goods applications while 802.15.4 will offer a broader interconnectionspectrum, and in that sense and thinking in a long term, Knx would probablyneed to establish gateways to other platforms to be competitive.

The main disadvantage of both initiatives is the absence of technical doc-umentation, KNX RF link is not really mature and 802.15.4 even if muchmore elaborated is still under draft status.

3.1 ZigBee

A little desciption of the ZigBee stardization body is given in advance. Amore detailed information can be found in [4] and [5].

ZigBee (formerly called as PURLnet, RF-Lite, Firefly, and HomeRF Lite)is a new short-range radio standard under development. ZigBee originatesfrom the HomeRF alliance, where the need of a low-capacity radio net-working solution to homes was seen in addition to a high-capacity WLANsolution.

ZigBee is a low-power, low-rate, short-range wireless radio solution. Com-panies developing the ZigBee have formed a ZigBee Working Group. TheWorking Group is also taking part in IEEE 802.15 Task Group 4 standard-ization process and giving the ZigBee solution as a basis for the standard.

The aim of the ZigBee Working Group is to bring about the existence of abroad range of interoperable consumer devices by establishing open industryspecifications for unlicensed, peripheral, control and entertainment devices


requiring the lowest cost and lowest power consumption communicationsbetween compliant devices anywhere in and around the home.

It operates at the 2.4 GHz unlicensed frequency band using direct se-quence spread spectrum (DSSS) technique and also in two other unlicensedfrequency bands: 915 MHz frequency band in the United States and 868MHz frequency band in Europe.

The MAC protocol of ZigBee is CSMA/CA (carrier sense multiple accesswith collision avoidance) but it is also possible to utilize time slots as inTDMA (time division multiple access) to support critical latency devicessuch as joysticks.

ZigBee should be working with two AA-batteries from 6 to 24 months,depending on activity and used transmission power.

There are three different network topologies defined in ZigBee:

• master-slave,

• peer-to-peer and

• mesh mode

The standardization work was expected to be finished by the end of theyear 2002, but it still not released. ”We expect that to take only a num-ber of months, because we are basically in total consensus on it”, said PatKinney, chairman of the IEEE 802.15.4 subcommittee and secretary of theZigBee Alliance on December 2003.”The biggest thing right now is what dowe include in it”.

3.2 IEEE 802.15.4

A little desciption of the ZigBee stardization body is given in advance. Amore detailed information can be found in [5].

The IEEE.802.15 Task Group 4 is the Working Group for Wireless Per-sonal Area Networks (WPAN). There exist still not a real standard justdraft proposals.


The aim of the standard is to specify physical and MAC level requirementsfor low capacity wireless devices with multi-month to multi-year battery life,and is intended to operate in an unlicensed, international frequency band.

They work in co-operation with the ZigBee Working Group, and aim at acommon standard. The task of the ZigBee Working Group is to define theupper protocol layers.

The main protocol features are:

• Data rates of 250 kbps and 20 kbps (will presumably be unified withthe ZigBee 28 kbps definition)

• Master-Slave or Peer-to-Peer operation.

• Up to 254 network devices or 64516 distribution nodes.

• Support for critical latency devices, such as joysticks.

• CSMA/CA channel access.

• Automatic network establishment by the coordinator.

• Dynamic device addressing.

• Fully handshaked protocol for transfer reliability.

• Power management to ensure low power consumption.

• 16 channels in the global 2.4GHz unlicensed band (DSSS modulation),10 channels in the 915MHz unlicensed band (USA) and one channelin the European 868 MHz band.

The specification stands for physical, MAC layers, and also incorporatesthe Service Specific Conversion Layer (SSCS) for interconnection with the802.2 Logic Link Control. Fig. 3.1 shows the layer structure and its relationwith the 802.15.4 standard:

3.3 KNX

A little desciption of the ZigBee stardization body is given in advance. Amore detailed information can be found in [3].


PURL Ntwk Layer

MESH Ntwk Layer

Custom Ntwk Layer

Application Convertion Layer Custom App. Conv. Layer

ZigBee Standard

802.15.4 MAC

802.15.4 868/915 MHz PHY

802.15.4 LLC 802.15 LLC-1

802.15.4 915/2400 MHz PHY

IEEE Standard

Figure 3.1: ZigBee/IEEE 802.15.4 Relationship

The Konnex Association was founded in 1999 as a consortium amongBatiBUS Club International (BCI), European Installation Bus Association(EIBA), and European Home Systems Association (EHSA). The idea wasto combine the previously competing low capacity home and building net-work standards to a single open standard called KNX. The standard shouldprovide connectivity as well as interoperability between devices. There is agreat effort for KNX becoming a global standard, however no radio bandsoutside Europe have been defined so far.

The standard is based on the communication stack of EIB (European In-stallation Bus) but enlarged with the physical layers, configuration modesand application experience of BatiBUS and EHS (European Home Systems).The standard covers three different configuration modes and four differentnarrowband network media. With this four different media in the Standard,installers can adapt the network to the conditions of the building and the dif-ferent functions required. It increases their possibility to fulfil the technicalspecifications. One of the configuration modes is intended for automatic,plug-and-play device discovery and configuration for domestic appliancessuch as washing machines etc.


The IP-based communication protocol is the same regardless of whichnetwork media is used. Among the media are at least twisted pair, powerlinedata and 868.3 MHz short-range radio. The radio uses Manchester codingand FSK modulation at 16384 bps data rate. A minimum transmit powerof 1 mW (0 dBm) has been defined. The maximum allowed transmit poweris 25 mW in this band.

Recently, the Konnex / KNX technology has become the worlds first open,royalty-free and hardware platform independent, standard for home & build-ing control. All the member companies who contributed to the developmentand realisation of the KNX technology have agreed to grant licenses on the61 patents that are necessary for the implementation of products based onthe KNX technology, version 1.0.

The KNX technology is the worlds first approved standard in this area ofcommunications that:

• Is completely free of additional royalty charges for Konnex members.

• Is completely independent of any specific hardware / software technol-ogy platform.

• Has application profiles incorporated as an integral part of the stan-dard.

• Has an compulsory product certification procedure to guarantee multi-vendor interworking allowing certified products to be marked with theKNX trademark logo.

• Has an integrated software tool for installation planning, engineeringand commissioning.

3.4 Analyst’s Review

In this scenario of draft proposals and no dominant standards, expectationsand time to market become critical issues for success. The election of thearchitecture to be implemented will condition the acceptance or rejection ofthe final product by the market.

We have been searching for different analysts’ opinions to try to offer anaccurate picture of what will happen in the coming future.


For Gartner’s analysts ”Many more devices will support wireless tech-nologies in 2004, from mobile phones and entertainment systems to homeappliances”. But they also warn that ”In combination with a lack of stan-dards in many areas, this will create confusion”.

For the close future, Gartner remarks that ”Technology using the 802.15.4/Zig-Bee standard will help automate machines, but integral design will take yearsdue to long product development cycle times”. As we have seen, VIPERStries to find its entry point at this weakness, shortening this long productdevelopment.

West Technology Research Solutions LLC (WTRS), a market research firmfocusing solely on emerging technologies reported that ”ZigBee will domi-nate two-way low data rate wireless applications in the home”. In addition,it provides corporate profile information of some of the companies currentlydeveloping to the ZigBee protocol.Companies profiled at some length includeAdcon Telemetry AG, Agere Systems, AMI Semiconductor, Atmel, EatonCorporation, Ember Corporation, ENQ Semiconductor, Helicomm, Integra-tion Associates, Invensys, Microchip Technology, Millenial Net, MitsubishiElectronic Industrial, Motorola, and Philips Semiconductors.

The future looks promising for the up and coming Wireless PAN (WPAN)technology, 802.15.4, and ZigBee, according to In-Stat/MDR: ”We expectcommercial building control to capture the lions share of the budding 802.15.4/Zig-Bee market, while residential automation and industrial applications fol-low.According to the high-tech market research firm, however, quite a bithinges on the ability of the ZigBee Alliance to deliver a final specificationin a timely manner, including completed, successful interoperability tests.If these milestones are not achieved in a reasonable amount of time, othercompeting wireless technologies could take hold in these markets, such as ayet-to-be-determined low-rate Ultra-Wideband WPAN alternate PHY or apotential Bluetooth Lite version. So, there is an impetus felt in the ZigBeeAlliance to move forward according to schedule”.

In an aggressive forecast, they predict ” 802.15.4/ZigBee nodes/chipsetannual shipments in 2008 to break 160 million”. Average sales prices willrapidly decline; however, the average pricing for all shipments will be de-pendent on the ratio of reduced function devices to full function devices.


In-Stat/MDR sees the 802.15.4/ZigBee market being dominated by the2.4GHz band; however, there is significant activity for 915MHz, primarilyin North America.

Karen Brown wrote for Wireless Week : ”With interoperability guidelinesclose to completion, backers of the ZigBee wireless scheme hope to createa market buzz.But while its focus is largely on automated systems, ZigBee’smarket adoption is by no means automatic. It has the backing of an industrymarketing and interoperability forum, but it still must face a rough-and-tumble wireless networking market where it could get lost in the crowd”.

According to that article, Motorola already has developed an accelerationand pressure sensor chip using the planks of the draft ZigBee specifications,and it is now making samples available. CompX recently announced itsBlencathra software and silicon platform is the first to win IEEE 802.15.4compliance certification from National Technical Systems Inc. But while thecompany firmly backs ZigBee and has a product based on the draft specifi-cations, it also is creating 802.15.4 products based on five other proprietaryschemes.

Analyst Kristen West of West Technology Research Solutions LLC saysZigBee chipset shipments likely will reach about 600 million units worldwideby 2008 and forecasts the overall market for ZigBee to exceed $500 millionby 2005, while fellow analyst firm ABI predicts U.S. residential ZigBee ship-ments will grow to more than 171 million by that time.

As we can see, this wireless applications’ world is in rapid movement andin a crucial phase for its development. VIPERS is right in the middle, devel-oping a new technology that contributes to the settlement and consolidationof this world of possibilities.

Chapter 4

Architectural Overview

Since it is in the aim of the project to be as general as possible, the twoprotocol stacks that have more importance currently in the frequency bandof the 900 Mhz would be used as a guide in the developments: Konnex andZigbee.

VIPERS will try to offer the broadest variety of Ips, developing modulesfor the two alternatives. It is planned to develop IP blocks for the lowestlevels of the architecture, that is Physical, MAC and Link Layer.

There are also several IPs that are of interest for generic wireless ap-plications and that do not appear in any of the two previously identifiedinitiatives, such as frequency hopping, encryption,. . . but that have beenconsidered could greatly enhance the transmission performance. The mostgeneral architecture we foresee is shown in fig. 4.1

The intention is to evaluate the IPs’ influence over the communicationperformance and to find the optimal configuration for the application, basedon quality parameters and cost.

The figure also shows which are the IPs considered more efficient to havein HW, which are the ones in the path from CSMA control to the lowestlevel function, leaving Application and other Link and MAC functions to theSW arena. Note that compression and encryption appear in the SW section,however DES Encryption could be very well and efficiently implemented byhardware as well.

24

CHAPTER 4. ARCHITECTURAL OVERVIEW 25

Application Data

Link/MAC frames

Compress/ Encypt

Modulation Spread

Spectrum FEC

PHY frames

Demodulat ion

Correct/ Detect

Despread Application

Data Decompr/ Deencrypt

Link/MAC protocol

PHY frame

Hardware Implemented

Hardware Implemented

Fading Inter-channel Interference

AWGN Inter-symbol Interference

Analog

Figure 4.1: General System Architecture

At the end we will have a set of library functions that will allow us toconfigure and implement, as in a puzzle, systems with more or less com-plexity based on the architecture depicted in fig. 4. Note that some of theblocks are optional or will have two different options for a particular cat-egory. In addition to those application specific configuration we will haveother general purpose IPs such as the I2C, parallel port, UART, etc

Through the next sections an overview of the different IPs that are tobe validated is made. As it is not the aim of this thesis, they will not beexplained in detail but just a little introduction to them and their function-ality is given. A deeper information about the implemented techniques canbe found in [12] to [23].

4.1 IPs Overview

In the next subsections the different IPs that had been previously developedat the company and that were to be validated, and their functionality willbe briefly described.

4.1.1 802.15.4 Differential Codec IP

The core developed is intended to the differential encoding and decodingprocess for the 802.15.4 physical layer on the 868/915 Mhz band, as describedin the standard draft D14 of April 2002, subsection 6.6.2.3.

Differential Encoding is the modulo-2 addition of a raw data bit withthe previous encoded bit. This is performed by the transmitter and can be


Diffrential Enc Mancherster

Freq. Hopp. Ctrl. Freq. Hopp. Acq.

M-Sequence Sliding Correlator

Convolutional Enc Viterbi Decoder

Reed-S. Encoder Reed-S. Decoder

Interleaver

IEEE 802.15.4 Konnex

CSMA/CA CRC

Modulation

Spread Spectrum

Error Detection/ Correction

PHY Processor

MAC

Xcver

Application

Encryption Link Processor

Figure 4.2: VIPERS Digital IP Blocks interconnect capabilities

described by eq. ( 4.1):

En = Rn ⊕ En−1 (4.1)

where Rn is the raw data bit to be encoded, En is the correspondingencoded bit and En−1 is the previously encoded bit. For each frame trans-mitted, R1 is the first raw data bit to be encoded and E0 is assumed to bezero.

The decoding process, as performed at the receiver, can be described byeq. ( 4.2):

Rn = En ⊕ En−1 (4.2)

For each received frame E1 is the first bit to be decoded and E0 is assumedto be zero.


This IP shows its functionality when phase problems appear (like signalinversion), and is able to detect errors and correct some of them.

4.1.2 Manchester Codec

In the Manchester code the bit value is represented by a transition ratherthan a level. The transition occurs at mid-bit, with a low-to-high transitionused to represent a logic ’0’ and a high-to-low to represent a logic ’1’. Thatbehavior is shown in fig. 4.3

0 0 0 0 1 1 1

Clock

Manch Data

Figure 4.3: Manchester Coding

The mid-bit transition in Manchester code provides a self-clocking featureof code. This can be used to improve synchronization over non-self clockingcodes as NRZ. That transition also allows for additional error detection,which could be done with relatively little circuitry.

The main concern when retrieving the encoded information is how tosynchronize the received data and clock signals. To do so a much higherfrequency source needs to be used at the receiver side.

This core has the particularity of a bit error output ensuring the bit valuehas changed within the bit cell. That output can be used by the upperlevels. It does indicates that the expected mid transition has not beenproperly detected but does not imply that the received bit isn’t correct.

4.1.3 Convolutional Coding & Viterbi Decoding

Forward Error Correction (FEC) techniques such as the Hamming code arecalled block coding, because a ”block” of data bits is examined to computethe required error control bits.


The technique of Convolutional Coding transforms a binary message intoa sequence of symbols to be transmitted. Upon reception, the receivedinformation must be related back to the original message bits. If there areno errors, the process of decoding is readily accomplished. It can be shownthat single bit errors can be corrected by simple inspection of the receivedsymbols.

In general, convolutional coding techniques are applied to very long mes-sages, such as the continuous stream of data from a satellite television trans-mitter. This technique is well suited for long bit streams in noisy channelsand is readily implemented in hardware.

The circuit shown in fig. 4.4 illustrates a simple convolutional coder suit-able for incorporating forward error correction into a transmitted message.It yields a series of two bit (dibit) symbols representing the data.

FF Sel

+

+

FF

Figure 4.4: Convolutional Coder

The way in which the output bits are generated defines a particular con-volutional coding circuit.

For each bit, two bits are transmitted. In common with other error con-trol techniques, convolutional coding involves increasing the length of theoriginal message. A coder such as this which doubles the number of bits iscalled a ”1/2 rate” (half rate) coder. In general, a 1/N rate code leads to aproportional length increase by N times the data bits.

Upon reception, the received information must be related back to the orig-inal message bits. A fast approach to applying bit correction dynamicallyduring reception is required.


If there are no errors, the process of decoding is readily accomplished. Itcan be shown that simple bit errors can be corrected by inspection of thereceived symbols.

However, a more systematic approach based on the estimation of a ’bestfit’ path through the so calledTrellis diagram (measuring the hamming dis-tance between each estimated path and the actual received result), has beenimplemented in this core. It is called the Viterbi Decoding Algorithm, andusing the properties of the trellis diagram make possible an iterative ap-proach in which all possible paths are explored, but only the best pathsare pursued, not having to identify and evaluate all possible alternativesthrough a very long message.

More information about this FEC technique can be found in [12], [13] and[19].

4.1.4 Reed Solomon (11,15)

Reed-Solomon codes are block-based error correcting codes with a widerange of applications in digital communications and storage.

A Reed-Solomon code is specified as RS(n,k) with s-bit symbols.Thismeans that the encoder takes k data symbols of s bits each and adds paritysymbols to make an n symbol codeword. There are n-k parity symbols of sbits each. A Reed-Solomon decoder can correct up to t symbols that containerrors in a codeword, where 2t = n-k.

RS codes are based on a specialist area of mathematics known as Galoisfields or finite fields. A finite field has the property that arithmetic op-erations (+,-,x,/ etc.) on field elements always have a result in the field.A Reed-Solomon encoder or decoder needs to carry out these arithmeticoperations.

A codeword is generated using a special polynomial. All valid codewordsare exactly divisible by the generator polynomial:

c(x) = g(x)i(x)

where g(x) is the generator polynomial, i(x) is the information data blockand c(x) is a valid codeword.


The designed IP is intended to provide the implementation of a Reed-Solomon (11,15) encoder/decoder for the Galois Field with generator P (x) =x4 + x + 1.

Table 4.1 contains the irreducible polynomials of the field in index, poly-nomial, binary and decimal form.

Index Polynomial Binary Decimal0 1 0001 11 α 0010 22 α2 0100 43 α3 1000 84 α+1 0011 35 α2+α 0110 66 α3+α2 1100 127 α3+α+1 1011 118 α2+1 0101 59 α3+α 1010 1010 α2+α+1 0111 711 α3+α2+α 1110 1412 α3+α2+α+1 1111 1513 α3+α2+1 1101 1314 α3+1 1001 9

Table 4.1: Irreducible Polynomials of Galois Field

The Reed Solomon Generator will be G(x) = x4 + 15x3 + 3x2 + x + 12.Inorder to encode a message (11 symbols of 4-bit each) the following procedureis followed:

• Multiply the message by x4

• Divide it by the generator.

• Encoded message will consist on the original data followed by theremainder of the division of previous step.

4.1.5 Interleaver / Deinterleaver

This IP allows for the interleaving of the data. The interleaving process isused to ease problems caused by burst interferences.


Burst errors cannot be corrected as efficiently as small duration errors. In-terleaving blocks of a stream permits splitting that burst (after deinterleav-ing) in different and separated small duration errors that may be correctedusing FEC techniques.

Within the architecture two Interleaver strucutures are included: a 4x41-bit Interleaver placed right after the Convolutional Encoder/Viterbi De-coder, and a 4x4 1-byte Interleaver structure following the RS Encoder/Decoder.

4.1.6 802.15.4 CRC / KONNEX CRC

The Cyclic Reduncacy Code technique is used for error detection. The algo-rithm treats all bit streams as binary polynomials. Given the original frame,the transmitter generates the parity symbols (FCS) for that frame. Thesesymbols are generated so that the resulting frame (the cascade of the originalframe and the FCS), is exactly devisable by some pre-defined polynomial.This pre-defined polynomial is called the devisor or CRC Polynomial.

The implemented cores are intended to the calculation of the CRC poly-nomial defined in the 802.15.4 draft D14 of April 2002, subsection 7.1.2.8.,and Konnex KTB0278 Draft. Polynomial are respectively:P802.15.14(x) = x16 + x12 + x5 + 1 andPKNX(x) = x16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1.

4.1.7 Additional IPs

Some other tasks that have not been defined yet and that either have beenincluded in the previously mentioned protocols or that have been consid-ered also to be interesting for a generic wireless application have also beenimplemented. Among them we must remark:

• Direct Sequence Spread Spectrum: which includes M-Sequence Gener-ation, to obtain a pseudo random sequence, Sliding Correlation, forsynchronization with that sequence and Frequency Hopping relatedtasks. The units included stand for the PN sequence selected by theIEEE 802.15.4 Standard.

• Encryption: The DES algorithm has been implemented to cipher-ing/deciphering the information to be sent/received.


• PHYSICAL Layer Controller for the 868Mhz ISM European band,compliant with the one described in the 802.15.4 D14 deliverable. Fur-ther technical data about it can be found on the IEEE reference spec-ification.

Chapter 5

FPGA1 Test Vehicle

In order to fulfill the first of our objectives, it is, to validate and test theafore designed IP blocks that will provide data processing capabilities, andto include them into the ISM band communication system, a complete unithas been designed.

This unit is to be inserted between a host that provides and retrieves datato be transmitted / received and the transceiver itself. The IPs contained inthe FPGA1 will improve the communication quality and include all functionsdescribed in chapter 4.

Moreover, the FPGA1 adds the capability to reconfigure the data paththrough the IPs (enabling and/or replacing blocks with no difficulty) anddifferent parameters to evaluate and find the best performance, accomplish-ing its function as a test vehicle. The interface with the FPGA1 is shown infig. 5.1.

The FPGA1 requires an asynchronous low active Reset and is designedfor a system clock with a frequency equal to 50 MHz. Frames are transmit-ted/received through serial interfaces specifically designed for this subsys-tem. It also includes a FIFO memory to allow for a faster host upload ofthe data. Provided the expected length of frames to be implemented it hasbeen decided to set the depth of that FIFO to 16 bytes.

On the Host side an asynchronous serial protocol has been implementedfor transmitting and receiving data to/from higher levels in a host controller

33

CHAPTER 5. FPGA1 TEST VEHICLE 34

FPGA1

RESET CLK

RTXDIR

DIO

DCLK

DnA

DATA

DVOUT

SDVIN

RX

TX

SDVOUT

FINT

WnR DVIN

Xciever Side Host Side

Figure 5.1: FPGA1 interface

microprocessor oriented interface. This way a low number of lines are dedi-cated to the data flow, since at the end, an ASIC version of the unit wouldbe implemented. An Interrupt Flag is also present and activates for anyexception or any attempt of an incorrect access.

On the Transceiver side a synchronous communication is defined. Theclock is provided by the transceiver itself and a bidirectional line is used fordata access to the FPGA1.

Configuration parameters within the test vehicle can be set either throughthe serial or parallel port with no difficulty. Controllers for those protocolshave been also designed and access different internal registers for recon-figuration or debug. Serial access is also accomplished through the aforementioned interfaces.

Finally, and before presenting the block diagram shown in fig. 5.2, wemust remark that every module within this design is technology indepen-dent, which means that it does not need to be implemented in a particular


technology to work. So it is totally portable to any other platform differentthan the one used to develop this thesis.

RTXDIR

DIO

DCLK

sWnR

SDVIN

RX

TX

SDVOUT

FINT

DnA WnR DVIN DATA

DVOUT

RESET CLK

Signal IF Host IF STORAGE/ CONTROL FEC ENC/SS

REGISTER BANK

Parallel

Serial

Config & Debug

CLK

FPGA1

Figure 5.2: FPGA1 Internal Block Diagram

The FEC and the ENC/SS stages within the FPGA1 block diagram werethe only blocks that had been previously designed. The contain the differentIPs to be tested.

5.1 Host Interface

This IP block has been designed to provide the communication protocolwith the host (master) that will produce data to be transmitted, will takereceived data and will generate control frames to set different configurationparameters of the test vehicle.

Hence, a half duplex byte oriented serial interface with an externallyconfigurable bit rate has been implemented in this core, creating an asyn-


Host Interface

SDVIN

SDVOUT

tx_rx

data_rx_ready

trx_ack

serial out parallel_out

Bit Rate 3x clk rst

serial in

data_tx_ready

parallel in

Figure 5.3: Host Interface

chronous communication protocol governed by two control flow signals thatvalidate contents of data lines, and a built-in byte encapsulation (a Start bit0 and an End bit 1 are attached to each transmitted byte and, of course,erased from every received byte).

Another remarkable feature is the priority set on reception over transmis-sion. It is, whenever activity is detected on the reception line, any trans-mission in process will be interrupted.

5.2 Storage & Control

The Storage and Control entity is in charge of taking control of the internalprocesses taking place within the FPGA1. It is able to distinguish betweendata and control frames that come from the serial interfaces, redirectingcontrol bytes to their proper destination registers and storing data bytes ina generic-depth 8 bits-width technology independent FIFO memory.

The frame length for transmission is also supervised by this core, andexception signals are generated whenever a problem is detected in accessingthe test vehicle or in transmitting/receiving through it.

Through its control signals, it actually performs a dual port, simultane-ously accessible storage device while it takes care of the necessary internalsynchronization tasks between the different blocks that conform the wholesubsystem.


Rx_flag

Storage & Control

IF_ack

IF _bus_in Host_bus_in

Data_trx_ready

Host_OE

Host_Data_Req

Trx_req

IF _bus_out Host_bus_out

Clr_ovf

clk rst

Write_mem

tx_rx

Full Empty Ovf Half Full

Control Register

Frame Length

Start Byte

Figure 5.4: Storage & Control

It is obvious that this IP must be totally independent of any device’s bitrate, but again, there are a series of configurable parameters that affect itsoperation. These parameters are those that have something to do with theframe format, such as number of bytes per frame, start byte for control anddata frames, etc.

5.3 Signal Interface

Again a serial interface. This is in charge of a half duplex transmission/receptionusing no control flow protocol and no byte encapsulation, but being providedwith the communication clock.

Its control signals adapt perfectly to the afore described blocks, and alongwith them, constitute the spine for the communication flow from host,through the test vehicle to the transceiver.

As it can be supposed, its main function is to generate the serial framethat will access the wireless medium through the transceiver, which is doneby adding a preamble at the beginning of the transmission, configurable notonly in length but also in content. After the preamble a start byte (alsoconfigurable) is inserted. And once the frame has been totally transmitted,


Signal Interface

nRst CLK

data_rx_ready

Bus in

data_trx_ready

Bus out

tx_rx

trx_req DCLK

serial in

serial out

Stop Byte Start Byte Preamble

trx_ack

Figure 5.5: Signal Interface

a stop byte which function is reserved for future use is added. In receptionjust the data bytes are given to subsequent modules.

As we can see, numerous parameters are to be set to configure this IP:Number of preamble bytes, content of those bytes, start byte, stop byte,frame length and bit rate. This fact provides the Signal Interface with agreat flexibility.

5.4 Clock Generator

The Clock Generator is able to produce, either from a 50 or 25 MHz clock,a series of ten different selectable clock signals which oscillate at differentstandard frequencies form 1200 Hz to 460800 Hz.

The chosen signal is used to adjust the bit rate at the Host Interface andany other needed module.

The available frequencies are shown in table 5.1:No PLL or any other technology dependent device has been used in the

design of this block and the root clock has not been gated at any point.


Group I Group II1200 Hz 57600 Hz2400 Hz 115200 Hz4800 Hz 230400 Hz9600 Hz 460800 Hz19200 Hz38400 Hz

Table 5.1: Available Frequencies at Clock Generator output

5.5 Configuration & Debug

Debug & Config

Pp_DnA Pp_WnR

Pp_DATA

Pp_DVOUT

nRst clk

IF_ack

ctrl_register

sp_DVOut

Sp_Trx

wr_ctrl_reg Default

clear

Config stream

Debug Macro

Pp_DVin

sp_data

Figure 5.6: Configuration & Debug Module

In order to achieve the desired flexibility and configuration options somekind of register bank is needed to store the configuration values. Moreover,to be able to easily validate the correct operation of the different blocks,some debug registers would be really useful.

This entity is provided with a register bank that contains 32 read/writeregisters and 32 read-only registers for debug purposes. This array has beentotally built on generics, which makes it easy to enlarge or reduce its sizeas applications may require it.

The writable registers contain values for all the configuration parameters.These parameters set:


• Communication mode (transmission or reception)

• Host Interface bit rate

• The enabled IP blocks within the FEC and the Encoding and SpreadSpectrum stages

• Length and value or the transmission preamble

• Start byte and End byte

• Frame length

The read-only registers contain mainly:

• a signature, that identifies the test vehicle and allows easy checking ofthe communication

• The Status Registers, that contain different flags for different excep-tions and state variables

• Data values at the inputs and/or outputs of different stages within thetest vehicle to allow the easy debugging and validating of the differentblocks during its operation.

Even more possibilities are brought by the inclusion of a serial and a par-allel access controller to read from and/or write to those registers. Withthese two modules reconfiguration and debug can be performed either seri-ally (through the Host Interface and using predefined control frames) or viastandard IEEE 1284 parallel port, using the same access address.

5.6 FEC & Encoding-Spread Spectrum Stages

The FEC and Encoding-Spread Spectrum stages are the two modules thatcontain the IP blocks under validation that will implement the target archi-tectures to be tested.

At this stage of the VIPERS Project the Forward Error Correction mod-ules includes:

• Convolutional Encoder/Viterbi Decoder

• 4x4 -1bit Interleaver


• Reed-Solomon (15,11) Encoder/Decoder

• 4x4 -1byte Interleaver

• 802.15.4 CRC

And the Encoding and Spread Spectrum module:

• Differential Encoder/Decoder

• Direct Sequence Spread Spectrum

• Manchester Encoder/Decoder

Each IP in any of these two blocks is totally independent from each other(except, perhaps, the interleavers within the FEC stage) and may be en-abled/disabled alone or in combination with any other IP through the con-figuration registers.

Chapter 6

Emulation Platform:Hardware

In a slotted multi-access wireless system, performance parameters are af-fected by the bit error rates on the communication channel. Errors occuras a result of noise introduced by the radio channel or data packet colli-sions. Collisions occur when two or more stations select the same time slotto transmit their data, thus causing corruption in data packets. Collisionsare out of the scope of the current digital IP library and shall be treatedat a MAC level. However noise related problems are good candidates to beconsidered at a pure physical level with our transceiver enhancement IPs.

Thus, the analysis to be performed using the FPGA1 is focused on in-vestigating the effect of the selected Ips on the performance of the physicallayer, it is, considering just bit errors effects.

To accomplish this task, an emulation platform has been set up based on:

• The models for emulation of two nodes built up on:

1. Host Emulator

2. FPGA1 test vehicle

3. Transceiver Emulator

• A Wireless Transmission Model that emulates the channel noise char-acteristics and among other tasks introduces a configurable Bit ErrorRate. It has been developed by one of the consortium partners.

42

CHAPTER 6. EMULATION PLATFORM: HARDWARE 43

• A Control & Analysis model coded in Microsoft Visual Basic that auto-mates the emulation procedure by setting up the configuration param-eters, launching test runs, gathering results and generating statistics,providing the user with a PC user-friendly interface to easily controlthe test and emulation process.

This platform permits the easy characterization of benefits and drawbacksof different architectures at a physical layer obtained against the load ofseveral parameters that affect the communication.

In other words, this platform fulfills the second of the main objectiveswithin this thesis, developing an easy-to-use tool for a wireless system rapiddesign, and for a rapid decision on the architecture to use for the physicallayer basing not only in simulation results but also on statistics obtainedfrom a physical implementation on the target technology.

6.1 Host Emulator

Host Emulator

CLK nRST

PC_TX

PC_RX

SDVOUT

TX

RX

SDVIN

FINT

Xver Config

DIR

Figure 6.1: Host Emulator

The Host Emulator is a technology independent VHDL core that receivescommands through a PC serial port, decode them and basing on them andemulating the behaviour of a host executes different action on the HostInterface ports of the FPGA1 core. This actions may be performed in order


to set configuration parameters or to transmit data. On reception, when thetest vehicle has stored a frame, the Host Emulator retrieves the data andtransmit it via serial port to the PC.

It is obvious that when the FPGA1 test vehicle is reconfigured, the HostEmulator must be also reconfigured in accordance, it is, many of the config-uration parameters of the FPGA1 have also to be set on the Host Emulator(communication bit rate, frame length. . . ). This is also accomplished viathe PC serial port. The Host Emulator supports several independent com-munication bit rates with PC and FPGA1.

Moreover, the host emulator not only stores the configuration values for it-self but also for the Transceiver Emulator and for the Wireless TransmissionModel.

The afore stated implies the definition of different control instructions forHost Emulator reconfiguration, Transceiver Emulator reconfiguration andFPGA1 access. They have been defined so that their decoding is as directas possible in order to reduce logic. The frames to be transmitted are by theFPGA1 are generated to adapt to the final user partner of the consortium’straffic model as much as possible.

6.2 Transceiver Emulator

The Transceiver Emulator is designed to connect the test vehicle with theWireless Transmision Model and behaves as the target transceiver would do.It provides the FPGA1 with a communication clock that synchronizes datatransitions. Again, the frequency of that clock can be configured throughthe PC serial port and its value is stored in the Host Emulator.

A Manchester encoder/decoder is included and may be enabled or not inorder to test the Manchester IP core included within the FPGA1.

6.3 Wireless Transmission Model (WTM)

Bit Error Rate (BER) is the parameter used to model the effect that thechannel has on wireless digital communications. These effect derives inerrors on the received frame and include noise introduced by the channel,collisions, attenuation, different sorts of interference,etc.


Xver Emulator

CLK nRST

FPGA1_TX

FPGA1_RX

TX_WTM

RX_WTM

Xver Config

DIR

DCLK

Figure 6.2: Transceiver Emulator

As it was stated before, collision issues are out of the scope of this thesissince they have to be handled at a MAC level while our work is focused onthe physical layer and so, the communication enhancement IP cores that weare testing cannot handle those collisions.

However, the rest of the effects of the channel are of the concern of thiswork since one of its aims is to determine how the use of the developed IPcores can ease their damage.

The Wireless Transmission Model (WTM) is the core that can modelBER and that is used to ”include” the wireless medium into the FPGA tobuild the emulation platform. It is able to generate different BER levels,burst noise with constant or random duration and collisions.

This core has been designed by one of the consortium partners and hasthe configurable features listed bellow:

• Number of nodes connected to the wireless medium.

• Connections between all those nodes

• BER value as 1/n where n is power of two


• Number of channels used in the communication (in case that frequencyhopping is used)

• Duration of Burst Noise

This configurability is achieved through signals that may be fixed at syn-thesis time or changed at execution time with any other data provisionmodule. In fact in our Emulation Platform, the Host Emulator is the mod-ule in charge of setting the different parameters for the WTM. Evidently, asthere is one of this cores for each node, not all of the nodes can control theWTM but just one of them is connected to it and act as the master node inthe network.

Given all this, the block diagram for the emulation platform hardwareis the one plotted in fig. 6.3. As we are not considering collisions, justtwo nodes are needed to test the different architectures, one configured astransmitter and the other as receiver. Both connected to the WTM andcommunicating with a PC.

In this figure there have been shown just two nodes. Since by this pointcollisions are out of the scope no more nodes are needed for the emulation ofthe communication. However, the platform has been designed so that in afuture it may be easily extended to emulate a complete network with severalnodes, one of them would be the master node (that may be dynamicallyconfigurable) and emulating the traffic model proposed by the final userpartner.


WTM

FPGA1 Host Emul.

Xver Emul

FPGA1 Host Emul.

Xver Emul

DnA

DATA

DVOUT WnR DVIN

Node #1

Node #2

PC RX1

PC TX1

PC RX2

PC TX2

nRST CLK

PC Serial Port

PC Parallel Port

Figure 6.3: Emulation Platform Hardware

Chapter 7

Emulation Platform:Controller Software

Once the hardware has been described this chapter will be dedicated tothe software that controls that hardware. For that control operations, amodel coded in Microsoft Visual Basic has been designed that permits theexecution of any possible action described in previous chapters.

The application runs on a normal PC and is connected to the designhardware through both, the PC serial and Parallel ports. It is able toset each one of the afore described parameters, to update any configurableregister within the emulation platform and to generate randomly built testfiles for the emulation process. It also launches the test and retrieves dataframes, generating the consequent statistics and storing them for its lateruse and representation.

The process of generating and storing the statistics is totally transparentto the user. Those results are stored in a Microsoft Excel format whichderives in a complete portability of the data base. This permits that onceall the desired tests are done, and all the obtained data stored, there is nodependency on the emulation platform software to be able to visualize theresults or to plot the different graphics using any other machine, providedthat, of course, Microsoft Excel is installed in that machine.

Configuration and communication actions are performed through the PCparallel and/or serial port exploiting the facilities that Visual Basic andthe designed hardware offer. The parallel port is used for debugging and

48

CHAPTER 7. EMULATION PLATFORM: CONTROLLER SOFTWARE49

observation of the internal registers of each FPGA1 test vehicle and fortheir reconfiguration. The serial port is mainly used for communicationissues and Host Emulator settings, which include the Transceiver Emulatorand the WTM configuration.

Figure 7.1: Start-up Screen

Figures 7.1 and 7.2 show the start screen of the application. It offers theoption of starting a new test session, which creates a new Excel file with thecorrect format for the storage of data, or opening an existing one.

Once a valid file name is introduced, the program takes us to the Settingstab. At this stage we can set the test characteristics. Fig. 7.3.

• Number of frames that compose the test (any positive number). Theywill be stored in an ascii file named test file in.tst. Most of the char-acters that compose the frames are randomly generated within a widerange of valid ascii characters, which provides a more realistic test.The rest of them are generated to be compliant with the final userpartner propietary frame.

• Frame Length. This will be one of the key parameters to obtain thestatistics. It can be set within a range of 9 to 16 bytes. This is not


Figure 7.2: Starting Session

Figure 7.3: Settings


applicable when the Reed Solomon core is enabled in the FPGA1 testvehicle as it requires a frame length equal to 11 bytes.

• Communication mode for each node. At application start-up the ini-tial configuration sets node #1 as transmitter and node #2 as re-ceiver, but it also can be changed. This feature is not very useful inthis version, but in the future, the network will be built on a numberof nodes greater than two and then it would be an interesting pos-sibility being able to reconfigure the network in terms of number oftransmitter/receivers from one test to another or even during the testprocess.

• Communication Bit Rate. It is possible to chose among several stan-dard bit rates for the Host Interface in the FPGA1 or, which is moreinteresting, for the transceiver.

Figure 7.4: IPs tab

The next step is enabling the desired IP blocks, it is, configuring thearchitecture to be tested. This is done in the IPs tab. There, for theFEC stage we can chose between any combination of IPs included in theFPGA1, which are Convolutional Encoder/Viterbi Decoder, different inter-leaving stages, Reed Solomon (11,15) and CRC. The only restriction is thatno interleaver can be selected when no other FEC IP is also enabled.


At the Encoding and Spread Spectrum stage Differential Encoding, DirectSequence Spread Spectrum and Manchester Encoding are available.

This tab offers also the possibility of accessing to each FPGA1 internalregisters for debugging purposes.

Figure 7.5: WTM tab

The next tab allows the user to configure the WTM. It is possible to setthe Bit Error Rate in a wide range of values form 4.88x10−4 to 15.62x10−3

and No Noise. The user can also select the duration of the Burst noise (itsmaximum value is set at synthesis time) and the type of noise:

• Random BER. The WTM introduces a error randomly at the selectederror rate.

• Burst Noise with the established duration.

• Random Length Burst Noise. The burst length varies between 1 bitand the selected duration randomly.

• Continuous noise.

Once all the parameters are set the program is ready to send the generatedframes and generate statistics. A status bar shows the progress of the process


Figure 7.6: Test tab

and also the frame that is being sent is shown in a text box. A new filenamed test file out.tst stores the received frames or the error message incase a frame is not received.

Comments on each specific test can be included in the Log file that shallbe generated after the test is done by pressing the command button SaveResults Generate Log. Results are saved to the previously specified Excelfile and a synopsis of those results is shown.

If the statistics are not perfect, it is, if not all the frames are receivedcorrectly a Debug button becomes active that opens a debug file that con-tains the sent frame and the corresponding received one in order to easilycompare and find errors.

Pressing the View .Log button opens the Log file that contains informationabout every specific test that has been performed during the test session. Itstores data such as selected configuration for IPs and bit rates, the numberof transmitted bits, frame length, the WTM configuration, etc.


Figure 7.7: Log File

When the test is finished the Send Test button becomes inactive and noother test can be performed unless a new test file is generated, however, itis not necessary to enter the whole configuration again.

At this point and once that several measures have been taken, the onlything left is to generate a representation of the obtained results. To achievethat, the controller software includes a Graphical Results Viewer.

This tool is the perfect complement for the controller software. It is ableto extract data from an Excel Worksheet and represent them in a two-dimensional chart. In this first version of the software the variables thatmay be plotted are:

• Bit overhead introduced by the use of the different IP cores

• Effective Bit Rate vs. BER (including bit overhead caused by IPs)


• Effective Bit Rate vs. Frame Length

• Effective Bit Rate vs. Transceiver Bit Rate

• Effective Bit Rate vs. BER (not including bit overhead caused by IPs)

• Effective Bit Rate vs. Frame Length

• Effective Bit Rate vs. Transceiver Bit Rate

• Frame Loss vs. BER

• Frame Loss vs. Frame Length

• Frame Loss vs. Transceiver Bit Rate

Figure 7.8: Graphical Results Viewer

All this variables are shown in groups of five plots each, of them containsthe results for an specific architecture. By clicking on the legend an specificplot may be selected and showed alone.

The Graphical Result Viewer provide with an easy method of comparisonfor the different architectures and to find anomalies, benefits and drawbacksof any specific IP module as we shall see in the first obtained results.

Chapter 8

Emulation Results

The emulation results will consist of performance results of different simula-tion runs in a clean environment without interference (not using WTM) andwithout IPs during the first stage, and in a coexistence environment, model-ing the interference effect by using WTM and setting different combinationof IPs, during the second one.

At this point of the project, the considered result metrics are:

1. Bit overhead: normalized ratio of bits added by the IPs.

2. Frame loss: measures the number of packets erroneously received. Itrepresents the number of frames lost divided by the total number offrames sent during the emulation process.

3. Total Effective Bit Rate: a measure, in bits/sec of the successful trafficbeing transmitted including the IPs overhead. It is represented as apercentage of the nominal transceiver bit rate.

4. Good Effective Bit Rate: TotalEffectiveBRx(1 − BitOverhead)

Different plots of those metrics will be obtained against the offered load ofthe default parameters shown in table 8.1, and with different combinationof them. Then they will be compared to determine the benefits and/ortrade-offs of the IPs usage.

In the future, some more metrics will be added to the afore mentionedsuch as different kinds of delay measurements for analysis and optimization.Those will be explained in next chapters.

56

CHAPTER 8. EMULATION RESULTS 57

GENERAL PARAMETERSParameter Type Default ValueTraffic Fixed Propietary frameFrame interarrival time Fixed msFrame length Variable 11bytesTopology Fixed 1Tx & 1 RxBER Variable 0Length of test runs Variable 1000 frames

HOST PARAMETERSComm. Speed Variable 9600bps

IP PARAMETERSCRC Variable DisabledReed Solomon Variable DisabledByte Interleaver Variable DisabledViterbi Variable DisabledBit Interleaver Variable DisabledDifferential Encoding Variable DisabledManchester Variable DisabledSpread Spectrum Variable Disabled

TRANSCEIVER PARAMETERSComm. Speed Variable 4800bps

Table 8.1: Emulation Parameters

Figure 8.1 shows an analysis obtained with the Emulation Platform 1.The chart represents the Frame Loss vs. BER. These results were obtainedusing a transceiver bit rate equal to 9600bps and a frame length of 11 bytes.The type of noise was set to Random BER.

It is remarkable how the percentage of lost frames obtained without us-ing any IP module (red plot) is decreased by using the Convolutional En-coder/Viterbi Decoder (blue). The addition of the bit Interleaver (green), asexpected, does not cause a big effect, provided that its function is improving

1The results shown in this sections are the first obtained results using the EmulationPlatform. At this point of the project, the test process is being performed and definitiveresults are not available yet


Figure 8.1: Frame Loss vs. BER results

the performance in presence of burst noise but not when errors affect justto single bits.

The yellow plot shows the results using the Reed Solomon (11,15) core.Results do not look better than in the initial case (no IPs), which was notthe expected result. Actually, it was foreseen that the Reed Solomon resultswould be better than the Viterbi ones as the RS module is able to correcttwo errors per frame while Viterbi can fix just one.

Hence, there was an error on the Reed Solomon (15,11) core implementa-tion. This error did not come up during the simulation or validation stagesbut there it was detected through the use of the Emulation Platform.

Some results about Frame Loss vs. Frame Length have been also obtainedand are shown in fig. 8.2:

As it was predicted, the percentage of lost frames increased lightly with theframe length (as there are more possibilities of an error to be inserted in theframe) and again was eased by the use of the Convolutional Encoder/Viterbi


Figure 8.2: Frame Loss vs.Frame Length results

Decoder. As it was commented before, this test could not be done using theReed Solomon module as it needs a fixed frame length of 11 bytes.

Chapter 9

Future Lines of Action

In the close future, the work will be directed to some tasks that have not beenfinished yet, specially those referred to the Emulation Platform Software. Inthat sense:

• The different tests for every architecture and varying every possibleparameter will be done until all the possible results are stored.

• As it was commented in previous chapters, the emulation platformwill be extended to support a complete network with several nodes,emulating the real traffic, once a MAC IP core (either software orhardware) is available. The, collisions and other parameters will beincluded within the scope of the tests.

• The obtained results will be compared with the field tests performed bythe final user partner to measure the accuracy of the exposed emulationmodel.

Also, some more hardware IP modules will be added to the detailed ones.Processing IPs would increase the possibilities of building different architec-tures, while new access and debug blocks such as a JTAG controller wouldimprove the validating process. A more sophisticated version of the WTMis foreseen to be included too.

And, finally, following other lines of work, some other metrics will beadded to the results and statistics data base such as:

• Access delay : The access delay measures the time it takes to transmita frame from the time it is given to the FPGA1 until it is successfully

60

CHAPTER 9. FUTURE LINES OF ACTION 61

received at the destination host. For internal analysis and optimizationof the IPs two additional values will be considered:

1. Send delay: measures the time it takes to receive a frame fromthe host and to completely send it.

2. Receive delay: measures the time it takes to receive a frame fromthe medium and to pass it to the host.

• Mean access delay : The average access delays is the sum of all accessdelays divided by the number of transmitted frames.

All this will be achieved by the inclusion of one of the consortium partners’tool. The CHDT permits the inclusion within the design at synthesis time ofdifferent kinds of observation modules that are able to capture those metrics.

Chapter 10

Conclusion

This thesis has resulted in an automated and easy-to-use Emulation Plat-form that is able of speeding the test process of different IP processing coreswithin a communication system. The field test are expected to confirm theadvantage that this platform will provide with in the development flow of awireless system, both in terms of simplification of test and validation tasksand time to market.

The contribution of this thesis is then a new tool that provides a newmethod for an easy and rapid selection of the definitive architecture that ismore suitable for the communication conditions.

The preliminary results obtained at this time through the use of the em-ulation platform have been really encouraging. Not only it has been ableof graphically show the effects of using different architectures in differentenvironments, but also it has detected errors where simulation failed.

Thus, future lines of action present promising expectations on the utilityof this tool, deriving in an inspiring outlook for the improving and perfectionof the project.

62

Appendix A

Target Technology, the ActelProAsicPLUS Family

For the physical implementation of all the functional units described through-out this document, the selected target technology was Actels second genera-tion Flash FPGAs, the ProAsicPlus Family, that combines the advantages ofASICs with the benefits of programmable devices through nonvolatile Flashtechnology. This family offers up to 1 million system gates, supported withup to 198kbits of two-port SRAM and up to 712 user I/Os. In particular,the largest of this family’s devices, the APA1000 is the one that has beenused.

The ProASICPLUS family achieves its nonvolatility and reprogramma-bility through an advanced Flash-based 0.22m LVCMOS process with fourlayers of metal. Standard CMOS design techniques are used to implementlogic and control functions, including the PLLs. This results in predictableperformance compatible with gate arrays, while the Flash technology al-lows all functionality to be live at power up with no external boot PROMrequired to support device programming.

The architecture provides granularity comparable to gate arrays. Thedevice core consists of a Sea-of-Tiles. Each tile can be configured as aflip-flop, latch, or three-input/one-output logic function by programmingthe appropriate Flash switches (see fig. A.2).Tiles and larger functions areconnected with any of the four levels of routing hierarchy.

63

APPENDIX A. TARGET TECHNOLOGY, THE ACTEL PROASICPLUS FAMILY64

Figure A.1: ProAsicPLUS Core Logic Tile

This technology’s devices also contain embedded, two-port SRAM blockswith built-in FIFO/RAM control logic, up to 198kbits. Programming op-tions include synchronous or asynchronous operation, two-port RAM config-urations, user defined depth and width, and parity generation or checking.

The four levels of routing hierarchy are:

• Ultra-fast local resources are dedicated lines that allow the output ofeach tile to connect directly to every input of the eight surroundingtiles.

• The efficient long-line resources provide routing for longer distancesand higher fanout connections.

• High-speed, very long-line resources resources, span the entire devicewith minimal delay, are used to route very long or very high fanoutnets.

• High performance global networks are low-skew, high fanout nets thatare accessible from external pins or from internal logic. These nets aretypically used to distribute clocks, resets, and other high fanout netsrequiring a minimum skew.

One of the main architectural benefits of ProASICPLUS is the set of powerand delay friendly global networks. ProASICPLUS offers four global trees.Each of these trees is based on a network of spines and ribs that reach allthe tiles in their regions. This flexible clock tree architecture allows usersto map up to 88 different internal/external clocks

APPENDIX A. TARGET TECHNOLOGY, THE ACTEL PROASICPLUS FAMILY65

A clock conditioning circuitry in each device includes two clock condition-ing blocks. Each block provides a PLL core, delay lines, phase shifts (0 , 90, 180 , 270 ), clock multipliers/dividers and all the circuitry needed for theselection and interconnection of inputs to the global network.

About the I/O, the ProASICPLUS family offers devices with a large num-ber of user I/O pins, up to 712. Each pad can be configured as an input,an output, a tristate driver, or a bidirectional buffer and also if the I/O padpower supply (VDDP) is 3.3V, each I/O can be selectively configured at the2.5V and 3.3V threshold levels. All I/Os include ESD protection circuits.

Moreover, for more comprehensive, lower cost, board-level testing, Ac-tels ProASICPLUS devices are fully compatible with IEEE Standard 1149.1(JTAG) for test access port and boundary-scan test architecture.

As it couldn’t be any other way, the ProASICPLUS family of FPGAsis fully supported by both Actel’s Libero Integrated Design Environment(IDE) and Designer FPGA Development software, described in AppendixB.

Figure A.2: ProAsicPlus APA1000 Evaluation Board

For additional information about the target technology visit [1]

Appendix B

Software Tools & DesignFlow

For compatibility with the chosen technology, the Libero Integrated DesignEnvironment (IDE) from Actel has been the suite of FPGA developmenttools that has supported the whole design flow. It provides an efficientand comprehensive start-to-finish methodology, form schematic/HDL entrythrough place-and-route and device programming.

The Libero IDE includes Actel Edition (AE) versions of industry-standardEDA development tools as well as Actel generated tools optimized for ActelFPGA devices. All this tools are invoked within the IDE and the projectmanager keeps track of the project files and guides the user through thedevelopment process.

The Design flow is illustrated in fig. B.1.

• Project Manger, HDL Editor : targets the creation of HDL code. HDLEditor supports VHDL and Verilog with color, high-lighting keywordsfor both HDL languages.

• ViewDraw AE is the Libero schematic entry vehicle. Supports mixed-mode entry in which HDL blocks and schematic symbols can be used.

• Actel ACTgen: Macro generator. Provides easy generation of manyfunctional macros for implementation with schematic or HDL entry.

• Synplify AE from Synplicity : for synthesis and optimization of HDLdesigns specifically targeted to Actel FPGA devices.

66

APPENDIX B. SOFTWARE TOOLS & DESIGN FLOW 67

Figure B.1: Libero IDE Design Flow

• WaveFormer Lite AE form SynaptiCAD coverts graphical stimulusfiles into HDL testbenches and manages multiple test benches neededfor different design configurations.

• ModelSim AE HDL simulator from Mentor Graphics for HDL sourcelevel verification. Supports simulation at all levels, behavioral, struc-tural, back-annotated and dynamic simulation.

• PALACE AE Physical Synthesis from Magma accepts a synthesized

APPENDIX B. SOFTWARE TOOLS & DESIGN FLOW 68

netlist and combines logic and architecture-specific optimization withplacement-driven mapping based on detailed device and interconnectmodeling throughout the physical synthesis process. The result isa highly optimized design with significant performance improvementwithout manual intervention,floorplanning, or iterations.

• Actel Designer Includes the Actel MultiView Navigator that displaysand manages the PinEditor for package level floorplanning, NetlistViewer for design schematics, I/O Attribute Editor and Chip Planner(a chip level module placer) tools. Designer also includes Actel place-and-route, Timer (a static timing analyzer and constrain editor) andSmartPower analysis tools.

• Actel FlashPro: a compact, low-cost In System Programming (ISP)FPGA programmer designed specifically for Actel Flash products.

Additional information about the Libero IDE and the design flow can befound at [1]

In the development of the Emulation Platform Controller Software, VisualBasic 6.0 from Microsoft Visual Studio was the chosen language. It provideseasy but very powerful high level, object oriented programming, and a fastway to create applications for Microsoft Windows. Combining its user-friendly interface whit easy code testing and debugging and its great libraryof functions and controls, Visual Basic was perfect for the rapid developmentof the Controller Software.

BIBLIOGRAPHY 69

Bibliography

[1] Actel Homepage. www.actel.com (Last visited on June 2004)

[2] Xilinx Homepage. www.xilinx.com (Last visited on June 2004)

[3] Konnex Consortium Webpage. www.konnex-knx.com (Last visited onMay 2004)

[4] Zigbee Organization Webpage. www.zigbee.org (Last visited on May2004)

[5] IEEE Organization, group 802 Homepage. www.ieee802.org (Last vis-ited on May 2004)

[6] Instat Analysts Webpage. www.instat.com (Last visited on May 2004)

[7] Etmag Analysts Webpage. www.etmag.com (Last visited on May 2004)

[8] Wireless Week Analyst Magazine page. www.wirelessweek.com (Lastvisited on May 2004)

[9] West Tech Research Homepage. www.westtechresearch.com (Last vis-ited on May 2004)

[10] IIR Analyst Homepage. www.iir-telecoms.com (Last visited on May2004)

[11] Dataquest Analysis Webpage. www.dataquest.com (Last visited on May2004)

[12] Online tutorial on Convolutional Encodig/Viterbi Decoding.www.ee.unb.ca/tervo/ee4253/convolution3.htm (Last visited onMay 2004)

[13] Alatek 2000. Viterbi Decoder. Application Notes.

BIBLIOGRAPHY 70

[14] James S. Plank. A Tutorial on Reed-Solomon Coding for Fault-Tolerance in RAID-like Systems. February 19, 1999.

[15] Phil Karn. Introduction to Spread Spectrum. Digital CommunicationsConference 1997.

[16] Overview of Forward Error Correction. WPI EE535 Telecommunica-tions and Transmission Technology Course.

[17] Digital ASICs for Spread Spectrum Applications. Intel ApplicationNote. April 1990.

[18] Forward Error Correction Encoding and Decoding. Intel ApplicationNote. May 1990.

[19] Chip Fleming. Tutorial on Convolutional Coding with Viterbi Decod-ing. January 2002.

[20] Spread Spectrum: Codes, Processing Gain, and Synchronization.Source: TechOnline.

[21] Charles Wang, Dean Sklar, Diana Johnson. Forward Error-CorrectionCoding. April 1991.

[22] Heather Bowers & Hui Zhang. Comparison of Reed-Solomon CodecImplementations. University of Berkeley. Fall 1996.

[23] Joel Kmetz. Solectek. DSSS vs. FHSS, The Skinny. June 1995.

[24] IEEE 802.15.4 Reference Specification.

[25] Eduardo de la Torre et. al. Specification remote configuration and re-mote debugging tool. Consortium internal Deliverable 1.

[26] Maria J. Perez. Architectural partitioning. HW and SW IP specifica-tion. Consortium internal Deliverable 1.

[27] Maria J. Perez. Detailed Digital HW Design. Consortium internal De-liverable 1.

1Confidential

Documents

Design of an Emulation Platform for the Test and ...ingo/MasterThesis/Hernandez.pdf · In this thesis an Emulation Platform for VHDL IP cores dedicated to ... RF-based embedded systems