Methods to Differentiate Mil/Aero Solutions Using FPGAs Dan Gardner Final MAPLD Presentation

Methods to Differentiate Mil/Aero Solutions Using FPGAs

Dan Gardner

Final MAPLD Presentation

Gardner MAPLD 2005/P145

2

Agenda

Why FPGA technology is important Technology to consider for FPGA EDA software Why you need these for Mil/Aero FPGA


3

FPGAs overtake ASICs in Mil/Aero Segment

Military/Aero- space Market

2002 2003 2004 2005 2006 2007 2008

Total Semiconductor

$ 3,751 $3,783 $4,357 $4,360

$4,295

$4,648

$5,160

ASIC $176 $188 $206 $219 $220 $212 $202

FPGA/PLD $158 $190 $222 $238 $253 $301 $381

ASIC Growth 7% 9% 7% 0% -4% -5%

FPGA/PLD Growth

20% 17% 7% 6% 19% 27%

Source: Gartner Dataquest


4

$206$219 $220 $212 $202

$158$190

$222$238 $253

$381

$188$176

$301

$-

$50

$100

$150

$200

$250

$300

$350

$400

$450

2002 2003 2004 2005 2006 2007 2008

-10%

-5%

0%

5%

10%

15%

20%

25%

30%

ASIC FPGA/PLD ASIC Growth FPGA/PLD

Source: Gartner Dataquest

FPGAs overtake ASICs in Mil/Aero Segment


5

Requirements for FPGA software in Mil/Aero

Cost effective delivery of mission performance— Initial Creation

Cost and speed of design— Predictable time to market at fixed cost— Fast iterations— Timing and system closure

— Complete Verification Commercial FPGA often skips many verification steps Some Mil/Aero applications have additional considerations

— Maintenance of Project Cost of life cycle maintainability of design Support of standard platforms Support Mil-preferred devices, documentation and flows


6

Many FPGA selections available— High-performance choices

Altera Stratix II/GX Xilinx Virtex-4

— High-volume choices Actel ProASIC3/3E Altera Cyclone II Lattice LatticeEC/ECP Xilinx Spartan-3/3E

— Radiation Tolerant choices Actel RTAX-S Xilinx QPro

FPGA Technologies are Very Competitive


7

Widespread Use in Mil/Aero

Complex applications require latest FPGA technologies

— Software defined radio— Platform-based computing— Reconfigurable computing— DSP algorithms in hardware co-processors

On the other end of the spectrum are the radiation tolerant devices

Low volumes fit FPGAs better than ASICs in many cases


8

Technologies to Consider

All technologies listed below are required to build a complete methodology and will be covered

This presentation will essentially focus on the unique requirements of Mil/Aero FPGA applications:

— Rule checker with platform-independent coding styles— Design management— RTL + physical synthesis— I/O design with integration path to PCB— System-level design— Verification

Electronic System-Level (ESL) Overview Assertion based (CDC to validate SEU protection) Coverage Driven Clock domain crossing (CDC)

— Embedded systems


9

Rule Checkers

Encapsulate knowledge:– Expect built-in checks from standard sources

– Reuse Methodology Manual

– FPGA vendor recommendations

– Must allow quick customization for your own checks Use Early and Often:

— Perform checking interactively or in batch— Understand the causes of violations— Easily interact, organize, & track violations— Interactively trace & fix violations

Share knowledge:— Share checks with the team/company— Allow any designer to apply accumulated knowledge— Export results for reporting

Static Design Checking for VHDL/Verilog RTL


10

Put a Senior Designer on Everyone’s Shoulder

Do not re-learn from the same mistakes over and over again

Code Browser indicates errors & warnings

Code lines highlighted

Hover help for each violation

Step through errors

Trace to graphics

Show rule/rule help

Rerun analysis


11

Designing in Teams Progressive development, validation, implementation

— Designers work in parallel, from RTL placed gates— Top-down & bottom-up methodology freedom

Supports team standards— Code, graphical appearance, tool preferences, design flows

Manages multiple versions of the design Long design existence requires reproducible flows Multiple contracts on single, long-term projects require comprehensive,

customized design management tools

Pro

cess A

uto

matio

nP

rocess A

uto

matio

nP

rocess A

uto

matio

nP

rocess A

uto

matio

n

Vers

ion

Man

ag

em

en

tV

ers

ion

Man

ag

em

en

tV

ers

ion

Man

ag

em

en

tV

ers

ion

Man

ag

em

en

tFPGA Vendor P&R

Synthesize

Design

Simulate


12

Visualization for Design Reviews & Reuse

Strict documentation and traceability rules dominate Mil/Aero design

Effective implementation of IP reuse— Minimize additional design for reuse time

Automate processes and policies to design IP

— Minimize design time to include IP Automate analysis of IP for fast implementation


13

Design and IP Reuse Flows

FIRM macro blocks enhance design productivity at physical implementation level

Achieve predictable results for FPGA fabric family

Seamless porting between like-family FPGA devices

Helps in easy verification


14

Platform FPGA Technology vs. Pushbutton FPGA Design Flow

Major technology changes in platform FPGA

— More gates per part

— Specialized embedded technology

— Specialized interconnect

— High-speed device effects

Emerging design challenges

— Design debug process is unreliable for complex designs

— Harder to bring quality product to market quickly

— Harder to manage flows: Design reuse & IP integration

— Harder to predict development costs


15

Control for Complex Requirements

Fully integrated RTL synthesis and physical synthesis capabilities

— Enhances RTL Synthesis Takes physical considerations into account Linking physical data with logic synthesis RTL to placed gates

— Improves productivity by enhancing design analysis

Cross selection between RTL code, schematic, physical and timing views

— Physically aware IP and design reuse Improves time to design completion

— Improves performance by interactively optimizing the placed design

Before Physical Synthesis

After Physical Synthesis


16

Advanced FPGA Methodologies Physical Awareness Fulfills Key Technology Needs

Placement reuse/ECO— Add new functionality safely — Add/change RTL code w/ minimum placement

impact

Divide and conquer approach— Meet challenging design requirements quickly— Isolate & optimize tricky portions of circuitry


17

System Design Trends

2004 EDA Study

None38%

One 32% Two

16%

Three5%

Five or more5%

Four4%

Almost half of all PCBs with FPGAs have multiple FPGAs per PCB

Average FPGAs on a single PCB

Many FPGAs now over 500 pins

Average pins of largest FPGA

100 to 249 pins 27%

1500 pins or more2%

Less than 100 pins7%

750 to 999 pins7%

1000 to 1499 pins19%

500 to 749 pins13%

250 to 499 pins25%


18

Isolated Flows with Manual Integration

FPGA & PCB teams typically don’t communicate well— All information entered and synchronized manually

Package, speed-grade, pin assignments

— Information must stay consistent in three locations FPGA, PCB schematic, PCB layout


19

HDLHDL

Best location to meet FPGA constraints

FPGA PCB Designer Issues

The FPGA must work on the board and the overall system must work

— Each design engineer has his own constraints to achieve May be in conflict/unsupportive of partner designer

Need to converge on a trade-off acceptable to both parties

Best location to meet Board constraints


20

LanguageLanguageLanguageLanguage

Design Languages & Tasks

TaskTaskTaskTask

RequirementsRequirementsRequirementsRequirements

AlgorithmAlgorithmExplorationExplorationAlgorithmAlgorithm

ExplorationExploration

Architecture Architecture AnalysisAnalysis


VerificationVerificationVerificationVerification

RTL DesignRTL DesignRTL DesignRTL Design

Text / UMLText / UMLText / UMLText / UML

C/C++C/C++UntimedUntimedSystemCSystemC


VHDLVHDLVerilogVerilogVHDLVHDL

VerilogVerilog

Architectural Analysis tools aren’t …

TransactionTransactionLevelLevel

SystemCSystemC


SystemCSystemC

…adopted by RTL Designers


21



TaskTaskTaskTask










SystemCSystemC


SystemCSystemC


VerilogVerilog

HVL’s Extend & Accelerate the

RTL Design Process

AssertionsAssertionsPSL/SVAPSL/SVA


SystemSystemVerilogVerilogSystemSystemVerilogVerilog




22



TaskTaskTaskTask










SystemCSystemC


SystemCSystemC


VerilogVerilog

…and enable RTL Designers to cross the chasm to system level design



SystemSystemVerilogVerilogSystemSystemVerilogVerilog




23

C Synthesis Typical end user: hardware designer

— Developing compute intensive designs— Have existing C functional models

Typical Applications — Wireless, satellite communications; video/image

processing — Automatic frequency control (AFC), clock tracking— Viterbi, turbo decoder, Reed-Solomon— FFT, DCT, FIR filters


24

What C Synthesis Delivers

Untimed C++ synthesis— Technology independent source focused on true

functional intent— Connects system to hardware design domain— Micro-architecture “what if” analysis— Interface “what if” analysis— SystemC compatible— No proprietary extensions

Automated RTL creation Algorithm and data path analysis Faster verification


25

Why SystemVerilog for Design?

Encapsulation allows designers to model at more abstract levels

Scalability makes incremental design changes simpler

Code re-usability increases design efficiency Easier to model accurate, synthesizable models

of any size designs Not only system-level designers need

SystemVerilog Both Synthesis and Simulation benefit from

SystemVerilog


26

Summary of SystemVerilog Design SystemVerilog increases productivity for both synthesis and simulation

— Can use existing VHDL and Verilog modules mixed with SystemVerilog

Interface features:— Ability to encapsulate functionality as well as connectivity— Ability to replace a group of names by a single name

New concise and powerful implicit port connection features speed design entry and provide early type checking

Allows designers to take advantage of new abstract architectural models

Allows designers to insert assertions directly into RTL code


27

Abstraction Drives Design Productivity

RTLRTLRTLRTL

Algorithmic C++Algorithmic C++Algorithmic C++Algorithmic C++

Untimed TLM SystemCUntimed TLM SystemCUntimed TLM SystemCUntimed TLM SystemC

Timed TLM SystemCTimed TLM SystemCTimed TLM SystemCTimed TLM SystemC

Cycle Accurate SystemCCycle Accurate SystemCCycle Accurate SystemCCycle Accurate SystemC

SimulationSource Implementation

1x (7 days)

10,000x (1 min)

10x

100x

1,000x

1x (5 weeks)

20x (2 days!!)

2x (2 weeks)

Functional

Structural

Cycle

RTL

Transaction


28

Automatic Generation of Verification Infrastructure

ComparatorComparatorComparatorComparator

Golden results DUT results

Original C++Original C++AlgorithmAlgorithm

Original C++Original C++AlgorithmAlgorithm RTLRTLRTLRTL

TransactorTransactorTransactorTransactor

TransactorTransactorTransactorTransactor

Facilitates the Verification of the synthesized design

The original C++ testbench can be reused to verify the design

— RTL or Cycle Accurate— SystemC, VHDL or Verilog

Transactors convert function calls to pin-level signal activity

Pushbutton verification solution includes Makefiles and Simulation scripts

Original C++Original C++TestbenchTestbench

Original C++Original C++TestbenchTestbench


29

Exhaustive Algorithm VerificationWith Automated Real Time Prototypes

Quickly produce RTL code from algorithmic specifications

— Regardless of the quality of the architecture

Run RTL synthesis and P&R with integrated tool flows

Validate the functional correctness of the algorithm on FPGA prototyping boards

— Architecture optimization can be pursued in parallel

Algorithms

Precision RTL Synthesis

Catapult CSynthesis

FPGA VendorP&R

Prototyping

?

NetlistConstraints

C CodeConstraints

RTL CodeConstraints


30

Functional Flaws Driving Need for Re-SpinIC/ASIC Designs Requiring Re-Spins by Type of Flaw

75%71%

0% 20% 40% 60% 80% 100%

Other

Firmware

IR Drops

Power Consumption

Mixed-Signal Interface

Slow Path

Delays/Glitches

Yield/Reliability

Fast Path

Tuning Analog Circuit

Clocking

Logic/Functional

Percent of Designs Requiring Two or More Silicon Spins

Market Study 2002

Market Study 2004

Source: 2004/2002 IC/ASIC Functional Verification Study, Collett International Research, Used with PermissionSource: 2004/2002 IC/ASIC Functional Verification Study, Collett International Research, Used with Permission

…the Problem is Getting Worse


31

Methodology Explosion Targeting Verification

Assertion-based verification Functional coverage Constrained-random testing Coverage-driven verification Dynamic-formal verification Transaction-level verification Model checking And more . . .


32

SystemVerilog for Verification

SystemVerilog is a complete Verification Language— Can be used with VHDL — Stimulus generation capabilities

Dynamically configurable constrained-random value generation Ability to generate constrained-random stimulus sequences Ability to randomly select control paths (test scenario selection, etc.)

— Functional coverage modeling Measure the verification quality and test effectiveness Dynamic reactivity with constrained-random stimulus generation

— Assertion-Based Verification Property specification Assertion & coverage monitoring

— High-level modeling (programming) capabilities Efficiently and effectively model the operational environment Develop reusable verification environments


33

Reference Model

AssertionCheckers

BusMonitor

AssertionCheckers

BusMonitor

Assertion-Based VerificationAssertions Enable Higher Quality Designs

Assertions provide observability for higher complexity designs

— ABV makes assertions a key element, ensuring that design properties are not violated

Assertions describe (un)desired behavior

Assertions dramatically shorten debug and repair time

Assertions stay on during block, chip and system-level tests

— Finds bugs you weren’t looking for


34

Coverage-Driven Verification

Verification is effectively metric-less— Few designers know if their strategy is adequate or

efficient

— Sign-off criteria are ad hoc and vary by company

— Code coverage is not a functional verification metric


35

Expect Widespread Use of Coverage-Driven Verification

PSL and SystemVerilog provide coverage constructs

Simulators integrating functional coverage to improve performance and debug

New test strategies require functional coverage— Random and constrained random tests need coverage to

determine what they tested


36

Clock-Domain Crossings

Incorrect handling of Clock-Domain Crossing (CDC) signals is the 2nd major cause of re-spins

Traditional verification techniques do not work for CDC signals

CDC problems are subtle, will occur in hardware, and are complex to debug

Assertion Synthesis automates CDC verification, significantly reducing the risk of

CDC-related silicon re-spins

Assertion Synthesis automates CDC verification, significantly reducing the risk of

CDC-related silicon re-spins


37

Common CDC Myths

Adding correct synchronizers on all paths is all that is needed— Even if implemented perfectly, protocol errors and reconvergence

error will still exist

I can detect protocol violations by sweeping clocks in my simulation

— Is very reliant on luck, and will only detect a small subset of errors

I use special synchronizers that add a random delay, so I am covered for reconvergence

— This only works for paths that contain synchronizers, and lacks the automation and coverage necessary to significantly reduce risk.

A complete CDC solution MUST verify the structural correctness, transfer protocols, and deep sequential

reconvergence, otherwise bugs WILL be missed


38

ASAPPlatform Exp

Platform FPGAs Need a Complete Flow

ISE ToolsChipscopeSW-HW OnChip DebugXRAYNucleus

InventraPrecision Synthesis

Modelsim

Platform Studio IDE

SeamlessISS

Microtec

BSP

Code|LabStacks

PPC405

PPC405

PLBArbiter

PLBArbiter

OPB<>

PLB

OPB<>

PLB

OPBArbiter

OPBArbiter

JTAGJTAGOPBGPIOOPBGPIO

16550UART16550UART

EMCCntrl

EMCCntrl

32KBBRAM

32KBBRAM

BRAMCntrl

BRAMCntrl

PPC405

PPC405

PLBArbiter

PLBArbiter

OPB<>

PLB

OPB<>

PLB

OPBArbiter

OPBArbiter

JTAGJTAGOPBGPIOOPBGPIO

16550UART16550UART

EMCCntrl

EMCCntrl

32KBBRAM

32KBBRAM

BRAMCntrl

BRAMCntrl

Software Hardware

PCB, Signal Integrity Tools


39

HW/SW Co-verification: Faster Iteration Loop

Supports: Edit/Compile/Verify

Eliminates: Edit/Synthesize/ Implement/Download/Verify

Promotes: Superior Visibility and Control

HDL Entry

Synthesis

Implementation

Download BitstreamInto FPGA

Evaluation Board

HDL Entry

HDL Compile

Seamless FPGACo-Verification

Without Co-verification With Co-verification


40

Processors Require SW Tools

Executable and

Translatable UML solution

generates embedded code

Eclipse-powered

complete, integrated

development

tool suite

Prototype whole

software application

Source code, royalty-free

RTOS & middleware

RTOS

Middleware

Prototyping

Dev Tools

Embedded software to cover it all

UML Suite


41

Support for Processor-based FPGAs

RTOS support for both Xilinx MicroBlaze and PowerPC architectures and Altera NIOS, NIOS II and ARM architectures

Target software debugger and build environment Support for Xilinx Spartan3, Virtex II Pro, and Virtex-4 and

Altera Cyclone II and Stratix II Embedded software suite for FPGA system design must include

complete tool offerings and target software platform, including high-level modeling with xtUML and advanced target software debugging environment.


42

Summary

With engineers from software, hardware and system disciplines all converging on FPGAs, it is important to focus on the methods that can help differentiate your solution from others.

It is necessary to use all the basic verification and design tools, but there are new technologies emerging that can better address the unique requirements of Mil/Aero applications.

Documents

Methods to Differentiate Mil/Aero Solutions Using FPGAs Dan Gardner Final MAPLD Presentation