fpga development techniques -...

FPGA Development Techniques

Wednesday November 3, 2004Polytech Orlans

FPGA Development Techniques 2

Agenda Static Timing Analysis

Constraining an FPGA design and ensuring it meets performance requirements

On-Chip Debugging Using a logic analyzer implemented inside the FPGA

to quickly debug at full system speed Power Estimation & Analysis

Obtaining an initial power estimate before starting your design & analyzing detailed results after implementation


Outline Static Timing Analysis

Introduction Review of Basic Constraints When to Use Advanced Constraints Handling Multiple Clock Domains Analyzing Design Results Demonstration of Constraints Editor & Timing

Analyzer to Floorplanner Cross-Probing On-Chip Debugging Power Estimation & Analysis


What are Timing Constraints for ?

The implementation tools do not try to find the placement & routing that will obtain the fastest speed Instead, the implementation tools try to meet your

performance expectations Performance expectations are communicated

with timing constraints Timing constraints cause the tools to improve the

design performance by placing logic closer together so shorter routing resources can be used


Without Timing Constraints This design had no timing

constraints or pin assignments entered with the design when it was implemented

Note the logical structure of the placement and pins

Xilinx recommends that you verify that your timing constraints are realistic before completing the functional verification of your design

This design has a maximum system clock frequency of 50 MHz


With Timing Constraints

This is the same design with three global timing constraints entered with the Constraints Editor

It has a maximum system clock frequency of 60 MHz

Note how most of the logic is placed closer to the edge of the device, where the pins have been placed


How do I add Constraints? Start the Constraints Editor

GUI from the Process window will create a new Implementation

Constrains source file and run the TRANSLATE step

Can also be invoked at the command line by typing constraints_editor

Or edit the constraints file a text file which contains constraints identified by a .ucf suffix


Constraints in the Design Flow Text EditorText Editor Text EditorText Editor

VHDLVHDLSynthesisSynthesisEDIF or NGCEDIF or NGC

1. Enter Timing Constraints here...2. and Physical Constraints here

(not covered today)3. Used by the implementation tools4. Analyze results here


Specifying Constraints

Usually written (automatically or by hand) in a separate file, one per project

Documented in the Constraints Guide see doc\usenglish\books\docs\cgd\cgd.pdf

or www.support.xilinx.com

Constraints can also be directly embedded in source code or IP core netlists


The PERIOD ConstraintNET CLK PERIOD = 10 nS ;

FPGA

This says, Data has 10nS to get from this flip-flop, to another flip-flop, here

All synchronous elements (RAMs, FFs, MULTS) are identified by forward propagation of the CLK net. Note that I/O Pads are not covered by the PERIOD constraint!

CLK


The OFFSET IN - BEFOREConstraint

OFFSET = IN 3nS BEFORE CLK;

CLK

UPSTREAM DEVICE FPGA

This says, Data will be valid here, 3 nS BEFORE the clock arrives here

The tools attempt to control internal data and clock delays for all flip-flops setup requirement (TsuFF).

Din

CLK


The OFFSET OUT - AFTERConstraint

This says, Data will be valid here, 4 nS AFTER the clock arrives here

The tools attempt to control internal data and clock delays to meet this clock-to-out requirement. The downstream devices setup time and the board delay will help you set this value. Using a DLL or DCM can help improve this number!

DOWNSTREAM DEVICE

FPGA

OFFSET = OUT 4nS AFTER CLK;

CLK


The PADS to PADS ConstraintTIMESPEC "TS_P2P" = FROM PADS TO PADS 15 ns;

FPGA

This says, from the input pad, Data has 15 nS to get to the output pad

This constraint is required to constrain combinatorial logic paths (ie, dont contain any synchronous elements) within the FPGA. Purely combinatorial paths, while easily implemented with consistent timing in CPLDs, should be used with caution in FPGAs.

UPSTREAM DEVICE DOWNSTREAM DEVICE


Using Advanced Constraints Review of Basic Constraints showed how to fully

constraint a simple, synchronous, single clock design Most real designs are more complicated than this! Many designs may require some of the following:

Specifying different setup and clk-to-out values for different I/O pins on the same clock domain (ie microprocessor I/F)

Defining multi-cycle paths (useful for clock enables) Ignoring some paths which arent timing critical Clocks on non-global routing Forwarding clocks off-chip


OFFSET IN & OUT Revisited For certain interfaces, I/O pins in the same clock

domain may have different setup & hold requirements Continue to use general OFFSET IN & OUT for entire

clock domain, but add exceptions: OFFSET = IN 3 nS BEFORE CLK; NET FAST_IN OFFSET = IN 1.8 ns BEFORE CLK; NET SLOW_IN OFFSET = IN 4.2 ns BEFORE CLK;

Specific exceptions will take precedence over general constraint, without duplication in the timing report

Wildcards, for example ADDR_BUS[*] can be used...


Creating Timing Groups To allow for more complex timing constraints, the

notion of groups of elements is required Since logic paths start and stop at synchronous

elements, the following keywords can be used:FFS All flip-flopsLATCHES All latchesRAMS All RAM elements

Input & outputs can also be grouped:PADS All I/O pads

Can be used globally and/or to create sub-groups


Slow Exceptions Slow Exceptions are FROM:TOs that define a different

delay for portion of the design. The majority of the design is covered by a PERIOD constraint.

IN

CLK

OUT

30 ns

D Q D Q D Q

60 nsExample 1: Using FROM:TOs only -- OK, but not best method

FROM:flop1:TO:flop2:30 FROM:flop2:TO:flop3:60

IN

CLK

OUT

30 ns

D Q D Q D Q

60 nsExample 2: Using PERIOD with a FROM:TO Slow Exception -- BEST, faster par & trce

FROM:flop2:TO:flop3:60NET CLK PERIOD=30


Use INST to create groups by matching the symbol nameNET CLK PERIOD = 10 ;INST CNT16/U1 TNM = CNT50 ;INST reg0 TNM = MYREGS ;TIMESPEC TS_MYBUS =FROM : CNT50 : TO : MYREGS : 20 ns ;

Multi-Cycle Delays

TS_MYBUS

CNT16 QD

QD

QD

QD

MY_REG_0

MY_REG_1

MY_REG_2

MY_REG_3

reg0

reg1

reg2

reg3


FROM : TO Syntax Details

TIMESPEC TS_name = FROM:group1:TO:group2:value;

TIMESPEC defines the type of specification TS_name must always start with TS. Any alpha-

numeric character or underscore may follow Group1 designates the origin of the path Group2 designates the destination of the path Value is in ns by default. Other possible values are

MHz or another time spec like TS_C2S/2 or TS_C2S*2


Ignoring Selected Paths Why use Timing IGnore (TIG) ?

Not all paths in designs require timing specifications Decreases competition for routing resources When non-critical timing paths are included in time

specifications, more important paths may be slower and may not meet time specifications

The TIG constraint ignores all nets that fan forward from the specified element

The TIG constraint prevents any constraints from being applied to the specified path


UCF Syntax: NET NETC TIG ;

NETC shown in the diagram is ignored. This will remove all constraints on 3 different paths

NETA, NETB and NETD which overlap some parts of NETCs path will not be ignored

TIG Example

NETA

NETB

NETC

NETD


TIG Attribute Syntax:

{NET|PIN|INST} name TIG = group1 [ group2, ];

name : element, net, or instance that is to be ignored group_name : optional field which ignores the net,

instance, or pin in the listed group All paths that fan forward from the net or instance will not

have any timing constraints applied to them The paths will be treated as if they dont exist

Paths can be specified between & through groups, ie:TIMESPEC ts_ignr =

FROM groupA THRU groupB TO groupC TIG ;


Clocks on non-global Routing

This shift register will not work because of clock skew!

Expected operation

Clock

Q_A

Q_B

Q_C

3 cycles

Clock skewed version

A & C Clock

Q_A

Q_B

Q_C

B Clock

2 cycles

D Q_B Q_CINPUT

CLOCK

DD Q_A3.1

3.0

3.1 3.3

4.5 3.0A B C

Clocks which dont use BUFGs can be skewed


Minimizing Clock Skew Global Clock networks, using GCK pin and

BUFG, distribute clocks with minimal skew In the case of clocks on non-global routing, two

constraints can help minimize skew: NET net_name USELOWSKEWLINES ; NET net_name MAXSKEW = 1 ns ;

USELOWSKEWLINES will instruct the tools to use backbone local clock routing resources

MAXSKEW will try to balance the clock delay


Forwarding Clocks off-chip When sending a clock off-chip, general purpose

routing will be used, even if the clock is on BUFG To properly constrain this path, use the following:

NET net_name MAXDELAY = 3 ns ;

MAXDELAY can be used for any timing critical nets, not just clocks

The Virtex-II/-II Pro/-4 & Spartan-3 IOB with its integrated DDR register provides a very effective way to send clock(s) off-chip with very little skew


Timing Constraint Priority Within a particular source:

Highest Priority

Lowest Priority


Tool Runtime Reduction Tips Limit number of time constraints

Add PERIOD and OFFSET constraints through Xilinx Constraints Editor, instead of doing Advanced Analysis

Consolidate similar timespecs to limit the number of time constraints Especially slow exceptions (TIG) Individual OFFSETs for every net with the same requirement

Be aware of duplicate constraints created by synthesis tools (.ncf files) Remove FROM:TO constraints between related clocks Use Global constraints, then grouped or net constraints Limit analysis of unconstrained paths

Group related I/O pads together and place early on Use higher placement effort, lower router effort


Constraining Between Multiple Clock Domains

OUT1

QD

CLK_A

CLK_B

D

QD

QDQ

By default, different clock domains are assumed to be unrelated (ie, no constraint applied between domains)

Define clock groups: NET CLK_A TNM = A_GRP; NET CLK_B TNM = B_GRP;

Define timing constraints: TIMESPEC TS_CLKA = PERIOD A_GRP 20; TIMESPEC TS_CLKB = PERIOD B_GRP TS_CLKA*2; TIMESPEC TS_CLKA2B = FROM: A_GRP: TO: B_GRP: 20;


Constraining Between Multiple Clock Domains

When generating clocks using a DLL or DCM, the phase & frequency relation will be determined automatically and handle the clock domain crossing

To constrain clocks which have a phase relation but which enter using separate pins, use the following constraints:

TIMESPEC TS01 = PERIOD clk0 10 ns;TIMESPEC TS02 = PERIOD clk180 TS01 PHASE + 5 ns;

Analyzing Design Results Place & Route Report lists all constraints and the

obtained results:Timing Score: 90071

WARNING:Par:62 - Timing constraints have not been met.

Asterisk (*) preceding a constraint indicates it was not met.

--------------------------------------------------------------------------------Constraint | Requested | Actual | Logic

| | | Levels--------------------------------------------------------------------------------TS_clk = PERIOD TIMEGRP "clk" 6.450 nS | 6.450ns | 10.772ns | 7 HIGH 50.000000 % | | | --------------------------------------------------------------------------------

1 constraint not met.

All signals are completely routed.

Total REAL time to par completion: 2 mins 44 secsTotal CPU time to par completion: 2 mins 39 secs

Placement: Completed - No errors found.Routing: Completed - No errors found.Timing: Completed - 52 errors found.

For more detail on why a constraint wasnt met, view the static timing analysis reports

*

Generating Timing Reports

Post-Map Static Timing Report can be created after Map process

May be useful for checking logic only delays early in the design process

Post-Place & Route Static Timing Report created after Place & Route process

Best way to get timing information on fully implemented design


Post-Map Versus Post-Place & Route Static Timing Reports

The Post-Map Static Timing Report indicates whether or not your constraints are reasonable Contains actual block delays and minimum net delays What is reasonable?

If less than 50 percent of the timing budget is used for logic delays, the Place & Route tools should be able to meet the constraint easily

Between 50 - 80 percent, software runtime will increase Greater than 80 percent, the tools may have trouble meeting your goals

The Post-Place & Route Static Timing Report indicates whether or not your constraints were actually met Contains actual block delays and actual net delays calculated

from Place & Route

Viewing Timing Reports Timing Reports are best viewed using the Timing

Analyzer Provides index into report greatly facilitating navigation The Timing Analyzer can create custom reports for

selected paths Note: Timing Reports can be created for designs

without constraints Advanced Analysis option (trce -a) Useful for finding paths that may have not been

constrained and obtaining their timing


Timing Report Example

Link to Timing Improvement Wizard(failing paths only)

Link to Timing Improvement Wizard(failing paths only)

Cross probing toFloorplanner and synthesis RTL

and Technology views

Cross probing toFloorplanner and synthesis RTL

and Technology views

Clock edge and time added to clock nameClock edge and time added to clock name

Timing Reports Contents Command line options for the trce program Timing Constraints section

Summary of each timing constraint Details on paths that fail to meet constraints

Data Sheet section Setup/hold, clock to pad, timing between clock domains,

and pad-to-pad delay information Organized in easy-to-read table format

Timing Summary section Number of errors and Timing Score Constraint coverage


Post-Place & Route Static Timing Report Properties

Report Type Error (failing) or Verbose (all)

Number of Items in Error/Verbose Timing Report

Analyze Skew for All Clocks Only necessary for clocks routed on

general routing as others are skew checked automatically

Stamp Timing Model Filename Timing Specification

Interaction Report file


ProActive Timing ClosureCross-Probing to the Xilinx Floorplanner

Link from the Xilinx timing report to the FloorplannerA graphical view provides powerful insights for timing debug strategies

Link from the Xilinx timing report to the FloorplannerA graphical view provides powerful insights for timing debug strategies


Click on PathOR

Click on Net

Cross-Probing to FloorplannerExample


Reference Material The Answers Database: support.xilinx.com

latest information on advanced constaints: using the DCM with phase offset, DDR I/O, etc...

The Constraints Guide syntax and examples for PERIOD, OFFSET,

MAXDELAY, etc The Development Systems Reference Guide

command line options for par, trce, etc On-line documentation:

http://www.xilinx.com/support/sw_manuals/xilinx6/index.htm


Outline Static Timing Analysis On-Chip Debugging

Traditional Debugging Techniques Introduction to On-Chip Debugging On-Chip Debugging Features Demonstration of On-Chip Debugging

Power Estimation & Analysis


System Debug and Verificationis Critical

Pressure of Time-to-Market deadlines Design milestones need to be met The debug phase is typically the largest variable

in the development cycle


Typical Board Debug Setup

Scope Probe

Download Cable

Logic Analyzer 40-Pin Pod


FPGA Debug Issues

FPGAs are getting bigger and faster Packages getting smaller with more pins, and

pin pitches are smaller Number of board layers is increasing Test point headers are consuming valuable

board space Access to logic analyzers


Existing Solution:FPGA Editor and Probe

Bring internal nodes out to a pin All nets available Use any available pin Additional routing delay is given No need to re-run Place and Route !!! Run Bitgen and download


FPGA Editor and Probe


The Need for On-Chip Debug

Traditional board level testing methods are not enough Need internal access to signals, nodes and system buses

Integrated IP means wider, faster busses = more I/O pins dedicated to debug

No direct access to IP within the FPGA Difficult to drive high speed clocks and signals off chip

without introducing new problems High pin count, fine pitch packaging makes accessing pins

nearly impossible


The ChipScope Pro SolutionLogic analysis core integrated in the FPGA

Software interface to monitor and analyze results Access to all internal design nodes Many flexible trigger options Operates at the full system speed synchronous to the

design clock up to 350 MHz Available for Virtex, Spartan-II and later FPGA families


Debugging with Chipscope Pro

USB port

Serial Port

-or-

JTAG Connections

Simple !


The ChipScope Pro System

Target Connection

IO Pads

IO P

ads

IO P

ads

IO Pads

Boundary Scan TAP Controller

Embedded System Bus

MemoryArray

PPC405Core

IPCore

CustomCore

ICON

ILA

ILA

ILA

IBACustomLogic

ILA

FPGA fabric provides full internal visibility Access all the internal signals and

nodes within the FPGA Access system busses

implemented in the FPGA Debug occurs at or near system

speeds Debug on-chip using the system

clock Minimize pins needed for debug

Access via the existingJTAG interface


ChipScope Pro Components ChipScope Pro Soft Cores

ICON Integrated Control Core communication to BSCAN ILA Integrated Logic Analysis Core ATC2 ILA core with Agilent ATC2 support for off-chip data capture & pin reduction IBA Integrated Bus Analysis Core for CoreConnect OPB and PLB VIO Virtual Input Output cores for internal stimulus

ChipScope Pro Software ChipScope Pro Core Generator ChipScope Pro Core Inserter

ChipScope Pro Analyzer Support for logic and bus analysis Project-centric interface

ChipScope Pro Communication Parallel Cable III and IV, MultiLINX, and Agilent FPGA Trace Port Analyzer via JTAG

and Trace Port ChipScope Pro Device Support

Spartan-II, Spartan-IIE, Spartan-3, Virtex, Virtex-E, Virtex-II, Virtex-II Pro & Virtex-4


ChipScope Pro Analyzer ChipScope Pro Logic and Bus Analysis

Interface Makes Debug and Verification Easy Multiple windows

Bus Plotting (Data vs. Time, Data vs. Data) Windows Capture Mode

Enables User to Compare Data Captured After Multiple Trigger Events

New Listing Viewer Import Bus Token Files and View Instructions

As They Occurred Core Polling Disable

Eliminate Conflicts with Software Debugger and Other JTAG Tools

VIO Console Assign Inputs, Pulse Trains and View Signal

Activity New Print Support


Xilinx On-Chip Debugging StrategyDesign with Debug and

Verification in Mind Adopt an On-Chip Verification and Debug Strategy

Define the ChipScope Pro Cores Needed to Debugand Verify Design

Allocate Resources for ChipScope Pro Cores BlockRAM Slice Logic BSCAN USER1 or USER2

Include Connectors in PCB Design JTAG Optional High-Speed Trace Port

Define Target Connection Cable JTAG (PCIV or MultiLinx) Agilent FPGA Dynamic Probing


ChipScope Pro ILA Core

User Selectable 1 to 4 Trigger Ports Up to 256 Channels Per Trigger Port Multiple Match Units on Same Trigger Port

Up to 16 Match Units Trigger Condition Sequencer

Define Complex Trigger Sequences that Include up to 16 States or Levels

Over 300Mhz performance


ChipScope Pro IBA Cores ChipScope IBA Pro Cores

IBA Core Supports CoreConnect OPB and PLB

Supports Both PPC and MicroBlaze OPB/PLB Buses

Automatic Mapping of Bus Signals to Trigger/Data Ports

CoreConnect OPB Protocol Violation Detection


ChipScope Pro VIO Core ChipScope Pro VIO Core

Insert virtual pins into your design Input or Output Synchronous or Asynchronous

System Clock or JTAG clock Up to 256 bits each

Inputs are Virtual LEDs Different Refresh Rates Available

Outputs are Virtual DIP Switches Force Value or Pulse Train into FPGA


ChipScope Pro Core GeneratorAdding ChipScope Pro Cores During Design Entry

ChipScope Pro Core Generator Specify ILA, ATC2, IBA and VIO Cores Generate Synthesizable HDL

to Add to Design HDL Access any Signal or Node with the

FPGA Under Test Define Internal or External Memory

Sample Storage Requirements


ChipScope Pro ILACore Generator Features

Enable and Define Trigger Sequence

Expanded Bit Values and FunctionsBased on Match Type

Define the numberof Trigger Ports, Width and Number of Match Units Used


ChipScope Pro IBACore Generator Features

Target CoreConnect Processor Local Bus (PLB) or On-Chip Peripheral Bus (OPB) Embedded PowerPC or Soft Core

MicroBlaze Trigger Input/Output Logic

Detects PLB and OPB Bus Activity Drive External Equipment or

Additional Cores Optional OPB Protocol Bus Monitor

Detect 32 IBM CoreConnect OPB Protocol Violations


ChipScope Pro Core Inserter Insert ChipScope Pro ILA/ATC2 Cores

No changes to source code required,modifications are performed on post-synthesis netlist

Support All Available Trigger Options Same Options as Core Generator

Easy to Use Core Configuration Trigger Options Tab Capture Settings Tab Net Connections Tab

Easy to Remove ChipScope Pro Cores Remove .CDC This File from Project

Available for HDL or EDIF Flows Core Inserter doesnt currently support for

IBA or VIO Cores


Automatically Launch the ChipScope Pro Analyzer

Inserter Called Automatically During Translate Stage

ChipScope Pro Core InserterAdd ChipScope Pro Cores to an Existing Design

ChipScope Pro Core Inserter Add ILA and ATC2 Cores to

an Existing Design Netlist ChipScope Pro and ISE

Integration ChipScope File (.CDC) Added to

Project as a Source, Associated With the Top Level Design Source

User Double-Clicks .CDC to Set Parameters and Connections

Versions of ISE and ChipScope Pro Must Match

Set ChipScope Pro Core Parameters and Connections Via This Source


ChipScope ProAnalyzer Features

Multiple windows Bus Plotting

data vs. time data vs. data

New listing viewer More trigger options Core polling disable

Eliminate conflicts with software debuggers or other tools using the JTAG chain


Storage Qualification Improves On-Chip Data Storage

Define Boolean storage qualification conditions Determine whether to capture

and store individual data samples

Use trigger and storage qualification together

When to start and stop capture To specify data to capture

Reduces required storage while maintaining full visibility


VIO Console in Analyzer

VIO Console gives you control over Virtual I/O ports

View activity

Assign internal inputs to FPGA


ChipScope CLBResource Utilization

Single basic ILA with ICON core for Virtex / -E or Spartan-II / -IIE:

Trigger/DataWidth Flops LUTs Slices

Percentageof XCV1000

2 125 143 72 0.58 %4 128 151 76 0.62 %8 134 167 84 0.68 %16 146 199 100 0.81 %32 173 265 133 1.08 %64 222 395 198 1.61 %


ChipScopeBlock RAM Resource Utilization

Single basic ILA with ICON core for Virtex / -E or Spartan-II / -IIE

Trigger/DataWidth

256samples

512samples

1024samples

2048samples

4096samples

2 1 unit 1 unit 1 unit 1 unit 2 units4 1 unit 1 unit 1 unit 2 units 4 units8 1 unit 1 unit 2 units 4 units 8 units16 1 unit 2 units 4 units 8 units 16 units32 2 units 4 units 8 units 16 units 32 units64 4 units 8 units 16 units 32 units 64 units

Spartan-3 & Virtex-II / -II Pro / -4 BRAMs are four times larger


Integration with FPGA Editor

Insert ILA and ICON into synthesized design

Connect Clock, Controland Data Points to Cores

Place and Route Design

Download Design

Set Triggers

Run ILA

Change Data Capture Points With FPGA Editor

Run BitGenChipscope

Change data and/or trigger nets connected to ILA...

...withoutre-running

PAR !


ILA in FPGA Editor

Select newnet to analyze


FPGA Dynamic Probe

Measures new groups of internal FPGAsignals in seconds without: Recompiling the design Impacting the timing of the designSave 15 min to 10 hours per new measurement

Achieves wider internal visibility over a fixed number of pins 64 internal probe points for every pin conserves FPGA resourcesSave 8 hours per problem by not having to create a testbench

Eliminates error prone & time consuming tasks Automates signal/bus labeling from FPGA design to logic analyzer Maps FPGA pins from board layout to logic analysis channelsSave 2 to 30 minutes per new measurement


Agilent FPGA Dynamic Probe

ATC2Insert ATC2 core with ChipScope Pro

FPGA

PC Board

FPGA Dynamic Probe SW application supported by

1680/1690/16900

Works with Xilinx Virtex-4, Spartan-3, Virtex-II Pro and

Virtex-II FPGAs

JTAG Header

Dynamic control of ATC2 with your

regular Xilinx Cable

Xilinx JTAGCable

Probe MUX outputs of ATC2 core and

PCB Signals


ATC2

Selection MUX

4 - 128

4 - 128

Output to FPGA

pins for debug

Agilent Trace Core (ATC2)2nd Generation Trace Core

Improved Signal Visibility

Number of Debug Pins

Maximum Internal Signals

4 2568 512

16 102432 2048

128 8192

.

.

.2X TDM

Change input bank selection dynamically via JTAG

JTAG

Selec

t

2, 4, 8, 16, or 32 input banks

All banks have identical width (4 to 128 signals wide)

Bank width determined by # of pins - each pin corresponds to 1 signal per bank

Using optional 2X TDM in state mode each pin corresponds to 2 signals per bank

Using optional 2X TDM in state mode each pin corresponds to 2 signals per bank

4 - 1284 - 128

4 - 128


ChipScope Demonstration Block Diagram

FIFO16 Byte

UART Tx

[17:16]

*RAM address [17:0]

[15:8]

[7:0]

* Common to both RAM devices

*WE*OECEUBLB

IC10

CEUBLB

IC11

Port14

Port12

Port11

Port80

Port60

RAM enables

Data [15:0]

*OE

[7:0]

[15:8] IC1016

8

Ain[15:0]

Data [15:0]

*OE

[7:0]

[15:8] IC1116

PortA0

LED [7:0]

PortC0

UART Rx

168 Dual Port RAM

PortsE0-E3

20-bitcounter

2 MSBs

A

deco

de

D

7-SegmentDisplay

dp,g,f,e,d,c,b,a

AN0AN1AN2AN3

KCPSM3

Program(BRAM)

PROMReader CCLK

OE

DIN

Ain[15:0]

PROMin[7:0]

Bin[15:0]

PROMin[7:0]

Port40

PROMstatus

Tx_status

FIFO16 Byte

Rx_status

Rx_Data

Tx_status

PROMstatus[15:8]

[7:0]

LBa

Bin[15:0][15:8]

[7:0]

LBb

CEa

Port 04

Port 00

Port 01

Port 03BUTTONS [3:0]

Port 02SWITCHES [7:0]

RAM_Data

Port 05

ChipScope Probe Points


Four-Character, 7-Segment LED Display Details

8 control lines light a specific segment on LED 4 anode control lines define which character responds

Control an individual character

Drive anode control Low to select character


Outline Static Timing Analysis On-Chip Debugging Power Estimation & Analysis

Initial Estimation Post-Implementation Analysis


Initial Power Estimation Online Estimation Tool:

Available at:http://www.xilinx.com/products/design_resources/design_tool/grouping/power_tools.htm


Initial Power EstimationTool Features

Provide Resource Estimates:

Save & Reload Data if required:


Outline Static Timing Analysis On-Chip Debugging Power Estimation & Analysis

Initial Estimation Post-Implementation Analysis


Power Estimation with XPower Integrated in ISEs Project

Navigator Operates on post-PAR

netlist (NCD file) Generate stimuli manually

or from timing simulation New Design Wizard:

Load Design & SimulationData Files


Power Estimation with XPower

Step 1: Set / Verify Voltage, Ambient temperature, and Airflow

Step 2: Set / Verify clock & input frequencies, and activity rates

Step 3: Set / Verify Capacitive Loads for the outputs

Step 4: Set / Verify DC loads for the outputs

Step 5: Set / Verify enable rate for the bi-directional IO

fpga development techniques -...

Documents