Advanced Xilinx Fpga Design With Ise

© 2002 Xilinx, Inc. All Rights Reserved

Course Agenda

Advanced Xilinx FPGA Design with ISE

Agenda - 3 © 2002 Xilinx, Inc. All Rights Reserved

AgendaSection 1 : Optimize Your Design for Xilinx Architecture

– Core Generator System• Lab : Core Generator System Flow

Section 2 : Achieving Timing Closure– Timing Closure with Timing Analyzer– Global Timing Constraints

• Lab : Global Timing Constraints– Advance Timing Constraints

• Lab : Achieving Timing Closure with Advance Constraints

Section 3 : Improve Your Timing– Floorplanner

• Lab: Floorplanner

Section 4 : Reduce Implementaion Time– Incremental Design Techniques

• Lab : IDT Flow– Modular Design Techniques

• Lab : MDT Flow


AgendaSection 5 : Reduce Debug Time

– FPGA Editor: Viewing and Editing a Routed Design• Lab: FPGA Editor

Section 6 : On-Chip Verification and Debugging– ChipScope Pro

• Demo

Section 7 : Course Summary

Optional Topics– Power Estimation with Xpower– Advance Implementation Options– Embedded Solutions with Power PC/MicroBlaze and Embedded Development Kit (EDK)– Xtreme DSP Solutions with System Generator


Objectives• Describe Virtex™-II advanced architectural features and how they can be used to

improve performance• Create and integrate cores into your design flow using the CORE Generator™ System• Describe the different ISE options available and how they can be used to improve

performance• Describe a flow for obtaining timing closure with Advance Timing Constraints• Use FloorPlanner to improve timing• Reduce implementation time with Incremental Design Techniques and Modular Design

Techniques• Reduce debugging time with FPGA Editor• On-Chip Verification with ChipScope Pro

After completing this course, you will be able to:


Prerequisites

Basic knowledge of :• Virtex™-II architecture features• The Xilinx implementation software flow and implementation options• Reading timing reports • Basic FPGA design techniques• Global timing constraints and the Constraints Editor

Basic HDL knowledge (VHDL or Verilog)

Basic digital design knowledge

CORE Generator System - 9 - 2 © 2003 Xilinx, Inc. All Rights Reserved










• Lab : MDT Flow


Optimize Your Design for Xilinx Architecture

CORE Generator System


After completing this module, you will be able to:

Objectives

• Describe the differences between LogiCORE and AllianceCOREsolutions

• List two benefits of using cores in your designs• Create customized cores by using the CORE Generator GUI• Instantiate cores into your schematic or HDL design• Run behavioral simulation on a design containing cores


Outline

• Introduction• Using the CORE Generator System• CORE Generator Design Flows• Summary


What are Cores?• A core is a ready-made function that you can instantiate into your design

as a “black box”• Cores can range in complexity

– Simple arithmetic operators, such as adders, accumulators, and multipliers– System-level building blocks, including filters, transforms, and memories– Specialized functions, such as bus interfaces, controllers, and

microprocessors• Some cores can be customized


Benefits of Using Cores• Save design time

– Cores are created by expert designers who have in-depth knowledge of Xilinx FPGA architecture

– Guaranteed functionality saves time during simulation• Increase design performance

– Cores that contain mapping and placement information have predictable performance that is constant over device size and utilization

– The data sheet for each core provides performance expectations• Use timing constraints to achieve maximum performance


Types of Cores• LogiCORE

• AllianceCORE

• The CORE Generator GUI lists the type of each core


LogiCORE Solutions• Typically customizable• Fully tested, documented, and supported by Xilinx• Many are pre-placed for predictable timing• Many are unlicensed and provided for free with the Xilinx software

– More complex LogiCORE products are licensed• Support VHDL and Verilog flows with several EDA tools• Schematic flow support for Foundation, Mentor, and Innoveda for most

cores


AllianceCORE Solutions• Point-solution cores

– Typically not customizable (some HDL versions are customizable)• Sold and supported by Xilinx AllianceCORE partners

– Partners may be contacted directly to provide customized cores • All cores optimized for Xilinx; some are pre-placed• Typically supplied as an EDIF netlist• Support VHDL and Verilog flows, some schematic


Sample Functions• LogiCORE solutions

– DSP functions• Time skew buffers, FIR

filters, correlators– Math functions

• Accumulators, adders, multipliers, integrators, square root

– Memories• Pipelined delay elements,

single and dual-port RAM• Synchronous FIFOs

– PCI master and slave interfaces, PCI bridge

• AllianceCORE solutions– Peripherals

• DMA controllers• Programmable interrupt

controllers• UARTs

– Communications and networking

• ATM• Reed-Solomon encoders /

decoders• T1 framers

– Standard bus interfaces• PCMCIA, USB


Outline



What is the CORE Generator System?

• Graphical User Interface (GUI) that allows central access to the cores themselves, plus:

– Data sheets– Customizable parameters (available for some cores)

• Interfaces with design entry tools– Creates graphical symbols for schematic-based designs– Creates instantiation templates for HDL-based designs

• Web access from the Help menu– The IP Center contains new cores to download and install

• You always have access to the latest cores– Direct access to http://support.xilinx.com


Invoking the CORE Generator System

• From the Project Navigator, select Project → New Source

• Select IP (CoreGen & Architecture Wizard) and enter a filename

• Click Next, then select the type of core


Xilinx CORE Generator System GUI

Cores can be organized by function, vendor, or device family

Core type, version, device support, vendor, and status


Selecting a Core• Double-click folders to browse the catalog of cores• Double-click a core to open its information window

– Or select a core, and click the Customize or Data Sheet icons in the toolbar


Core Customize Window

Parameters tab allows you to customize the core

Contact tab provides information about the vendor

Data sheet access

Web Links tab provides direct access to related Web pages

Core Overview tab provides version information and a brief functional description


CORE Data Sheets• Performance

expectations (not shown)

Features

Functionality

Pinout

Resource utilization


Outline



Schematic Design Flow• Generate a core

– Use the Edit → Project Options to select a schematic symbol instead of HDL templates

– Creates an EDIF file and schematic symbol

• Instantiate symbol onto your schematic

– Treated as a “black box” - no underlying schematic

• Proceed with normal schematic flow

Generate Core

Simulate

Instantiate

.EDN &

symbol

Implement

.xco


HDL Design Flow

Compile library for behavioral simulation (one time only)

Core generation and integration

compxlib.exe

XilinxCoreLib

.EDN

Instantiate

Simulate

.VHD, .V

Implement

.VHO, .VEO

Generate Core

.xco


HDL Design Flow: Compile Simulation Library

• Before your first behavioral simulation, you must run compxlib.exe to compile the XilinxCoreLib simulation library

– Located in $XILINX\bin\<platform>– Supports ModelSim, Cadence NC-Verilog, VCS, Speedwave, and Scirocco

• If you download new or updated cores, additional simulation models will be automatically extracted during installation


HDL Design Flow: Core Generation and Integration

• Generate or purchase a core – Netlist file (EDN)– Instantiation template files (VHO or VEO)– Behavioral simulation wrapper files (VHD or V)

• Instantiate the core into your HDL source– Cut and paste from the templates provided in the VEO or VHO file

• Design is ready for synthesis and implementation• Use the wrapper files for behavioral simulation

– ISE automatically uses wrapper files when cores are present in the design– VHDL: Analyze the wrapper file for each core before analyzing the file that

instantiates the core


Outline



Skills CheckSkills Check


Review Questions• What is the main difference between the LogiCORE and the

AllianceCORE products?• What is the purpose of compxlib.exe?• What is the difference between the VHO/VEO files and the VHD/V files

that are created by the CORE Generator™ system?


Answers• What is the main difference between the LogiCORE and the

AllianceCORE products?– LogiCORE products are sold and supported by Xilinx– AllianceCORE products are sold and supported by AllianceCORE partners

• What is the purpose of compxlib.exe?– Makes it easy to compile the XilinxCoreLib library before your first behavioral

simulation• What is the difference between the VHO/VEO files and the VHD/V files that

are created by the CORE Generator™ system?– VHO/VEO files contain instantiation templates– VHD/V files are wrappers for behavioral simulation that reference the

XilinxCoreLib library


Summary• A core is a ready-made function that you can “drop” into your design• LogiCORE products are sold and supported by Xilinx• AllianceCORE products are sold and supported by AllianceCORE

partners• Using cores can save design time and provide increased performance• Cores can be used in schematic or HDL design flows


Where Can I Learn More?• Xilinx IP Center http://www.xilinx.com/ipcenter

– Software updates– Download new cores as they are released

• Tech Tips on http://support.xilinx.com• Software manuals: CORE Generator Guide











• Lab : MDT Flow


CORE Generator System Lab


After completing this lab, you will be able to:

Objectives

• Create a core using the Xilinx CORE Generator™ system• Instantiate a core into an HDL design• Perform behavioral simulation on a design that contains a core


Lab Design:Correlate and Accumulate


Channel FIFO Block


Lab Overview• Generate a dual-port block RAM core• Replace an instantiated library primitive with the core• Perform behavioral simulation on the design

– Testbench file provided


General FlowStep 1: Review the designStep 2: Generate the coreStep 3: Instantiate block RAM core into Verilog or VHDL sourceStep 4: Perform behavioral simulation

Timing Closure with Timing Analyzer - 2 © 2003 Xilinx, Inc. All Rights Reserved










• Lab : MDT Flow


Achieving Timing Closure

Timing Closure with Timing Analyzer



Objectives

• Interpret a timing report and determine the cause of timing errors• Use the Timing Analyzer report options to create customized timing

reports


Outline

• Timing Reports• Interpreting Timing Reports• Report Options• Summary


Timing Reports• Timing reports enable you to determine how and why constraints were

not met– Reports contain detailed descriptions of paths that fail their constraints

• The Project Navigator can create timing reports at two points in the design flow

– Post-Map Static Timing Report– Post-Place & Route Static Timing Report

• The Timing Analyzer is a utility for creating and reading timing reports


Using the Timing Analyzer• Create and open a report in the

Timing Analyzer by double-clicking on Post-Place & Route Static Timing Report

• Open a plain text version of the report

• Start the Timing Analyzer to create custom reports by double-clicking on Analyze Post-Place & Route Static Timing (Timing Analyzer)


• Hierarchical browser– Quickly navigate to specific

report sections• Current position in the report

– Identifies the portion of the report that is displayed in the text window

• Report text– Links to the Timing

Improvement Wizard, Interactive Data Sheet and Floorplanner, highlighted in blue

Timing Analyzer GUI


• Shows the placement of logic in a delay path

• To enable cross probing, use the command: View → Floorplanner for Cross probing

• Click highlighted text– The corresponding logic is

selected in the Floorplanner

Cross Probing


• Timing Constraints– Number of paths covered and number of paths that failed for each constraint– Detailed descriptions of the longest paths

• Data Sheet Report– Setup, hold, and clock-to-out times for each I/O pin

• Timing Summary– Number of errors, Timing Score

• Timing Analyzer Settings– Allows you to easily duplicate the report

Timing Report Structure


Report Example• Constraint summary

– Number of paths covered– Number of timing errors– Length of critical path

• Detailed path description– Delay types are described

in the data sheet– Worst-case conditions

assumed, unless pro-rated• Total delay

– OFFSET paths have two parts– Logic/routing breakdown


Outline



Estimating Design Performance

• Performance estimates are available before implementation is complete• Synthesis report

– Logic delays are accurate– Routing delays are estimated based on fanout– Reported performance generally accurate to within 20 percent

• Post-Map Static Timing Report– Logic delays are accurate– Routing delays are estimated based on the fastest possible routing resources– Use the 60/40 rule to get a more realistic performance estimate


60/40 Rule• A rule-of-thumb to determine whether timing constraints are reasonable• Open the Post-Map Static Timing Report• Look at the percentage of the timing constraint that is used up by logic

delays– Under 60 percent: Good chance that the design will meet timing– 60 to 80 percent: Design may meet timing if advanced options are used– Over 80 percent: Design will probably not meet timing (go back to improve

synthesis results)


Analyzing Post-Place & Route Timing

• There are many factors that contribute to timing errors, including:– Neglecting synchronous design rules or using incorrect HDL coding style– Poor synthesis results (too many logic levels in the path)– Inaccurate or incomplete timing constraints– Poor logic mapping or placement

• Each root cause has a different solution– Rewrite HDL code– Add timing constraints– Resynthesize or re-implement with different software options

• Correct interpretation of timing reports can reveal the most likely cause– And therefore, the most likely solution


Example: Poor Placement

Data Path: source to destLocation Delay type Delay(ns) Logical Resource(s)------------------------------------------------- -------------------U29.IQ1 Tiockiq 0.382 sourceSLICE_X0Y65.F2 net (fanout=7) 1.921 net_1SLICE_X0Y65.X Tilo 0.291 lut_1SLICE_X15Y1.G2 net (fanout=1) 2.359 net_2SLICE_X15Y1.Y Tilo 0.291 lut_2SLICE_X15Y1.F2 net (fanout=1) 0.008 net_3SLICE_X15Y1.X Tilo 0.291 lut_3SLICE_X15Y2.DY net (fanout=1) 0.108 net_4SLICE_X15Y2.CLK Tdyck 0.001 dest------------------------------------------------- ------------------------------Total 5.652ns (1.256ns logic, 4.396ns route)

(22.2% logic, 77.8% route)

• net_2 has a long delay, even though fanout is low• Location column reveals that bad placement is the cause

– Go to Edit → Preferences in the Timing Analyzer to show this column


Poor Placement: Solutions• Timing-driven Map, if the placement is caused by packing unrelated logic

together – Cross-probe to the Floorplanner to see what has been packed together– Timing-driven Map is covered in the Advanced Implementation Options

module• PAR extra effort or MPPR options

– Covered in the Advanced Implementation Options module• Floorplanning or RLOC constraints, if you have the skill

– Covered in the Advanced FPGA Implementation course


Example: High FanoutData Path: source to dest

Delay type Delay(ns) Logical Resource(s)---------------------------- -------------------Tcko 0.382 sourcenet (fanout=87) 4.921 net_1Tilo 0.291 lut_1net (fanout=1) 0.080 net_2Tilo 0.291 lut_2net (fanout=2) 0.523 net_3Tilo 0.291 lut_3net (fanout=1) 0.108 net_4Tdyck 0.001 dest---------------------------- --------------------------------------Total 6.888ns (1.256ns logic, 5.632ns route)

(18.2% logic, 81.8% route)

• net_1 has a long delay and high fanout


High Fanout: Solutions

• Most likely solution is to duplicate the source of the high-fanout net– In this example, the net is the output of a flip-flop, so the solution is to

duplicate the flip-flop– If the net is driven by combinatorial logic, it may be more difficult to locate

the source of the net in the HDL code


Example: Too Many Logic Levels

Data Path: source to destDelay type Delay(ns) Logical Resource(s)---------------------------- -------------------Tcko 0.314 sourcenet (fanout=7) 1.221 net_1Tilo 0.291 lut_1net (fanout=1) 0.180 net_2Tilo 0.291 lut_2net (fanout=1) 0.423 net_3Tilo 0.291 lut_3net (fanout=1) 0.123 net_4Tilo 0.291 lut_4net (fanout=1) 0.610 net_5Tilo 0.291 lut_5net (fanout=1) 0.533 net_6Tilo 0.291 lut_6net (fanout=1) 0.408 net_7Tdyck 0.001 dest---------------------------- --------------------------------------Total 5.559ns (2.129ns logic, 3.430ns route)

(38.3% logic, 61.7% route)


Too Many Logic Levels: Solutions

• The implementation tools cannot do much to improve performance• The netlist must be altered to reduce the amount of logic between

flip-flops• Possible solutions:

– Check whether the path is a multi-cycle path• If it is, add a multi-cycle path constraint

– Use the retiming option during synthesis to distribute logic more evenly between flip-flops

– Confirm that good coding techniques were used to build this logic (no nested IF or CASE statements)

– Add a pipeline stage


Example: I/O TimingClock Path: clk to source_ff

Delay type Delay(ns) Logical Resource(s)---------------------------- -------------------Tiopi 0.669 clk

clk_BUFGP/IBUFGnet (fanout=1) 0.019 clk_BUFGP/IBUFGTgi0o 0.802 clk_BUFGP/BUFG.GCLKMUX

clk_BUFGP/BUFGnet (fanout=226) 0.307 clk_BUFGP---------------------------- ------------------------------Total 1.797ns (1.471ns logic, 0.326ns route)

(81.9% logic, 18.1% route)

Data Path: source_ff to dest_padDelay type Delay(ns) Logical Resource(s)---------------------------- -------------------Tcko 0.314 source_ffnet (fanout=2) 1.234 net_1Tilo 0.291 lut_1net (fanout=1) 1.693 net_2Tioop 4.133 dest_pad_OBUF

dest_pad---------------------------- ------------------------------Total 7.665ns (4.738ns logic, 2.927ns route)

(61.8% logic, 38.2% route)


I/O Timing: Solutions• Use a DCM to remove clock distribution delay• Register all top-level inputs and outputs

– IOB flip-flops have the best timing• Increase the slew rate or drive strength on outputs

– Only available for LVCMOS and LVTTL I/O standards


Outline



Creating Custom Reports• The Post-Map and Post-Place & Route Static Timing Reports are usually

sufficient timing analysis tools• Custom reports can be created with the Timing Analyzer to:

– *Show detailed path descriptions for more timing paths– *Analyze specific paths that may be unconstrained– Analyze designs that contain no constraints– Change the constraints or design parameters to perform “what-if” analysis


Types of Timing Reports• Analyze Against Timing Constraints

– Compares design performance with timing constraints– Most commonly used report format

• Used for Post-Map and Post-Place & Route Static Timing Reports if design contains constraints

• Analyze Against Auto Generated Design Constraints – Determines the longest paths in each clock domain– Use with designs that have no constraints defined

• Used for Post-Map and Post-Place & Route Static Timing Reports if design contains no constraints

• Analyze Against User Specified Paths by Defining Endpoints– Custom report for selecting sources and destinations

• Analyze Against User Specified Paths by Defining Clock and I/O Timing– Allows you to define PERIOD and OFFSET constraints on-the-fly – Use with designs that have no constraints defined


• After selecting a Timing Analyzer report, you can select from various report options

• Report Failing Paths: Lists only the paths failing to meet your specified timing constraints

• Report Unconstrained Paths: Allows you to list some or all of the unconstrained paths in your design

• You can also select which constraints you want reported

Timing Constraints Tab


• Speed grade– Generate new timing information

without re-implementing• Constraint Details

– Specify the number of detailed paths reported per constraint

– Report details of hold violations• Timing report contents• Prorating

– Specify your own worst-case environment

Options Tab


• Restrict which paths are reported by selecting specific nets

• Each net is assigned to be included by default

• Net Filter values:– Exclude paths

containing this net– Include Only paths

containing this net– Default

Filter Paths by Net Tab


• Restrict which paths are reported by selecting path end points or path types

• In this example, if you had an OFFSET OUT constraint associated with this design, the report would only include paths associated with the TENSOUT0 and TENSOUT1 pins

Path Tracing Tab


Outline



Review Questions• To which resources is the timing report linked?

• List the possible causes of timing errors


Answers• To which resources is the timing report linked?

– Timing Improvement Wizard on the Web– Interactive Data Sheet on the Web– Floorplanner for cross-probing

• List the possible causes of timing errors– Neglecting synchronous design rules or using incorrect HDL coding style– Poor synthesis results (too many levels of logic)– Inaccurate or incomplete timing constraints– Poor logic mapping or placement


• Timing reports enable you to determine how and why constraints were not met

• Use the synthesis report and Post-Map Static Timing Report to estimate performance before running place & route

• The detailed path description offers clues to the cause of timing failures• Cross probe to the Floorplanner to view the placement of logic in a

timing path• The Timing Analyzer can generate various types of reports for specific

circumstances

Summary


Where Can I Learn More?• Online Help

– Help → Timing Analyzer Help Contents– Help button available in the Options GUIs

• Timing Improvement Wizard: http://support.xilinx.com → Problem Solvers

– Decision-tree process guides you to the suggested next step to achieve timing closure

Global Timing Constraints - 2 © 2003 Xilinx, Inc. All Rights Reserved










• Lab : MDT Flow



Timing Groups and OFFSET Constraints


• Use the Constraints Editor to create groups of path endpoints• Use the Constraints Editor to create path-specific OFFSET constraints


Objectives


Outline

• Introduction• Creating Groups• OFFSET Constraints• Summary


Path-Specific Timing Constraints

• Using global timing constraints (PERIOD, OFFSET, and PAD-TO-PAD) will constrain your entire design

• Using only global constraints often leads to over-constrained designs– Constraints are too tight– Increases compile time and can prevent timing objectives from being met– Review performance estimates provided by your synthesis tool or the Post-

Map Static Timing Report• Path-specific constraints override the global constraints on specified paths

– This allows you to loosen the timing requirements on specific paths


More About Path-Specific Timing Constraints

• Areas of your design that may benefit from path-specific constraints– Multi-cycle paths– Paths that cross between clock domains– Bidirectional buses – I/O timing

• Path-specific timing constraints should be used to define your performance objectives and should not be indiscriminately placed


• Using the global PERIOD, OFFSET IN, and OFFSET OUT constraints will constrain all of these paths

• This makes it easy to control the overall performance of your design

Global Constraint Review

BUFG

CLK

ADATA

OUT2

OUT1Q

FLOP3

DQ

FLOP1

D

Q

FLOP5

DQ

FLOP4

D

BUS [7..0]

CDATA

Q

FLOP2

D


Path-Specific Constraint Example

• A path-specific constraint can optimize as little as one path• This gives you greater control over your design’s performance and gives the

implementation tools the greatest flexibility in meeting your performance and utilization needs

CDATA

BUFG

CLK

ADATA

OUT2

OUT1FLOP3FLOP1

Q

FLOP5

D

FLOP4

BUS [7..0]

FLOP2

QD

QDQD QD


The Advanced Tab of the Constraints Editor

• Creating path-specific constraints requires two steps

– Step 1: Create groups of path end points

– Step 2: Communicate the timing objective between the groups

• The constraints we discuss in this module can all be entered from the Advanced tab of the Constraints Editor


Outline



Creating Groups of Endpoints• Path-specific timing constraints will only be effective if path end points

can be easily grouped together– Otherwise, constraining a large design would be time consuming and

painstaking• The Constraints Editor makes this easy by allowing you to define groups

of path end points (pads, flip-flops, latches, and RAMs)• Specific delay paths can then be constrained with advanced timing

constraints


Creating Groups of Endpoints

• With the Constraints Editor, grouping path end points is made easy with the following options:

– Group by nets– Group by instance name– Group by hierarchy– Group by output net name– Timing THRU Points option– Group by clock edge


Grouping by Nets orOutput Net Name

• Step 1: Enter a group name• Step 2: Select the type of net to

search for– Optional filter string

• Matching nets appear in the Available list

• Step 3: Select nets and click Add– Nets appear in the Time Name

Targets list


Grouping by Nets versusOutput Net Name

• Grouping by net “NET_A” will create a group containing FLOP2 only– Group contains flip-flops that are driven by the selected net

• Grouping by output new “NET_A” will create a group containing FLOP1 only

– Group contains the flip-flop that sources the selected net

QDQDNET_A

FLOP1 FLOP2


• Steps are the same• Design Element Types are

different– Instance Name: FFs, pads,

latches, RAMs– Hierarchy: User levels, Xilinx-

created levels

Grouping by Instance Name or Hierarchy


• Step 1: Enter a group name• Step 2: Select a previously

defined group– Optional filter to help find

the group• Step 3: Select clock edge

Grouping by Clock Edge


Timing THRU Points• Allows you to optimize paths through specific nets and 3-state buffers• In this example, a group of nets was named TEOUTS. A constraint can now

be referenced such that only the delay paths through the TEOUTS nets will be optimized

TPTHRU = TEOUTS

MYCTR

QD

QD

QD

reg

reg

reg


Timing THRU Points• Group nets or 3-state buffers• Use these groups to identify

specific paths to be constrainedStep 1

Enter TPTHRU Name

Step 3Select Nets or 3-state

Buffers and click on Add

Step 2Select Element Type


Managing Groups• Groups that you have defined are written into the UCF file

– INST <element_name> TNM = <group_name>; OR– NET <net_name> TNM_NET = <group_name>; OR– TIMEGRP <group_name> = <elements>;

• To add items to an existing group, click one of the grouping buttons and use the same Time Name

– Not allowed when grouping by output net name• To delete a group, right-click on the line in the Constraints window and

select Delete Constraint– Or delete the line with a text editor

• You cannot remove items from a group with the Constraints Editor– Edit the UCF file with a text editor


Outline

• Introduction• Creating Groups• OFFSET constraints• Summary


Review of Global OFFSET Constraints

• Use the Pad-to-Setup and Clock-to-Pad columns to specify OFFSETs for all I/O paths on each clock domain

• Easiest way to constrain most I/O paths– However, this may lead to an over-constrained design


Pin-Specific OFFSET Constraints

• Use the Pad-to-Setup and Clock-to-Pad columns to specify OFFSETs for each I/O pin

• Use this type of constraint when only a few I/O pins need different timing


Creating Groups of Pads• Groups of I/O pads can be made in the Ports tab

– Use Shift-click or CTRL-click to select multiple pads– Enter a group name and click the Create Group button

• Click the Pad to Setup or Clock to Pad button to define group OFFSETs– Or use the Advanced tab


Creating Group OFFSET Constraints

• OFFSET IN/OUT constraints can also be entered in the Advanced tab

• The Pad-to-Setup and Clock-to-Pad options allow you to enter OFFSET IN/OUT constraints on specific groups of pads


Group OFFSET Constraints• Select a group of pads

• Enter timing requirement

• Select a clock domain

• Optional: Select a group of synchronous elements


Source Synchronous OFFSET Constraints

• For source synchronous inputs, you can specify the width of the valid data window


OFFSET Constraints with Two-Phase Clocks

• OFFSET constraints define the relationship between the data and the initialclock edge at the pins of the FPGA

• Initial clock edge is defined in the global PERIOD constraint using the HIGH or LOW keyword

– HIGH: Initial edge rising (default)– LOW: Initial edge falling

• If all I/O are clocked on a single edge, use the HIGH/LOW keywords in the PERIOD constraint to define which edge is used

• If both clock edges are used, create two OFFSET constraints– One for each clock edge– This includes cases where DDR flip-flops are used


OFFSET IN UsingBoth Clock Edges

• Input data is valid 3 ns before rising and falling edge – PERIOD constraint is 10 ns, initial edge rising, 50-percent duty cycle

• Create groups of flip-flops for each clock edge• For inputs clocked on a rising edge, OFFSET = IN 3 ns BEFORE clk;• For inputs clocked on a falling edge, OFFSET = IN –2 ns BEFORE clk;

– 2 ns after initial (rising) edge = 3 ns before falling edge

data_falling

data_rising

2ns3ns10 ns 3ns

clk

t = -3 0ns 2 5


OFFSET OUT UsingBoth Clock Edges

• Output data must be valid 3 ns after rising and falling edge – PERIOD constraint is 10 ns, initial edge rising, 50-percent duty cycle

• Create groups of flip-flops for each clock edge• For outputs clocked on a rising edge, OFFSET = OUT 3 ns AFTER clk;• For outputs clocked on a falling edge, OFFSET = OUT 8 ns AFTER clk;

– 8 ns after initial (rising) edge = 3 ns after falling edge

8ns

3ns10 ns

3ns

data_falling

data_rising

clk

t = 0ns 3 8


Outline



Review Questions• How do path-specific timing constraints improve your design’s performance?• How would you constrain this design to get an internal clock frequency of

100 MHz?• The input will be valid at least 3 ns before the rising edge of CLK. The output

must be valid 4 ns after the falling edge of CLK. Write the appropriate OFFSET constraints

DOUT

Q

RESET_A

CLK

QQD Q

RESET_B

IN

C CCC

D D


Answers• How do path-specific timing constraints improve your design’s performance?

– They give the implementation tools more flexibility to meet all of your timing objectives

• How would you constrain this design to get a maximum internal clock frequency of 100 MHz?

– Enter a global PERIOD constraint of 10 ns on the CLK signal• Write the appropriate OFFSET constraints.

– Assuming that the PERIOD constraint uses the HIGH keyword and 50-percent duty cycle:

• OFFSET = IN 3 ns BEFORE CLK;• OFFSET = OUT 9 ns AFTER CLK;


Summary• Path-specific constraints are used to override global constraints

– Keeps your design from becoming over-constrained– Allows the software to make intelligent trade-offs to meet all of your

performance goals• Creating path-specific constraints is a two-step process

– Create groups of path endpoints– Communicate the timing objective between the groups

• Path-specific OFFSET constraints can be entered on either the Ports tab or the Advanced tab

• When using both clock edges for I/O, write separate OFFSET constraints for each clock edge


Where Can I Learn More?• Timing Presentation on the Web: http://support.xilinx.com → Tech Tips →

Timing & Constraints• Constraints Guide: http://support.xilinx.com → Software Documentation

– Documentation may also be installed on your local machine











• Lab : MDT Flow


Review of Global Timing Constraints Lab



Objectives

• Enter global timing constraints in the Constraints Editor• Read reports to determine whether constraints were met




Lab Overview• Enter global timing constraints for five clock domains• Implement the design using the default software options• Review reports


General FlowStep 1: Enter Global Timing ConstraintsStep 2: Implement and analyze timing

Advance Timing Constraints - 2 © 2003 Xilinx, Inc. All Rights Reserved










• Lab : MDT Flow





Objectives

• Constrain paths that cross between clock domains by using the Constraints Editor

• Describe how constraints are prioritized• Constrain multi-cycle paths by using the Constraints Editor• Set path exception constraints• Set I/O specific constraints


Outline

• Inter-Clock Domain Constraints• Multi-cycle Paths• False Paths• Miscellaneous Constraints • Summary


OUT

QD QD

CLK

Constraining Between Rising and Falling Clock Edges

• The PERIOD constraint automatically accounts for two-phase clocks– Includes adjustments for non-50-percent duty-cycle clocks

• Example: A PERIOD constraint of 10 ns on CLK will apply a 5-ns constraint between these two flip-flops

• No path-specific constraints are required for this case


Constraining Between Related Clock Domains

• Create a PERIOD constraint for one clock– Define all related clocks in terms of this PERIOD constraint

• The implementation tools will use the relationships to determine how to cross between clock domains

• DCM with multiple outputs:– Define a PERIOD constraint on the input to the DCM– The implementation tools will “push” the constraint onto each output– All constraints will be defined relative to the original PERIOD constraint


Constraining Between Unrelated Clock Domains

• In this example, the delay path between the two clock domains is NOT covered by either of the PERIOD constraints

– This is the default behavior• You must add a constraint to cover paths when crossing between related

clock domains– Example: Same frequency, but CLK_B is phase shifted

• You must add a synchronization circuit when crossing between unrelated clock domains

D

PERIOD CLK_A PERIOD CLK_B

D QOUT1

Q

CLK_ACLK_B

QQD D D



• To constrain the paths between the two clock domains (highlighted in gray)

– Define groups of registers CLK_A and CLK_B with the Group by Nets option• Automatically done if you have specified a PERIOD constraint for both clock

domains– Place a Slow/Fast Path Exception between the two groups of registers

D Q

PERIOD CLK_A PERIOD CLK_B5 ns

D

OUT1

Q

CLK_ACLK_B

QD Q D


• Step 1: Create the groups by using the Group by Nets option

– Group by clock net– Skip this step if PERIOD

constraints are defined• Step 2: Create the

constraint by clicking the Slow/Fast Path Exceptions button



• Enter a name for this constraint– Must begin with “TS”

• Select the groups that define the constraint

• Specify the value of the constraint



Outline



Multi-cycle Path Constraints• Multi-cycle paths occur when

registers are not updated on consecutive clock cycles

– Always at least one clock cycle between updates

– Typically, the registers are controlled by a clock enable

• A prescaled counter is one example

– Registers in COUT14 are updated every 4 clock cycles

– Paths between these registers are multi-cycle paths

Q0 Q1

PRE2 TC CE

Q3 Q4 Q15Q14Q2

COUT14

200 MHz 50 MHz

CLK


Creating Multi-cycle Path Constraints

• Step 1: Create a global PERIOD constraint (not shown)

• Step 2: Create groups by using the Group by Nets option

– Group by enable net• Step 3: Click the Multi-

cycle Paths button


Creating Multi-cycle Path Constraints

• Enter a TIMESPEC name

• Select the groups that were previously defined

• Define the constraint relative to the PERIOD constraint


Outline



False Paths• The False Paths options

will prevent constraints from being applied to specific paths

– Define False Paths to reduce the number of constrained paths in your design


Defining False Paths• Use the False Paths

(FROM:TO:TIG) button to define false paths between groups of path endpoints

– TIG = Timing IGnore– Prevents any constraints from being

applied to the paths– Paths through specific nets or 3-

state buffers can be defined with the THRU points option

• What is wrong with this example?


Defining False Paths by Nets

• The False Paths by Nets option allows you to ignore timing constraints on a specific net

– Any delay path containing the RESET net will not be constrained

• The Ignored TIMESPECs option allows specific constraints to be ignored

– TS_P2P constraint will be ignored on paths containing the RESET net


Outline



Miscellaneous Tab• Assign individual registers to

IOBs• Mark asynchronous registers

– Prevents “X” propagation during simulation

• Select nets to be routed on the Low Skew Resources

– Use for high-fanout control signals

• Assign timing group elements to area groups for floorplanning

• FEEDBACK constraint for DCMs• Define initial values for storage

elements


Prorating Constraints• Prorating allows the tools to use the most accurate information

– The implementation tools use the worst-case operating temperature and voltage for your chosen device package (85 º for Commercial, 100 º for Industrial)

• Specify your own worst-case conditions– This will prorate the device delay characteristics to accurately reflect your

worst-case system conditions


Timing Constraint Priority• False Paths

– Must be allowed to override any timing constraint

• FROM THRU TO• FROM TO • Pin-Specific OFFSETs• Group OFFSETs

– Groups of pads or registers• Global PERIOD and OFFSETs

– Lowest priority constraints

Highest

Lowest


Timing Constraint Interaction• Whenever a path is covered by more than one constraint, the tools must

choose which constraint to use for timing analysis• If the constraints are of different types, the highest priority constraint is

applied• If the constraints are of the same type (Example: FROM TO), the

decision is more complex– Can be dictated with the PRIORITY keyword in the UCF file

• To see where your constraints overlap, generate a Timing Specification Interaction (TSI) file

– Under Properties for Post-Place & Route Static Timing Report, type in a filename

– In the Timing Analyzer, select Analyze → Constraints Interaction


Outline





Review Question Background Information

• Prescaled 16-bit counter is created in two blocks– Q0 and Q1 in block PRE2 toggle at 200 MHz– Q[15:2] toggle every fourth clock edge (50 MHz)– The design is fully synchronous because all registers share the same clock

• However, COUT14 registers are disabled 3/4 of the time so they do not have to meet a 200-MHz PERIOD constraint

Q0 Q1

PRE2 TC CE

Q3 Q4 Q15Q14Q2

COUT14

200 MHz 50 MHz

CLK


Q0 Q1

PRE2 TC CE

Q3 Q4 Q15Q14Q2

COUT14

200 MHz 50 MHz

CLK

Review Questions• What constraints need to be placed on this design to assure it will meet the

performance objectives?• How would you enter these constraints through the Constraints Editor?• How do multi-cycle path constraints improve your design’s performance?


• What type of constraints need to be placed on this design to assure it will meet the performance objectives?

– Global PERIOD constraint of 5 ns (or 200 MHz)– Multi-cycle path constraint of 5 x 4 = 20 ns (or 200 / 4 = 50 MHz)

• How would you enter these constraints through the Constraints Editor?– PERIOD constraint: Use the Global tab– Multi-cycle path constraint:

• Group the flip-flops in COUT14 by clock enable net (group name: MSB)• Constrain from MSB to MSB

• How do multi-cycle path constraints improve your design’s performance?– They allow the implementation tools to place some logic farther apart and use

slower routing resources

Answers


BIDIR_PAD(7:0)

Control Register

Status Register

Control_Enable Status_Enable

Review Questions

• If a PERIOD constraint were placed on this design, what delay paths would be constrained?

• If the goal is to optimize the input and output times without constraining the paths between registers, what constraints are needed?

– Assume that a global PERIOD constraint is already defined

BIDIR_BUS(7:0)


Answers• If a PERIOD constraint were placed on this design, what delay paths

would be constrained? – Paths between the control registers and the status registers would be

constrained

BIDIR_PAD(7:0)

Control Registers

Status Registers


BIDIR_BUS(7:0)


Answers• If the goal is to optimize the input and output times without constraining the

paths between registers, what constraints are needed?– Enter OFFSET constraints on the Global tab– Define False Paths By Nets

• Select the BIDIR_BUS[7:0] nets• Select the global PERIOD constraint to be ignored

BIDIR_PAD(7:0)

Control Registers

Status Registers


BIDIR_BUS(7:0)


Summary• Use a Slow/Fast Path Exception to constrain paths that cross between

clock domains• Identifying multi-cycle and false paths allows the implementation tools to

make appropriate tradeoffs– These paths will use slower routing resources, which frees up fast routing

for critical signals• Prorating your operating conditions gives the tools the most accurate

picture of your design environment• In general, more-specific constraints have a higher priority than less-

specific constraints


Where Can I Learn More?• Timing Presentation on the Web: http://support.xilinx.com → Tech Tips

→ Timing & Constraints• Constraints Guide: http://support.xilinx.com → Software Documentation

– Documentation may also be installed on your local machine











• Lab : MDT Flow


Achieving Timing Closure with Advance Constraints Lab



Objectives

• Enter path-specific and I/O timing constraints by using the Constraints Editor

• Take steps to achieve timing closure




Lab Overview• Add path-specific timing constraints based on design knowledge

– You will add some constraints– Other constraints will be copied from a file


General FlowStep 1: Create a group OFFSET constraintStep 2: Create multi-cycle path constraintsStep 3: Create path exception constraintsStep 4: Create I/O constraintsStep 5: Implement and analyze timing

Floorplanner - 2 © 2003 Xilinx, Inc. All Rights Reserved










• Lab : MDT Flow


Improve Your Timing

FloorPlanner



Objectives

• Identify the Floorplanner windows• Specify the Floorplanner flow • Describe how to use area constraints• Identify how PACE is used to specify area constraints• Identify optimal pin layout


Outline• Introduction• Floorplanning Procedures• Area Constraints & I/O Layout• PACE• Summary• Appendix:

– RPM Core– Overcoming MAP/PAR Limitations– Pseudo Guide File with Floorplanner– Additional I/O Considerations


What is the Floorplanner?• Graphical tool used to

display/edit design layout– Easy to review the

results of implementation

Close-up of Virtex-II die


When to Floorplan• Use the Floorplanner to:

– Increase productivity/design performance– View the layout of your implemented design– Partition design sub-systems into general areas on the die (area

constraints/layout)– Make minor placement modifications– Create RPMs (Relationally Placed Macros)

• Use the Floorplanner carefully– Poor floorplanning can decrease design performance– The implementation tools cannot disregard a poor floorplan


Floorplanner Prerequisites• Do not perform significant floorplanning unless you are very familiar with:

– The design– The target device architecture– Xilinx software

• Without sufficient knowledge, it is suggested you try the following first– Use timing constraints– Increase Place & Route Effort Level– Specify → Perform Timing-Based Packing (Map) and extra-effort level

(PAR)– Pipeline or redesign logic in critical paths– Use re-entrant routing or MPPR


Floorplanning Advantage:• Given sufficient knowledge…

– In large and/or high performance designs, floorplanning/layout is an effective precursor to implementation

• Provides guidance to implementations tools on the layout of the design• Can help to reduce run time• Can help to increase performance

– Floorplanning is required for Incremental Design Techniques and Modular Design Techniques


Floorplanning Flow

NGDBUILD

MAP

PAR

edn, ngc

ucf

ngd

ncd, pcf

ncf

FloorplannerFloorplanner

fnf

ncd


Floorplanner Versus PACE• PACE:

– Easiest tool for specifying pin placement constraints and area constraints

• Floorplanner:– More advanced tool with placement capabilities beyond that of PACE

• Create groups of logic• Constrain logic to a specific location (hard location constraints - hard LOC)• Constrain logic from a current placement (hard LOC)• View and edit placed design• Perform packing of logic resources• Used for cross-probing with Timing Analyzer

– PACE is much better for specifying pin constraints– Specifying area constraints is similar to PACE


Main Floorplanner Windows

Floorplan (in back)Shows current placement constraints and design edits

PlacementShows the current design layout from the implementation tools

Design HierarchyDisplays color-coded hierarchicalBlocks.Traverse hierarchy to view any component in the design

Design NetsLists all the nets in the design


Viewing the Device• Click View → Options, or

click the Toggle Resources button to display device resources

– Function Generators and RAM

– Flip-flops and latches

– Three-state buffers– I/O pads

and global buffers• Row and column numbers are

displayed for easy reference


Locating Logic and Nets• Use the Edit →

Find command• Filters help you narrow

your search– Logic type (flip-flops,

I/O pins, nets, etc.)– Status (floorplanned,

not floorplanned, selected, etc.)– Connections (driving selected

logic, sourcing selected logic, etc.)


Viewing Connectivity• View connectivity by components

– Click Edit → Preferences → Ratsnest Tab. Check Display nets connected to selected logic

– Select a component or group of logic in the Hierarchy window

Connections are shown in the Placement and Floorplan windows


Package View• To view the package pins, click

View menu → Package Pins

• You can view the bottom view or the top view

• PACE provides a more complete package view for more beneficial pin placement

– All dual-purpose and special pins are identified


Timing Analyzer Cross-Probing

• The Timing Analyzer and Floorplanner can be used together to cross-probe paths

Click on path in Timing Analyzer

Click on path in Timing Analyzer1

Path appears in Floorplanner

Path appears in Floorplanner2


Outline

• Introduction• Floorplanning Procedures• Area Constraints & I/O Layout • PACE• Summary• Appendix:

– RPM Core – Overcoming MAP/PAR Limitations– Pseudo Guide File with Floorplanner– Additional I/O Considerations


Floorplanning Procedures• Creating groups of logic• Constraining logic to a specific location• Constraining from the current placement• Locking I/O pins• Area constraints (covered in the next section)


Creating Groups of Logic• When the design is loaded,

logic is automatically grouped according to the design hierarchy

• Create your own groups of logic in two ways:

– Select the logic and use the command Hierarchy → Group

– Use the command Hierarchy →Group By, to select and group logic


Changing Group Colors• Use color to identify

parts of your design easily

• Select a group of logic • Use the command

Edit → Colors• Choose a new color• Click Apply


Constraining Logic toa Specific Location

• Select the method in which you would like the logic to be distributed

– Distribute One at a Time drops each component individually

– Up, Down, Left, or Right quickly shapes the logic into a row or column

• Pick up the logic by clicking the icon in the Hierarchy window

• Move the cursor in the Floorplan window

• Click to place the logic– Valid locations are highlighted


Moving Logic• To move logic that is already placed in the Floorplan window

– Select the logic that you want to move (in the Hierarchy, Placement, or Floorplan window)

– Click the logic to pick it up– Move the cursor to a new location– Click to place the logic

• To remove logic from the Floorplan window– Select the logic you want to remove– Press <Delete> or move the logic back into the Hierarchy window


Block RAM Placement• The placement algorithm for block RAM does not always result in an

optimal placement with its source and load

• Consider placing most (if not all) of your block RAMs– Block RAM placement can be very critical to the timing of your design

• Hand-place them to use the flow of the device wisely– Horizontal data flow, carry chain runs up

• Discussed further in Area Constraints section


Constraining From theCurrent Placement

• Use these commands when you want to make minor layout changes

• To constrain selected logic in Placement window:– Select the logic that you want to constrain, from the Placement window– Use the command Floorplan → Constrain from Placement– The layout for the selected logic is copied from the Placement window into

the Floorplan window– Make changes to the logic placement in the Floorplan window

• To copy the entire Placement window: use the command Floorplan →Replace All with Placement


Locking I/O Pins• For high-speed, complicated, and large I/O designs, Xilinx suggests you

manually lock I/O– Use PACE (recommended)– Use the Constraints Editor (Ports tab) – Lock the pins based on the pinout from the implementation tools:

• From ISE Project Navigator: Expand Implement Design, expand Place & Route, double-click Back-annotate Pin Locations

• Floorplanner– Use the Edit → Find command to select all I/O Pads– Use the Floorplan → Constrain from Placement command– Make adjustments, if needed, and save


Outline

• Introduction• Floorplanning Procedures• Area Constraints & I/O Layout• PACE • Summary• Appendix:



I/O Location Constraints• For high-speed designs, complex designs, and designs with a large

number of I/O pins, Xilinx recommends manual placement of I/O– Guides the internal data flow– The implementation tools have the ability to place logic and pins, but this

does not always result in the most optimal placement– Poor pin placement can reduce the chances of your design meeting your

performance objectives– Making good pin assignments requires detailed knowledge of the design

functionality and Xilinx architecture• Pin assignments must also comply with the silicon’s capabilities

– Assignments must follow the I/O banking rules and the pre-grouping of the differential I/O pins

– Clock pin assignments affect clock region access and shared input pairs– Take advantage of internal data-flow


Pin Constraints• Clocks should be constrained to dedicated clock pins

– Or clock pin pairs for differential clocks– Keep in mind the global clock buffer limitations

• Eight global clocks or eight clocks total into each clock region• Rules previously described

• Use dual-purpose pins last – For example, configuration and DCI pins– This will help to reduce contention during board power-up or when the

FPGA is reconfigured on demand– PACE or the Xilinx Constraints Editor can be used to prohibit configuration

pins


Internal Logic Layout

C_REG E_REG G_REG

A+B E+FC+DBit 0

Datapath

Bit 7Datapath

• Horizontal data flow with vertical bus alignment

– Carry logic runs vertically– Bidirectional data bus longlines

run horizontally• 3-state enable lines run

vertically– Control lines (CE, resets, etc)

are generally driven on vertical long lines


General guidelines for chips with 100K system gates or less:

Layout for Smaller FPGAs

• I/O for control signals on the top or bottom

– Signals are routed vertically• I/O for data buses on the left or right• Internal layout favors horizontal data

flow– Align area blocks to flow horizontally– Allow enough room for carry chains– Place block RAMs appropriately to align

with arithmetic logic

Dat

a B

uses

Control Signals

Control Signals

Data B

uses

Data Flow


Layout for Larger FPGAs

• Use the same guidelines as you would use for smaller chips

• In addition, consider the following:– Group control signals and data

buses near related internal logic– High-fanout signals may be placed

near the middle of the chip, for easy access to horizontal long lines

For chips with 500K system gates or more:

Con

trol

Sig

nals C

ontrol Signals

Data Flow


LSB

MSB

Data Bus Layout• Arithmetic functions with more

than five bits typically utilize carry logic

• Carry chains require specific vertical orientation

– Affects both internal and I/O layout


Interleaved Bus Layout• Arithmetic functions involving two

or more buses will benefit from interleaved pin constraints

– For example:• C <= A + B; or

C <= A * B;

A(0)B(0)A(1)B(1)A(2)B(2)A(3)B(3)


Area Constraints(a.k.a. Layout, a.k.a. AREA_GROUPs)

• Easiest and most effective application of floorplanning

• Preferred method of floorplanning for synthesis users and large designs– Individual component names change often during synthesis, but

hierarchical block names remain constant• For this to be effective, you must retain hierarchy during synthesis

– Each sub-section of a large design can be constrained to an area• Area constraints allow you to provide guidance while still giving the

implementation tools freedom• This is the primary floorplanning methodology for use with incremental

design techniques


Area Constraints1. Select the area group you want

to constrain2. Click the Assign Area button3. Click and drag to define the

area constraint– Floorplanner estimates the

required area and will not allow you to select an area that is too small

1

2

3


Area Constraint Compression

• When assigning area constraints, it may be helpful to apply a compression factor for mapping

– This is equivalent to the global -c option applied in map, but it only applies to an individual AREA_GROUP

– Right-click the AREA_GROUP, select → Edit Constraints

• Constraint: Compression• Value: <%>

– <%> represents the percentage of logic resources in that area constraint available for packing

– Click OK


Area Constraints in UCF• Floorplanner (and PACE) area constraints create AREA_GROUP and

RANGE constraints in the UCF– AREA_GROUP constraints bind instances into a group– RANGE constraints assign an AREA_GROUP to an area on the die– Syntax:

• INST <hierarchical_group> AREA_GROUP = AG_<ag_name>;• AREA_GROUP <ag_name> RANGE = SLICE_XnYm:SLICE_XnYm;• AREA_GROUP <ag_name> COMPRESSION= <value>; # if applied

– For example:• INST data_control_inst AREA_GROUP = AG_data_control_inst;• AREA_GROUP AG_data_control_inst RANGE =

SLICE_X0Y47:SLICE_X27Y32 ; • AREA_GROUP AG_data_control_inst COMPRESSION= 90;


RANGE Constraints• RANGE constraints are written for slices, block RAM, multipliers, and 3-

state buffers – Range constraints will be written for each of these logic types

• Slices: AREA_GROUP "AG_data_control_inst" RANGE = SLICE_X0Y47:SLICE_X27Y32 ;• Block RAMs: AREA_GROUP " AG_data_control_inst " RANGE = RAMB16_X1Y18:RAMB16_X3Y15 ;• Block multipliers: AREA_GROUP " AG_data_control_inst " RANGE = MULT18X18_X1Y18:MULT18X18_X3Y15 ;• Three state buffers:AREA_GROUP " AG_data_control_inst " RANGE = TBUF_X0Y15:TBUF_X10Y9 ;


Multiplier and Block RAM RANGE Constraints

• In this situation, you are only interested in constraining the slices and 3-state buffers

– Hand-place the block RAMs and block multipliers

There’s only room for 4 block RAMs…

but, I need room for 8!What do I do?


Multiplier and Block RAM RANGE Constraints

• Comment-out the block RAM and multiplier RANGE constraints in the UCF

• Hand-place the block RAMs and multipliers for optimal placement and timing

• This will provide the most optimal approach to floorplanning– Control placement of block RAMs and multipliers through hand placement– Control placement of slice logic and 3-state buffers through area constraints


Outline

• Introduction• Floorplanning Procedures• Area Constraints & I/O Layout• PACE• Summary• Appendix:



Pinout and Area Constraints Editor (PACE)

• PACE is a tool used to create pinout and area constraints• Constraints are written to the UCF file• The flow, look, and use are very similar to that of Floorplanner

– It does not have all the capabilities of Floorplanner


Pinout and Area Constraints Editor (PACE)

Device ArchitectureAllows area constraint specification

Package PinsAllows pin loc specifications

DesignHierarchy

Displays color-coded hierarchicalblocks

Design Object ListDisplays elements contained in the group that are selected in the Design Hierarchy window

Package Pins Legend


Pin Constraints• Pin constraints most easily made using PACE

Specify I/O options in Object List window

Drag & Drop I/O to Package Pin window


PACE Features• To prohibit pin sites or slice sites, use the Prohibit icon in the toolbar

• To allow the use of prohibited sites, use the Allow Icon

• Package migration: When a design has the possibility of moving to a different package, PACE will write out prohibit constraints on incompatible pins so user can avoid reassigning I/Os

– IOB → Make Pin Compatible With...


Area Constraints1. Select the area group that

you want to constrain2. Click the Assign Area

button3. Click and drag to define the

area constraint– PACE estimates the

required area and will not allow you to select an area that is too small

1

2

3


Area Constraint Compression

• When assigning area constraints, it may be helpful to apply a compression factor for mapping

– This is equivalent to the global -c option applied in MAP, but it only applies to an individual AREA_GROUP

– Click Areas menu → Edit Constraints, enter Constraint: Compression, Value: <%>

• <%> represents the number of logic resources in that area constraint available for packing

– Click → Enter, click → OK


Outline




Review Questions• Will the implementation tools override any manual edits that decrease

performance of your design?• What is Floorplanner beneficial for?• What is the easiest and most beneficial application of floorplanning?• After which implementation steps can you perform floorplanning? • After creating a new floorplan, which phases of implementation need to

be run again?• Describe an optimal pin layout for Virtex-II/Spartan -3 devices


Review Questions• Specify the windows of the

floorplanner and explain how they are used


Answers• Will the implementation tools override any manual edits that decrease

performance of your design?– No


Answers• What is Floorplanner beneficial for?

– In large and/or high performance designs• Provides guidance to implementations tools on the layout of the design• Can help to reduce run time• Can help to increase performance

– Floorplanning is required for IDT and MDT– Increase productivity/design performance– View the layout of your implemented design– Partition design sub-systems into general areas on the die (area

constraints/layout)– Make minor placement modifications– Create RPMs (Relationally Placed Macros)


Answers• What is the easiest and most beneficial application of floorplanning?

– Area Constraints (a.k.a. Layout, a.k.a. AREA_GROUPs)• After which implementation steps can you perform floorplanning?

– Translate– MAP– Place & Route

• After creating a new floorplan, which phases of implementation need to be run again?

– Translate, MAP, Place & Route, Configuration


Answers• Specify the windows of the

floorplanner and explain how they are used

Floorplan (in back)Shows the current placement constraints and design edits

PlacementShows the current design layout from the implementation tools

Design HierarchyDisplays color-coded hierarchical blocks. Traverse hierarchy to view any component in design

Design NetsLists all nets in the design


Answers• Describe an optimal pin layout for Virtex-II/Spartan-3 devices

– Place data to flow horizontally across the device– Place data, addresses, etc. for proper alignment with carry chain

• LSBs below MSBs -- flowing up


Summary• Take care when editing design placement because the implementation

tools cannot change a poor floorplan • Floorplanning can be an effective method of providing guidance to

implementation tools• Area constraints give the implementation tools guidance but provide the

most flexibility to meet your goals• I/O pin layout guidelines:

– Data buses on the left and right of the die– Control signals on the top and bottom– MSB of buses at the top, LSB at the bottom


Where Can I Learn More?• Virtex-II, Virtex-II Pro, and Spartan-3 User Guides and Data book

– Details on device architecture– http://support.xilinx.com → Documentation

• Online Software Manuals → Constraints Guide → Constraint Entry →Floorplanner

• Floorplanner → Online Help


Outline


– RPM Core– Overcoming MAP/PAR Limitations– Pseudo Guide-File with Floorplanner– Additional I/O Considerations


Reusable RPM Core• Floorplanner can be used to create cores that retain relative placement

and, therefore, performance and timing repeatability– It allows you to transform a design (or design block) into a Relationally

Placed Macro (RPM) core that can be reused via instantiation in any design


Reusable RPM Core StepsStep 1: Define the logical function of your core in HDLStep 2: Synthesize your design to create an EDIF netlist such as

my_core.edf– Disable I/O insertion and clock buffer insertion

Step 3: Process the EDIF netlist using NGDBuild to produce an NGD file, such as my_core.ngd

Step 4: Load your design (NGD or NCD) into the Floorplanner, and shape the relative placement of the design

Step 5: Save your design using the Write RPM to NCF command in the File menu


Relationally Placed Macro• What is a Relationally Placed Macro (RPM)?

– An RPM uses relative location constraints to constrain logic relationally to other logic

– This helps to keep associated logic close together to reduce routing delays• RPMs can be created on BELs, COMPs, and hierarchy

– Before COMPs can be relationally placed, BELs must be relationally placed – Before hierarchy can be relationally placed, COMPs must be relationally

placed• You must be aware that too many RPM blocks can significantly hinder

the placement tools – They can, in fact, prohibit the tools from finding a placement


Outline

• Introduction• Floorplanning Procedures• Area Constraints & I/O Layout • PACE• Summary• Appendix:



MAP Limitations• RPM sourcing locked flip-flops

• Constrained by Packing problems


RPM Sourcing Locked Flip-Flops

• Relationally Placed Macros are components that have been assigned a specific shape with RLOC constraints

– Synthesized arithmetic components larger than six bits may be RPMs

– All RPMs in your design are listed in Section 7of the MAP report

• In this example, an 8-bit incrementer/decrementer is driving 8 flip-flops to create a counter

8 Flip-flops

8-Bit Inc-Dec


RPM Sourcing Locked Flip-Flops

• When the flip-flops are physically constrained with LOC or RLOC, MAP is unable to pack the Inc-Dec and flip-flops together

– Creates extra delay in the datapath

8 Flip-flops8-Bit Inc-Dec


RPM Sourcing LockedFlip-Flops: Workarounds

• Remove the constraints from the flip-flops

– Now MAP can pull the flip-flops into the same slice with the RPM

• Use the Floorplanner to place both components into the same slice

8 registers8-Bit Inc-Dec


Design Considerations • When locking down flip-flops, make sure you know what is sourcing them • If the flip-flops are sourced by an RPM, you should lock down the RPM

instead of the flip-flops• If flops are sourced by non-RPM logic, then it is up to you to determine

whether you want to lock down the logic– In many cases, it should NOT be necessary to lock down the non-RPM

logic. MAP will pack this logic into the appropriate slice


Constrained By Packing• Flip-flop A is constrained to Slice_R1C1 because it drives an output on the

NW corner of the die• Flip-flop B is unconstrained and drives an output on the SE corner of the die• MAP is allowed to pack unconstrained logic together with constrained logic• Result: Bad placement for flip-flop B

D Q

AD Q

F/G

F/GH

Slice R1C1

D Q

B

D Q

AF/G

F/GH

Slice R1C1

D Q

B

MAP


Constrained by Packing: Workarounds

• Avoid partially filled slices (Recommended)– Constrain all the components (LUTs, FFs) of a locked slice– You can use the Floorplanner to fill up the slice

• Set the XIL_MAP_LOC_CLOSED environment variable to TRUE– Tells MAP not to pack unconstrained logic into slices with constrained logic– Can cause an increase in resource utilization if many slices are only

partially filled• Use the Floorplanner to lock flip-flop B in the example• Use map -timing implementation option


Interleaving Logic• Interleaving spreads out the resources associated with a bus

– Other logic can be interspersed with the bus

• MAP and PAR will not automatically interleave logic– You must manually interleave logic with RLOCs or the Floorplanner


Interleaving Example:Related Buses

• A and B input pins are interleaved– Skew between bits of interrelated

buses is minimized– Nets do not cross each other

Verilog:always@(posedge CLK)OUT <= A & B;

VHDL:process ( clk )

beginif ( clk' event and clk = '1' ) then

Q <= (A AND B);end if;

end process;

A1

A0

B0

B1LUT FF

LUT FF


Dual-PortRAM

ArithmeticFunction

6-7

0-1

2-3

4-5

0 1

2 3

4 5

6 7

Interleaving Example:Dual-Port RAM

• Dual-port RAM produces 1-bit of output per slice• Arithmetic functions and registers produce 2-bits per slice• Placing the RAM in a tall column can cause routing problems and skew• Horizontally interleave the dual-port RAMs to line up with other functions


Working with Patterns• The Capture Pattern and Impose Pattern commands allow you to create

a template pattern of placed logic that can be used later when placing similar logic

– Multiple instances of the same hierarchical block– Components along a datapath

• Procedure:– Select a template group of logic, and click the Capture Pattern button– Select a new group of logic to impose the pattern upon and click the Impose

Pattern button• The new group of logic must have the same number and type of components

as the template group– Place the new logic in the Floorplan window


Outline




Guide Introduction• The Floorplanner can be used to create a pseudo guide file to guide

future implementations• What is a guide file?

– A guide file is a file from a previous implementation that is used to guide the placement and/or routing of future implementations

– Guiding of logic is based on re-using named elements (FFS, latches, RAMs, ROMs, LUTs, BUFTs, etc.) from a previous implementation on a new one

• What is the purpose of using a guide file?– To preserve previous good results– Reduce run time




Guide Questions• What are the prerequisites for using a Floorplanner guide file?

• When would it be appropriate to use a Floorplanner guide file?

• Which elements would be appropriate to floorplan (i.e., which elements are least likely to change)? Why?


Guide Answers• What are the prerequisites for using a Floorplanner guide file?

– Preservation of hierarchy • When would it be appropriate to use a Floorplanner guide file?

– Small changes to overall design (generally, less than ten percent) • Which elements would be appropriate to floorplan (i.e., which elements

are least likely to change)? Why? – Synchronous elements: FFs, latches, RAMs– Guide files are effective if names remain the same. Names of synchronous

elements usually do not change from one implementation to the next as long as the hierarchy does not change. LUT names (because they are usually machine generated) change almost entirely


Floorplanned Guide File• Step One: Click Synchronous

Elements• From the Floorplanner window,

click Edit → Find• Enter * (star wildcard) in the

Name textbox• Enter Flip-Flops (or memory) in

the Type drop-down box • Click Find• Click Select Found• Click Close


Floorplanned Guide File• Step Two: Constrain selected logic• From Floorplanner window, click Floorplan menu → Constrain from

Placement

• Save and Exit Floorplanner


Expected Guide Results• Keep in mind with this flow that you are preserving only the placement of

the synchronous elements– In addition to not placing any LUT logic, you have not retained the routing– You are only guiding the placement of LUT logic based on the location of

the synchronous elements• You can expect the results to be similar

– You should not expect the results to match entirely. Why?• Because of the changes that were made to the design


Outline




Device Migration Considerations

• Virtex-II and Virtex-II Pro pinouts were created to allow for migration to a larger or smaller device

• For a larger device, the number of reference voltage pins will increase (Vcco and Vref)

– Those pins will need to be connected on the PCB, as if you are planning for the larger device

• Vref pins connected to reference supply voltage– That is, not used as user I/O– Listed as No Connect (NC) for smaller devices

• Vcco pins connected to reference supply voltage


Package Migration Considerations

• Specific packages allow migration to a larger or smaller package

– The FG456 and FG676 packages are pinout compatible

– The FF896 and FF1152 packages are pinout compatible

• Pin definitions remain nearly identical – Some Vref pins in larger packages are

user I/O in smaller packages– LVDS pairs are different– Some user I/O are in different banks


Planning Board Layout • Due to the board-level

layout of devices, some internal layout tips may not be obeyed

– For example, for the board shown here, interface signals between the two FPGAs may not allow for the most optimal internal layout

• Attempt to take into account the optimal internal layout when performing board-level layout


I/O Layout: ReducingGround Bounce

• Simultaneously Switching Outputs (SSO) are the main cause of ground bounce

• Review the Ground Bounce Recommendation Charts in the Data Book– This chart describes the maximum number of SSO pins per power and

ground pair for Virtex-II devices– Do not exceed these ratings if possible– If you do, you may need to modify your design, your pin assignments, or

your system to reduce the risk of suffering from ground bounce • Some possible solutions are described in the notes

• PACE will help you review SSO via command Tools → SSO Analysis











• Lab : MDT Flow

Incremental & Modular Design Techniques - 2 © 2003 Xilinx, Inc. All Rights Reserved










• Lab : MDT Flow


Incremental and Modular Design Techniques


Objectives

• Describe incremental design• Outline the incremental design flow• Describe modular design• Outline the modular design flow• Identify incremental and modular design prerequisites• Describe how a guide file is used



Outline

• Incremental Design Introduction• Modular Design Introduction• Incremental Design Flow• Modular Design Flow• IDT/MDT Prerequisites and Synthesis• Guide Files• Summary


What is Incremental Design?IDT

• Incremental design is used to make iterative design changes to one sub-block and preserve the placement and routing of unchanged blocks

Sub-BlockBlock A1

Sub-BlockBlock A2

Sub-BlockBlock A

Sub-BlockBlock B1

Sub-BlockBlock B2

Sub-BlockBlock B

Sub-BlockBlock C

Top-LevelBlock Top


Why UseIncremental Design?

• The first expectation is that the recompiled design must meet timing – Assuming the original design met timing

• The second expectation is that the recompile (synthesis, place&route) is faster than a full compile

– Allowing you to increase the number of bug fixes per day• The basic concept is to maintain “good” results

– In synthesis you will only resynthesize the changed blocks– Then the implementation (place&route) tools will have to run placement and

routing on only the changed portions of your design• Maintaining the placement and routing of unchanged blocks


How?• Resynthesize only the changed block

(Block A2)• Use the previous implementation

information, map and par NCDs, as a guide file

– The guide file will matchall previous routing andplacement information for the unchanged blocks and redoplacement and routing for thechanged block (Block A2)

Sub-BlockBlock A1

Sub-BlockBlock A2

Sub-BlockBlock A

Sub-BlockBlock B1

Sub-BlockBlock B2

Sub-BlockBlock B

Sub-BlockBlock C

Top-LevelBlock Top


IDT Case Study 1• Case 1: Packet Processing Design:

– XC2V500 -4 FG456– Utilization:

• 92% of Slices• 67% of FFs

– Performance Objectives:• 25 MHz clock

– Incremental design techniques results:• Implementation time before IDT implemented:

– ~1.5 hours• Implementation after IDT implemented (after each incremental design change):

– ~20 minutes


IDT Case Study 2• Case 2: Routing algorithm

– XC2V3000 -4 FF1152– Utilization:

• 85% of Slices• 59% of FFs

– Performance Objectives:• 112 MHz clock

– Incremental design techniques results:• Implementation time before IDT implemented:

– ~8 hours• Implementation after IDT implemented (after each incremental design change):

– 2.5 hours


Outline



What is Modular Design?MDT

• Modular design is used for a system on a chip, where individual teams fully implement their design block(s) independent of other blocks

Team A Team B

Team C

Sub-BlockBlock A1

Sub-BlockBlock A2

Sub-BlockBlock A

Sub-BlockBlock B1

Sub-BlockBlock B2

Sub-BlockBlock B

Sub-BlockBlock C

Top-LevelBlock Top


Why UseModular Design?

• Team-based design– Designers want to:

• Implement design in parallel, piece-wise fashion: Divide and conquer• Optimize each block separately, tuning each towards their unique design goals

– Focus on smaller blocks• Achieve perfectly repeatable, predictable results on unchanged modules:

Lock down and forget– If this is your only goal, incremental design techniques are likely to

provide a more beneficial solution than modular design • Save time


A Consistent Spectrumof Flows

Divide and Conquer Methodologies

•Simplest•Changes still “uncontrolled”

•Developed for quick runtimes for small design changes•Simple flow requirements

•True bottom-up flow: modules implemented separately•Most complex•Module TSPECs are required

Area Groups Incremental Design Modular Design

•Simplest•Changes still “uncontrolled”

•Quick runtimes for small design changes

•Simple flow requirements

•True bottom-up flow: modules implemented separately

•Most complex•Module TSPECs are required


How?• Create a layout that identifies where to place each design block on the die• Each block is fully implemented independently of one another• All blocks are combined using their individual implementation information

– Via Guided implementation files (NCD)

Sub-BlockBlock A1

Sub-BlockBlock A2

Sub-BlockBlock A

Sub-BlockBlock B1

Sub-BlockBlock B2

Sub-BlockBlock B

Sub-BlockBlock C

Top-LevelBlock Top

BlockA

BlockB

BlockC

Chip Layout


Modular Design Tools• The modular design tools are available as part of all ISE toolsets starting

with 5.2• Currently, modular design tools can only be used via the command line




Review• Describe how Incremental Design Techniques differ from Modular

Design Techniques


Answer• Describe how Incremental Design Techniques differ from Modular

Design Techniques

– Incremental Design Techniques: used for rapid bug fixes where changes are limited to a single design block

– Modular Design Techniques: used for team based designs where individual design blocks are implemented independently by individual teams


Outline



Incremental Design Flow


Incremental Design: Step 1Partition boundaries to match the (incremental) blocks that you would like to preserve

– The synthesis tool must not be allowed to optimize across these boundaries– XST, LS, Synplify pre 7.2: Individual netlists for each incremental block– Synplify using Multi-Point synthesis: One netlist for entire design– Typically, you would create between two and eight blocks


Incremental Design: Step 1In this example, we have circled the sub-blocks for which we want to incrementally apply changes

– Each circled block indicates an incremental block• Generally results in an individual netlist • Each incremental block will require floorplanning

Sub-BlockBlock A1

Sub-BlockBlock A2

Sub-BlockBlock A

Sub-BlockBlock B1

Sub-BlockBlock B2

Sub-BlockBlock B

Sub-BlockBlock C

Top-LevelBlock Top


Incremental Design: Step 2Synthesize design

– Synthesize each incremental design block• Generally, write out individual netlists (EDIF, NGC) for each incremental block • For incremental block netlists, you need to disable I/O insertion (I/O pads and

buffers) – Apply synthesis attribute: do not insert clock buffers


Incremental Design: Step 3Use Floorplanner (or PACE) to layout AREA constraints for each of the preserved blocks

– Use non-overlapping area constraints


Incremental Design: Step 4Implement the design until timing objectives

are met– Using the floorplan information contained in the

UCF– This may require several implementation

iterations with a high effort level• Additionally, it may have required the use of

Multi-Pass Place and Route (MPPR)– Once this step is complete we want to maintain

these “good” results• Utilize incremental design techniques


Incremental Design: Step 5As changes are required, make changes incrementally: one module ata time

– Resynthesize only the incremental block that changed


Incremental Design: Step 6Incremental Implementation

– Reimplement using guide files (NCD)

• As a guide, apply both the previous map NCD file and the par NCD file

• All previous blocks that did not change will retain placement and routing

• Once all the unchanged logic is placed and routed, the new logic will be placed and routed


Outline



Modular Flow


Phase 1: Initial Budgeting Goals

• Three goals:– Position global logic in the top-level design outside of the other modules

– Size and position each module in the target device using the floorplanner to create Area Groups

– Position the I/O ports of each module in such a way as to guide the implementation tools on the flow of the signals from one module to another


Phases 2 to 3: Implementation

• Phase 2:– Each module is implemented separately

• This allows each team/designer to individually implement their portion of the design until timing goals are met

• Phase 3:– Files from the first two steps are merged together– During this step, the implementation tools will primarily be routing the nets

between the individual blocks


Required Directory Structure• Under your “work” directory you will create the following structure:

– /<top_level_directory>• Will contain top-level NGO file and UCF which are used for all active module

implementations– /<active_moduleA_directory>, /<active_moduleB_directory>…

• One directory for each active module• This will contain the active module implementation information

– /<pim_directory>• Stores “guide” information from each active module implementation


Phase 1A: Create NGD• Creating an NGD file of the top-level design without

any module implementation information

ngdbuild -modular initial <design_name>

– Second level of hierarchy is all black-boxes

– Module files must not be included in the top-level directory

– The NGDBUILD output file <design_name>.ngo file is used during subsequent Modular Design steps, while <design_name>.ngd is not


Phase 1B: Top Level Timing Constraints

• Add top level timing constraints

constraints_editor <design_name>.ngd

– At this point, clocks may not drive any loads, hand edit constraints in UCF to specify clocks


Phase 1C: Floorplan• Floorplan

floorplanner <design_name>.ngd

– Select File → Read Constraints to read in top level UCF– All top level logic must be floorplanned:

• Such as: Top-level I/O ports, global buffers, 3-state buffers, flip-flops, and look-up tables

– Floorplan area constraints to assign placement of logic• Use Autofloorplanning for placement of “Pseudo Logic”

– Select Floorplan → Distribute Options, make sure Autofloorplan as needed is selected. When you assign an area constraint for a module, the Floorplanner positions the pseudo logic automatically


Phase 2A: Setup Active Module

Active Module Implementation• Setup Active Module

– Synthesize each module and sub-blocks in separate module directories– Copy top level UCF to module directory and rename to <module_name>.ucf

• This allows you to maintain common top level constraints but also add module level specific constraints


Phase 2A: Setup Active Module (Continued)

Active Module Implementation• Setup Active Module

– Run NGDBUILD on active module(s)ngdbuild -uc <module_name>.ucf -modular module -active <module_name>

<top_level_directory>/<design_name>.ngo– <top_level_directory>/<design_name>: Top-level ngo file used as an input file for

the Active Module Implementation phase

– If necessary create module level constraints• If changes are made to the UCF, rerun the modular NGDBUILD command


Phase 2B: Implement and Publish Active Module

Active Module Implementation• Implement and Publish Active Module

– Run MAP, PAR, and TRACE until timing is met:map <design_name>.ngdpar -w <design_name>.ncd <design_name>_routed.ncd

– No Modular specific commands– Apply map and par commands as necessary

trce <design_name>_routed.ncd

– Publish Implemented Module (PIMCREATE) to a central location:pimcreate pim_directory_path -ncd <design_name>_routed.ncd• This command will publish the module implementation files to the

pim_directory_path


Phase 3: Final Assembly• To incorporate all the logic for each module into the top-level design, run

ngdbuild as follows: ngdbuild -modular assemble -pimpath pim_directory_path <design_name>.ngo

• Run MAP, PAR, and TRACE:map <design_name>.ngdpar -w <design_name>.ncd <design_name>_routed.ncd

– No Modular specific commands– Apply map and par commands as necessary

trce <design_name>_routed.ncd


Outline



IDT/MDT Prerequisites• Basic guidelines

– Well-partitioned hierarchical design– Well-defined data flow– Well-defined port interaction– Registered leaf-level hierarchical boundaries

• MDT specific guidelines

• IDT specific guideline


Partitioning• The design must have an effective functional and physical partition into

proper modules– The design should be broken into functional hierarchical blocks that can be

placed onto the chip with a well-defined physical flow– Separate structural levels and RTL levels of the code

• Do not mix the two types of HDL in a single entity/module• Structural -- instantiations of lower-level blocks• RTL -- leaf-level code where functionality is created

• This is not new to designing, but it does require a top-down design approach be used with some up-front budgeting


Hierarchy Preservation• Synthesis tool should preserve hierarchy

– Primarily an IDT requirement, but also useful for MDT• Why?

– If the hierarchy is flattened, any change to any single piece of code will require the entire design to be resynthesized

– This will cause a ripple effect; any small change will effectively change the entire netlist

– Also, to effectively use incremental design, the hierarchy must be in place


Hierarchy Preservation• Exemplar, Synplicity, Synopsys, and XST synthesis tools all have the

capability to preserve the hierarchy • Synopsys:

– Set checkbox to Preserve Hierarchy in Implementation • Synplicity:

– Set syn_netlist_hierarchy = TRUE on top-level entity/module– Set syn_hier hard for each level of hierarchy

• Exemplar:– Optimize tab → Hierarchy box → Preserve button– Set checkbox to Optimize single level of hierarchy

• XST:– Properties → Check Keep Hierarchy


Data-Flow• What is well-defined data-flow?

• A large portion of the blocks in the design should not include global logic

• Rather, the blocks should have a data-flow that passes from block A1 to block B2 with limited interaction of multiple blocks

– This will make floorplanning easier

Block B2

Block A1

Block A2


Port Interaction• What is meant by well-defined port interaction?

• A small number of ports on each module– Limit large amounts of interaction so that each module is a self-contained

module

• This allows each module to be more optimally implemented and placed


Registered Boundaries• Registering the outputs of each leaf-level boundary eliminates the need

for synthesis tools to optimize across boundaries– This is also a fundamental aspect of synchronous design methodology

• Enables synthesis of individual modules without resynthesizing the whole design

• Provides consistent clock-budgeting between modules in a team-based design environment


Modular Design Guidelines• MDT specific guidelines:

– All lower-level modules must be declared– Modular design supports only two levels of hierarchy

• The top level and its sub-blocks• IDT can have multiple levels

– You cannot make multiple instantiations of the same block• This requires copying and renaming the entity/module for each unique instance • IDT allows this, assuming the synthesis tools support it (XST does not)

– IOB registers must be inferred in the top-level code– Three-state logic inference should occur inside of one level

• The 3-state logic should not span several different hierarchical blocks– Three-state signals that are outputs of a block must be declared as inout


IDT Specific Guidelines• For incremental design to be effective, the full design netlist must change

very little for each iteration– This requires the synthesis tool to limit changes to a single incremental

design block • You will generally generate a netlist file for each incremental block

• Select the top-level EDIF/NGC in the Xilinx implementation tools, and the implementation tools will find the remaining files in the same directory

– Or you can provide the search directory information (-sd) if each netlist is in a separate directory/folder


Incremental SynthesisLeonardoSpectrum

• To create incremental design blocks, create a separate LS project for each block that you want to preserve

– In sub-blocks, disable pad insertion and clock buffer– A separate netlist will be written for each block – During implementation, specify Translate Macro Search Path directory for

each netlist• For more than one directory add -sd (search directory) for each netlist, for

example:-sd ../<ls_blockB_directory> -sd ../<ls_blockC_directory>


Incremental SynthesisSynplify

• For all Synplify versions 7.1 and previous:– To create incremental design blocks, create a separate Synplify project for

each block that you want to preserve• In sub-blocks, disable pad insertion and clock buffer• A separate netlist will be written for each block • During implementation, specify -sd (search directory) for each netlist

• For Synplify Pro 7.2+:– Utilize Synplify’s MultiPoint Synthesis Design Flow

• Allows you to specify incremental design blocks in single Synplify project– Results in a single netlist

» Only changed incremental blocks will change in the netlist


Incremental SynthesisXST

• For XST, apply an incremental_synthesis attribute to each module/entity– This will be applied on a top-down basis – Use the resynthesize attribute if you have changed that module/entity– VHDL example:

attribute incremental_synthesis: string;attribute incremental_synthesis of <entity_name>: entity is “yes”;

– Verilog example:// synthesis attribute incremental_synthesis of <module_name> is yes;// synthesis attribute resynthesize of <module_name> is yes;

– XCF example:MODEL <entity_name> incremental_synthesis = yes;MODEL <module_name> incremental_synthesis = yes; MODEL <module_name> resynthesize = yes;


Outline



Guide File• What is a guide file?

– It is a file from a previous implementation that is used to guide a more recent implementation

– The map.ncd file contains mapping (packing) information for slices, IOBs, etc.– The <par>.ncd file contains placement and routing information

• What happens during a guided implementation?1. The implementation tools try to match names of internal resources between the

guide file and the current netlist 2. When the tools find a match, they place that logic into the same location as it

was located in the guide file3. Routing is also maintained when matching signals between logic is found


Checkerboard Guide File• If you do NOT use incremental or modular

design techniques, guide will result in a “checkerboard” guide file

– A checkerboard of changes• Black represents unchanged slices

in the design• Yellow represents the changed slices

in the design– A checkerboard guide file is one in which

many small changes have occurred to the placed and routed design

– This results in less flexibility for PAR to place-and-route the changed components


Incremental DesignGuide File

• When you use incremental design techniques, all design changes are limited to one area on the die

– Due to floorplanning• Incremental guiding will not use guide

information for any incremental block that changes (AREA_GROUP)

– This gives PAR more flexibility in re-placing and routing that block

• PAR is not hindered by a checkerboard guide file


Guide File Requirements• Limited changes to the netlist

– For the checkerboard approach, the netlist should change less than ten percent

– For an incremental design approach, only a single incremental block should change

• To satisfy this requirement in a HDL-based design, there is a single recommendation:

– Recompile only the input HDL files where the changes are made• This can be accomplished by adhering to the rules in the previous sections


Guide File Use• Guide is used during mapping, placement, and routing phases of

implementation• In Project Navigator, right-click Implement Design → Properties →

Place & Route Properties tab– Use the Guide Design File, and browse to the location of the previous

implementation NCD file that you want to use as the guide file• <design_name>.ncd: Placed & routed NCD file that contains mapping,

placement, and routing information• <design_name>_map.ncd: Mapped NCD file that contains only mapping

information – Only the packing of the logic into CLBs and IOBs will remain the same as

the guide file. No placement & routing information will be retained


Guide Mode• For incremental designs, use Incremental

guide mode • For modular designs, Incremental guide mode is

automatically used– Exact:

• The placement and routing is maintained regardlessof constraints for all matching components

– Leverage:• The tools will use all matching components as the INITIAL starting point for placement and

routing• They will then make changes to adhere to constraints and optimize netlist changes

– Incremental:• Within a floorplanned block, if any component does not match the previous implementation,

none of the components within that block are guided– Otherwise it is the same as Exact guide mode


Outline



Review Questions• Describe each of the incremental design flow steps• Describe each of the modular design flow steps• What are the basic prerequisites for incremental and modular design?• What is a guide file?


Answers• Describe each of the incremental design flow steps


Answers• Describe each of the modular design flow steps


Answers• What are the basic prerequisites for incremental and modular design?

– Well-partitioned hierarchical design– Well-defined data-flow– Well-defined port interaction– Registered leaf-level hierarchical boundaries

• What is a guide file?– An NCD file from a previous implementation that is used to guide the

packing, placement, and routing of a new (partially changed) netlist


Summary• Incremental Design Techniques and Modular Design Techniques require

adherence to synchronous design methods

• Incremental Design Techniques are used to reduce compile time and maintain previous “good” results for unchanged blocks

• Modular Design Techniques is a team based design flow and toolset, which allows separate teams to independently implement individual design blocks


Where Can I Learn More?• Online Software Manuals:

– Xilinx Synthesis Technology (XST) Users Guide– Development System Reference Guide → Incremental Design– Development System Reference Guide → Modular Design– Development System Reference Guide → Map → Guided Map– Development System Reference Guide → PAR → Guided PAR

• Synplify → Help menu → Online Documents• LeonardoSpectrum → Help menu → Open Manuals Bookcase











• Lab : MDT Flow

FPGA Editor - 2 © 2003 Xilinx, Inc. All Rights Reserved



Section 6 : On-Chip Verification and Debugging– ChipScope Pro– Demo


Optional Topics– Power Estimation with Xpower– Advance Implementation Options– Embedded Solutions with Power PC/MicroBlaze and Embedded Development Kit (EDK)– DSP Solutions with System Generator


Reduce Debug Time

FPGA Editor: Viewing and Editing a Routed Design


Objectives

After completing this module, you will be able to:• Use the FPGA Editor to view device resources• Connect the internal nets of an FPGA to output pins (Insert Probes)• Determine the specific resources used by your design• Make minor changes to your design without re-implementing


Outline

• FPGA Editor Basics• Viewing Device Resources

and Constrained Paths • Adding a Probe• Making Minor Changes• Summary• Appendix: Creating a Macro


What Does the FPGA Editor Do?

• The FPGA Editor is a graphical application

– Displays device resources– Precise layout of chosen

device• The FPGA Editor is commonly

used to:– View device resources– Make minor modifications

• Done late in the design cycle• Does not require re-

implementation of the design– Insert Probes

• Used for in circuit testing


When to Use the FPGA Editor

• Use the FPGA Editor to:– View the design’s layout– Drive a signal to an output pin for testing (inserting a probe)– Add logic or special architectural features to your design without having to

recompile the design

• Do not use the FPGA Editor to:– Floorplan– Carelessly control the place and route


What the FPGA Editor Cannot Do

• The FPGA Editor cannot:

– Add additional logic from a second netlist• Because translation (NGDBuild) is completed • Additional logic would need to be hand-placed and routed

– Make modification to design files • HDL and netlist files will not reflect modifications


Design Flow Diagram

• Xilinx implementation flow – Entry points for FPGA Editor

• Placing and routing critical components

– Before implementation (Post-MAP)

• Making minor changes – After implementation (Post-PAR)

MAP

NCD

NCD & PCF

PAR

BITGEN

FPGA Editor

BIT

Remember to document the changes to your design, becauseyour netlist will not reflect the changes made by the FPGA Editor!


History Window

Push Button Panel

World Window

Menu Bar

Array Window

List Window

FPGA Editor


Navigating

• Zoom

• Use the World window to keep track of your location on the die when you are zoomed in

• Array window resources


List Window• Easiest way to select objects in your design• Displays

– Components– Nets– Paths– Layers– Constraints– Macros

• Name Filter search feature– Limit the number of elements shown– Use Wildcards (* and ?)

• Ability to highlight components– Choose from 15 different colors


Outline


and Constrained Paths• Adding a Probe• Making Minor Changes• Summary• Appendix: Creating a Macro


Viewing the Contentsof a Slice or IOB

• Select a slice or IOB • Click the editblock button• View LUT configuration

– LUT– RAM– ROM– SRL

• View the LUT equations– Click the Show/Hide Attributes

button


Viewing Constrained Paths• View constraints in the List window

– Select Constraints in the pulldown menu

• Perform a timing analysis – Tools Trace Setup and Run

• Trace window– Generates a Timing Analysis report – Select the Type of Report – Click Apply


Viewing Constrained Paths• Trace Summary window

– Select the constraint to report on– Click Details

• The Trace Errors window– Lists the slack on each delay path– Most-critical path is listed last – Select a delay path to be

displayed– Click Hilite


Calculating Skew• Determine net delays

– History window shows:• Net destination• Associated delay

• Click the “attrib” button– Located on the Push Button Panel– Select Pins tab

• Determine skew– (Longest Delay) - (Shortest Delay)


Viewing Multiple Windows• Multiple Array windows

can be viewed by using the command:

– Window New Array Window

– List, Array, or World window can be selected

• Useful for viewing different areas of interest at the same time

• View and edit the sources and destinations of routes


Outline


and Constrained Paths• Adding a Probe• Making Minor Changes• Summary• Appendix: Creating a Macro


Adding a Probe:Probes GUI

• Ties an internal signal to an output pin

• Probes are managed in the Probes GUI

– Click the “probes” button on the Push Button Panel

– Tools Probes

• Probes can be added, deleted, edited, or highlighted


Adding a Probe:Probes GUI

• Click the Add button– Opens the Define Probe

window• Select desired probes

to Delete, Edit, or Hilite• After a Probe has been

added:– Click Bitgen to create

new bitfile– Click Download to open

iMPACT programmer – Document the change


Defining a Probe• Enter a Pin Name• Select Net to be probed• Click OK

• Filter feature to limit net options

• Method – Automatic routing

• Selects the shortest route • Possible long wait times

– Manual routing • Specific pins can be selected • Selects the shortest route if multiple pins are selected


Outline




Adding Components• Adding a Component

– Select the resource (slice, IOB, etc.) from the Array window – Click the add button– Complete the Component Properties box

• All resources can be added


Adding Component Pins• Adding component pins

– Select pin– Select “add” in push button panel– Complete Properties box

• Pin name


Modifying LUTs• Modifying the equations

– Click the Show/Hide Attributes button

– Complete the Component Properties box

• * (AND), + (OR), ~ (NOT), @ (XOR)

– Select Apply changes • Tool performs a Design Rule

Check (DRC)• Click the Save Changes

and Close Window button


Modifying Other Slice Resources

• Add resources– Select properties of resource – Click on pin to route signal paths – This will automatically route

the signals inside the slice

• Click the Apply button– Performs a Design Rule Check

• Click the Save Changes and Close Window button


Routing Signals• Routing setup: Tools → Route → Auto Route Setup…

– Auto Route Design: Options used to auto route the entire design (default values)

• Timespec Driven: Auto routes signals to meet timing constraints

– Generally best results • Allow Pin Swap: Allow for pin swapping during auto

routing. Enables better use of resources– Auto Route Selection: Options used for a selected route

(pins, nets, components)• Delay driven: Auto routes selected item as fast as possible

– Generally best results• Resource Driven: Minimizes use of resources (wires and

pips) during auto route– Default


Rerouting SignalsAuto Routing

• Rerouting a signal:– Select net in Array or List window to

reroute– Click → unroute in pushbutton panel– Specify routing options (Auto Route

Setup)– Click → autoroute in pushbutton

panel


Manual Routing Signals I• Select site pins

– Click the site pin of a resource– Hold down the Shift key– Click another site pin

• Route the net– Click the “route” button

• Automatically chooses the shortest route between site pins


Manual Routing Signals II• Select object to route

– Click the site pin of a resource

– Hold down the Shift key– Click net– Click subsequent nets


• Routes one net segment


Manual Routing Signals III• Select object to route

– Click previously routed segment

– Hold down the Shift key– Click site pin


• Automatically chooses the shortest route from segment to site pins


Adding an External IOB• Adding an IOB

– Select IOB• Make certain the IOB is bonded,

unbonded IOBs have X in IOB box– Select “add” in pushbutton panel– Edit Properties, click OK

• Use the editblock command to edit resources


IOB Resources• Input/Output registers, output 3-state, I/O standard, drive strength, and

slew rate control can be viewed and modified


Outline




Review Questions• List some of the common uses for the FPGA Editor

• When should the FPGA Editor not be used?

• What are the benefits of inserting a probe?

• If any modifications were made using the FPGA Editor, it is important to __________ any changes. Why?


Answers• List some of the common uses for the FPGA Editor

– View device resources– Make minor modification– Insert probes– Generate a new bitstream

• When should the FPGA Editor not be used?– FPGA Editor should not be used to Floorplan a design or control the place

and route


Answers• What are the benefits of inserting a probe?

– The probes capability makes it possible to route a signal to an output pin for testing, and generate a new bitstream for the design without re-implementing

• If any modifications were made using the FPGA Editor, it is important to Document any changes. Why?

– It is necessary to document your changes because the netlist will not reflect the changes made by the FPGA Editor


Summary• The FPGA Editor provides you with a tremendous amount of design

control• Most customers use this tool for understanding the device utilization or

adding test probes• Careful use of this tool is important because indiscriminate movement of

logic can severely reduce the likelihood of getting good design performance and utilization

• The FPGA Editor allows you to make minor changes to a design without re-implementing your design

• Document any changes to your design because your netlist will not reflect the changes made by the FPGA Editor


Where Can I Learn More?• FPGA Editor Help

– http://support.xilinx.com Software Manuals– Help Help Topics

• Tech Tips– http://support.xilinx.com Tech Tips Floorplanner & FPGA Editor


Outline




Creating a New Macro • Use the Command: File New

– Choose the Macro radio button– Give the Macro a File name

• Example will be a wide AND gate named WIDEAND

• Macro file name wideand.nmc• Add the Macro resources

– Select necessary components– Use the add command

• Program the detailed use of each component – Use the editblock command

• Manually route any internal signals


Creating External Pins • External pins define the ports on the macro

– The macro cannot be used if there are undefined external pins• Add external pins to the macro

– Select a site pin – Edit Add Macro External Pin

• External Pin Properties GUI– “External Name” is the port name

referenced in the top level (in1)– Choose Type of Pin

• Save the Macro • Instantiate the component WIDEAND

in your design


Instantiation ofWIDEAND Macro

--Declaration of Macros ----

component WIDEANDport ( in1, in2, in3, in4 : in std_logic;

XOUT : out std_logic);end component;

-- Instantiation of Macros ------- (port_map_name=>signal_name)

U1:WIDEAND port map (in1=>W, in2=>X, in3=>Y, in4=>Z, XOUT=>PROD);

-- Declaration of Macros -----

module WIDEAND (in1, in2, in3, in4, XOUT)

input in1;input in2;input in3;input in4;output XOUT;endmodule

-- Instantiation of Macros -----

U1(.in1 (W), .in2 (X), .in3 (Y), .in4 (Z), .XOUT(PROD));

VHDL Verilog


Setting a Reference Comp • Shape of the macro will be

maintained – In an RPM

• Use the command: Edit Set Macro Reference Comp

– Maintains the relative placement of the slicesin your macro

• Macros do not maintain the routing selected


Viewing a Macro Placement • After implementing a design with

an instantiated Macro– Select All Macros from

the List window– Choose desired Macro to view– View Macro placement

in the Array window


Converting an ExistingDesign to a Macro

• File Save As, then select Macro radio button

• Perform necessary edits– Delete any logic/routing, etc. – Any hanging nets will generate an error

• A macro should not have any IOBs• Routing used in a macro cannot be

locked down– It will be considered a “rat’s nest”

• Add external pins to the macro and select a Reference Comp

• When finished with edits, save the macro




Section 6 : On-Chip Verification and Debugging– ChipScope Pro

• Demo




FPGA Editor Lab


Objectives

After completing this lab, you will be able to:• Analyze the contents of a slice• Add a probe • Change I/O locations and contents• View a constrained path and take steps to improve the performance

of a net


Lab Design: Correlate and Accumulate


General Flow• Step 1: Implement the Design and Launch FPGA Editor• Step 2: Analyze Slice Contents• Step 3: Add a Probe• Step 4: Modify IOB Properties• Step 5: Move an IOB’s Location• Step 6: Analyze Timing Results• Step 7: View a Path• Step 8: Reroute a Net

Xilinx Confidential

Xilinx On-Chip Debug Solutions

Xilinx ConfidentialPresentation Name 2







Shorten Debug and VerificationUnleash the Power of Xilinx FPGAs

• Flexible On-Chip Debug– Place ChipScope Pro cores anywhere in

your design to gain point access for debug– Debug occurs at or near system clock

speeds• Integration with Xilinx ISE Tools

• Define, add and remove cores at any point in the design phase

• Change ChipScope Pro core inputs without recompiling the entire design

• It’s Never Too Late in an FPGA– Hardware problems can be fixed during

development AND after product deployment


Enabling System Level Verification and Debug

• Virtual Input Output (VIO) – Stimulate and monitor logic in real-time

using virtual input and outputs – Detect activity asynchronously or

synchronously on rising or falling clock edges

– Define and drive pulse trains to simulate input signal activity

• Integrated Bus Analysis (IBA)– Access CoreConnect bus structures, the

interface between the PowerPC and processor peripherals

MAC

ATM Utopia L2

Vite

rbi

PLB

Bus

OPB

BusBridge OPB GPIO

Arbi

ter

Use ChipScope Pro IBA cores to monitor andanalyze PLB and OPB bus transactions

Use ChipScope Pro VIO cores to add virtual DIP switches and LEDs toany design


Enabling Logic Verification and Debug

• Integrated Logic Analysis (ILA)– Point access to every node and signal within a Xilinx FPGA – Support system clock rates up to 255MHz

• No I/O pins required for debug– Access via the JTAG Port

JTAG

ChipScope Pro

VIRTEX-II PRO

XC2VP20FF1152

ILA BlockRAM

Probepoints


ChipScope Pro with Agilent Trace CoreCombining On-Chip Debug with Deep External Sample Storage

ChipScope Pro

LAN

FPGATrace Port AnalyzerVIRTEX-II PRO

XC2VP20FF1152

Probepoints

ILA ATC

JTAG

Trace

• Deep External Sample Depth– Debug complex system designs that require deeper sample storage– Up to 2M samples without using any on-chip BlockRAM– Access via the high-speed Trace Port

• On-Chip Access to Every Signal and Node in the FPGA design– Access any signal and nodes on-chip


Xilinx ChipScope Pro Enabling Complete FPGA Debug Solutions

ChipScope ProChipScope ProILA with ATCILA with ATC

ChipScope ProChipScope ProIBAIBA

ILA with ATCILA with ATC

ChipScope Pro ChipScope Pro ILAILA

Traditional Logic Analyzer

Solution

Syst

em C

ompl

exity

Debug and Verification Requirements


Complete Solutions Available Today

• ChipScope Pro On-Chip Debug Solution– Free 30 Day Evaluation– $695 Full version

• Agilent FPGA Trace Port Analyzer– $7,295 Available Now

www.xilinx.com/chipscopepro

www.agilent.com/find/FPGA

Course Summary - 2 © 2002 Xilinx, Inc. All Rights Reserved







Course Summary

Advance FPGA Design With Xilinx

Course Summary - 4 © 2002 Xilinx, Inc. All Rights Reserved

Summary• CORE Generator™ cores can be used to take full advantage of the Xilinx

FPGA architecture• Timing reports are used to identify critical paths and analyze the cause of

timing failures• Multi-cycle, false path, and critical path timing constraints can be easily

specified via the Advanced tab in the Xilinx Constraints Editor• Advanced implementation options, like timing-driven packing and extra

effort, can help increase performance• Floorplanner can be uses to improve timing for the design• FPGA Editor can be use to make minor changes to routed design to reduce

debugging time• You can improve implementation time with Incremental Design Techniques

and Module Design Techniques• On-Chip Verification with ChipScope Pro


Power Estimation

Power Estimation - 3 © 2003 Xilinx, Inc. All Rights Reserved


Objectives

• List the three phases of the design cycle where power calculations can be performed

• Estimate power consumption by using the Xilinx Power Estimator worksheet

• Estimate power consumption by using the XPower utility


Outline

• Introduction• Power Estimator Worksheet• Using XPower Software• Summary


Performance (MHz)P M

AX

Package PowerLimit

Real World DesignPower Consumption

High Density

LowDensity

Power Consumption Overview

• As devices get larger and faster, power consumption goes up

• First generation FPGAs had:– Lower performance– Lower power requirements– No package power concerns

• Today's FPGAs have:– Much higher performance– Higher power requirements– Package power limit concerns exist


Power Consumption Concerns• High-speed and high-density designs require more power, leading to

higher junction temperatures• Package thermal limits exist

– 125oC for plastic– 150oC for ceramic

• Power directly limits:– System performance– Design density– Package options– Device reliability


Estimating Power Consumption

• Estimating power consumption is a complex calculation– Power consumption of an FPGA is almost exclusively dynamic– Power consumption is design dependent and is affected by:

• Output loading• System performance (switching frequency)• Design density (number of interconnects)• Design activity (percent of interconnects switching)• Logic block and interconnect structure• Supply voltage


Estimating Power Consumption

• Power calculations can be performed at three distinct phases of the design cycle

– Concept phase: A rough estimate of power can be calculated based on estimates of logic capacity and activity rates

• Use the Xilinx Power Estimator worksheets on the Web– Design phase: Power can be calculated more accurately based on detailed

information about how the design is implemented in the FPGA• Use XPower™ software

– System integration phase: Power is calculated in a lab environment• Use actual instrumentation

• Accurate power calculation at an early stage in the design cycle will result in fewer problems later


Activity Rates• Accurate activity rates (A.K.A. toggle rates)are required for meaningful

power calculations• Clocks and input signals have an absolute frequency• Synchronous logic nets use a percentage activity rate

– 100-percent indicates that a net is expected to change state on every clock cycle

– Allows you to adjust the primary clock frequency and see the effect on power consumption

– Can be set globally to an average activity rate, on groups or individual nets• Logic elements also use a percentage activity rate

– Based on the activity rate of output signals of the logic element– Logic elements have capacitance


Outline



Xilinx Power Estimator• Excel worksheets with power estimation formulas built in

– Enter design data in white boxes– Power estimates are shown in red boxes

• Worksheet sections:– Summary (device totals)– Quiescent power– CLB logic– Block RAMs– Block multipliers– DCMs– I/O pins


Power Estimator Worksheet:Summary and Quiescent


Power Estimator Worksheet:CLB, RAM, and Multipliers


Power Estimator Worksheet:DCM and I/O


Outline



What is the XPower Software?

• A utility for estimating the power consumption and junction temperature of FPGA and CPLD devices

• Reads an implemented design (NCD file) and timing constraint data• You supply activity rates:

– Clock frequencies– Activity rates for nets, logic elements, and output pins– Capacitive loading on output pins– Power supply data and ambient temperature– Detailed design activity data from simulation (VCD file)

• XPower calculates total average power consumption and generates a report


Running XPower• Expand Implement Design →

Place & Route• Double-click Analyze Power to

launch XPower in interactive mode

• Use the Generate Power Dataprocess to create reports using VCD files or TCL scripts


XPower GUI


XPower Reports• ASCII (design.pwr) or HTML (design.html) formats

– Select format in the Edit → Preferences dialog• Summary of power consumption• Detailed breakdown of power usage (optional)• Thermal data

– Junction temperature– Theta J-A for chosen package


XPower Summary ReportPower summary: I(mA) P(mW)----------------------------------------------------------------Total estimated power consumption: 807

Vccint 1.50V: 160 240Vccaux 3.30V: 100 330Vcco33 3.30V: 72 237

(Additional breakdowns deleted)

Thermal summary:----------------------------------------------------------------

Estimated junction temperature: 46C250 LFM 43C

...Ambient temp: 25C

Case temp: 43CTheta J-A range: 26 - 26C/W

Decoupling Network Summary: Cap Range (uF) #----------------------------------------------------------------Capacitor Recommendations: Total for Vccint : 8

470.0 - 1000.0 : 10.0470 - 0.2200 : 10.0100 - 0.0470 : 20.0010 - 0.0047 : 4

(Other power supplies deleted)


XPower Detailed ReportPower details:-------------------------------------------------------------------------------Clocks: Loads Loading(fF) C(pF) F(MHz) I(mA) P(mW)-------------------------------------------------------------------------------rd_clk_inst/IBUFGLogic:rd_clk_inst/CLKDLL 40 166.7 10.0 15.0rd_clk_inst/BUFG 6 166.7 1.5 2.3

Nets:rd_clk_dll 364 231 166.7 58.0 86.9rd_clk_inst/CLK0 1 0 166.7 0.0 ~0.0rd_clk_inst/IBUFG 1 0 166.7 0.0 ~0.0

. . .-------------------------------------------------------------------------------Outputs: Loads Loading(fF) C(pF) F(MHz) I(mA) P(mW)-------------------------------------------------------------------------------Vcco33

final_data_obuf[0] 35000 13 5.0 0.8 2.6. . .-------------------------------------------------------------------------------Logic: Loads Loading(fF) C(pF) F(MHz) I(mA) P(mW)-------------------------------------------------------------------------------cha_fifo_inst/.../FIFO_BRAM.A 32 6.0 0.3 0.4. . .


Outline



Review Questions• Power estimations are typically made during which three phases of the

design cycle?

• What methods can be used to enter activity rates into the XPower tool?


Answers• Power estimations are typically made during which three phases of the

design cycle?– Concept phase: Rough estimate based on estimated logic capacity and

activity rates– Design phase: More accurate estimate based on information about how the

design is implemented in the FPGA– System integration phase: Actual power usage is measured in a lab

environment• What methods can be used to enter activity rates into the XPower tool?

– Load a VCD file– Manually enter activity rates


Summary• Power calculations can be performed at three distinct phases of the design

cycle:– Concept phase: (Xilinx Power Estimator Worksheet)– Design phase: (XPower software)– System integration phase: (lab measurements)

• Accurate power calculation at an early stage in the design cycle will result in fewer problems later

• XPower software is a utility for estimating the power consumption and the junction temperature of FPGA and CPLD devices

• XPower software uses activity rates to calculate total average power consumption


Where Can I Learn More?• Software manuals: Development System Reference Guide

– XPower chapter• Online Help from XPower GUI• Application Notes:

– XAPP158: “Powering Xilinx FPGAs”– XAPP415: “Packaging Thermal Management”

• Power Estimators (Excel spreadsheets): – http://www.xilinx.com/ise/power_tools/spreadsheet_pt.htm


Advanced Implementation Options

Advanced Implementation Options - 17 - 3 © 2003 Xilinx, Inc. All Rights Reserved


Objectives

• Increase design performance by using timing-driven packing and advanced place & route options


Outline

• Introduction• Timing-Driven Packing• Advanced Place & Route Options• Summary


Introduction• Xilinx recommends using the default options and global timing

constraints the first time you implement a design• If your design does not meet timing goals, follow the recommended flow

presented earlier– Early in the design-cycle, look at ways of changing your HDL code

• Confirm that good coding styles were used• Try synthesis options, such as retiming or adding pipeline stages, to reduce

logic-levels• If it is early in the design cycle, you do not want to run a full implementation

every time a change is made - this will be time consuming and frustrating– Increase the Place & Route effort level– Apply path-specific timing constraints for synthesis and implementation


When to UseAdvanced Options

• If timing is still not met, consider using advanced Map or Place & Route (PAR) options

– Map: Perform Timing-Driven Packing• Uses timing constraints to pack critical paths

– PAR: Extra Effort– PAR: Multi-Pass Place & Route (MPPR)– PAR: Re-entrant Routing

• These options will increase the software run time– This module discusses the expected tradeoffs and benefits of each option


Outline



Timing-Driven Packing• Timing constraints are used to optimize which pieces of logic are packed

into each slice– Normal (standard) packing is performed– PAR is run through the placement phase– Timing analysis analyzes the amount of slack in constrained paths– If necessary, packing changes are made to allow better placement

• The output of Map contains mapping and placement information– Post-Map Static Timing Report will contain more realistic net delays


Example• Originally, the FFs were packed together into a slice• After placement and timing analysis, the FFs are packed into different

slices to allow independent movement

Standard Pack

FF1

FF2

Timing Driven Pack

FF1

FF2


Turning onTiming-Driven Packing

• Set the Property Display Level to Advanced

• Right-click Implement or Map Process, and select Properties

– Check the Perform Timing-Driven Packing box


Tradeoffs• Typical performance improvement: Five to eight percent• Has the greatest effect when unrelated packing has occurred

– Look in the Map Report, Design Summary section• Number of slices containing unrelated logic

– If no unrelated packing has occurred, performance improvement will be minimal• Run time for the Map process always increases

– Up to 200 percent


Outline



PAR Extra Effort• Only available when Highest effort level is selected• Two settings: Normal (1), Continue on Impossible (2)• Typical performance improvement: Four percent• Run time for the Place & Route process always increases

– Potential 200-percent increase or more


Setting Extra Effort• Set the Property Display

Level to Advanced• Right-click Implement or

Place & Route Process and select Properties

– Set Place & Route Effort Level (Overall) to High

– Set Extra Effort


Multi-Pass Place & Route (MPPR)

• Runs the Place & Route process multiple times• Uses a different placement seed (cost table) for each pass

– One-hundred cost tables available– One or more cost tables may meet your timing objectives

• Keeps the best results and discards the restPlaced & Routed

Result #1

Place RouteMappedDesign

Placed & RoutedResult #2

Placed & RoutedResult #3


Running MPPR• Expand the Implement Design

and Place & Route Processes• Right-click Multi-Pass Place &

Route and select Properties– Set properties, then click OK

• Double-click Multi-Pass Place & Route to run MPPR


MPPR Results• MPPR Report (under the Multi-Pass Place & Route process)

– Lists all of the cost tables that were run, from best to worst– Saved results are marked

• Saved results are placed in the specified directory– Each cost table has its own subdirectory

• The best result is also copied back into the main project directory– Use this result to continue with re-entrant routing if timing has not been met– To try a different result, manually copy the files out of the subdirectory


Re-entrant Routing

• Runs the Place & Route process on a design that has already beenplaced & routed before

– Skips the placement phase and goes directly to the router

Placed & RoutedDesign

Place Route

MappedDesign

Re-entrant RoutedDesign


When to UseRe-entrant Routing

• To complete the routing of a design that was not 100-percent routed• To improve timing on the best results from MPPR• In general, use this option when routing was initially limited by selecting a

low Overall or Router Effort Level


Running Re-entrant Routing• Right-click Implement or

Place & Route process, and select Properties

– Set Place & Route Effort Level to High

– Set Place and Route Modeto Reentrant Route


Outline





Review Questions• Under what conditions will timing-driven packing have the most impact on

design performance?• What is the tradeoff when using PAR with the Extra Effort option?


Answers• Under what conditions will timing-driven packing have the most impact

on design performance?– When unrelated logic is packed together into the same slice

• What is the tradeoff when using PAR with the Extra Effort option?– PAR run time can increase by a factor of two or more


Summary• Implement your design with global timing constraints and default

software options first– Then verify that your constraints are reasonable– Try increasing the Place & Route Effort Level– Consider applying path-specific constraints

• If unrelated logic is packed together, try timing-driven packing• Otherwise, try PAR with the Extra Effort option• If these methods do not work, then try MPPR


Where Can I Learn More?• Online Software Manuals: Development System Reference Guide

– MAP and PAR chapters


Xilinx Embedded Solutions


ISE Platform Studio IDE – Your Desktop SoC Factory

Optimized SWLibs and Drivers

libc.aXilinx

Micro-Kernel

ParameterizableHW IP

Your Code,Apps, OS…

Your CustomHW

PPC405

PPC405

4KB IOCMBRAM

4KB IOCMBRAM

8KB DOCMBRAM

8KB DOCMBRAM

DDRCntrl

DDRCntrl

32KBBRAM

32KBBRAM

JTAGJTAG

128MB DDR

SDRAM

128MB DDR

SDRAM

BRAMCntrl

BRAMCntrl

PLBArbiter

PLBArbiter

OPB<>

PLB

OPB<>

PLB

16450UART

16550UART

OPBArbiter

OPBArbiter

OPBGPIO

2KBBRAM

OPBPCI

OPB10/100 E-Net

BRAMCntrl

SerialPort

SerialPort

LEDs&

Buttons

LEDs&

ButtonsSerialPort

SerialPort

EthernetEthernet

32/33 PCI32/33 PCI

VxWorksBSP &Kernel

VxWorksBSP &Kernel

LinuxBSP &Kernel

LinuxBSP &Kernel

PPC405

PPC405

4KB IOCMBRAM

4KB IOCMBRAM

8KB DOCMBRAM

8KB DOCMBRAM

DDRCntrl

DDRCntrl

32KBBRAM

32KBBRAM

JTAGJTAG

128MB DDR

SDRAM

128MB DDR

SDRAM

BRAMCntrl

BRAMCntrl

PLBArbiter

PLBArbiter

OPB<>

PLB

OPB<>

PLB

16450UART16450UART

16550UART16550UART

OPBArbiter

OPBArbiter

OPBGPIOOPBGPIO

2KBBRAM2KB

BRAM

OPBPCI

OPBPCI

OPB10/100 E-Net

OPB10/100 E-Net

BRAMCntrl

BRAMCntrl

SerialPort

SerialPort

LEDs&

Buttons

LEDs&

ButtonsSerialPort

SerialPort

EthernetEthernet

32/33 PCI32/33 PCI

VxWorksBSP &Kernel

VxWorksBSP &Kernel

LinuxBSP &Kernel

LinuxBSP &Kernel

YourCustom

ComputingPlatform

Work the WayYou Want – GUI,Command Lines

or Both!

Work the WayYou Want – GUI,Command Lines

or Both!

GUIGUI

Bash (Unix-style) Shell with Tcl applications

and text input

Programmable Platform Design


PowerPC405 Core

Dedicated Hard IPFlexible Soft IP

RocketIO

Full system customization to meet performance, functionality, and cost goals

DCR Bus

UART GPIO On-ChipPeripheral

Hi-SpeedPeripheral

GB E-Net

e.g.Memory

Controller

ArbiterOn-Chip Peripheral BusOPB

Arbi

ter

Processor Local Bus

Instruction Data

PLB

DSOCMBRAM

ISOCMBRAM

Off-ChipMemory

ZBT SSRAMDDR SDRAM

SDRAM

BusBridge

IBM CoreConnect™on-chip bus standardPLB, OPB, and DCR

PowerPC-based Embedded Design


Flexible Soft IPMicroBlaze32-Bit RISC Core

UART 10/100E-Net

On-ChipPeripheral

Off-ChipMemory

FLASH/SRAM

LocalLink™FIFO Channels

0,1…….32

CustomFunctions

CustomFunctions

BRAM Local Memory

BusD-CacheBRAM

I-CacheBRAM

ConfigurableSizes

Arbi

ter

Processor Local Bus

Instruction Data

PLBBus

Bridge

PowerPC405 Core

Dedicated Hard IP

Arbi

ter

Processor Local Bus

Instruction Data

PLBBus

BridgeBus

Bridge

PowerPC405 Core

Dedicated Hard IP

PowerPC405 Core

Dedicated Hard IP

PowerPC405 Core

Dedicated Hard IPPossible inVirtex-II Pro

Hi-SpeedPeripheral

GB E-Net

e.g.Memory

ControllerHi-Speed

PeripheralHi-Speed

PeripheralGB

E-NetGB

E-Net

e.g.Memory

Controller

e.g.Memory

Controller

Arbi

ter OPB

On-Chip Peripheral Bus

MicroBlaze-based Embedded Design


Standard Embedded SWDevelopment Flow

CPU code in on-chip memory

CPU code in off-chip memory

Download to Board & FPGA

Standard FPGA HWDevelopment Flow

Data2BlockRAM

Bitstream

Download to FPGA

Synthesizer

Place & Route

Simulator

VHDL/Verilog

?

Compiler/Linker

(Simulator)

C Code

?

Object Code

Embedded Development Tool Flow

Debugger


More being added over time, stay tuned…

OSes

Tools

Linux

NetBSD

vxWorks 5.4/5.5

Neutrino

eCos

LinuxLinux

NetBSDNetBSD

vxWorks 5.4/5.5vxWorks 5.4/5.5

NeutrinoNeutrino

eCos µC Linux

µC/OS-II

Nucleus

ThreadX

µC LinuxµC Linux

µC/OS-IIµC/OS-II

Nucleus

ThreadXThreadX

Nucleus

ThreadX

µC/OS-II

µC Linux

3rd Party Support


Complete design solution for processing system HW

Complete design solution for processing system SW

Generation of bootable HW & SW design ensures a correct HW/SW interface

Complete set of optimized peripheral firmware and programming libraries

Optimized set of bus infrastructure and peripheral cores

GUI and Tcl-based, text-driven applications enable you to work the way you want

Common design environment for PowerPC™, MicroBlaze™ and mixed processor designs

Xilinx Programmable System Design Solution Provides :


PowerPC405 Core

Dedicated Hard IP300MHz

100MHzRef Clk In

DCM

Flexible Soft IP

10/100Enet MAC UARTLite

Off-ChipMemory

32MB SDRAM32MB SDRAM

Memory Controller

MemoryController

16KB BRAM16KB BRAM

DCR BusINTC

Arbi

ter

Instruction

Data100MHzProcessor Local Bus

ArbiterOn-Chip Peripheral Bus100MHz

BusBridge

IBM CoreConnect™On-chip bus standardPLB, OPB & DCR

PowerPC405 Core


100MHzRef Clk In

DCM

Flexible Soft IPPowerPC405 Core


100MHzRef Clk In

DCM

Flexible Soft IPPowerPC405 Core


100MHzRef Clk In

DCM

PowerPC405 Core

Dedicated Hard IP

PowerPC405 Core

Dedicated Hard IP

PowerPC405 Core


100MHzRef Clk In

DCMDCM

Flexible Soft IP

10/100Enet MAC UARTLite10/100Enet MAC

10/100Enet MAC UARTLiteUARTLite

Off-ChipMemory

32MB SDRAM32MB SDRAMOff-ChipMemory

32MB SDRAM32MB SDRAM

Memory Controller

MemoryController

16KB BRAM16KB BRAM

Memory ControllerMemory

ControllerMemory

ControllerMemory

Controller

16KB BRAM16KB BRAM16KB BRAM16KB BRAM

DCR BusINTC

DCR BusINTCINTC

Arbi

ter

Instruction


Arbi

ter

Instruction


Arbi

ter

Instruction


Arbi

ter

Instruction


Arbi

ter

Instruction



BusBridge


BusBridge

ArbiterOn-Chip Peripheral Bus100MHz ArbiterOn-Chip Peripheral Bus100MHz

BusBridge

BusBridge



Generated System

Embedded Solutions Demo


System Block Diagram

PPC

PLB2OPB

PLBBRAMCntlr

PLBBRAM

PLBBus

PLBBRAMCntlr

PLBBRAM

OPBBus

MY IPLCD

PSB

JTAG_PPC

Proc_Sys_Reset

DCM

UART

INTC

Timer

GPIO

GPIO

GPIO

LEDs

SWs


Additional Slides


XMDMB/PPC CycleAccurate ISSes

Others…

ppc-eabi-gdb

gdb remote protocol

TCP/IPsockets

gdb remote protocol

TCP/IPsockets

MB-GDBmb-gdb

Others…

PPC405 dbg port

RISCWatchProtocol overJTAG

MBdbg port

JTAG SerialXMD

Protocol

XMDStub

Tcl/Terminal Interface

Plumbing and synchronization between host-side application and:• Other host-side applications• Actual targetsUse of sockets and TCP/IPenables remote and localconnections

Tcl Interface enables:• Command line control of

debugging using Tcl capabilities• Complex verification and analyses

scripting

Simultaneous, multiple targets and applications

Xilinx Microprocessor Debug (XDM)


Custom HW Platform

RTOS or Application

L2 Driver

RTOS Adaptation LevelMemory managementThreads, ITCRTOS-specific calls Etc.

High Level DriverNon-blockingISR included,Maintains state Etc.

L1 Driver Low Level orLightweight Driver#defines for registersPolled mode blockingEtc.L0 Driver

L0 & L1 drivers are included for all HW IP peripherals

Enables automatic generation of stand-alone or RTOS BSP that matches the custom hardware platform

Hand-creating drivers to match and be optimized for the processor, bus structure and peripherals is a time-consuming task that involves HW and SW developer interaction. The EDK provides these as a push-button process – Xilinx has already done the work (source is provided as well)

Hardware-Software Integration


Basic Step 1, Kernel supportKernel scheduler matched to tool set

Debugger support

Required Step 2, Board SupportSpecific board bootable image, Serial

Desirable(Vendor, roll your own, services, etc.)

Step 3, FileSystem, Network Stack

Ethernet driver integration

As Needed(Vendor, roll your own, services, etc.)

Step4, Additional Driver Support I2C, GPIO,…..

Complete, automatic BSP generation (Steps 1-4) for VxWorks 5.4/5.5 on PowerPC and XMK on PowerPC &

MicroBlaze

Complete, automatic BSP generation (Steps 1-4) for VxWorks 5.4/5.5 on PowerPC and XMK on PowerPC &

MicroBlaze

RTOS Support Levels


• Lightweight kernel and libraries targeted to PowerPC and MicroBlaze

– Ships with the Embedded Development Kit – source included

– No royalties or extra charge for use– Components:

• Kernel – Process management,

Schedulers, IPC facilities, etc.• Net

– Lightweight TCP/IP network stack• File System / Memory File System

– Standard block open/close/read/write/chdir

– Memory implementation included

2,67242162452File

15,292

3,66940311,220

Net

15,239

5,9361439,160Kernel

Total .bss.data

.txt

(Total size is ALL services, on PowerPC an additional 8K vector section is required. Real systems could be smaller if they use less services)

Xilinx MicroKernel (XMK)


The Programmable Systems IDE

Source Code Editor

Source Code EditorSystem

Diagram View

System Diagram

ViewSystem Details View

System Details View

Integrated HW & SW System Development Tools

Integrated HW & SW System Development Tools

Platform Studio


• A wizard that build a default system with just a few mouse clicks

– Includes all connections and generates memory map– Ready to be downloaded to a target board and have

SW written for it• Data-driven extensibility

– New Xilinx Board Description (XBD) file (based on MHS)

– Defines all chip-level interconnect to board resources– By default, limits peripheral selection to what is

actually on the target board

Base System Builder


Select Target Board1

Select MB or PPC2

Configure CPU3

Note: Support for a generic board is in upcoming release. For now, you can target any system as the UCF file is the only board-specific item

Base System Builder Wizard


Configure IP4

Auto-Generated Memory Map

5Base HW Done!

6

Base System Builder Wizard


• A wizard that takes already existing IP and formats for inclusion in EDK.

– Core will show up in Add/Edit Cores dialog– Need to close project and reopen to see change

• Creates local project pcores directory structure

• Generates the pao and mpd files• Copies all necessary files into pcores

Start

1Identify source type

2

Done!

4

Bus Type

3

Import Peripheral Wizard


bram_block_v1_00_a dcm_module_v1_00_a (New) dcr_intc_v1_00_b dcr_v29_v1_00_a dsbram_if_cntlr_v1_00_a dsbram_if_cntlr_v2_00_a (New) dsocm_v10_v1_00_a (New) fit_timer_v1_00_a fsl_v20_v1_00_b isbram_if_cntlr_v1_00_a isbram_if_cntlr_v2_00_a (New) isocm_v10_v1_00_a jtagppc_cntlr_v1_00_a jtagppc_cntlr_v1_00_b (New) lmb_bram_if_cntlr_v1_00_b lmb_v10_v1_00_a microblaze_v2_00_a mii_to_rmii_v1_00_a opb2dcr_bridge_v1_00_a opb2plb_bridge_v1_00_c opb_atmc_v2_00_a opb_bram_if_cntlr_v1_00_a opb_bram_if_cntlr_v2_00_a opb_central_dma_v1_00_a (New)

opb_ddr_v1_00_b opb_emc_v1_10_a opb_emc_v1_10_b opb_ethernet_v1_00_m (New) opb_ethernetlite_v1_00_a opb_gpio_v1_00_a opb_gpio_v2_00_a (New) opb_hdlc_v1_00_b (New) opb_iic_v1_01_a opb_intc_v1_00_b opb_intc_v1_00_c opb_jtag_uart_v1_00_b opb_mdm_v1_00_b opb_mdm_v1_00_c opb_memcon_v1_00_a opb_opb_lite_v1_00_a opb_pci_v1_00_b opb_sdram_v1_00_c opb_spi_v1_00_b opb_sysace_v1_00_a opb_timebase_wdt_v1_00_a opb_timer_v1_00_b opb_uart16550_v1_00_c opb_uartlite_v1_00_b

opb_v20_v1_10_b plb2opb_bridge_v1_00_b plb_atmc_v1_00_a plb_bram_if_cntlr_v1_00_a plb_ddr_v1_00_b plb_ddr_v1_00_c plb_emc_v1_10_b plb_ethernet_v1_00_a (New) plb_gemac_v1_00_b (New) plb_rapidio_lvds_v1_00_a plb_sdram_v1_00_c plb_uart16550_v1_00_c plb_v34_v1_01_a ppc405_v1_00_a ppc405_v2_00_a (New) proc_sys_reset_v1_00_a util_bus_split_v1_00_a (New) util_flipflop_v1_00_a (New) util_reduced_logic_v1_00_a (New) util_vector_logic_v1_00_a (New)

Supported EDK IP


• CoreConnect™ bus infrastructure IP

– PLB2OPB Bridge– PLB & OPB Arbiter– PLB & OPB IPIF Interface

• Memory controllers– OPB Block Memory OPB

SDRAM, OPB DDR, OPB EMC, OPB ZBT

– PLB Block Memory, PLB SDRAM, PLB DDR

• Standard peripherals– OPB Timer / Counter, OPB

Watchdog Timer– OPB Uart-Lite, OPB JTAG

Uart, OPB GPIO, OPB SPI – OPB Interrupt Controller

• Additional IP– OPB System ACE

controller

Xilinx Developed,Delivered, and Supported

Processor IP Included as VHDL Source


– OPB Uart-16450 & OPB Uart-16550

– OPB HDLC– OPB IIC– OPB Ethernet 10-100 MAC &

Ethernet-Lite 10-100 MAC– OPB ATM Master

Utopia Level 2– OPB ATM Slave

Utopia Level 2

– OPB PCI 32 Bridge– OPB ATM Master

Utopia Level 3– OPB ATM Slave Utopia Level 3– PLB ATM Master

Utopia Level 2– PLB ATM Slave Utopia Level 2– PLB GMAC Ethernet– PLB RapidIO (Installs in to EDK)

Xilinx Developed,Delivered, and Supported

Processor IP Included as Evaluation


For LogiCORE IP that Xilinx Licenses ($$)• Evaluation IP in the EDK

– To evaluate $$ IP, you must buy the EDK– OPB 10/100 Ethernet MAC, OPB2PCI 32/33 Bridge, IIC, UART 16450/550,

ATM Utopia 2 & 3• EDK 6.1 install includes evaluation IP• Evaluation core can be treated in every way like its licensed counterpart

– Evaluation core can be processed through MAP, PAR and through bitstream generation

– Evaluation core will function in hardware for 6-8 hours• Re-configure device to reset clock Xilinx Developed,

Delivered, and Supported

IP Evaluation In The EDK


Xilinx IP Evaluation


The Xilinx Embedded Development Kit (EDK) includes an extensive list of IP to support designs using the IBM PowerPC hard processor core and the Xilinx MicroBlaze soft processor core.

EDK – Supported IP








DIAB XE C/C++ compiler– Benchmark leading PowerPC compiler – Ideal for applications that demand minimal code

size and maximum program performance– Integrated with XPS

SingleStep XE software debugger– Debugger for embedded PowerPC designs– Provides complete control over all PPC405 settings,

such as initial register values

visionPROBE II XE hardware debugger– Download and run time control for debugging PowerPC designs

(parallel port)• ProbeServer enables any SingleStep XE debugger host

(Solaris or PC) to connect to a networked lab PC

Wind River XE (Xilinx Edition)

Xilinx Confidential

High-Performance DSPin an FPGA Made Easy and Affordable

Xilinx ConfidentialXilinx XtremeDSP 2

Agenda• Why should I use FPGAs for DSP?• Which FPGAs for DSP?

– VirtexTM-II Series, SpartanTM-3• What DSP algorithms are available?• Which Design Tools should I use?

– Software– Hardware

• What’s next?



– Virtex-II Series, Spartan-3 • What DSP Algorithms are available?• Which Design Tools should I use?


• What’s Next?


FPGAs Mean Parallelism

Conventional DSP Device(Von Neumann architecture)

Data Out

RegData In

MAC unit....C0

Data Out

C1 C2 C255

FPGA

Reg0 Reg1 Reg2 Reg255Data In

All 256 MAC operations in 1 clock cycle256 Loops needed to process samples

256 Tap FIR Filter Example

Reason 1: FPGAs handle high computational workloads


FPGAs are Ideal for Multi-channel DSP designs?

LPF

Multi ChannelFilter

80MHzSamples

ch1

ch2

ch3

ch4

LPF

LPF

LPF

LPF

20MHzSamples

• FPGAs are also ideally suited for multi-channel DSP designs– Many low sample rate channels can be multiplexed (e.g. TDM) and

processed in the FPGA, at a high rate– Interpolation (using zeros) can also drive sample rates higher


Why FPGAs for DSP? (2)

Q = (A x B) + (C x D) + (E x F) + (G x H)

can be implemented in parallel

××

×× +

+

+

+

+

+

A

BC

DE

FG

H

Q

Reason 2: Tremendous Flexibility

But is this the only way in the FPGA?


××

×× +

+

+

+

+

+ ×+

+D Q

××

+

+

+

+D Q

Parallel Semi-Parallel Serial

Customize Architectures to Suit Your Ideal Algorithms

FPGAs allow Area (cost) / Performance tradeoffs

Optimized for?Speed Cost


Why FPGAs for DSP? (3)

DDCDDC

A/D

A/D

D/A

D/A

MACs

ControlDDCDDC

DUCDUC

DUCDUC

MACs

Control

DSPProcs.

DUCDUC

DUCDUC

DDCDDC DDCDDC

SDRAMAFE

FPGA DSP Card

Hundreds of Termination Resistors

PowerPC

SDRAM

SSTL3TranslatorsQuad

TRx

QuadTRx

ASSP

FPGA NetworkCard

SDRAMA/D

A/D

D/A

D/A

Control

Control

PL4

CORBA

PowerPC

MACs, DUCs, DDCs, Logic

PowerPC

PowerPCPowerPC

3.125 Gbps

ASSP

SDRAM

Reason 3: Lower System Cost through Integration



– Virtex-II Series, Spartan-3• What DSP Algorithms are available?• Which Design Tools should I use?


• What’s Next?


FPGAs as Signal Processors

• Industry’s lowest cost FPGA– 90nm process– 300mm wafers

• High performance DSP– Up to 104 hard embedded 18x18

multipliers– Up to 2MB of dual port block RAM– 32-bit MicroBlazeTM µP

• Industry’s most used FPGAs for DSP• Highest performance DSP

– Up to 556 hard embedded 18x18multipliers

– Up to 10MB of dual port block RAM– Up to 4 PPC 405 processors for control– 3.125 Gbps serial transceivers

• Ideal for multi-channel designs


DCE

DCELUT

LUT DCE

DCE

LUT

F0

F1

F2F3

0000 00001 00010 00011 0

1101 01110 01111 1

AND4

GatesRAM16x1S

DINCEA0A1A2A3

DOUT

CLK

Q0Q1

Q14Q15

Q0

Q15

SRL16EDin

A0A1A2A3

DoutCE

LUT

Flexible Architecture Allows LUTs, RAM or SRL16


Highest DSP Performance Using Virtex-II Pro

• FFT– 1024-point complex FFT (16-bit data & phase factors)

• 5.2 µs execution time (fclk=197 MHz, 2VP20-7, 2,764 logic slices)– FFTs with execution times in the 1 to 2 µs have also been

demonstrated (see www.dilloneng.com or www.altrabroadband.com)

• FEC– Viterbi decoder at OC3 data rates: 203 MHz– Interleaver/de-interleaver @fclk > 200 MHz– RS decoding OC192 rates (10 Gbps)

• 16 parallel RS decoders in a single XC2V3000-4• OC768 (40 Gbps) can also be achieved

– TPC Decoder at 155MHz (802.16, 802.16a)


Driving Down the Cost of High-Performance DSP

$400

$800

$1,200

$1,600

$2,000

1999 2000 2001 2002 2003 2004

Uni

t Pric

e

Estimates based on a 1M Gate part (75 GMACs/s performance today)

Industry’s first- 90nm process- 300mm wafer- DSP features

Industry’s first- 90nm process- 300mm wafer- DSP features

First FPGA with dedicated DSP features

First FPGA with dedicated DSP features

First FPGA with DSP features + µprocessors

First FPGA with DSP features + µprocessors


• 276 GMACs/s performance for $100* (3S4000)• Data Path - Rich DSP Fabric

– Up to 104 embedded multipliers, SRL16 logic, 1.8Mb of memory

– 60+ DSP algorithms built as IP Cores• Control Path

– MicroBlaze processor for control path• 68 DMIPs at 85 MHz

New Low Price-points Enable New DSP Applications

Enables Customer-Premise Equipment, Consumer, Automotive, Industrial Control Type Applications

* 8-bit MAC ** 2004 projections for 250Kunit volumes*250KU volume pricing in 2004


High-end Car Multimedia System

VGA Controller32-bit µP

LVDS Tx

Multi-Ch CAN

ControllerPHY

Rear-seatDisplays

SDRAM

Processor I/F

PHY

FrontDisplay

32-bit Embedded µP

8-bit µCDTCP

SHA-1

M6 Cipher

DCT/IDCT for MPEG-4

Motion Compensation

MPEG-4 H/W AccelerationSDRAM

PCI Controller

MDCT for MP3

Flash Controller

DDR Memory Controller

MMC/SD CF+

UART, I2C, SPI, PWM

1394 USB 2.0MOST

PeripheralsPeripheralsMemoryStick





• What’s Next?


DSP Algorithms for Xilinx FPGAs• Math Functions

– Add, Subtract, multiply, Cordic etc.

• Common DSP Functions– FFTs (64pt-16Kpt) - Configurable datapath, phase vectors, transform length– Correlators, Modulation, Demodulation, DDS etc.

• Filters,– MAC, DA, CIC etc.

• FEC– RS, Viterbi, TPC, (De)Interleavers, TCC, AWGN etc.

• Video/Imaging– DCT/IDCT, JPEG, JPEG2000, Color space conversion

• Cable Modem– DOCSIS ITU-T J.83 Modulator


Xilinx DSP Algorithms for an OFDM Receiver & Demodulator

InterpolatorInterpolator

Digital Down

Conversion

Digital Down

Conversion

Data in from channel Embedded

MultipliersCORDIC Core

FFT Core

CORDIC Core

•MAC-based FIR Filter Core•DDS Core

FEC Cores:•Reed-Solomon Decoder•Viterbi Decoder•De-interleaver•Turbo Product Code (TPC) Decoder

Frame Synchronization

Frame Synchronization

Remove Cyclic Prefix

Remove Cyclic Prefix FFTFFT

Channel Equalizer &

Detector

Channel Equalizer &

Detector

Channel EstimationChannel

Estimation

FECFEC

Sample Clock SynchronizationSample Clock

Synchronization

Frequency Synchronization

Frequency Synchronization


Advanced algorithms from Xilinx(DOCSIS ITU-T J.83 Modulator)

2 ch.RRC

a =0.18or

a =0.12

M PE GFram er

8b->7b&

FIFO

R S(128,122)

In te r-leaver

R ando-m izer TC M

Fram e C ontro ls

Prog . C ontro lsIn terleaver S electQ AM SelectLevel S elect

I

Q

I

Q

Data In

Optional

Cable

External Memory

Baseband (Bb) Processor Modulator


Digital Up Conversion• Interpolation LPF• Pulse Shaping (RRC)• Digital Pre-distortion

Xilinx DSP Algorithms in a 3G Base Station

Mobile Station

Rx Linear Amplifier

IF Mixer& BP Filter

Multi Carrier Power Amp.

(MCPA)

Low Power Antenna

Combiners

Digital Quadrature

Demod

Downlink Symbol Rate Processing• CRC coding• FEC coding• Rate matching• 1st Interleaving• TrCH radio frame generation• 2nd Interleaving

Uplink Symbol Rate Processing• 2nd De-interleaving• Radio frame deconstruction• Rate recovery• 1st De-interleaving• FEC decoding• CRC decoding

Downlink Chip Rate Processing• Power scaling• Dedicated phys channel generation• Phys channel combining• LFSR code generation• Spreading/scrambling

Uplink Chip Rate Processing• Searcher(for multipaths)• LFSR code generator• Channel estimation• Tracking rake receiver• Multipath combiner (max ratio)

ADC

DAC

Interface to Base

Station Controller

Downlink (Forward

Link)

Uplink (Reverse

Link)Rx

Tx

RF

I/Q

I/Q

DigitalUp/Down

Conversion

Base Band Processing

FEC CoresCDMA2000 TCC

EncoderConvolutional EncoderInterleaver

• MAC FIR for interpolation & pulse shaping

• DDS for pulse shaping

• MAC FIR for decimation & matched filtering

• DDS for matched filtering

FEC CoresCDMA2000 TCC Decoder, Viterbi Decoder, De-interleaver

Digital Down Conversion• Decimation LPF• Matched Filtering

Back Plane Drivers LVDS & Gigabit IO

Quadrature Modulation

QPSK


Advanced Algorithms from Xilinx CDMA2000/3GPP2 TCC

• Designed for use in 3G wireless base stations• Implements

– 3GPP2/1xEVDO/CDMA2000 specification– Full 3GPP2 Interleaver– MAX*, MAX or MAX SCALE algorithms

• Dynamically selectable number of iterations (1-16)

• Usable on Virtex-II Pro, Virtex-II and Spartan-3 FPGAs





• What’s Next?


4 DSP Design Flows Give You Total Flexibility

System Modeling

HDL

Synthesis

Implementation

FPGA Designers

WritingHDL

System Engineers

using MATLAB& Simulink

System Engineers

using MATLABonly

System Engineers

UsingCoWare

HDL AutomaticallyGenerated- SysGen

Leonardo SpectrumSynplify Pro or XST

ISE FoundationISE Foundation ISE Foundation ISE Foundation

Manual Entry of VHDL or Verilog

Leonardo Spectrum, Synplify Pro or XST

RTL AutomaticallyGenerated

MATLAB & AccelFPGA SPW

Leonardo SpectrumSynplify Pro or XST XST

Increasing Cost

MATLAB, Simulink & SysGen for DSP

HDL AutomaticallyGenerated


Push-button Performance using Xilinx System Generator for DSP

From Simulink to FPGA bitstream, at the push of a button


Unrivaled Capabilities on System Generator for DSP

System Generator for DSP v3.1 Allows Systems Designers to target external simulation engines- Hardware in the loop- HDL co-simulation

System Generator for DSP v3.1 Allows Systems Designers to target external simulation engines- Hardware in the loop- HDL co-simulation

HDL co-simulation using ModelSimAllows the user automatically invoke ModelSim and simulate his Verilog/VHDLdirectly from Simulink.

HDL co-simulation using ModelSimAllows the user automatically invoke ModelSim and simulate his Verilog/VHDLdirectly from Simulink.

Hardware in the loopco-simulationAllows the user to simulate part of his system on actual hardware. This means acceleration & verification

Hardware in the loopco-simulationAllows the user to simulate part of his system on actual hardware. This means acceleration & verification


Documented Reference Designs to Accelerate Your Learning

• 16-QAM receiver, including LMS based equalizer and carrier recovery loop

• A/D and delta-sigma D/A conversion• Concatenated FEC codec for DVB• Custom FIR filter reference library• Digital down converter for GSM• 2D discrete wavelet transform (DWT)

filter• 2D filtering using a 5x5 operator• Color space conversion• CORDIC reference design• Polyphase MAC-based FIR• Streaming FFT/IFFT• BER Tester using AWGN model


Partition Tasks Between Processor and DSP Fabric

Control Tasks

Control Tasks

FIR Filter

C++ Code Stack

Control Tasks

FIR Filter

FIR Filter FIR Filter

Processing timeTraditional

PowerPCProcessor

PowerPCProcessor

ExtremeProcessing™

FIR Engine (fabric/multipliers)

OCMRAMOCMRAM

3

+

2

+

0 1

+

n

+

PowerPC with Application-SpecificHardware Acceleration

The Virtex-II Pro Advantage


Use System Generator to Develop DSP Peripherals for OPB

OPB

Reloadable DA FIR Peripheral

UART Lite

PowerPC/MicroBlaze

Host PC(post-processing and filter design in Matlab)

Application Note XAPP264Using SysGen to Create CoreConnectTM Peripherals

• XAPP264 shows designers how to use Simulink & System Generator to create DSP peripherals that can connect to the OPB

– PowerPC – MicroBlaze

• This enables 32-bit control for XtremeDSP using:

– VirtexTM-II, Virtex-II ProTM

– Spartan-3• Still need EDK to program the

processor


HW Development Flow

2. Automatic HardwarePlatform Generation

HW Configuration

Bitstream

MHS

PlatGen

Xflow /ProjNav

Data2BRAM

Executable in on-chipmemory

Download to Board

SW Development Flow

Executablein off-chipmemory

?

2. Automatic SoftwareBSP/Library Generation

3. Software Compilation

SW Configuration

Executable

MSS

LibGen

RTOS/eOS

MicroBlaze/PPC

UART

Arbiter

GPIODownload to FPGA

GDB /XMD

Embedded Design Flow

Module in EDK

1. Specify Processor,Bus & Peripherals

1. Specify Software Architecture

3. Xilinx Implementation Flow


XtremeDSP Hardware Development Kit

• Developed with Nallatech• Includes:

– Motherboard populated with a Dime-II module– Nallatech FUSE Software– XtremeDSP Software Evaluation CD kit

• MATLAB/Simulink• Xilinx System Generator for DSP• Xilinx ISE• Synplify ProTM (Synplicity) & FPGA AdvantageTM (Mentor)

– User manual and example designs– $1995


XtremeDSP Development Kit Specifications

• Specifications– Virtex-II user FPGA: XC2V3000– 2 ADC channels

• AD6644 A/Ds (14-bits up to 65 MSPS)– 2 DAC channels

• AD9772A D/As (14-bits up to 160 MSPS)– Support for external clock + on board

oscillator + programmable clock– One bank of ZBT-SSRAM

(133MHz, 256 kbyte)– PCI & USB interface

• Supports Hardware in the Loop/HDL co-simulation with Xilinx System Generator for DSP

• Multiple Dime-II daughter boards available from Nallatech


• 40+ DSP development boards available today using Xilinx FPGAs (www.xilinx.com/dsp)– General Purpose– Software Defined Radio– Video/Imaging

• Many vendors support hardware-in-the loop/HDL co-simulation with Xilinx System Generator for DSP

What if the XtremeDSP Kit Doesn’t Meet Your Needs?





• What DSP Services & Technical Support will I get from Xilinx for DSP?

• What’s Next?


DSP Design Services, Training & Hotline Systems Expertise

FPGAs with DSP Functions Shortest Design Time Familiar Design Flows

Dedicated Field Specialists60+ Advanced DSP Cores 60+ DSP Development Boards

Highest Performance

• 50+ Field DSP Experts• Processor, I/O Experts too

• Comprehensive Library• Fast Turnaround• Exceptional Performance

The World’s Fastest Programmable DSP Solution

• Xilinx Design Services, Education and Support

Lowest Cost(90nm)


What’s Next?• Evaluate Xilinx System Generator for DSP

– Free 60 day eval CD kit or web download

• Try Xilinx IP cores in your next DSP design for free– Free eval on most pay cores

• Sign up for a Xilinx DSP Design Flow class– Implementation techniques or Design Flow

Visit DSP Central at www.xilinx.com/dsp