of 68/68
Issue 73 Fourth Quarter 2010 Xcell journal Xcell journal SOLUTIONS FOR A PROGRAMMABLE WORLD SOLUTIONS FOR A PROGRAMMABLE WORLD INSIDE FPGA Partial Reconfiguration Goes Mainstream Resurrecting the Mighty Cray on a Spartan-3 FPGA How Hardware Accelerators Can Speed Your Processor’s Sine Calculations Xilinx Releases 2009 Quality Report INSIDE FPGA Partial Reconfiguration Goes Mainstream Resurrecting the Mighty Cray on a Spartan-3 FPGA How Hardware Accelerators Can Speed Your Processor’s Sine Calculations Xilinx Releases 2009 Quality Report www.xilinx.com/xcell/ FPGAs Enable Greener Future for Industrial Motor Control FPGAs Enable Greener Future for Industrial Motor Control

Xcell Journal Issue 73

  • View

  • Download

Embed Size (px)


Technical Magazine for Electronic Engineers using Xilinx FPGAs to create a number of wonderful innovations

Text of Xcell Journal Issue 73

  • Issue 73Fourth Quarter 2010

    Xcell journalXcell journalS O L U T I O N S F O R A P R O G R A M M A B L E W O R L DS O L U T I O N S F O R A P R O G R A M M A B L E W O R L D


    FPGA Partial ReconfigurationGoes Mainstream

    Resurrecting the Mighty Cray on a Spartan-3 FPGA

    How Hardware Accelerators Can Speed Your Processors Sine Calculations

    Xilinx Releases 2009 Quality Report


    FPGA Partial ReconfigurationGoes Mainstream

    Resurrecting the Mighty Cray on a Spartan-3 FPGA

    How Hardware Accelerators Can Speed Your Processors Sine Calculations

    Xilinx Releases 2009 Quality Report


    FPGAs Enable Greener Future

    for Industrial Motor Control

    FPGAs Enable Greener Future

    for Industrial Motor Control

  • Avnet, Inc. 2010. All rights reserved. AVNET is a registered trademark of Avnet, Inc.

    Introducing the First-ever Battery-powered Xilinx FPGA Development BoardThe low-cost Xilinx Spartan-6 FPGA LX16 Evaluation

    Kit, designed by Avnet, combines a Spartan-6 LX16

    FPGA with a Cypress PSoC 3 controller and LPDRAM

    memory. This kit demonstrates a versatile battery-

    powered solution for low-power applications and

    provides a sound development environment for the

    most demanding applications. The baseboard can also

    be expanded with new FPGA Mezzanine Card (FMC)

    modules, making design porting and FMC swapping

    nearly seamless between Avnet and Xilinx platforms.

    FMC modules for ISM Networking, Dual Image Sensing

    and DVI I/O are currently available from Avnet.

    Spartan-6 FPGA LX16Evaluation Kit Includes:

    tSpartan-6 LX16 DSP FPGA tLCD add-on panel tUSB A-mini B cable tISE WebPACK DVD t AvProg configuration & programming utility tDownloadable documentation

    & reference design

    To purchase this kit, visit www.em.avnet.com/spartan6lx-evl or call 800.332.8638.

  • Toggle among banks of internal signals for incremental real-time internal measurements without:

    2oyy`lU]E 2]!lU`lU]E

  • L E T T E R F R O M T H E P U B L I S H E R

    Xilinx, Inc.2100 Logic DriveSan Jose, CA 95124-3400Phone: 408-559-7778FAX: 408-879-4780www.xilinx.com/xcell/

    2010 Xilinx, Inc. All rights reserved. XILINX, the Xilinx Logo, and other designated brands includedherein are trademarks of Xilinx, Inc. All other trade-marks are the property of their respective owners.

    The articles, information, and other materials includedin this issue are provided solely for the convenience ofour readers. Xilinx makes no warranties, express,implied, statutory, or otherwise, and accepts no liabilitywith respect to any such articles, information, or othermaterials or their use, and any use thereof is solely atthe risk of the user. Any person or entity using suchinformation in any way releases and waives any claim itmight have against Xilinx for any loss, damage, orexpense caused thereby.

    PUBLISHER Mike [email protected]

    EDITOR Jacqueline Damian

    ART DIRECTOR Scott Blair

    DESIGN/PRODUCTION Teie, Gelwicks & Associates1-800-493-5551

    ADVERTISING SALES Dan [email protected]

    INTERNATIONAL Melissa Zhang, Asia [email protected]

    Christelle Moraga, Europe/Middle East/[email protected]

    Miyuki Takegoshi, [email protected]

    REPRINT ORDERS 1-800-493-5551

    Xcell journal


    Xilinx Demonstrates Quality Commitment to Customersfew years ago, I wrote a cover story for EDN magazine on the subject of reliability in elec-tronic design. In the process of researching the topic, I learned many interesting thingsfirst of which is that most companies dont want to speak publicly about the quality of

    their products. Most, not all.That original article was inspired by a shopping experience. While ringing up an Xbox 360 that

    I was purchasing for the kids, the salesperson strongly suggested I also buy an aftermarket coolingunit that plugged into the console to keep it from getting too hot. At the time it seemed absurd thatafter forking over hundreds of dollars for a videogame system Id need to pony up extra money tomake up for the possibility that there were deficiencies in the Xbox 360s design.

    Needless to say, I didnt buy the cooling gizmo, and a year later (and a year after I wrote thereliability article) my Xbox 360 experienced what many Xbox 360 owners collectively called thered ring of death. Microsoft subsequently fixed the defect (rumored to be a thermal issue withan ASIC) for free for all its customers. The companymust have forked over untold amounts of cash to respinthe ASIC, set up the infrastructure to refurbish units,cover postage and organize the training for customerservice folks to say Ive never heard of the term redring of death with some attempt at sincerity. Giventhe quasi recall, one has to wonder how much moresuccessful the Xbox would have been had Microsoft notencountered the quality issue.

    Quality is really something everyone in electronicsshould be more mindful of, especially as IC siliconprocesses continue to shrink and can accommodate ever-more-elaborate designs that power a broader range ofapplications, spanning from consumer electronics tomedical and mission-critical systems.

    So given this background, I was very proud to see ourquality team establish one of the few corporate qualityreports available for public consumption. For many years,our customers have recognized Xilinx for its outstandingquality. The 2009 quality reportdownloadable in PDFform at https://docs.google.com/viewer?url=http://www.xilinx.com/publications/prod_mktg/2009-quality-annual-report.pdfhighlights Xilinxs continued improvements in quality and customer satisfaction.

    Quality is no longer just about silicon, said Vincent Tong, senior vice president of worldwidequality and new product introductions. The whole Xilinx design experience and IP ecosystem arenow being transformed into the types of programs weve run for decades to drive relentless qualityimprovements and superb customer experiences.

    In keeping with this thrust, Tong says this years report will focus on Xilinxs Targeted DesignPlatforms, with an emphasis on how quality is important in each element of what Xilinx delivers toits customers. We offer outstanding FPGAs, but our commitment to quality does not end with sil-icon, said Tong. We are committed to improving the overall customer experience. Our customershave done amazing things with our products and we are committed to helping them become evenmore successful in creating wonderful new innovations.

    I encourage you to give the 2009 quality report a read.


    Mike SantariniPublisher

  • C O N T E N T S



    Letter From the Publisher At Xilinx, Quality Extends Beyond Silicon4 Xcellence in Industrial

    FPGAs Fuel a Revolution in Intelligent Drive Design12

    Xcellence in A&D Using FPGAs in Mission-Critical Systems16

    Xcellence in Wireless Comms Virtex-4 Forms Foundation for GSM Security20

    Xcellence in Networking Research Design Platform Ignites Real-World Network Advances24

    Xcellence in New ApplicationsA Flexible Operating System for Dynamic Applications30

    Cover StoryFPGAs Create a Greener Future for Industrial Motor Control 88


  • F O U R T H Q U A R T E R 2 0 1 0 , I S S U E 7 3

    Xperiment Resurrecting the Cray-1 in a Xilinx FPGA36

    Xperts Corner FPGA Partial ReconfigurationGoes Mainstream42

    Xplanation: FPGA 101 Multirate SignalProcessing for High-Speed Data Converters50

    Ask FAE-X How to Speed Sine Calculations for Your Processor54




    Are You Xperienced? Take advantage of a simplified training experience60

    Xtra, Xtra The latest Xilinx tool updates and patches, as of September 201062

    Xclamations! Share your wit and wisdom by supplying a caption for our cartoon, and win an SP601 Evaluation Kit66



    Xcell Journal recently received 2010 APEX Awards of Excellence in the

    categories Magazine & Journal Writing and Magazine & Journal Design and Layout.




  • by Mike SantariniPublisher, Xcell JournalXilinx, [email protected]

    Electric motors are everywhererunningtoys and appliances in your home, coolingyour office and powering cars, trains and fac-tory assembly lines worldwide. They are evenfound in robots on Mars. Given this widerange of applications, it isnt surprising thatthere are dozens of types of electric motors,each with advantages and disadvantages.Function, size, power consumption/efficien-cy, performance, reliability, product life and,of course, cost are all attributes companiestake into account when designing new elec-tric motors and deciding which ones toincorporate in their products.

    Today, however, the electric motor is atthe dawning of a new era of maximum effi-ciency and automation built upon highlysophisticated FPGA-powered motor con-trol systems. These new systems are juststarting to make their way into the facto-ries that create the worlds products andconsume a huge percentage of the worldspower. In the first quarter of 2011, Xilinxwill deliver a Targeted Design Platformthat will allow companies to quickly devel-op the most advanced motor control sys-tems to date and help factories reach newlevels of automation and efficiency.

    8 Xcell Journal Fourth Quarter 2010

    Xilinx FPGAs: Creating a Greener Future for Industrial Motor Control

    FPGAs are advancing the sophistication of industrialmotor control products. An upcoming TargetedDesign Platform aims to push it further.

    FPGAs are advancing the sophistication of industrialmotor control products. An upcoming TargetedDesign Platform aims to push it further.


  • The Growing Complexity of Factory Motor ControlJoe Mallett, senior product line manager inXilinxs industrial, scientific and medicalgroup, breaks industrial motor control intofive elements: communications, control,drive, feedback and diagnostics.

    At a minimum, said Mallett, all industri-al motor control systems employ some typeof communications to the outside world toallow a motor to work with other motors viamaster controllers or enterprise software.Traditionally, the communications part ofmotor control for the factory has been basedon serial communications, but it is rapidlymoving to Ethernet due to the real-timerequirements of communications, especiallyin safety applications, and to more easilylink with the enterprise, which has beenEthernet based for years, said Mallett.

    Then comes an element called control,which is the term the industry generally usesto describe the algorithm at the heart of themotor control system. This algorithm con-trols another element called driveessen-tially, the silicon power devices that switchthe current on and off to drive the motor.The control and drive work together inwhats called the control and drive loop torun motors at optimum performance andefficiency given their application.

    The next element in a motor control sys-tem is feedback. These are sensors thatmonitor various aspects of a motor in realtime, including position, speed and torque,among others, said Mallett. To ensure reli-ability, many companies are trying to mini-mize the number of sensors they use in theirmotor control systems. As such, many aremoving to sensorless control, which requireshigh-performance, advanced algorithms toretrieve the feedback information.

    The final piece of the system puzzle isdiagnostics. Being able to predict when amotor is likely to fail is becoming a com-mon requirement, said Mallett. Here

    medical markets at Xilinx, pointed out thatits quite complex to create a motor controlunit that makes even one motor more effi-cient because for maximum efficiency, thecontrol algorithms must be tailored to agiven motors targeted task in the factory.The complexity of the algorithm growsexponentially if it needs to control multiplemotors and even more so if the motor needsto incorporate feedback or diagnostics.

    Corradi explained that even the mostbasic motor control systems employ com-plex algorithms to regulate the amount ofpower going into a motor or series ofmotors. Incorporating feedback and diag-nostics adds another level of complexity,but delivers systems that will instantly warnoperators if there is a potential problemwith a motor, and perhaps identify whatthe problem is and gauge its severity. Themost advanced systems even estimate howlong the motor will last given the problem.

    All motors will eventually wear out, butits extremely valuable if you can estimate ifand when it will happen, said Corradi. Ifa motor in an assembly line fails unexpect-edly, it can bring an entire factory to astandstill. Creating algorithms to controlthe efficiency of a motor is very complex,but adding these diagnostic capabilities ontop of efficiency controls requires a far moresophisticated algorithm, and a sophisticateddevice to execute that algorithm.

    The most advanced control systemstoday include active, real-time safety featuressuch as sensors that spot cracks in machineryand stop the machines in milliseconds toavoid catastrophic failure or conditions thatcould injure factory workers. Mallett notesthat in many cases these advanced safety fea-tures are also becoming standardized andmandated by government. The IEC 61508standards effort, for example, stipulates thatcontrol systems include functionality todetect potentially dangerous conditions andprevent hazardous events. In Europe, the

    too, prediction and diagnostics requirefast decisions and sophisticated signal-processing capabilities.

    In recent years, most of the R&D andwork in the motor control segmentwhether it be for factory equipment, auto-mobiles or even toyshas focused onimproving motor efficiency.

    Factories depend heavily on electricmotors to power robots, tools, assembly linesand HVAC (heating, cooling and ventila-tion) systems. Many run all this machinery24 hours a day, seven days a week, to fillorders and keep revenue coming in. As such,reliability and efficiency are paramount, as anunexpected failure in an electric motor canbring an entire assembly line or factory to ahalt, and may even harm workers.

    Advanced Motor Control Combines Efficiency, Reliability and SafetyFurther, with 24/7 operation, energy con-sumption has a drastic impact on the totalcost of ownership and bottom line. In thefactory space, efficiency is increasinglymandatory, said Mallett.

    Its always great to drive down energybills, but the fact is, many factories have nochoice in the matter, said Mallett. Theyhave to comply with government mandatesto reduce the pollution they create and theenergy they consume. However, most facto-ries cant afford to shut down for a long peri-od of time and replace their entiremanufacturing lines with newer, more effi-cient ones. What they would prefer to do isrun their existing machinery more efficient-ly and swap in newer, more efficient motorsover time, as neededkeeping factorydowntime to a minimum. To that end,equipment manufacturers are racing todevelop the most efficient motor and con-trol combination possible to help factoriesmeet their energy-savings goals, Mallett said.

    However, Giulio Corradi, ISM systemsarchitect for the industrial, scientific and

    Fourth Quarter 2010 Xcell Journal 9

    Creat ing a lgor i thms to contro l the e f f ic iency o f a motor is very complex, and adding these d iagnost ic capabi l i t ies on top o f e f f ic iency contro ls requires a far more sophis t ica ted a lgor i thm.


  • Machinery Directive 2006/42/EC went intoeffect in December 2009, mandating thatmachinery manufacturers provide productsthat comply with IEC 61508.

    But motor control in the factory is notrestricted to monitoring efficiency, safetyand motor longevity, Corradi explained.Companies also leverage motor controls tomake robots perform ever-more-sophisticat-ed and exacting functions. A single robothas several motors and they must be able toperform several functions, said Corradi.They must be programmable to changetasks and they must work in concert withother robots. The algorithms to run themotors in a robot are extremely advanced.

    Even an HVAC system motor control isvitally important. Many factories use chemi-cals, solvents and contaminants and mustventilate them properly. Clean rooms mustalso minimize contaminants. Thesemachines must operate correctly all the time.

    Mallett points out that in modern facto-ries all these systemsassembly lines, robots

    and HVACare interrelated and intercon-nected. They must be orchestrated in concertwith one another. In many cases, newer sys-tems use high-speed wired interconnect stan-dards such as Industrial Ethernet, while someare starting to even use wireless communica-tions. Since factories tend to be noisy envi-ronments, the latter trend adds further layersof complexity to motor control designs.

    FPGAs Displacing Off-the-Shelf Processors in Advanced Motor ControlBecause of all this complexity on the factoryfloor, the demand for processing perform-ance is growing exponentially and program-mable logic control is increasingly displacingtraditional processor-based motor control.

    Historically, engineers have used micro-controllers for factory-class motor control,said Corradi. But that design approach ishitting a wall. The new factory systems areso sophisticated now and integrate so manyfunctions that you would have to use sever-al microcontrollers, and often the biggest

    and most expensive ones, he said. Then,after youve done that, you are fairly restrict-ed in what functionality you can add to yourmotor control. With an FPGA, you can addall the advanced features required to a singlechip and even add new functions after youvedeployed the system in a factory.

    A prime example of this elevated com-plexity is a new trend called networkedcontrol systems, in which motor controlfeedback is routed via networking toenterprise software systems, not just to alocal operators station. In this application,not only are the control algorithms morecomplex, but also, the network is essen-tially in-the-loop, demanding real-timeperformance far beyond what standardoff-the-shelf processors can handle,Corradi said. By contrast, FPGAs canperform networking and control supportsimultaneously (see Figure 2).

    A single FPGA can really do the workof dozens of microcontrollers, saidCorradi. Its much easier to have this com-

    10 Xcell Journal Fourth Quarter 2010


    Enterprise toFactory Bridge/Gateway

    Industrial Networkingand Field Bus

    Figure 1 Xilinx FPGAs play an increasing role in advanced motor control at multiple points in the factory and even the connection between the factory and the enterprise.


  • Fourth Quarter 2010 Xcell Journal 11

    plexity in one device rather than distributedacross a board with many processors.

    Whats more, FPGAs excel at parallel aswell as serial operations. This means design-ers can program a single FPGA to coordi-nate multiple motor controller functions fora variety of motors simultaneously. The real-time requirements dont stop there, but alsoinclude functional safety features, with theconcomitant need to shut down a line inmilliseconds if attached sensors detectunsafe conditions. Functional safety isenabled within FPGAs by using silicon-spe-cific functions, dedicated hardware IP and asoftware stack that, combined, make thecomplete system, said Corradi.

    Corradi noted that customers can leveragean FPGAs reliability and the design tech-niques Xilinx has refined over 20 years foraerospace applications to implement safetyfeatures in their motor control systems.Companies that add safety features to theirmotor control units typically have to designspecific chips dedicated to safety, saidCorradi. In an FPGA, you can partition asegment of the chip just for this purpose andhave a clear separation between the safety andnonsafety segments of the chip. This makes iteasier if they need to create derivative systemsor upgrade systems, because they can simplyleave the safety part of the chip alone.

    Another option would be to add dupli-cate or triplicate functions in the design toensure space-quality safety controls inthese systems.

    In fact, the companies that specialize inthe safety aspect of motor control havebeen the early adopters of FPGA technolo-gy. They see the advantage in how theFPGA could clearly bring a reduction indevelopment times and additional reliabili-ty, and a clear separation of safety and non-safety functions, Corradi said.

    Xilinx Readies Industrial Ethernet Motor Control Targeted Design PlatformIt is for these reasons that companies areturning to FPGAs over processor-basedsystems for industrial motor control.Mallett predicts that the pace of adoptionwill advance rapidly over the next fewyears, especially once engineers get theirhands on the upcoming Xilinx TargetedDesign Platform tailored for factoryautomation and motor control.

    This market-specific platform will pullall the pieces together for the end customerdeveloping advanced motor controllers.The development environment willinclude the hardware, tools and IP neededto integrate Industrial Ethernet and motorcontrol into a single platform. Corradi said

    the Targeted Design Platform will alsoinclude a targeted reference design to helpcustomers shorten their development cyclesand differentiate their products.

    Xilinx will base the first-generation sys-tem on a Spartan-6 FPGA running aMicroBlaze processor. Looking forward,one can envision a platform leveragingXilinxs ARM MPU-based ExtensibleProcessing Platform, further acceleratingthe role of programmable logic in motorcontrol designpotentially saving factoriesmillions of dollars and ensuring the safetyof industrial workers worldwide.

    A key part of the factory automationTargeted Design Platform is a library ofgeneral-purpose and market-specific IPthat Xilinx and its alliance partners willoffer to help customers develop Spartan-6-based integrated motor controllers quickly(see related story, page 12).

    Mallett predicts that as companiesbecome more familiar with programmingFPGAs for motor control systems that endup in factories, they will start to useFPGA-based motor control across otherproduct lines and for other control appli-cations. Companies are always seekingways to build a better motor or at least abetter way to control them, and FPGAs areideal for the job, said Mallett.


    Motor Control and Drive









    ProgramMemory 16K

    DataMemory 2K





    Position andAngle







    Bridge (2)











    Stator Current(1)

    Stator Current(2)

    DC Bus Voltage


    Bridge (1)













    Figure 2 Engineers can implement many motor control features on a single FPGA.


  • by Kasper Feurer Embedded Systems Engineer Xilinx [email protected]

    Richard TobinEmbedded Systems EngineerXilinx [email protected]

    Manufacturers of intelligent drives, as wellas many other players in the automotiveand ISM sectors, are facing numerouschallenges to satisfy new market demandsand meet constantly evolving standards.In modern industrial and automotiveapplications, motors must provide maxi-mum efficiency, low acoustic noise, a widespeed range and reliability, all at anacceptable cost. On todays factory floor,motor-driven equipment consumes two-thirds of total electricity energy, leading tothe urgent need to develop more energy-efficient systems. Interoperability is also acritical design requirement, as in manycases a drive will serve as a component ina large-scale process. A key factor thatinfluences this requirement is the breadthof industrial networking protocols (thefield buses) and associated device profiles,which serve to standardize the representa-tion of a drive within a network. The fieldbuses themselves (for example, CAN andProfibus) are diverse, and despite sharingthe same generic name they are not readi-ly interchangeable. In an attempt toreduce cost and improve communicationsbetween industrial controllers, field bus

    providers have developed Ethernet-basedindustrial networking solutions, and sev-eral new protocols, such as EtherCAT,Profinet and EtherNet I/P among others,have emerged in recent years. However,these are also divergent technologies anddrive manufacturers struggle to supportall the major players.

    Xilinx Design Services (XDS) hasaddressed all of these issues in developingan FPGA-based prototype motor controlplatform supporting the CANopen andEtherCAT interfaces for a key player inthe ISM space. Our role was to designand implement a fully functional andmodular system fit for reuse in the cus-tomers next-generation intelligent drives.The Xilinx Spartan-6 FPGA SP605Evaluation Kit Base Targeted DesignPlatform, along with third-party IP, pro-

    vided state-of-the art motor control algo-rithms and industrial networking supportin a modular system architecture, yieldingan efficient and scalable design.

    Choosing the FPGA PathThe customers existing, microcontroller-based solutions did not deliver what thecustomer wanted most: a scalable platform.A Spartan-6 FPGA-based intelligent drivecontrol system provides all the necessaryscalability, logic and compute power in asingle chip, reducing costs while also avoid-ing obsolescence. Such a platform can beupgraded for years to come with the lateststandards of industrial networking and themost efficient motor control algorithms. Inaddition, the reprogrammable nature ofFPGAs facilitates customization of a singlebase motor control system to meet specific

    12 Xcell Journal Fourth Quarter 2010

    Revolutionizing Intelligent DriveDesign with the Spartan-6Xilinx Design Services uses the SP605 Evaluation Kitand state-of-the-art motor control IP to prototype aninterface-independent intelligent drive control system.


  • customer requirements, allowing easy inte-gration into the existing industrial net-work. In short, the Spartan-6 FPGA fulfillsall the challenging requirements of theindustrial space.

    For newcomers to the world of FPGA-based system design, like our customer,Xilinxs Targeted Design Platforms offerthe ideal starting point by providing arobust set of well-integrated and tested ele-ments right out of the box. You can auto-mate an even greater portion of the finaldesign by adding domain-specific and mar-ket-specific platform offerings to the Baseplatform. These targeted reference designsreduce the learning curve by demonstratingFPGA implementations of real-world con-cepts, allowing customers to put their mus-cle into the design and development of thedifferentiating features of the final product.

    Our solution combined the Spartan-6SP605 Evaluation Kit with third-partyofferingsnamely the NetMot FMCboard and IP from QDeSys plus industrialnetworking IP from Bosch and Beckhoff.Not only were all the basic building blocksof the desired system in place from thestart, but we could proceed with prototypedevelopment without the need for a cus-tom FPGA board, thus allowing the cus-tomer to verify the viability of this newplatform at minimum cost. To furtherenhance the time-to-market and reduce therisks involved with a first-time FPGA sys-tem design, the customer asked us to notonly deliver this prototype but also to sup-port the adoption of FPGAs in its next-generation intelligent drives.

    Ultimately, both engineers and theirmanagers benefited by this approach. Theformer learned FPGA-based design faster,armed with best practices gleaned fromXDS, while the management slashed thetime it took to deliver product along withthe business risks.

    Intelligent Drive Control System PrototypeThe XDS portfolio covers the entireFPGA design development cycle, fromspecification creation through coding,verification, timing closure and systemintegration. Drawing on years of experi-ence in embedded-processor system and

    Depending on the combination of PLCand the type of intelligent drive (CAN orEtherCAT), the industrial network is eithera serial bus or a standard 100-MbitEthernet interface. For both solutions theprototype uses a direct line link betweenthe PLC and the motoreither a two-wireserial interface for CAN, or a standardRJ45 100Base-TX Ethernet connection forEtherCAT.

    The motor control printed-circuitboard, typically one of a number of PCBsin an intelligent drive, is dedicated to con-trolling the motor via commands from thePLC. This motor control board is wherethe flexibility of an FPGA comes intoplay. Rather than a single interface andsingle motor control algorithm solution,as in the conventional ASIC/microproces-sor approach, the Spartan-6 FPGA can bereprogrammed with dedicated networkingand motor control IP blocks, as well as thecontrol software to suit the customers spe-cific needs. In this manner, a single FPGA-based PCB can fulfill the functions ofmany ASIC-based boards. At the sametime, it future-proofs the intelligent driveby providing a mechanism to update the IPto the latest standards.

    Rather than designing this motor con-trol board from scratch, XDS exploited the

    software application design, along withthe ability to integrate third-party IP,good project management practices and afully certified ISO9001 developmentprocess, XDS delivered the intelligentdrive control system prototype very earlyin the customers product developmentcycle. The resulting custom TargetedDesign Platform enabled the customersengineers to familiarize themselves withFPGA design processes and hence opti-mize the power of this new technology intheir next-generation products.

    Lets look more closely at the main com-ponents of this intelligent drive control sys-tem prototype as illustrated in Figure 1.

    The programmable logic controller(PLC) operates the intelligent drive, whichis attached to the industrial network in realtime. For the purpose of this prototype, weused two PC-based PLCs to handle thetwo industrial networking standards thesystem supports: miControl mPLC for thecontroller-area network (CAN) andTwinCAT for the EtherCAT industrialEthernet field bus system. The PLC gener-ates predefined command messages (forexample, start and stop) and verifies thecorrect behavior of the motor by analyzingthe responses received (current speed, tem-perature, voltage and so on).

    Fourth Quarter 2010 Xcell Journal 13

    Industrial Network

    Intelligent Drive FPGA-basedMotor Control PCB

    IndustrialNetwork IP

    MotorControl IP



    Spartan-6 FPGA

    Figure 1 The drive control system prototype


  • Targeted Design Platform concept, inte-grating all the customers desired elementsby combining the Xilinx Spartan-6 SP605Evaluation Kit, the NetMot FMC board,and industrial networking and motor con-trol IP, thus delivering this proof-of-con-cept prototype before the customer hadcompleted its new PCB. Figure 2 showshow we combined the various compo-nents to yield the prototype developmentplatform. As a result, the customer greatlyreduced the integration effort and wasable to explore the best design optionswithout re-engineering the final design.

    The SP605 Base Targeted DesignPlatform is a general-purpose FPGA plat-form that hosts a Spartan-6 LX45T in aproven implementation, alongside manycommonly needed peripherals such asDDR3 RAM, flash memories for pro-gram/bitstream storage, UART for debugand JTAG for FPGA programming.Another key element of the SP605 as wellas all recent Xilinx boards is the FPGAMezzanine Card (FMC) connector, whichenables designers to expand the base boardwith custom functions and interfaces.

    This feature of the SP605 enabled usto build on this base by using features pro-vided by the QDeSys NetMot FMC(www.qdesys.com), which implements the

    power electronics required for motor con-trol, such as voltage inverters and ADCsfor obtaining sensor data. You can connectthe motor directly to these inputs/outputsas shown in Figure 2. The NetMot FMCalso expands the industrial network con-nectivity features of the SP605 by addingtwo CAN and two Ethernet physical-layerinterfaces. They are accessible to the FPGAvia the FMC connector and a PLC overstandard interfaces.

    The test PC functions as both a host forthe PLC software and an FPGA program-ming/debug platform using the UART andJTAG interfaces. In addition, we used thistest PC to develop the MicroBlazeembedded-processor system for theSP605s LX45T FPGA with Xilinxs ISE

    12.1 Design Suite. This embedded systemis responsible for processing the commandsreceived from the PLC and controlling themotor accordingly.

    The MicroBlaze software application,networking and motor control IP blocksseen in Figure 2 represent the modules ofthe design that change depending on theinterface (EtherCAT or CANopen) andmotor type chosen. One of the main chal-lenges for XDS was to ensure that theprocess of switching between these optionsbe as simple as possible, thus ensuring that

    the customer would be able to reuse thesame methods in the future for furtherindustrial network types like Profinet andfor new motors.

    Implementation Details Lets examine these parts of the Spartan-6embedded system in greater detail. As shownin Figure 3, the motor control IP block thatwe usedthe Xilinx Motor Control Library(XMCLIB)is identical for both versions ofthe design. This custom IP core, which per-mits the FPGA to control the NetMotFMCs motor power electronics, plugs direct-ly into Xilinxs Embedded Development Kit(EDK). This allowed us to add the IP to ourembedded design from the Xilinx PlatformStudio (XPS) project and configure it to suitthe motor that was connected to the FPGAvia the FMC connector. The XMCLIB soft-ware driver is a set of low-level functions giv-ing the motor control application access tothe XMCLIB register interface.

    The networking IP, on the other hand, iswhere the system differs for the two variants.For the CAN version of the design we chosethe standard LogiCORE IP XPSController Area Network, delivered with theISE 12.1 design suite and licensed by BoschGmbH. For the EtherCAT version, we usedBeckhoff s EtherCAT Slave Controller IP

    14 Xcell Journal Fourth Quarter 2010

    Test PC

    PLCTwinCAT / mPLC

    JTAGProgramming I/F

    NetMot FMC

    Ethernet /CAN PHY




    FMC Connector Flash DDR3

    MicroBlazeSoftware Application




    MDM, etc.)


    MotorControl IP


    UART DebugConsole


    LX45T FPG




    Figure 2 Prototype Spartan-6 FPGA-based motor control board


  • Fourth Quarter 2010 Xcell Journal 15

    Core (www.beckhoff.com) for Xilinx FPGAs.Both of these IP cores are also available fromthe XPS tools IP Catalog tab, making inte-gration and configuration in the design verystraightforward. In this case, instead of usinga simple driver to provide access to the net-working IP, we used Ports (www.port.de)CANopen and EtherCAT Stack solutions,which offer fully featured protocol imple-mentations right out of the box.

    Finally, we designed a custom embed-ded-software application to run onMicriums (www.micrium.com) C/OS-IIon the MicroBlaze processor system. Thisembedded operating system enhances theprototype systems real-time capabilitiesand provides multitasking, message queuesand semaphores, among other features.

    We also recognized that it was importantto structure the application in a way thatwould allow us to retarget it to differentnetwork interfaces. To achieve this, wedesigned an interface abstraction layer thatlets us encapsulate the communications andmotor control elements of the software.

    On one side of this interface (Figure 4), weimplemented a networking module (PortsCANopen or EtherCAT) to manage the com-munications for the networking IP availablein the system. These modules plug in seam-lessly to our interface abstraction layer. At thetop level of these stacks, we pass communica-tions and control data (such as PDOs, SDOsand NMT state transitions) into the abstrac-tion layer, which interprets the data and pres-ents it to the motor control application ascommands such as start/stop or rotate at aspecified velocity or to a specified position.

    To determine a common set of messagesand commands for the interface abstraction,we researched existing publications in thearea of industrial networking and encoun-tered the IEC 61800-7 standard. For theexisting field bus technologies, severalschemes are used to standardize the commu-nications with a drive device (such as CiA-402 for CANopen or PROFIdrive forProfinet). IEC 61800-7 presents a commonrepresentation of a drive and proceeds to pro-vide a set of mappings between this represen-tation and the existing drive profiles.

    The concepts presented in this standardallowed us to develop our interface abstrac-tion, which in turn allowed us to encapsu-late the networking component of thesystem. We can therefore change the net-working interface present in the system, andwe only need to tailor a small portion of thesoftware to make it compatible with theexisting motor control application.

    Going ForwardThe successful delivery of the intelligent drivecontrol system prototype has clearly illustrat-ed the potential power of FPGAs in industri-al Ethernet networking, field buses and motorcontrol. Although some work remains todevelop a fully featured product, XDS tai-lored a Targeted Design Platform andenhanced it for the customer, creating a cus-tom solution that will greatly reduce the risksand effort required to come to a final, engi-neered product. As a next step, XDS is inves-tigating expanding this Targeted DesignPlatform to support the Profinet IP core andstack, demonstrating that the modularapproach and the design practices adopted arevery effective for the customer.

    Spartan-6 LX45T


    Micrium C/OS-II

    Motor Control Application





    EtherCAT IPOR

    CAN IP

    NetMot FMCEthernet Ports

    NetMot FMCPower Electronics

    StandardXilinx SW


    SW Driver

    Standard XilinxIP

    (UART, MDM, MPMC, etc.)





    Message passing



    Figure 3 CAN/EtherCAT embedded system

    Figure 4 Interface abstraction layer


  • by Adam Peter TaylorPrincipal EngineerEADS [email protected]

    Dramatic surges in FPGA technology,device size and capabilities have over thelast few years increased the number ofpotential applications that FPGAs canimplement. Increasingly, these applica-tions are in areas that demand high relia-bility, such as aerospace, automotive ormedical. Such applications must func-tion within a harsh operating environ-ment, which can also affect the systemperformance. This demand for high reli-ability coupled with use in rugged envi-ronments often means you as theengineer must take additional care in thedesign and implementation of the statemachines (as well as all accompanyinglogic) inside your FPGA to ensure theycan function within the requirements.

    One of the major causes of errors with-in state machines is single-event upsetscaused by either a high-energy neutron oran alpha particle striking sensitive sectionsof the device silicon. SEUs can cause a bitto flip its state (0 -> 1 or 1 -> 0), resultingin an error in device functionality thatcould potentially lead to the loss of the sys-tem or even endanger life if incorrectlyhandled. Because these SEUs do not resultin any permanent damage to the deviceitself, they are called soft errors.

    16 Xcell Journal Fourth Quarter 2010

    Using FPGAs in Mission-Critical SystemsUsing FPGAs in Mission-Critical SystemsSEU-resistant state machines hold the keyto adapting programmable logic devicesfor high-reliability applications.


  • The backbone of most FPGA design isthe finite state machine, a design methodol-ogy that engineers use to implement con-trol, data flow and algorithmic functions.When implementing state machines withinFPGAs, designers will choose one of twostyles, binary or one hot, although inmany cases most engineers allow the synthe-sis tool to determine the final encodingscheme. Each implementation scheme pres-ents its own challenges when designing reli-able state machines for mission-critical

    systems. Indeed, even a simple state machinecan encounter several problems (Figure 1).You must pay close attention to the encod-ing scheme and in many cases take the deci-sion about the final implementationencoding away from the synthesis tool.

    Detection SchemesLets first look at binary implementations(sequential or gray encoding), whichoften have leftover, unused states that the

    startup following reset release. Typically,these states also keep the outputs in a safestate; should they be accidentally entered,the machine will cycle around to its idlestate again.

    One-hot state machines have one flip-flop for each state, but only the currentstate is set high at any one time.Corruption of the machine by havingmore than one flip-flop set high canresult in unexpected outcomes. You canprotect a one-hot machine from errors by

    monitoring the parity of the state regis-ters. Should you detect a parity error, youcan reset the machine to its idle state or toanother predetermined state.

    With both of these methods, the statemachines outputs go to safe states and thestate machine restarts from its idle position.State machines that use these methods canbe said to be SEU detecting, as they arecapable of detecting and recovering froman SEU, although the state machines oper-

    state machine does not enter when it isfunctioning normally. Designers mustaddress these unused states to ensure thatthe state machine will gracefully recover inthe event that it should accidentally enteran illegal state. There are two main meth-ods of achieving this recovery. The first is todeclare all 2N number of states when defin-ing the state machine signal and cover theunused states with the others clause at theend of the case statement. The othersclause will typically set the outputs to a safe

    state and send the state machine back to itsidle state or another state, as identified bythe design engineer. This approach willrequire the use of synthesis constraints toprevent the synthesis tool from optimizingthese unused states from the design, asthere are no valid entry points. This typi-cally means synthesis constraints within thebody of the RTL code (syn_keep).

    The second method of handling theunused states is to cycle through them at

    Fourth Quarter 2010 Xcell Journal 17





    t state


    ionIncorrect state transition

    State c


    to unm


    stateState change to unmapped state

    No Recovery Back to Idle State


    State Encoding 00

    WriteState Encoding 10

    ReadState Encoding 01

    Unmapped StateState Encoding 11

    Figure 1 Even a simple state machine can encounter several types of errors.

  • ation will be interrupted. You must takecare during synthesis to ensure that registerreplication does not result in registers witha high fanout being reproduced and henceleft unaddressed by the detection scheme.Take care also to ensure that the error doesnot affect other state machines that thismachine interacts with.

    Many synthesis tools offer the option ofimplementing a safe state machineoption. This option often includes more

    logic to detect the state machine entering anillegal state and send it back to a legal onenormally the reset state. For a high-reliabilityapplication, design engineers can detect andverify these illegal state entries more easilyby implementing any of the previouslydescribed methods. Using these approaches,the designers must also take into accountwhat would happen should the detectionlogic suffer from an SEU. What effectwould this have upon the reliability of the

    design? Figure 2 is a flow chart that attemptsto map out the decision process for creatingreliable state machines.

    Correction SchemesThe techniques presented so far detect orprevent an incorrect change from one legalstate to another legal state. Dependingupon the end application, this could resultin anything from a momentary systemerror to the complete loss of the mission.


    State MachineRequired


    Implement StateMachine as




    Detection orCorrection

    Implement StateMachine UsingTriple-ModularRedundancy

    Implement StateMachine UsingState Encodingwith a Hamming

    Distance of Three

    Sequential or One-Hot





    Implement StateMachine to CycleThrough Unused


    Implement StateMachine to

    Preserve UnusedStates

    Implement StateMachine UsingState Encodingwith a HammingDistance of Two

    Implement StateMachine With

    Parity Protection

    18 Xcell Journal Fourth Quarter 2010

    Figure 2 This flow chart maps out the decision process for creating reliable state machines.


    Fourth Quarter 2010 Xcell Journal 19

    Techniques for detecting and fixingincorrect legal transitions are triple-modu-lar redundancy and Hamming encoding.The latter provides a Hamming distance ofthree and covers all possible adjacent states.A simpler technique for preventing legaltransitions is the use of Hamming encod-ing with a Hamming distance of two(rather than three) between the states, andnot covering the adjacent states. This, how-ever, will increase the number of registersyour design will require.

    Triple-modular redundancy, for its part,involves implementing three instantiationsof the state machine with majority votingupon the outputs and the next state. This isthe simpler of the two approaches andmany engineers have used it in a numberof applications over the years. Typically, aTMR implementation will require spatialseparation of the logic within the FPGA toensure that an SEU does not corrupt morethan one of the three instantiations. It isalso important to remove any registersfrom the voter logic, since they can create asingle-point failure in which an SEU couldaffect all three machines.

    The use of a state machine with encod-ing that provides a Hamming distance ofthree between states will ensure both SEUdetection and correction. This guaranteesthat more than a single bit will changebetween states, meaning an SEU cannotmake the state transition from one legalstate to another erroneously. The use of aHamming distance of two between states issimilar to the implementation for thesequential machine, where the unused statesare addressed by the when others clause orreset cycling. However, as the states areexplicitly declared to be separate from eachother by a Hamming distance of two with-in the RTL, the state machine cannot movefrom one legal state to another erroneouslyand will instead go to its idle state shouldthe machine enter an illegal state. This pro-vides a more robust implementation thanthe binary one mentioned above.

    If you wish to implement a state machinethat will continue to function correctlyshould an SEU corrupt the current state reg-ister, you can do so by using a Hamming-code implementation with a Hamming

    distance of three and ensuring its adjacentstates are also addressed within the statemachine. Adjacent states are those which areone bit different from the state register andhence achievable should an SEU occur. Thisuse of states adjacent to the valid state tocorrect for the error will result in N*(M+1)states, where N is the number of states andM is the number of bits within the state reg-ister. Its possible to make a small high-relia-bility state machine using this technique,but crafting a large one can be so complicat-ed as to be prohibitive. The extra logic foot-print associated with this approach couldalso result in lower timing performance.

    Deadlock and Other IssuesThere are other issues to consider whendesigning a high-reliability state machinebeyond the state encoding schemes.Deadlock can occur when the state machineenters a state from which it is never able toleave. An example would be one statemachine awaiting an input from a secondstate machine that has entered an illegal stateand hence been reset to idle without gener-ating the needed signal. To avoid deadlock,it is therefore good practice to provide time-out counters on critical state machines.Wherever possible, these counters shouldnot be included inside the state machine butplaced within a separate process that outputsa pulse when it reaches its terminal count.Be sure to write these counters in such a wayas to make them reliable.

    When checking that a counter hasreached its terminal count, it is preferableto use the greater-than-or-equal-to opera-tor, as opposed to just the equal-to oper-ator. This is to prevent an SEU fromoccurring near the terminal count andhence no output being generated. Youshould declare integer counters to apower of two and, if you are usingVHDL, they should also be modulo thepower of two to ensure in simulation thatthey will wrap around as they will in thefinal implementation [ count

  • by Mansoor NaseerAssistant ProfessorBahria University, E-8, Islamabad, [email protected]

    Mobile telephony, the Internet and stream-ing applications enable people to communi-cate over long distances and findinformation and entertainment online. Butwith the explosion in mobile communica-tions usage, the tremendous volume ofinformation transmitted in the air is vulner-able to security risks. In order to maintainsecurity, engineers use cryptographic tech-niques to disguise the data. For the GlobalSystem for Mobile communication (GSM)standard, their algorithm of choice is theA5/1. Using A5/1, the encryption anddecryption are performed over the network,both at the handset and at the base station.

    This article will walk you through animplementation of the A5/1 stream cipher,taking note of the code snippets used toimplement different blocks of the cipher.We will also take a look at a couple of newand different twists on the original A5/1algorithm for enhanced security. In partic-ular, I am changing how the feedback func-tion behaves as well as reworking thecombiner output. For this work, I used aXilinx Virtex-4 LX series FPGA forhardware implementation and the XilinxISE for synthesis. I used MentorGraphics ModelSim 6.0 for simulation.

    Before plunging into implementationdetails, let us begin with a brief descriptionof the A5/1 algorithm.

    20 Xcell Journal Fourth Quarter 2010

    Virtex-4 FPGA Forms Foundation for Secure GSM StandardsVirtex-4 FPGA Forms Foundation for Secure GSM StandardsHere are some design mechanisms and tips you can try when implementing current and future A5/x algorithms using Xilinx FPGAs.Here are some design mechanisms and tips you can try when implementing current and future A5/x algorithms using Xilinx FPGAs.


  • Ins and Outs of A5/1 Algorithm In the GSM standard, information travelsover the airwaves as sequences of frames.Frame sequences contain a digitized versionof the users voice as well as streaming audioand video data used in mobile Internetbrowsing. The system transmits each framesequentially, 4.6 milliseconds apart. Aframe consists of 228 bits; the first 114 bitsare called uplink data and the next 114bits are known as downlink data.

    We initialize A5/1 using a 64-bit secretkey together with a known frame numberthat is 22 bits wide. The next step is tofeed the input bits of the frame and secretkey into three linear feedback shift regis-ters (LFSRs) that are 19, 22 and 23 bits insize respectively. The feedback is providedafter XORing of selected taps, whichhelps increase randomness in the finaloutput. I will call the three LFSRs R0, R1 and R2, such that each LFSR followsa primitive function. R0, R1 and R2 respectively use x19+x5+x2+x+1,x22+x+1 and x23+x15+x2+x+1 as theirprimitive functions.

    other. The session key KC takes 64cycles in loading whereas Fn takesanother 22 cycles. In every cycle, theinput bit is XORed with a linear feed-back value coming from selective taps.

    3. Next, allow the LFSRs to clock for100 cycles, a process called mixing.Linear feedback is active and so arethe chip enables, allowing a shift/no-shift that is also active.

    4. After the mixing step is complete, thenext 228 cycles result in the final out-put key stream. The uplink and down-link streams (each consisting of 114bits) are used for decryption andencryption operations. This stepemploys nonlinear feedback and amodified combiner as against the tra-ditional A5/1 algorithm defined above.

    5. You can repeat the previous steps forevery new frame Fn. The frame num-bers are updated where the session keyremains unchanged until authentica-tion protocols provoke it.

    Hardware ImplementationI did the hardware implementation of theproposed algorithm on Xilinx Virtex-4series FPGAs. Because we designed theimplementation logic for compactness, Itargeted the smallest device in the Virtex-4family, namely the XC4VLX15. Figure 1shows the overall architecture of the top-level module.

    The top level comprises two buildingblocks and glue logic. I designed the gluelogic to provide chip connectivity, startlogic and data-loading features. There aretwo other building blocks, Majority/Taprule and LFSR bank, each with its ownunique functions.

    The Majority/Tap rule block receivesthe selective tap positions from the LFSRbank and performs two separate functionsindependently. As the selection criteria forMajority or Tap rule are based on the lasttap of R0, R1 and R2, the logic forMajority rule and Tap rule is implementedin parallel. I also performed one other opti-mization in the implementation ofMajority rule. The pseudo algorithm forselecting majorities is described as:

    The clocking sequences of LFSRs use aparticular mechanism; otherwise, it wouldbe very easy to decipher the output ofLFSRs. Therefore, clocking is based on amajority rule. This rule uses one tap eachfrom R0, R1 and R2, and determineswhether the taps are mainly 0 or 1. That is,two or more taps with a value of 0 imply amajority value 0; otherwise, it is 1. Oncethe majority is established, clock the LFSRsif their input bit matches the majority bit.If the input bit does not match the majori-ty value, no input bit will be inserted in theLFSR and hence, no shifting will takeplace. Additionally, we get the output byXORing each output bit of R0, R1 and R2in the original A5/1. In this work, I havereplaced the standard XORing with amore sophisticated output-generatingfunction that we call a combiner.

    The key setup routine of the A5/1 algo-rithm is as follows:

    1. Initialize R0, R1 and R2 with 0.

    2. Load the value of session key KC andframe Fn into the LFSRs, one after the

    Fourth Quarter 2010 Xcell Journal 21









    Load Logic

    LFSR Bank





    Majority / TapRule


    Figure 1 Architectural diagram of the top module


  • If (R0[13] + R1[12] + R2[16])

    >= 2 then maj1 = 1

    else then maj1 = 0

    Similarly, we find the value of maj2based on tap numbers 7, 5 and 8. Based onthese majority functions, we define thechip enable for R0 as:

    If (R0[13]== maj1) AND (R0[7] ==

    maj2) then chip enable for Majority

    rule is 1 else 0.

    I implemented the pseudo code forselecting maj1 and maj2 in the form ofsimple and/or gates. Similarly, the pseudocode for chip enables maps onto a simpleXNOR function, combining all the logicand reducing area.

    The technique implements the Tap rulealgorithm using case statements. The orig-inal A5/1 algorithm determines the shiftoperation or chip enable for LFSRs basedon the majority rule only. As I have intro-duced a modified Majority rule and anadditional Tap rule for shifting LFSRs, Ineeded another mechanism. Thus, makethe final selection of chip enables for R0,

    R1 and R2 based on the PoliSel signal,which determines whether to output thechip enable signal established by Majorityor Tap rule. The PoliSel signal imple-ments this equation: PoliSel = R0[18]XOR R1[21] XOR R2[22].

    The LFSR BankThe LFSR bank module houses multiplefunctions and implementations. Thismodule instantiates a core LFSR withvarying parameters for establishing R0,R1 and R2 LFSRs. The width of theseLFSRs is 19, 22 and 23 respectively. Thismodule also instantiates an improvedlinear feedback function from A5/1.Additionally, the LFSR bank imple-ments our novel nonlinear feedbacklogic. I also implemented in this blockthe combiner that produces the finaloutput. Figure 2 shows the block dia-gram for the LFSR bank. Here, theLFSRs are serial-in, parallel-out shiftregisters. Xilinx Virtex-4 devices allowconvenient mapping of these shift regis-ters onto hardware. Using the standard

    template for LFSRs as shown below, wecan infer generic serial registers.

    module lsr (clk, ce, si, po);

    parameter width = 18;

    input clk, ce, si;

    output [width-1:0] po;

    reg [width-1:0] shftreg = 0;

    always @ (posedge clk)


    if (ce) shftreg

  • Fourth Quarter 2010 Xcell Journal 23

    (The latter controls the parameter widthinside instance lsr.)

    As seen from the following code snippet,the input loading path of the LFSRs is well-defined in terms of simple XOR operations.

    wire frameXor19, keyXor19, si19input;assign frameXor19 = frame ^ si19lfb;assign keyXor19 = key ^ si19lfb;assign si19input = (frameXor19 ^keyXor19) ? frameXor19:keyXor19;

    The existence of asynchronous gatesincreases the length of the critical path.However, here it is well within tolerablelimits, as the critical path in the currentcase consists of only three XORs and onemultiplexer.

    After loading is completed, the feed-back path chooses between either linear ornonlinear feedback. The nonlinear feed-back controller makes this selection deci-sion. A choice of nonlinear feedbacksuddenly changes the design specificationsand parameters. For instance, the nonlin-ear feedback function is activated periodi-cally every 11 clock cycles and remainsactive for 10 clock cycles. To keep theimplementation area small, we have imple-mented counters rather than adders toenforce the periodic behavior of the non-linear feedback function. The imple-mentation requires separate counters for

    R0, R1 and R2 for counting the numberof 1s. The pseudo algorithm for thisimplementation is as follows:

    1. Detect falling edge on ldlfsr signal.

    2. Start counting for 100 cycles.

    3. After 100 cycles, for every 10 cyclesactivate the stream breaker, then deactivate for 10 cycles until 114clocks elapse.

    Stream breaker pseudo code:

    4. Sum the contents of lfsr 19, 22, 23.

    5. If count19 > 10, count22 > 11 orcount23 > 11

    6. pass 1 into the LFSR

    7. else

    8. pass 0 into the LFSR.

    Since the decision of inserting 1s or 0sin the input of R0, R1 and R2 needs to betaken every clock cycle, once the nonlinearfeedback is activated, the number of coun-ters and adders significantly increases inarea and critical path.

    The combination of chip enable andinput causes the nonlinear feedback path toassume 0 or 1 based on the algorithm of thestream breaker. Figure 3 shows a hardwarebuilding block implementing this scheme.

    Using counters with defined thresh-olds assists the implementation of the

    nonlinear feedback controller. Do notallow the counter to decrement afterapproaching 0 or to increment afterreaching the high value corresponding toR0, R1 and R2, namely 19, 22 and 23respectively. The following code snippetprovides one example implementation ofthe counter:

    reg [4:0] sum19=5'd0;wire inc_sum19, dec_sum19;assign inc_sum19 = si19 & ce19; assign dec_sum19 = lfsr19[18] & ce19;always @ (posedge clk)begin

    case ({inc_sum19, dec_sum19})2'b01:

    begin if (sum19 == 5'd0) sum19 =

    Figure 3 Nonlinear feedback controller and input selection values


  • by Michaela BlottSenior Research Engineer Xilinx, Inc. [email protected]

    Jonathan EllithorpePhD CandidateStanford University

    Nick McKeownProfessor of Electrical Engineering and Computer ScienceStanford University

    Kees VissersDistinguished EngineerXilinx, Inc.

    Hongyi ZengPhD CandidateStanford University

    Stanford University, together with XilinxResearch Labs, is building a second-gener-ation high-speed networking design plat-form called the NetFPGA-10G specificallyfor the research community. The new plat-form, which is poised for completion thisyear, uses state-of-the art technology tohelp researchers quickly build fast, complexprototypes that will solve the next crop oftechnological problems in the networkingdomain. As with the first-generation plat-form, which universities worldwide haveeagerly adopted, we hope the new platformwill spawn an open-source community thatcontributes and shares intellectual proper-ty, thus accelerating innovation.

    24 Xcell Journal Fourth Quarter 2010

    FPGA Research Design PlatformFuels Network AdvancesFPGA Research Design PlatformFuels Network AdvancesXilinx and Stanford University are teaming up to create an FPGA-based referenceboard and open-source IP repository to seed innovation in the networking space. Xilinx and Stanford University are teaming up to create an FPGA-based referenceboard and open-source IP repository to seed innovation in the networking space.


  • This basic platform will provide every-thing necessary to get end users off theground faster, while the open-source com-munity will allow researchers to leverageeach others work. The combination effec-tively reduces the time spent on the actualimplementation of ideas to a minimum,allowing designers to focus their efforts onthe creative aspects.

    In 2007, we designed the first-genera-tion board, dubbed NetFPGA-1G, arounda Xilinx Virtex-II Pro 50, primarily toteach engineering and computer sciencestudents about networking hardware.Many EE and CS graduates go on to devel-op networking products, and we wanted togive them hands-on experience buildinghardware that runs at line rate, uses anindustry-standard design flow and can beplaced into an operational network. Forthese purposes, the original board had to below in cost. And with generous donationsfrom several semiconductor suppliers, wewere able to bring the design in at an endprice of under $500. As a result, universi-ties were quick to adopt the board andtoday about 2,000 NetFPGA-1Gs are inuse at 150 schools worldwide.

    But the NetFPGA very quickly becamemore than a teaching vehicle. Increasingly,the research community began to use ittoo, for experiments and prototypes. Forthis purpose, the NetFPGA team providedfree, open-source reference designs andmaintains a repository of about 50 con-tributed designs. We support new users,run online forums and offer tutorials, sum-mer camps and developers workshops.

    Trend Toward ProgrammabilityFor more than a decade, networking tech-nology has trended toward more-program-mable forwarding paths in switches, routersand other products. This is largely because

    designs in addition to FPGA silicon so asto speed up the design process.

    To realize this vision, we will deliver aboard with matching FPGA infrastructuredesign in the form of both basic anddomain-specific IP building blocks toincrease ease of use and accelerate develop-ment time. We further will develop refer-ence designs, such as a network interfacecard and an IPv4 reference router, as well asbasic infrastructure that assists with build-ing, simulating and debugging designs. Theidea is to allow users to truly focus theirdevelopment time on their particular areaof expertise or interest without having toworry about low-level hardware details.

    Unlike the mainstream Targeted DesignPlatforms, our networking platform targetsa different end-user group, namely, the larg-er research community, both academic andcommercial. Semiconductor partners areheavily subsidizing this project to assist inthe effort to keep the board cost to anabsolute minimum so as to encouragebroad uptake. Not only Xilinx but otherkey component manufacturers such asMicron, Cypress Semiconductor andNetLogic Microsystems are donating partsfor the academic end user. (Commercialresearchers will pay a higher price.)

    Part of the projects strength is the fact thatthis platform is accompanied by a communi-ty as well as an open-source hardware reposi-tory that facilitates the sharing of software, IPand experiences beyond the initial base pack-age. The result is an ever-growing IP librarythat we hope will eventually encompass awide range of reference components, net-working IP, software and sophisticated infra-structure thanks to contributions from manywell-known universities, research groups andcompanies. We hope that by providing acarefully designed framework, some light-weight coordination to share expertise and IP

    networking hardware has become morecomplicated, thanks to the advent of moretunneling formats, quality-of-serviceschemes, firewall filters, encryption tech-niques and so on. Coupled with quicklychanging standards, those factors havemade it desirable to build in programma-bility, for example using NPUs or FPGAs.

    Researchers often want to change someor all of the forwarding pipeline. Recently,there has been lots of interest in entirelynew forwarding models, such asOpenFlow. Researchers can try out newnetwork architectures at the national scaleat national testbeds like GENI in theUnited States (http://geni.net) and FIRE inthe EU (http://cordis.europa.eu/fp7/ict/fire/calls_en.html).

    Increasingly, researchers are embracingthe NetFPGA board as a way to prototypenew ideasnew forwarding paradigms,scheduling and lookup algorithms, andnew deep-packet inspectorsin hardware.One of the most popular reference designsin the NetFPGA canon is a fully function-al open-source OpenFlow switch, allowingresearchers to play with variations on thestandard. Another popular reference designaccelerates the built-in routing functions ofthe host computer by mirroring the kernelrouting table in hardware and forwardingall packets at line rate.

    NetFPGA, Take TwoFor the second-generation platform, theso-called NetFPGA-10G, we haveexpanded our original design goals to alsoinclude ease of use, with the aim of sup-plying end customers with a basic infra-structure that will simplify their designexperience. This goal is closely alignedwith the objective of Xilinxs mainstreamTargeted Design Platforms, which pro-vide users with tools, IP and reference

    Fourth Quarter 2010 Xcell Journal 25

    An open-source hardware repository facilitates the sharing

    of software, IP and design experiences, promoting technological

    solutions to the next generation of networking problems.


  • in a systematic way, and a well-designedplug-and-play architecture with standardizedinterfaces, the open-source hardware reposi-tory will grow, promoting technologicalsolutions to the next generation of network-ing problems.

    The NetFPGA-10G is a 40-Gbit/secondPCI Express adapter card with a largeFPGA fabric that could support as many

    applications as possible. As shown in Figure1, the board design revolves around a large-scale Xilinx FPGA, namely a Virtex-5XC5VTX240T-2 device [1].

    The FPGA interfaces to five subsystems(see Figure 2). The first of these, the net-work interface subsystem, hosts four 10-Gbps Ethernet interfaces with PHY devices

    through which the network traffic entersthe FPGA. The memory subsystem, for itspart, consists of several QDRII andRLDRAMII components. The majority ofthe I/Os are used for this interface, to max-imize the available off-chip bandwidth forfunctionality such as routing tables orpacket buffering. The FPGA also interfacesto the PCIe subsystem.

    The fourth subsystem is an expansioninterface designed to host a daughter card orto communicate with another board. Forthat purpose we brought all remaining high-speed serial I/O connections out to twohigh-speed connectors. Finally, the fifth sub-system is concerned with the configurationof the FPGA.

    Overall, the board is implemented as adual-slot, full-size PCIe adapter. Two slotsare required for reasons of heat/power andheight. Like high-end graphics cards, thisboard needs to be fed with an additionalATX power supply, since power consump-tiongiven absolute maximum load onthe FPGAcould exceed the PCIe single-slot allowance of 50 watts. However, theboard can also operate standalone outside aserver environment.

    Memory SubsystemA central focus in our design process wasthe interface to SRAM and DRAM com-ponents. Since the total number of I/Os onthe FPGA device limits the overall avail-able off-chip bandwidth, we had to strike acarefully considered compromise to facili-tate as many applications as possible.Trying to support applications rangingfrom network monitoring through securityand routing to traffic management impos-es greatly varying constraints.

    In regard to external memory access,for example, a network monitor wouldrequire a large, flow-based statistics tableand most likely a flow classificationlookup. Both accesses would require shortlatencies, as the flow classification needsmore than one lookup with intradepen-dencies, and the update in a flow statisticstable would typically encompass a read-modify-write cycle. Hence, SRAM wouldbe an appropriate device selection.However, a traffic manager would mainlyneed a large amount of memory for pack-et buffering, typically implementedthrough DRAM components due to den-sity requirements. As a final example, con-sider an IPv4 router that needed arouting-table lookup as well as packetbuffering in respect to external memory.

    Summing up the requirements from arange of applications, we realized that cer-tain functionality would consume externalmemory bandwidth, whether it be SRAMor DRAM. Where packet buffering (requir-ing a large storage space) would point toDRAM, SRAM would be the choice forflow classification search access, routing-table lookup, flow-based data table for sta-tistics or rule-based firewall, memory

    26 Xcell Journal Fourth Quarter 2010

    Figure 1 The NetFPGA-10G board is built around a Virtex-5 FPGA.







    Figure 2 The board connects to five subsystems: network interface, PCIe, expansion, memory, configuration and power.


  • Fourth Quarter 2010 Xcell Journal 27

    management tables for packet bufferimplementations and header queues.

    All of this functionality needs to be car-ried out on a per-packet basis. Therefore,given the worst case of minimum-sizepackets of 64 bytes with 20 bytes of over-head, the system needs to service a packetrate of roughly 60 Megapackets per second.Second, we need to differentiate the access-es further. To begin with, many memorycomponents such as QDR SRAM andRLDRAM SIO devices have separate readand write data buses. Since the access pat-terns cannot be assumed to be symmetri-

    cally distributed, we cannot pool theoverall access bandwidth, but must consid-er the operations individually.

    Whats more, there is a third type ofaccess, namely searches. Searches can beideally implemented through TCAM-based devices, which give guaranteedanswers with fixed latencies. However, weruled out this type of device for our boardfor price and power reasons, along withthe fact that TCAMs further constrainthe use of the I/O. Searches can also beimplemented in many other ways such asdecision trees, hash algorithms anddecomposition approaches, with or with-out caching techniques, to name a few[2]. For the purpose of this discussion, weassumed that a search can be approximat-ed through two read accesses on average.Given these facts and making some com-mon assumptions on data widths, we

    refined our requirements further as seenin Table 1.

    Assuming a clock speed of 300 MHz onthe interface, a QDRII interface can service2*300 = 600 million accesses/second forread and for write operations. Hence, threeQDRII x36-bit interfaces could fulfill all ofour requirements.

    In regard to DRAM access, we consid-ered mainly the case of packet storage,where each packet is written and read oncefrom memory. This translates into a dataaccess bandwidth of roughly 62 Gbps onceyou have removed the packet overhead

    from the originally incoming 2*40 Gbps.In terms of physical resources, anRLDRAMII access can probably achievean efficiency of around 97 percent, where-as DDR2 or DDR3 devices would morelikely come in at around 40 percent [3],hence requiring significantly more I/O. Wetherefore chose RLDRAMII CIO compo-nents. Two 64-bit RLDRAMII interfaces at300 MHz deliver a combined bandwidththat is roughly enough to service therequirement.

    Network InterfaceThe network interface of the NetFPGA-10G consists of four subsystems that can beoperated as 10-Gbps or 1-Gbps Ethernetlinks. To maximize usage of the platform aswell as minimize power consumption, wechose four Small Form-Factor PluggablePlus (SFP+) cages as the physical interface.

    Compared with other 10G transceiverstandards such as XENPAK and XFP,SFP+ has significant advantages in termsof power consumption and size. WithSFP+ cages, we can support a number ofinterface standards, including 10GBase-LR, 10GBase-SR, 10GBase-LRM andlow-cost direct-attach SFP+ copper cable(Twinax). Furthermore, SFP modules for1-Gbps operation can be utilized, therebysupporting the 1000Base-T or 1000Base-X physical standards as well.

    Each of the four SFP+ cages connects toa NetLogic AEL2005 device via the SFI

    interface. The AEL2005 is a 10-GigabitEthernet physical-layer transceiver with anembedded IEEE 802.3aq-compliant elec-trical-dispersion compensation engine.Besides regular 10G mode, the PHY devicecan support Gigabit Ethernet (1G) mode.On the system side, these PHY devicesinterface to the FPGA via a 10-GigabitAttachment Unit Interface (XAUI). Whenoperating in 1G mode, one of the XAUIlanes works as a Serial Gigabit MediaIndependent Interface (SGMII).

    Suitable interface IP cores are availableinside the Virtex-5 FPGA. For 10-Gbpsoperation, Xilinx markets the XAUILogiCORE IP as well as a 10-GigabitEthernet media-access controller(10GEMAC) LogiCORE IP [4, 5]. For 1Goperation, the interfaces can be directlyconnected to the embedded Xilinx Tri-Mode Ethernet MAC core [6].

    Data width #Reads #Writes #Reads #Writes (bits) per packet per packet per x36 interface per x36 interface

    Flow classification (5tupel + return key) 144 2 0 8 0

    Routing-table lookup (dip + next hop) 96 2 0 6 0

    Flow-based information 128 2 0 8 0

    Packet buffer memory management 32 2 2 2 2

    Header queues 32 1 1 1 1

    Total number of accesses 25 3

    Total number of accesses per second (MAps) 1,500 180

    Table 1 SRAM bandwidth requirements


  • PCIe SubsystemThe NetFPGA-10G platform utilizes theOpen Component Portability Infrastructure(OpenCPI) as its main interconnect imple-mentation between the board and the hostcomputer over PCIe [7]. Presently we sup-port the x8 first generation, but mightpotentially upgrade to second generation inthe future. OpenCPI is a generalized, open-source framework for interconnectingblocks of IP that may each use varied typesof communication interfaces (streaming,byte-addressable and so on), with variedbandwidth and latency requirements. In itsessence, OpenCPI is a highly configurableframework that provides the critical com-munication glue between IP that is need-ed to realize a new design quickly.

    OpenCPI delivers a few key features forthe NetFPGA-10G platform. On the soft-ware side, we are able to provide a cleanDMA interface for transferring data (pri-marily including packets, although not

    limited in any way to this type of informa-tion) and for controlling the device via pro-grammed input/output. For networkingapplications, we provide a Linux networkdriver that exports a network interface foreach of the physical Ethernet ports on theNetFPGA device. This allows user-spacesoftware to transfer network packets to thedevice as well as read any host-visible regis-ter in the design.

    On the hardware side, OpenCPI pro-vides us with a clean, or even multiple,data-streaming interfaces, each config-urable through the OpenCPI framework.In addition, OpenCPI handles all of thehost-side and hardware-side buffering andPCIe transactions, so that users can focuson their particular application rather thanthe details of device communication.

    Expansion Interface, Configuration SubsystemThe purpose behind the expansion sub-system is to allow users to increase port

    density by connecting to a secondNetFPGA-10G boardto add differentflavors of network interfaces through anoptical daughter card, for exampleor toconnect additional search componentssuch as knowledge-based processors withhigh-speed serial interfaces. We bring out20 GTX transceivers from the FPGA andconnect them through AC-coupled trans-mission lines to two high-speed connec-tors. Designed for transmission interfacessuch as XAUI, PCIe, SATA andInfiniband, these connectors can link toanother board either directly, with matingconnector, or via cable assemblies. Eachtransmission line is tested to operate at6.5 Gbps in each direction, thereby pro-viding an additional 130-Gbps data pathin and out of the FPGA.

    Configuring FPGAs with ever-increas-ing bitstream size can potentially be aproblem when the configuration time ofthe device exceeds the PCIe limits. This is

    28 Xcell Journal Fourth Quarter 2010


    PCIe EP with DMA









    QDR memoryinterface

    RLDRAM memoryinterface

    clk & rst &pwr with



    AXI interconnect

    Configuration controland bitstream gear box


    CPLD (flash controller andconfiguration circuit)

    Figure 3 The FPGA design architecture for 10G operation relies on the AXI protocol.


  • Fourth Quarter 2010 Xcell Journal 29

    the case with the V5TX240T. The accessspeed of the platform flash devices, whichis significantly below what the V5TX240Tcan theoretically handle, imposes a bottle-neck. As countermeasures, designers mightconsider configuration of partial bit-streams, as well as accessing platform flashdevices in parallel and configuring theFPGA at maximum speed. To facilitatethe latter possibility, we equipped theboard with two platform flash devices thatconnect through a CPLD to the FPGAsconfiguration interface. In addition, theboard also supports the standard JTAGprogramming interface.

    The FPGA DesignA key aspect behind a successful open-source hardware repository must be a cleanarchitectural specification with standard-ized, abstracted and well-defined interfaces.In fact, we believe these interfaces to becrucial to providing a building-block sys-tem that enables easy assembly of compo-nents contributed from a large globalcommunity. Standardization ensures physi-cal compatibility, and a rigorous definitionthat goes beyond physical connectivityreduces the potential for misunderstandingon the interface protocols. Ideally, users canthen deploy abstracted components with-out further knowledge of their intrinsicimplementation details.

    As part of the full platform release, wewill provide the complete architecturalspecification as well as a reference designwith key components. These key compo-nents include:

    PCIe endpoint from OpenCPI [4]

    Four XAUI LogiCORE IP blocks andfour 10GEMAC LogiCORE cores(the latter under licensing agreement)in 10G mode [7,8]

    Two RLDRAMII memory controllersbased on the XAPP852 [8]

    Three QDRII memory controllersbased on MIG3.1 [9]

    Clocking and reset block that checksclock frequencies and power-OK signals,and generates all required system clocks

    Tri-Mode Ethernet MAC (TEMAC)for 1G operation [9]

    MDIO interface for configuration ofthe PHY devices

    Control processor in the form of aMicroBlaze, with a support systemthat handles all administrative tasks

    UART interface

    Configuration control and bitstreamgear box, which provides a program-ming path to the platform flash devices

    Input arbiter that aggregates allincoming traffic into one data stream

    Output arbiter that distributes the traffic to the requested output port

    Figure 3 illustrates how these compo-nents are interconnected for 10G opera-tion. For data transport we chose theAMBA4 AXI streaming protocol, and forcontrol traffic the interface is based onAMBA4 AXI-Lite. You can find furtherdetails on these interface specifications onwww.arm.com (and on the Xilinx webpagein the near future).

    Status and OutlookDesign verification of the board is com-plete. Once production test development isfinished, the board should shortly bereleased for manufacturing. Initial FPGAdesigns are running and we are workingnow toward a first code release.

    You can order through HiTech Global,which is manufacturing and distributingthe board (http://www.hitechglobal.com/Boards/PCIExpress_SFP+.htm). Differentpricing models apply to academic andcommercial customers. For the most up-to-date information on the project, please visitour website, www.netfpga.org, or subscribeto the netfpga-announce mailing list:https://mailman.stanford.edu/mailman/listinfo/netfpga-announce.

    The first code releases, planned for thecoming months, will open up the sourcecode to the wider community. It basicallycontains the design detailed in the FPGAdesign section and implements the intro-duced architecture. In addition, we will put

    significant effort into providing the righttype of infrastructure for building, simulat-ing and debugging the design. A last focuspoint in the coming months will be therepositories and framework that enable theefficient sharing of experience, expertise andIP within the NetFPGA community.

    AcknowledgementsMany thanks to the following people for theirhelp with this project: Shep Siegel, CTO ofAtomic Rules and driving force behindOpenCPI; John Lockwood, CEO of Algo-LogicSystems, driving force behind the first genera-tion of NetFPGA and an active contributor tothe current platform; Paul Hartke from XilinxUniversity Program (XUP) for his endless ener-gy and support; Rick Ballantyne, senior staffengineer at Xilinx, for his invaluable advice onboard design; Adam Covington and Glen Gibbat Stanford for their support; Fred Cohen fromHiTech Global for his cooperation.

    Furthermore, we would like to thank theNational Science Foundation and the followingsponsors for donating their components, namelyMicron, Cypress Semiconductor and NetLogicMicrosystems.


    [1] XC5VTX240T data sheet: http://www.xilinx.com/support/documentation/data_sheets/ds202.pdf

    [2] David E. Taylor, Survey and Taxonomy of Packet Classification Techniques, ACMComputing Surveys (CSUR), volume 37, No. 3,September 2005

    [3] Bob Wheeler and Jag Bolaria, Linley Report:A Guide to Network Processors, 11th Edition,April 2010

    [4] XAUI data sheet: http://www.xilinx.com/products/ipcenter/XAUI.htm

    [5] 10GEMAC data sheet:http://www.xilinx.com/products/ipcenter/DO-DI-10GEMAC.htm

    [6] Tri-Mode Ethernet MAChttp://www.xilinx.com/support/documentation/ip_documentation/hard_temac.pdf

    [7] www.opencpi.org

    [8] XAPP852 (v2.3) May 14, 2008:http://www.xilinx.com/support/documentation/application_notes/xapp852.pdf

    [9] MIG data sheet: http://www.xilinx.com/products/ipcenter/MIG.htm


  • by Fabrice MullerAssociate ProfessorUniversity of Nice Sophia, Antipolis, France LEAT - [email protected]

    Jimmy Le RhunResearch [email protected]

    Fabrice LemonnierProject [email protected]

    Benot MiramondAssociate ProfessorETIS, UMR 8051 CNRS - ENSEA - [email protected]

    Ludovic DevauxPhDUniversity of Rennes 1/ Cairn Inria [email protected]

    An autonomous robot finding its way inunknown terrain; a video decoder changingits decompression format according to sig-nal strength; a broadband electronic coun-termeasure system; an adaptiveimage-tracking algorithm for automotiveapplications. These are among the manyemerging embedded or mission-criticalapplications that show dynamic behaviorwith strong dependency on an unpre-dictable environment. Where staticallyresolved worst-case allocation was once ananswer to strong real-time constraints, flex-ibility is now also a requirement. The solu-tion proposed in a French research project isan operating system distributed onto theFPGA resources that manages both hard-ware and software threads.

    30 Xcell Journal Fourth Quarter 2010

    A Flexible Operating System for Dynamic ApplicationsA Flexible Operating System for Dynamic ApplicationsBy using the dynamic reconfiguration capabilities of Xilinx FPGAs, software flexibility and hardware performance meet in a homogeneous multithread execution model.

    By using the dynamic reconfiguration capabilities of Xilinx FPGAs, software flexibility and hardware performance meet in a homogeneous multithread execution model.


  • In recent years, denser systems-on-chip(SoCs) have made it possible to meet thedesign constraints by parallelizing tasks anddata, thereby increasing the number of com-putation units, in particular in embeddedsystems. This trend continues today with theaddition of heterogeneity of computingcores. But this technique becomes a wall ofcomplexity which dictates a higher level ofabstraction in the programming model.

    To surmount these challenges, we pro-pose to define a unified execution modelthat is used whether the threads aremapped onto hardware or software. Thehardware implementation of this executionmodel relies strongly on the use of dynam-ically reconfigurable logic. Coupled with atraditional multicore software subsystem, afully distributed architecture provides thebest of both worlds. The software part iswell-suited to intelligent event-based con-trol and decision making, while the hard-ware part excels in power efficiency, highthroughput and number crunching. Inbetween, we get the ability to balance per-formance and resource utilization, not justfor each specific application, but also for aspecific state of an application.

    The high integration capabilities of mod-ern, platform FPGAs make it possible to puta full, heterogeneous and dynamic comput-ing system into one or two chips, with ahigh level of flexibility and scalability.

    The adaptive hardware is very useful inapplications such as missile e