Advanced Xilinx Fpga Design With Ise

Advanced Xilinx FPGA
Design with ISE
Course Agenda
© 2002 Xilinx, Inc. All Rights Reserved

Agenda
Section 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
Agenda - 3 © 2002 Xilinx, Inc. All Rights Reserved

Agenda
Section 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
After completing this course, you will be able to:
• 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

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

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
CORE Generator System - 9 - 2 © 2003 Xilinx, Inc. All Rights Reserved

Optimize Your Design for
Xilinx Architecture
CORE Generator System

Objectives
After completing this module, you will be able to:
• Describe the differences between LogiCORE and AllianceCORE

solutions
• 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 • AllianceCORE solutions
– DSP functions – Peripherals
• Time skew buffers, FIR • DMA controllers
filters, correlators • Programmable interrupt
– Math functions controllers
• Accumulators, adders, • UARTs
multipliers, integrators, – Communications and
square root networking
– Memories • ATM
• Pipelined delay elements, • Reed-Solomon encoders /
single and dual-port RAM decoders
• Synchronous FIFOs • T1 framers
– PCI master and slave – Standard bus interfaces
interfaces, PCI bridge • PCMCIA, USB

Outline
• Introduction
• Summary

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
Core Overview tab provides version information
and a brief functional description
Parameters Web Links

tab allows tab provides
you to direct access
customize to related
the core Web pages
Contact tab provides
information about the vendor
Data sheet
access

CORE Data Sheets
• Performance
expectations (not shown)
Features
Functionality
Pinout
Resource utilization

Outline
• Introduction
• Summary

Schematic Design Flow
• Generate a core
.EDN
Generate
– Use the Edit → Project Core
&
Options to select a schematic symbol
.xco
symbol instead of HDL
Instantiate
templates
– Creates an EDIF file and
Implement Simulate
schematic symbol
• Instantiate symbol onto your
schematic
– Treated as a “black box” - no
underlying schematic
• Proceed with normal
schematic flow

HDL Design Flow
compxlib.exe
XilinxCoreLib
Compile library for
behavioral simulation
(one time only)
Generate
Core
.EDN
.VHD,
.VHO, .V
Core generation
.xco
.VEO and integration
Instantiate
Simulate Implement

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
• Introduction
• Summary

Skills 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

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow

CORE Generator
System Lab

Objectives
After completing this lab, you will be able to:
• 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 Flow
Step 1: Review the design
Step 2: Generate the core
Step 3: Instantiate block RAM core into Verilog or VHDL source
Step 4: Perform behavioral simulation

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
Timing Closure with Timing Analyzer - 2 © 2003 Xilinx, Inc. All Rights Reserved
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)
Timing Analyzer GUI
• 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
Cross Probing
• 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
Timing Report Structure
• 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
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
• Timing Reports
• Report Options
• Summary
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 dest
Location Delay type Delay(ns) Logical Resource(s)
------------------------------------------------- -------------------
U29.IQ1 Tiockiq 0.382 source
SLICE_X0Y65.F2 net (fanout=7) 1.921 net_1
SLICE_X0Y65.X Tilo 0.291 lut_1
SLICE_X15Y1.G2 net (fanout=1) 2.359 net_2
SLICE_X15Y1.Y Tilo 0.291 lut_2
SLICE_X15Y1.F2 net (fanout=1) 0.008 net_3
SLICE_X15Y1.X Tilo 0.291 lut_3
SLICE_X15Y2.DY net (fanout=1) 0.108 net_4
SLICE_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 Fanout
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.382 source
net (fanout=87) 4.921 net_1
Tilo 0.291 lut_1
Tilo 0.291 lut_2
Tilo 0.291 lut_3
Tdyck 0.001 dest
---------------------------- --------------------------------------
(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
---------------------------- -------------------
Tcko 0.314 source
Tilo 0.291 lut_1
Tilo 0.291 lut_2
Tilo 0.291 lut_3
Tilo 0.291 lut_4
Tilo 0.291 lut_5
Tilo 0.291 lut_6
Tdyck 0.001 dest
---------------------------- --------------------------------------
(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 Timing
Clock Path: clk to source_ff
---------------------------- -------------------
Tiopi 0.669 clk
clk_BUFGP/IBUFG
net (fanout=1) 0.019 clk_BUFGP/IBUFG
Tgi0o 0.802 clk_BUFGP/BUFG.GCLKMUX
clk_BUFGP/BUFG
net (fanout=226) 0.307 clk_BUFGP
---------------------------- ------------------------------
(81.9% logic, 18.1% route)
Data Path: source_ff to dest_pad

---------------------------- -------------------
Tcko 0.314 source_ff
Tilo 0.291 lut_1
Tioop 4.133 dest_pad_OBUF
dest_pad
---------------------------- ------------------------------
(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
• Timing Reports
• Report Options
• Summary
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
Timing Constraints Tab
• 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
Options 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
Filter Paths by Net 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
Path Tracing 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
Outline
• Timing Reports
• Report Options
• Summary
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
Summary
• 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
• 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
Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
Global Timing Constraints - 2 © 2003 Xilinx, Inc. All Rights Reserved

Timing Groups and OFFSET Constraints

Objectives
• Use the Constraints Editor to create groups of path endpoints

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

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

Global Constraint Review
• 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
FLOP1 FLOP2 FLOP3

ADATA OUT1
D Q D Q D Q
CLK
BUFG FLOP4 FLOP5
D Q D Q OUT2
BUS [7..0]
CDATA

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
FLOP1 FLOP2 FLOP3
ADATA OUT1
D Q D Q D Q
CLK
BUFG FLOP4 FLOP5
D Q D Q OUT2
BUS [7..0]
CDATA

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
• Introduction
• Creating Groups
• Summary

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 or
Output 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 versus
Output 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
NET_A
D Q D Q
FLOP1 FLOP2

Grouping by Instance Name
or Hierarchy
• Steps are the same
• Design Element Types are
different
– Instance Name: FFs, pads,
latches, RAMs
– Hierarchy: User levels, Xilinx-
created levels

Grouping by Clock Edge
• 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

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
D Q
reg
MYCTR D Q
reg
D Q
reg

Timing THRU Points
• Group nets or 3-state buffers
Step 1
• Use these groups to identify Enter TPTHRU Name
specific paths to be constrained
Step 2
Select Element Type
Step 3
Select Nets or 3-state
Buffers and click on Add

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 initial
clock 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 Using
Both Clock Edges
clk
2ns
10 ns 3ns 3ns
data_rising
data_falling
t = -3 0ns 2 5
• 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

OFFSET OUT Using
Both Clock Edges
8ns
clk 3ns
10 ns 3ns
data_rising
data_falling
t = 0ns 3 8
• 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

Outline
• Introduction
• Creating Groups
• Summary

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
IN D Q D Q D Q D Q
OUT
C C C C
CLK
RESET_A
RESET_B

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

• 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

Agenda


– Floorplanner

• Lab : IDT Flow
• 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 Design:

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

General Flow
Step 1: Enter Global Timing Constraints
Step 2: Implement and analyze timing

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
Advance Timing Constraints - 2 © 2003 Xilinx, Inc. All Rights Reserved


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

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
D Q D Q
OUT
CLK

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

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
PERIOD CLK_A PERIOD CLK_B
DQ D Q D Q D Q
OUT1
CLK_A
CLK_B

• 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
PERIOD CLK_A 5 ns
PERIOD CLK_B
D Q D Q D Q D Q
OUT1
CLK_A
CLK_B

• 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
• False Paths
• Summary

Multi-cycle Path Constraints
• Multi-cycle paths occur when
registers are not updated on
consecutive clock cycles
200 MHz 50 MHz
– Always at least one clock cycle
between updates
Typically, the registers are TC CE
–
CLK PRE2 COUT14
controlled by a clock enable
• A prescaled counter is one Q0 Q1 Q2 Q3 Q4 Q14 Q15
example
– Registers in COUT14 are
updated every 4 clock cycles
– Paths between these registers
are multi-cycle paths

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
• Summary

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
• False Paths
• Summary

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 Highest
– 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 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
• False Paths
• Summary

Skills Check

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
200 MHz 50 MHz
TC CE
CLK PRE2 COUT14
Q0 Q1 Q2 Q3 Q4 Q14 Q15

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?
200 MHz 50 MHz
TC CE
CLK PRE2 COUT14
Q0 Q1 Q2 Q3 Q4 Q14 Q15

Answers
• 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

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
Control Status
Register Register
Control_Enable Status_Enable
BIDIR_PAD(7:0)
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
Control Status
Registers Registers
BIDIR_PAD(7:0)
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
Control Status
Registers Registers
BIDIR_PAD(7:0)
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

• 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

Agenda


– Floorplanner

• Lab : IDT Flow
• 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 Design:

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 Flow
Step 1: Create a group OFFSET constraint
Step 2: Create multi-cycle path constraints
Step 3: Create path exception constraints
Step 4: Create I/O constraints
Step 5: Implement and analyze timing

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
Floorplanner - 2 © 2003 Xilinx, Inc. All Rights Reserved

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
edn, ngc ncf
ucf NGDBUILD
Floorplanner ngd
MAP
fnf
ncd, pcf
PAR
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
Design Hierarchy Placement
Displays color- Shows the
coded current design
hierarchical layout from the
Blocks. implementation
Traverse tools
hierarchy to view
any component in
the design
Design Nets
Lists all the nets in the Floorplan (in back)
design Shows current placement
constraints and design edits

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
2 Path
Pathappears
appears
1 Click
in
inFloorplanner
Floorplanner
Clickon
onpath
path
in Timing Analyzer
in Timing Analyzer

Outline
• Introduction
• PACE
• Summary
• Appendix:
– RPM Core

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 to
a 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 the
Current 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
• PACE
• Summary
• Appendix:
– RPM Core

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
• Horizontal data flow with vertical
bus alignment
– Carry logic runs vertically Bit 7
– Bidirectional data bus longlines Datapath
run horizontally
• 3-state enable lines run
vertically
– Control lines (CE, resets, etc)
are generally driven on vertical
long lines Bit 0
Datapath A+B C+D E+F
C_REG E_REG G_REG

Layout for Smaller FPGAs
General guidelines for chips with 100K system gates or less:
• I/O for control signals on the top or Control Signals

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

flow Data Flow
– Align area blocks to flow horizontally
– Allow enough room for carry chains
– Place block RAMs appropriately to align
with arithmetic logic
Control Signals

Layout for Larger FPGAs
For chips with 500K system gates or more:
• Use the same guidelines as you
Control Signals
would use for smaller chips
Control Signals
• In addition, consider the following:
– Group control signals and data Data Flow
buses near related internal logic
– High-fanout signals may be placed
near the middle of the chip, for
easy access to horizontal long
lines

Data Bus Layout
• Arithmetic functions with more MSB
than five bits typically utilize carry
logic
• Carry chains require specific
vertical orientation
– Affects both internal and I/O
layout
LSB

Interleaved Bus Layout
• Arithmetic functions involving two
or more buses will benefit from
interleaved pin constraints B(3)
A(3)
– For example: B(2)
• C <= A + B; or A(2)
C <= A * B; B(1)
A(1)
B(0)
A(0)

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 Constraints
2
1. Select the area group you want
to constrain
2. Click the Assign Area button
3. Click and drag to define the 1 3
area constraint
– Floorplanner estimates the
required area and will not
allow you to select an area
that is too small

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
There’s only room
for 4 block RAMs…
but, I need room for 8!
What do I do?
• In this situation, you are only interested in constraining the slices and
3-state buffers
– Hand-place the block RAMs and block multipliers

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
• PACE
• Summary
• Appendix:
– RPM Core

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)
Design
Hierarchy Package Pins
Displays Allows pin loc
color-coded specifications
hierarchical
blocks
Package Pins
Design Object List Legend
Displays elements
contained in the
group that are
selected in the Device Architecture
Design Hierarchy Allows area
window constraint
specification

Pin Constraints
• Pin constraints most easily made using PACE
Drag & Drop I/O to

Package Pin window
Specify I/O options in

Object List 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 Constraints
1. Select the area group that 2
you want to constrain
2. Click the Assign Area
1
button 3
3. 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

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
• Introduction
• PACE
• Summary
• Appendix:
– RPM Core

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
Design Hierarchy
Displays color-coded hierarchical
blocks. Traverse hierarchy to view
any component in design
Design Nets
Lists all nets in the design
Placement
Floorplan (in back) Shows the current design layout from the
Shows the current placement implementation tools
constraints and design edits

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

• 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
• Introduction
• PACE
• Summary
• Appendix:
– RPM Core
– Pseudo Guide-File with Floorplanner

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 Steps
Step 1: Define the logical function of your core in HDL
Step 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
• PACE
• Summary
• Appendix:
– RPM Core

MAP Limitations
• RPM sourcing locked flip-flops
• Constrained by Packing problems

RPM Sourcing Locked
Flip-Flops
• Relationally Placed Macros are components 8-Bit Inc-Dec
that have been assigned a specific shape with
8 Flip-flops
RLOC constraints
– Synthesized arithmetic components larger than
six bits may be RPMs
– All RPMs in your design are listed in Section 7
of the MAP report
• In this example, an 8-bit incrementer/decrementer
is driving 8 flip-flops to create a counter

RPM Sourcing Locked
Flip-Flops
• When the flip-flops are physically 8-Bit Inc-Dec 8 Flip-flops
constrained with LOC or RLOC,
MAP is unable to pack the Inc-Dec
and flip-flops together
– Creates extra delay in the datapath

RPM Sourcing Locked
Flip-Flops: Workarounds
• Remove the constraints from the 8-Bit Inc-Dec 8 registers
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

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
Slice R1C1 Slice R1C1

D Q D Q
F/G A MAP F/G A
H D Q
H
D Q
F/G F/G
B
D Q
B

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
B1
– Skew between bits of interrelated LUT FF
buses is minimized A1
– Nets do not cross each other B0
LUT FF
A0
VHDL: Verilog:
process ( clk ) always@(posedge CLK)
begin OUT <= A & B;
if ( clk' event and clk = '1' ) then
Q <= (A AND B);
end if;
end process;

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
6 7 6-7
Dual-Port 4 5 4-5 Arithmetic

RAM 2 3 Function
2-3
0 1 0-1

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
• Introduction
• PACE
• Summary
• Appendix:
– RPM Core

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

Skills Check

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
• Introduction
• PACE
• Summary
• Appendix:
– RPM Core

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: Reducing
Ground 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

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow

Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
Incremental & Modular Design Techniques - 2 © 2003 Xilinx, Inc. All Rights Reserved
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
Top-Level
Block Top
Sub-Block Sub-Block Sub-Block

Block A Block B Block C
Sub-Block Sub-Block Sub-Block Sub-Block

Block A1 Block A2 Block B1 Block B2
Why Use
Incremental 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 Top-Level
(Block A2) Block Top
• Use the previous implementation Sub-Block Sub-Block Sub-Block

information, map and par NCDs, Block A Block B Block C
as a guide file
– The guide file will match Block A1 Block A2 Block B1 Block B2
all previous routing and
placement information for the
unchanged blocks and redo
placement and routing for the
changed block (Block A2)
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
• Guide Files
• Summary
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
Top-Level
Block Top

Team C

Team A Team B
Why Use
Modular 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 Spectrum
of Flows
Divide and Conquer Methodologies
Area Groups Incremental Design Modular Design
•True
•Simplest
•Simplest
•Developed for quick
•Quick runtimes for •Truebottom-up
bottom-upflow:
flow:
•Changes runtimes for small modules implemented
•Changesstill
still small design modules
separately
implemented
“uncontrolled” design changes separately
“uncontrolled” changes •Most
•Simple
•Simpleflow
flow •Mostcomplex
complex
•Module
requirements
requirements •ModuleTSPECs
TSPECsare
are
required
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)
Chip Layout
Top-Level
Block Top
Block
A
Block
Block A Block B Block C C
Block
Sub-Block Sub-Block Sub-Block Sub-Block B
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
Skills Check
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
• Guide Files
• Summary
Incremental Design Flow
Incremental Design: Step 1
nPartition 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
nIn 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
Top-Level
Block Top


oSynthesize 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
pUse Floorplanner (or PACE) to layout AREA constraints for each of the
preserved blocks
– Use non-overlapping area constraints
q Implement 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
rAs changes are required, make changes incrementally: one module at
a time
– Resynthesize only the incremental block that changed
s Incremental 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
• Guide Files
• Summary
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)
• 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
• Implement and Publish Active Module
– Run MAP, PAR, and TRACE until timing is met:
map <design_name>.ngd
par -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>.ngd
par -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
• Guide Files
• Summary
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?
Block A1
• A large portion of the blocks in Block B2
the design should not include
global logic Block A2
• 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
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 Synthesis
LeonardoSpectrum
• 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>
Synplify
• 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
XST
• 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 Files
• Summary
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 file
3. 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 Design
Guide 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 regardless
of 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
• Guide Files
• Summary
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?
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
– 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
• 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
Agenda


– Floorplanner

• Lab : IDT Flow
• Lab : MDT Flow
Agenda

– ChipScope Pro
– Demo
Optional Topics
– DSP Solutions with System Generator
FPGA Editor - 2 © 2003 Xilinx, Inc. All Rights Reserved

Reduce Debug Time
FPGA Editor: Viewing and Editing a

Routed Design

Objectives
• 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
MAP
• Xilinx implementation flow

FPGA Editor
– Entry points for FPGA Editor NCD & PCF
PAR
• Placing and routing critical
components
NCD
– Before implementation (Post-MAP)
BITGEN
• Making minor changes
– After implementation (Post-PAR)
BIT
Remember to document the changes to your design, because

your netlist will not reflect the changes made by the FPGA Editor!
FPGA Editor
Push
Button
Menu Panel
Bar
Array List
Window Window
History World
Window Window

Navigating
• Zoom • Array window resources
• Use the World window to keep

track of your location on the die
when you are zoomed in

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
• Adding a Probe
• Summary

Viewing the Contents
of 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
• Adding a Probe
• Summary

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 a Probe
• Summary

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 Signals
Auto 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
– Click net
– Click subsequent nets
• Route the net

• Routes one net segment

Manual Routing Signals III
• Select object to route
– Click previously
routed segment
– Click site pin
• Route the net

• 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
• Adding a Probe
• Summary

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

• FPGA Editor Help
– http://support.xilinx.com Æ Software Manuals
– Help Æ Help Topics
• Tech Tips
– http://support.xilinx.com ÆTech Tips Æ Floorplanner & FPGA Editor

Outline
• Adding a Probe
• Summary

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 of
WIDEAND Macro
VHDL Verilog
--Declaration of Macros ---- -- Declaration of Macros -----
module WIDEAND (in1, in2, in3, in4,
component WIDEAND
XOUT)
port ( in1, in2, in3, in4 : in std_logic; input in1;
XOUT : out std_logic); input in2;
end component; input in3;
input in4;
-- Instantiation of Macros ----- output XOUT;
-- (port_map_name=>signal_name) endmodule
-- Instantiation of Macros -----
U1:WIDEAND port map (
in1=>W, in2=>X, in3=>Y, in4=>Z, U1(.in1 (W), .in2 (X), .in3 (Y), .in4 (Z),
XOUT=>PROD); .XOUT(PROD));

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 slices
in 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 Existing
Design 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

Agenda

– ChipScope Pro
• Demo
Optional Topics

FPGA Editor
Lab

Objectives
• 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:

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 On-Chip Debug
Solutions
Xilinx Confidential
Agenda

– ChipScope Pro
– Demo
Optional Topics
Presentation Name 2 Xilinx Confidential

Shorten Debug and Verification
Unleash 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) Use ChipScope Pro VIO cores to
add virtual DIP switches and LEDs to
– Stimulate and monitor logic in real-time any design
using virtual input and outputs
– Detect activity asynchronously or
Viterbi
MAC
synchronously on rising or falling clock
OPB GPIO
OPB Bus
Bridge
edges
PLB Bus
– Define and drive pulse trains to simulate ATM Utopia L2
Arbiter
input signal activity
• Integrated Bus Analysis (IBA)
– Access CoreConnect bus structures, the
interface between the PowerPC and
processor peripherals
Use ChipScope Pro IBA cores to monitor and
analyze PLB and OPB bus transactions

Enabling Logic Verification and
Debug
ChipScope Pro
VIRTEX-II PRO
JTAG
Probe ILA Block
points RAM
XC2VP20
FF1152
• 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

ChipScope Pro with Agilent Trace Core
Combining On-Chip Debug with Deep External Sample Storage
FPGA
Trace Port Analyzer
VIRTEX-II PRO ChipScope Pro
JTAG
ILA LAN
Probe Trace
ATC
points
XC2VP20
FF1152
• 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
System Complexity
ChipScope Pro Traditional

IBA Logic Analyzer
ILA with ATC Solution
ChipScope Pro ChipScope Pro

ILA ILA with ATC
Debug and Verification Requirements

Complete Solutions Available Today
• ChipScope Pro On-Chip Debug
Solution
– Free 30 Day Evaluation
– $695 Full version
www.xilinx.com/chipscopepro
• Agilent FPGA Trace Port Analyzer

– $7,295 Available Now
www.agilent.com/find/FPGA
Agenda

– ChipScope Pro
– Demo
Optional Topics
Course Summary - 2 © 2002 Xilinx, Inc. All Rights Reserved

Course Summary
Advance FPGA Design With Xilinx

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
Course Summary - 4 © 2002 Xilinx, Inc. All Rights Reserved

Power Estimation

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
Power Estimation - 3 © 2003 Xilinx, Inc. All Rights Reserved

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

Power Consumption Overview
• As devices get larger and faster, power
consumption goes up
Package Power
• First generation FPGAs had: Limit
Lower performance
PMAX
–
High Density
– Lower power requirements
– No package power concerns
• Today's FPGAs have: Low
Density
– Much higher performance Real World Design
Power Consumption
– Higher power requirements
Performance (MHz)
– 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
• Introduction
• Summary

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

CLB, RAM, and Multipliers

DCM and I/O

Outline
• Introduction
• Summary

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 Data
process 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 Report
Power summary: I(mA) P(mW)
----------------------------------------------------------------
Total estimated power consumption: 807
Vccint 1.50V: 160 240
Vccaux 3.30V: 100 330
Vcco33 3.30V: 72 237
(Additional breakdowns deleted)
Thermal summary:
----------------------------------------------------------------
Estimated junction temperature: 46C
250 LFM 43C
...
Ambient temp: 25C
Case temp: 43C
Theta J-A range: 26 - 26C/W
Decoupling Network Summary: Cap Range (uF) #

----------------------------------------------------------------
Capacitor Recommendations:
Total for Vccint : 8
470.0 - 1000.0 : 1
0.0470 - 0.2200 : 1
0.0100 - 0.0470 : 2
0.0010 - 0.0047 : 4
(Other power supplies deleted)

XPower Detailed Report
Power details:
-------------------------------------------------------------------------------
Clocks: Loads Loading(fF) C(pF) F(MHz) I(mA) P(mW)
-------------------------------------------------------------------------------
rd_clk_inst/IBUFG
Logic:
rd_clk_inst/CLKDLL 40 166.7 10.0 15.0
rd_clk_inst/BUFG 6 166.7 1.5 2.3
Nets:
rd_clk_dll 364 231 166.7 58.0 86.9
rd_clk_inst/CLK0 1 0 166.7 0.0 ~0.0
rd_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
• Introduction
• Summary

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

• 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

Objectives
• Increase design performance by using timing-driven packing and
advanced place & route options
Advanced Implementation Options - 17 - 3 © 2003 Xilinx, Inc. All Rights Reserved

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 Use
Advanced 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
• Introduction
• Summary

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 Timing Driven Pack
FF1 FF1
FF2
FF2

Turning on
Timing-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
• Introduction
• Summary

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 rest
Placed & Routed
Result #1
Mapped Place Route Placed & Routed

Design Result #2
Placed & Routed

Result #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 been
placed & routed before
– Skips the placement phase and goes directly to the router
Mapped Placed & Routed

Design Design
Place Route
Re-entrant Routed
Design

When to Use
Re-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 Mode
to Reentrant Route

Outline
• Introduction
• Summary

Skills Check

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

• Online Software Manuals: Development System Reference Guide
– MAP and PAR chapters

Xilinx Embedded
Solutions

Programmable Platform Design
ISE Platform Studio IDE – Your Desktop SoC Factory
GUI
GUI Your Custom
Your Code,
HW
Apps, OS…
Bash (Unix-style)
Parameterizable
Optimized SW Shell with Tcl
HW IP
Libs and applications
Drivers and text input
libc.a
Xilinx Work
WorkthetheWay
Way
Micro-Kernel LEDs
LEDs
128MB
128MB
You
YouWant
Want––GUI,
GUI,
Your
&& Serial Serial
Serial Serial DDR
DDR
Buttons
Buttons Port Port
Port Port SDRAM
SDRAM
OPB 16450 16550 DDR JTAG

Command
CommandLines
Lines
Custom
GPIO UART DDR JTAG
UART Cntrl
Cntrl VxWorks
VxWorks
or
orBoth!
4KB
4KBIOCM BSP
IOCM
BRAM BSP&&
Both!
BRAM Kernel
Kernel
Computing
Ethernet
Ethernet
OPB
10/100 E-Net
OPB
OPB
Arbiter
Arbiter
OPB
OPB
<>
<>
PLB
PLB
PLB
PLB
Arbiter
Arbiter
PPC
PPC
405
405
Linux
Linux
BSP
BSP&&
Platform
Kernel
Kernel
OPB
32/33
32/33PCI
PCI 8KB
PCI
2KB BRAM 32KB BRAM
BRAM 8KBDOCM
DOCM
BRAM Cntrl 32KB BRAM
BRAM
BRAM Cntrl
Cntrl
BRAM

PowerPC-based Embedded Design
RocketIO
DSOCM
Dedicated Hard IP ISOCM
BRAM PowerPC BRAM Flexible Soft IP
405 Core IBM CoreConnect™
DCR Bus on-chip bus standard
Instruction Data
PLB, OPB, and DCR
PLB OPB
Arbiter
Arbiter
Bus
Processor Local Bus On-Chip Peripheral Bus
Bridge
e.g.
Hi-Speed Memory GB On-Chip
UART GPIO
Peripheral Controller E-Net Peripheral
Off-Chip ZBT SSRAM Full system customization to meet

Memory DDR SDRAM performance, functionality, and
SDRAM cost goals

MicroBlaze-based Embedded Design
I-Cache
BRAM
Local Memory
MicroBlaze
BRAM Flexible Soft IP
Configurable
Bus 32-Bit RISC Core Sizes
D-Cache Possible in Dedicated Hard IP
BRAM Virtex-II Pro PowerPC
405 Core
Instruction Data
LocalLink™ OPB
Arbiter
FIFO Channels PLB
Arbiter
Bus
On-Chip Peripheral Bus Bridge
Processor Local Bus
0,1…….32
e.g.
Hi-Speed Memory GB
Custom Custom Peripheral Controller E-Net
Functions Functions
10/100 On-Chip
UART
E-Net Peripheral
Off-Chip FLASH/SRAM
Memory

Embedded Development Tool Flow
Standard Embedded SW Standard FPGA HW
Development Flow Development Flow
C Code VHDL/Verilog
Compiler/Linker Synthesizer
(Simulator) Simulator
Object Code Place & Route

Data2BlockRAM
? ?
Bitstream
CPU code in CPU code in
off-chip memory on-chip memory Download to FPGA
Download to Board & FPGA
Debugger

3rd Party Support
vxWorks 5.4/5.5 Nucleus

Nucleus
Neutrino
ThreadX
ThreadX
Linux
NetBSD µC/OS-II
µC/OS-II
eCos µCLinux
µC Linux
OSes
Tools
More being added over time, stay tuned…

Xilinx Programmable System Design
Solution Provides :
; 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

Embedded Solutions Demo
Generated System
Dedicated Hard IP
300MHz PowerPC Flexible Soft IP
405 Core
INTC
Instruction DCR Bus
Data
100MHz
Arbiter
Arbiter
100MHz Bus
Processor Local Bus
Bridge On-Chip Peripheral Bus
16KB BRAM
Memory Memory 10/100

Controller Controller UARTLite
Enet MAC
DCM
Off-Chip 32MB SDRAM IBM CoreConnect™

100MHz
Memory Ref Clk In
On-chip bus standard
PLB, OPB & DCR

System Block Diagram
OPB
Bus
PLB
Bus
UART
JTAG_PPC PLB2OPB
INTC
PPC
PLB Timer
PLB
BRAM
BRAM
Cntlr
Proc_Sys_
Reset GPIO PSB
PLB
PLB
BRAM GPIO
DCM BRAM LEDs
Cntlr
LCD MY IP GPIO SWs

Additional Slides

Xilinx Microprocessor Debug (XDM)
Plumbing and synchronization

between host-side application Tcl Interface enables:
and: • Command line control of
• Other host-side applications debugging using Tcl capabilities
• Actual targets • Complex verification and analyses
Use of sockets and TCP/IP scripting
enables remote and local
Tcl/Terminal Interface
connections
gdb remote gdb remote

protocol protocol
XMD
ppc-eabi-gdb
MB/PPC Cycle
MB-GDB
mb-gdb
TCP/IP Accurate ISSes
TCP/IP
sockets sockets
Others… RISCWatch
Protocol JTAG Serial Others…
overJTAG XMD
Protocol
PPC405 dbg port MB

dbg
Simultaneous, multiple port
XMDStub
targets and applications

Hardware-Software Integration
L0 & L1 drivers are

Enables automatic included for all HW IP
generation of stand-alone peripherals
or RTOS BSP that
matches the custom RTOS or Application RTOS Adaptation Level
hardware platform Memory management
Threads, ITC
Hand-creating drivers to match RTOS-specific calls
Etc.
and be optimized for the
processor, bus structure and L2 Driver High Level Driver
peripherals is a time-consuming Non-blocking
task that involves HW and SW ISR included,
developer interaction. The EDK Maintains state
provides these as a push-button Etc.
process – Xilinx has already
done the work (source is
L1 Driver Low Level or
provided as well) Lightweight Driver
#defines for registers
Polled mode blocking
L0 Driver Etc.
Custom HW Platform

RTOS Support Levels
Complete,
Complete,automatic
automaticBSP
BSPgeneration
generation
(Steps
(Steps 1-4) for VxWorks 5.4/5.5on
1-4) for VxWorks 5.4/5.5 on
PowerPC
PowerPC and XMK on PowerPC&&
and XMK on PowerPC
As Needed Step4, Additional MicroBlaze
(Vendor, roll your MicroBlaze
own, services, etc.)
Driver Support I2C, GPIO,…..
Desirable Step 3, FileSystem, Network

(Vendor, roll your
own, services, etc.)
Stack
Ethernet driver integration
Required Step 2, Board Support
Specific board bootable image, Serial
Basic Step 1, Kernel support

Kernel scheduler matched to tool set
Debugger support

Xilinx MicroKernel (XMK)
• 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: .txt.dat .bss Total
• Kernel
a 5,936 15,23
Kern 9,160 143
– Process management, el 9
Schedulers, IPC facilities, etc. Net 11,22 403 3,669 15,29
Net 0 2
•
File 2452 216 4 2,672
– Lightweight TCP/IP network stack
• File System / Memory File System (Total size is ALL services, on
PowerPC an additional 8K vector
– Standard block section is required. Real systems
open/close/read/write/chdir could be smaller if they use less
– Memory implementation included services)

Platform Studio
The Programmable Systems IDE

Source
Source
System Code
Code
System
Diagram Editor
Editor
Diagram
System View
View
System
Details
Details
View
View
Integrated
IntegratedHW
HW&&SW
SW
System
SystemDevelopment
DevelopmentTools
Tools

Base System Builder
• 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 Wizard
Select Target Board Select MB or PPC Configure CPU

1 2 3
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
Auto-Generated
Configure IP Memory Map Base HW Done!
4 5 6

Import Peripheral Wizard
• A wizard that takes already existing IP and formats for

inclusion in EDK.
– Core will show up in Add/Edit Cores dialog Done!
– Need to close project and reopen to see change 4
• Creates local project pcores directory
structure
• Generates the pao and mpd files
• Copies all necessary files into pcores
Start
1
Identify source type Bus Type
2 3

Supported EDK IP
bram_block_v1_00_a opb_ddr_v1_00_b opb_v20_v1_10_b
dcm_module_v1_00_a (New) opb_emc_v1_10_a plb2opb_bridge_v1_00_b
dcr_intc_v1_00_b opb_emc_v1_10_b plb_atmc_v1_00_a
opb_ethernet_v1_00_m (New) plb_bram_if_cntlr_v1_00_a
dcr_v29_v1_00_a
opb_ethernetlite_v1_00_a plb_ddr_v1_00_b
dsbram_if_cntlr_v1_00_a opb_gpio_v1_00_a plb_ddr_v1_00_c
dsbram_if_cntlr_v2_00_a (New) opb_gpio_v2_00_a (New) plb_emc_v1_10_b
dsocm_v10_v1_00_a (New) opb_hdlc_v1_00_b (New) plb_ethernet_v1_00_a (New)
fit_timer_v1_00_a opb_iic_v1_01_a plb_gemac_v1_00_b (New)
fsl_v20_v1_00_b opb_intc_v1_00_b plb_rapidio_lvds_v1_00_a
opb_intc_v1_00_c plb_sdram_v1_00_c
isbram_if_cntlr_v1_00_a
opb_jtag_uart_v1_00_b plb_uart16550_v1_00_c
isbram_if_cntlr_v2_00_a (New) opb_mdm_v1_00_b plb_v34_v1_01_a
isocm_v10_v1_00_a opb_mdm_v1_00_c ppc405_v1_00_a
jtagppc_cntlr_v1_00_a opb_memcon_v1_00_a ppc405_v2_00_a (New)
jtagppc_cntlr_v1_00_b (New) opb_opb_lite_v1_00_a proc_sys_reset_v1_00_a
lmb_bram_if_cntlr_v1_00_b opb_pci_v1_00_b util_bus_split_v1_00_a (New)
opb_sdram_v1_00_c util_flipflop_v1_00_a (New)
lmb_v10_v1_00_a
opb_spi_v1_00_b util_reduced_logic_v1_00_a
microblaze_v2_00_a opb_sysace_v1_00_a (New)
mii_to_rmii_v1_00_a opb_timebase_wdt_v1_00_a util_vector_logic_v1_00_a (New)
opb2dcr_bridge_v1_00_a opb_timer_v1_00_b
opb2plb_bridge_v1_00_c opb_uart16550_v1_00_c
opb_atmc_v2_00_a opb_uartlite_v1_00_b
opb_bram_if_cntlr_v1_00_a
opb_bram_if_cntlr_v2_00_a
opb_central_dma_v1_00_a (New)

Processor IP Included as
VHDL Source
• CoreConnect™ bus • Standard peripherals
infrastructure IP – OPB Timer / Counter, OPB
– PLB2OPB Bridge
Watchdog Timer
– OPB Uart-Lite, OPB JTAG
– PLB & OPB Arbiter
Uart, OPB GPIO, OPB SPI
– PLB & OPB IPIF Interface
– OPB Interrupt Controller
• Memory controllers
• Additional IP
– OPB Block Memory OPB
– OPB System ACE
SDRAM, OPB DDR, OPB
EMC, OPB ZBT controller
– PLB Block Memory, PLB
SDRAM, PLB DDR Xilinx Developed,

Delivered, and
Supported

Processor IP Included as Evaluation
– OPB Uart-16450 & OPB Uart- – OPB PCI 32 Bridge

16550 – OPB ATM Master
– OPB HDLC Utopia Level 3
– OPB IIC – OPB ATM Slave Utopia Level 3
– OPB Ethernet 10-100 MAC & – PLB ATM Master
Ethernet-Lite 10-100 MAC Utopia Level 2
– OPB ATM Master – PLB ATM Slave Utopia Level 2
Utopia Level 2 – PLB GMAC Ethernet
– OPB ATM Slave – PLB RapidIO (Installs in to EDK)
Utopia Level 2
Xilinx Developed,
Delivered, and
Supported

IP Evaluation In The EDK
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

Xilinx IP Evaluation

EDK – Supported IP
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.





Wind River XE (Xilinx Edition)
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

High-Performance DSP
in an FPGA
Made Easy and Affordable
Xilinx Confidential
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?
Xilinx XtremeDSP 2 Xilinx Confidential

Agenda
– Virtex-II Series, Spartan-3
• What DSP Algorithms are available?
– Software
– Hardware
• What’s Next?

FPGAs Mean Parallelism
Reason 1: FPGAs handle high computational workloads
Conventional DSP Device FPGA

(Von Neumann architecture)
Data In Data In
Reg Reg0 Reg1 Reg2 Reg255
C0 C1 C2 .... C255
MAC unit
Data Out Data Out
256 Loops needed to process samples All 256 MAC operations in 1 clock cycle
256 Tap FIR Filter Example
FPGAs are Ideal for
Multi-channel DSP designs?
20MHz ch1 80MHz
LPF Samples
Samples
LPF ch2
LPF
LPF ch3
Multi Channel
ch4 Filter
LPF
• 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)
Reason 2: Tremendous Flexibility
A
Q = (A x B) + (C x D) + (E x F) + (G x H) B
× +
C
can be implemented in parallel
D
× + +
Q
E +
F
× +
G
H
× +
But is this the only way in the FPGA?

Customize Architectures to Suit
Your Ideal Algorithms
Parallel Semi-Parallel Serial
× +
+
× + +
× + DQ
+
+ DQ
+
× + × + × +
× +
Speed Optimized for? Cost
FPGAs allow Area (cost) / Performance tradeoffs

Why FPGAs for DSP? (3)
Reason 3: Lower System Cost through Integration
Hundreds of
A/D Termination Resistors
SDRAM
AFE
A/D MACs
DSP MACs
Procs. SSTL3 ASSP
Quad C Translators
DDC
DDC DDC Control
DDC Control TRx
e rP
w
DDC DDC Po FPGA
DDC DDC Quad Network
SDRAM TRx
Card
D/A DUC
DUC DUC
DUC FPGA DSP
D/A DUC
DUC DUC
DUC Card
A/D SDRAM
A/D Control PL4 ASSP
PowerPC PowerPC
3.125 Gbps
MACs, DUCs,
D/A DDCs, Logic
PowerPC PowerPC
D/A Control CORBA
SDRAM

Agenda
– Software
– Hardware
• What’s Next?

FPGAs as Signal Processors
• Industry’s most used FPGAs for DSP • Industry’s lowest cost FPGA
• Highest performance DSP – 90nm process
– Up to 556 hard embedded 18x18 – 300mm wafers
multipliers • High performance DSP
– Up to 10MB of dual port block RAM – Up to 104 hard embedded 18x18
– Up to 4 PPC 405 processors for control multipliers
– 3.125 Gbps serial transceivers – Up to 2MB of dual port block RAM
• Ideal for multi-channel designs – 32-bit MicroBlazeTM µP

Flexible Architecture Allows
LUTs, RAM or SRL16
SRL16E
RAM16x1S
Gates
Din
0000
Q0 Q0
Q1
0
F0 0001 0
DIN
0010 DOUT
0
F1 CE Dout
0011 0
CE A0
AND4
D
F2 A1Q14
A2Q15 Q15
LUT CE D F3 A0 1101
A3 0
LUT CE A1 1110 0
A2 CLK
1111 1
A3
D
CE D
LUT
LUT CE

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
$2,000
$1,600 First
First FPGA
FPGA with
with
dedicated
dedicated DSP
DSP features
features
Unit Price
$1,200 First
First FPGA
FPGA with
with
DSP
DSP features
features ++ µprocessors
µprocessors
$800 Industry’s
Industry’s first
first
-- 90nm
90nm process
process
-- 300mm
300mm wafer
wafer
$400 -- DSP
DSP features
features
1999 2000 2001 2002 2003 2004
Estimates based on a 1M Gate part (75 GMACs/s performance today)

New Low Price-points Enable New
DSP Applications
• 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
Enables Customer-Premise Equipment, Consumer,

Automotive, Industrial Control Type Applications
* 8-bit*250KU
MAC volume**pricing
2004 inprojections
2004 for 250Kunit volumes

High-end Car Multimedia System
32-bit
Embedded µP
Rear-seat
Displays
Processor I/F
M6 Cipher
VGA Front
SHA-1 8-bit µC LVDS Display
32-bit µP Controller
DTCP Tx
MDCT for DDR Memory
MPEG-4 H/W Acceleration MP3 SDRAM
Controller SDRAM
DCT/IDCT Motion
for MPEG-4 Compensation Flash Multi-Ch
Controller CAN PHY
PCI Controller PHY
UART, I2C,
Controller
SPI, PWM
MemoryStick MMC/SD CF+ Peripherals 1394 USB 2.0

Peripherals
MOST

Agenda
– Software
– Hardware
• 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
Data in from Embedded CORDIC Core
channel Multipliers FFT Core
Digital Channel
Down Frame
Synchronization Estimation
Conversion
Channel
Interpolator Remove Cyclic Equalizer & FEC
FFT
Prefix Detector
•MAC- Frequency
based FIR Synchronization FEC Cores:
Filter Core •Reed-Solomon Decoder
•DDS Core •Viterbi Decoder
Sample Clock •De-interleaver
Synchronization •Turbo Product Code
CORDIC Core (TPC) Decoder

Advanced algorithms from Xilinx
(DOCSIS ITU-T J.83 Modulator)
External
Memory Optional
Data I 2 ch. I
RRC
In M PEG 8b->7 b RS In te r- R ando-
F ram er
& (12 8,
le a ver m izer
TCM a =0 .18 Cable
F IFO 12 2) Q or Q
a =0 .12
P ro g . C o n tro ls
Interlea ver S elect
Q A M S elect
Level S elect
F ram e C o n tro ls
Baseband (Bb) Processor Modulator

Xilinx DSP Algorithms in a 3G
Base Station • MAC FIR for decimation
& matched filtering
• DDS for matched filtering
Downlink
(Forward
Link) Digital Digital Down Conversion
Rx Linear IF Mixer&
ADC Quadrature • Decimation LPF
Uplink Amplifier BP Filter • Matched Filtering
(Reverse Rx Demod
Link)
Tx
Digital Up Conversion • MAC FIR for
Multi Carrier Low Power • Interpolation LPF interpolation &
Mobile pulse shaping
Power Amp. Antenna DAC • Pulse Shaping (RRC)
Station Digital •
• DDS for pulse
(MCPA) Combiners Up/Down
Digital Pre-distortion shaping
RF Conversion
FEC Cores
CDMA2000 TCC
Encoder Downlink Symbol Rate Processing Downlink Chip Rate Processing Quadrature
Convolutional Encoder • CRC coding • Power scaling
Interleaver • FEC coding • Dedicated phys channel generation
Modulation
• Rate matching • Phys channel combining QPSK
• 1st Interleaving • LFSR code generation
Interface to • TrCH radio frame generation • Spreading/scrambling
• 2nd Interleaving Back Plane Drivers
Base I/Q LVDS & Gigabit IO
Station
Controller Uplink Symbol Rate Processing Uplink Chip Rate Processing
• 2nd De-interleaving • Searcher(for multipaths)
• Radio frame deconstruction • LFSR code generator
• Rate recovery • Channel estimation
• 1st De-interleaving • Tracking rake receiver I/Q
• FEC decoding • Multipath combiner (max ratio)
• CRC decoding Base Band
Processing
FEC Cores
CDMA2000 TCC Decoder, Viterbi Decoder, De-interleaver

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

Agenda
– Software
– Hardware
• What’s Next?

4 DSP Design Flows Give You Total
Flexibility
FPGA System System System
Designers Engineers Engineers Engineers
Writing using MATLAB using MATLAB Using
HDL & Simulink only CoWare
System MATLAB, Simulink MATLAB &
SPW
Modeling & SysGen for DSP AccelFPGA
Manual Entry of HDL Automatically RTL Automatically HDL Automatically

HDL VHDL or Verilog Generated- SysGen Generated Generated
Leonardo Spectrum, Leonardo Spectrum Leonardo Spectrum

Synthesis XST
Synplify Pro or XST Synplify Pro or XST Synplify Pro or XST
ISE Foundation ISE Foundation ISE Foundation ISE Foundation

Implementation
Increasing Cost

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
Hardware in the loop
System Generator for
co-simulation
DSP v3.1
Allows the user to simulate
Allows Systems Designers
part of his system on actual
to target external simulation
hardware. This means
engines
acceleration & verification
- Hardware in the loop
- HDL co-simulation
HDL co-simulation using ModelSim

Allows the user automatically invoke
ModelSim and simulate his Verilog/VHDL
directly from Simulink.

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
C++ Code Stack FIR Engine
(fabric/multipliers)
Control Tasks 0 1 2 3 n
PowerPC
PowerPC OCM
FIR Filter Processor
Processor RAM
+ + + +
Control Tasks
PowerPC with Application-Specific
Hardware Acceleration
FIR Filter
Extreme The Virtex-II Pro Advantage
Processing™
Control Tasks
Traditional FIR Filter FIR Filter
Processing time

Use System Generator to Develop
DSP Peripherals for OPB
Application Note XAPP264
• XAPP264 shows designers Using SysGen to Create
how to use Simulink & CoreConnectTM Peripherals
System Generator to create

DSP peripherals that can
connect to the OPB Host PC
– PowerPC UART Lite (post-processing and
– MicroBlaze filter design in Matlab)
PowerPC/
• This enables 32-bit control for MicroBlaze
XtremeDSP using: Reloadable DA

FIR Peripheral
– VirtexTM-II, Virtex-II ProTM
OPB
– Spartan-3
• Still need EDK to program the
processor

Embedded Design Flow
SW Development Flow HW Development Flow
1. Specify Software 1. Specify Processor,

Architecture
RTOS/eOS Bus & Peripherals
SW Configuration MSS MHS HW Configuration
2. Automatic Software 2. Automatic Hardware

BSP/Library Generation LibGen PlatGen Platform Generation
3. Software Compilation Xflow / 3. Xilinx Implementation

ProjNav Flow
Executable
Executable in on-chip
memory
Executable Data2BRAM
in off-chip ? Bitstream
memory
GDB / GPIO
Download to Board Download to FPGA

XMD MicroBlaze/
PPC Arbiter
Module UART
in EDK

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

What if the XtremeDSP Kit Doesn’t
Meet Your Needs?
• 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

Agenda
– Software
– Hardware
• What DSP Services & Technical Support will
I get from Xilinx for DSP?
• What’s Next?

The World’s Fastest Programmable DSP Solution
FPGAs with DSP Functions Shortest Design Time Familiar Design Flows
Highest Lowest Cost

Performance (90nm)
60+ Advanced DSP Cores 60+ DSP Development Boards Dedicated Field Specialists
• Comprehensive Library • 50+ Field DSP Experts
• Fast Turnaround • Processor, I/O Experts too
• Exceptional Performance
DSP Design Services, Training & Hotline Systems Expertise
• Xilinx Design Services, Education and Support

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


Advanced Xilinx Fpga Design With Ise

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Advanced Xilinx Fpga Design With Ise

Caricato da

Copyright:

Formati disponibili

Advanced Xilinx FPGA

Design with ISE

© 2002 Xilinx, Inc. All Rights Reserved

Section 2 : Achieving Timing Closure

Section 3 : Improve Your Timing

Section 4 : Reduce Implementaion Time

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

Section 6 : On-Chip Verification and Debugging

Section 7 : Course Summary

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

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

Basic HDL knowledge (VHDL or Verilog)

Basic digital design knowledge

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

Section 2 : Achieving Timing Closure

Section 3 : Improve Your Timing

Section 4 : Reduce Implementaion Time

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

CORE Generator System

© 2003 Xilinx, Inc. All Rights Reserved

• Describe the differences between LogiCORE and AllianceCORE

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

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

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

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

• The CORE Generator  GUI lists the type of each core

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

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

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

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

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

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

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

Core type, version, device

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

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

Parameters Web Links

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

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

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

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

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

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

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

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

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

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

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

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

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

Section 2 : Achieving Timing Closure

Section 3 : Improve Your Timing

Section 4 : Reduce Implementaion Time

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

© 2003 Xilinx, Inc. All Rights Reserved

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

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

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

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

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

Section 2 : Achieving Timing Closure

Section 3 : Improve Your Timing

Section 4 : Reduce Implementaion Time