Synopsys

Synopsys FPGA Synthesis
User Guide
March 2014
https://solvnet.synopsys.com
LO
Preface
2014 Synopsys, Inc. Synopsys FPGA Synthesis User Guide
2 March 2014
Copyright Notice and Proprietary Information
Copyright 2014 Synopsys, Inc. All rights reserved. This software and
documentation contain confidential and proprietary information that is the
property of Synopsys, Inc. The software and documentation are furnished
under a license agreement and may be used or copied only in accordance
with the terms of the license agreement. No part of the software and
documentation may be reproduced, transmitted, or translated, in any form or
by any means, electronic, mechanical, manual, optical, or otherwise, without
prior written permission of Synopsys, Inc., or as expressly provided by the
license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the
documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and
proprietary rights notices, if any. Licensee must assign sequential numbers
to all copies. These copies shall contain the following legend on the cover
page:
This document is duplicated with the permission of Synopsys, Inc., for the
exclusive use of __________________________________________ and its
employees. This is copy number __________.
Destination Control Statement
All technical data contained in this publication is subject to the export
control laws of the United States of America. Disclosure to nationals of other
countries contrary to United States law is prohibited. It is the readers
responsibility to determine the applicable regulations and to comply with
them.
Preface
Synopsys FPGA Synthesis User Guide 2014 Synopsys, Inc.
March 2014 3
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks ()
Synopsys, AEON, AMPS, Astro, Behavior Extracting Synthesis Technology,
Cadabra, CATS, Certify, CHIPit, CoMET, CODE V, Design Compiler,
DesignWare, EMBED-IT!, Formality, Galaxy Custom Designer, Global
Synthesis, HAPS, HapsTrak, HDL Analyst, HSIM, HSPICE, Identify, Leda,
LightTools, MAST, METeor, ModelTools, NanoSim, NOVeA, OpenVera, ORA,
PathMill, Physical Compiler, PrimeTime, SCOPE, Simply Better Results, SiVL,
SNUG, SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity,
the Synplicity logo, Synplify, Synplify Pro, Synthesis Constraints Optimization
Environment, TetraMAX, UMRBus, VCS, Vera, and YIELDirector are regis-
tered trademarks of Synopsys, Inc.
Trademarks ()
AFGen, Apollo, ARC, ASAP, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves,
BEST, Columbia, Columbia-CE, Cosmos, CosmosLE, CosmosScope, CRITIC,
CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design
Analyzer, Design Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon
Access, Discovery, Eclypse, Encore, EPIC, Galaxy, HANEX, HDL Compiler,
Hercules, Hierarchical Optimization Technology, High-performance ASIC
Prototyping System, HSIMplus, i-Virtual Stepper, IICE, in-Sync, iN-Tandem,
Intelli, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty,
Libra-Passport, Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail,
Mars-Xtalk, Milkyway, ModelSource, Module Compiler, MultiPoint, ORAengi-
neering, Physical Analyst, Planet, Planet-PL, Polaris, Power Compiler,
Raphael, RippledMixer, Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT,
Star-SimXT, StarRC, System Compiler, System Designer, Taurus, Total-
Recall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet Buffer are
trademarks of Synopsys, Inc.
LO
Preface
4 March 2014
Service Marks (sm)
MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under
license.
ARM and AMBA are registered trademarks of ARM Limited.
Saber is a registered trademark of SabreMark Limited Partnership and is
used under license.
All other product or company names may be trademarks of their respective
owners.
Printed in the U.S.A
March 2014
March 2014 5
Contents
Chapter 1: Introduction
Synopsys FPGA and Prototyping Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
FPGA Implementation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Synopsys FPGA Tool Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Scope of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Document Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Starting the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
User Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 2: FPGA Synthesis Design Flows
Logic Synthesis Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Synplify Premier Synthesis Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Logic Synthesis with Enhanced Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Design Plan-Based Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Altera Graph-Based Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Altera Graph-Based Physical Synthesis with Design Planner . . . . . . . . . . . . . . 51
Design Plan-based Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Altera Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Guidelines for Physical Synthesis in Altera Designs . . . . . . . . . . . . . . . . . . . . . 58
Set up the Altera Physical Synthesis Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Run Logic Synthesis for the Altera Physical Synthesis Flow . . . . . . . . . . . . . . . 62
Validate Logic Synthesis Results for Altera Physical Synthesis . . . . . . . . . . . . 63
Run Altera Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Analyze Results of Altera Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Xilinx Physical Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
LO
Contents
6 March 2014
Physical Plus Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Setting Up I/O and Clock Component Constraints . . . . . . . . . . . . . . . . . . . . . . . 69
Creating Region Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Running Physical Plus Starting from RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Running Physical Plus Starting from EDIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Input/Output Files and Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Physical Plus Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Hierarchical Project Management Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Block-First Development Flow for Hierarchical Projects . . . . . . . . . . . . . . . . . . . 89
Top-First Development Flow for Hierarchical Projects . . . . . . . . . . . . . . . . . . . . 90
Bottom-Up Synthesis for Hierarchical Projects . . . . . . . . . . . . . . . . . . . . . . . . . 92
Top-Down Synthesis for Hierarchical Projects . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Mixed Block Synthesis for Hierarchical Projects . . . . . . . . . . . . . . . . . . . . . . . . 96
Prototyping Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapter 3: Preparing the Input
Setting Up HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Creating HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Using the Compiler Directives Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Using the Context Help Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Checking HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Editing HDL Source Files with the Built-in Text Editor . . . . . . . . . . . . . . . . . . . 111
Setting Editing Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Using an External Text Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Using Library Extensions for Verilog Library Files . . . . . . . . . . . . . . . . . . . . . . 117
Using Mixed Language Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Using the Incremental Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Using the Structural Verilog Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Working with Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
When to Use Constraint Files over Source Code . . . . . . . . . . . . . . . . . . . . . . . 129
Using a Text Editor for Constraint Files (Legacy) . . . . . . . . . . . . . . . . . . . . . . . 130
Tcl Syntax Guidelines for Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Checking Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Generating Constraint Files for Forward Annotation . . . . . . . . . . . . . . . . . . . . 132
Using Input from Related Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Contents
March 2014 7
Chapter 4: Setting up a Logic Synthesis Project
Setting Up Project Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Creating a Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Opening an Existing Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Making Changes to a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Setting Project View Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Updating Verilog Include Paths in Older Project Files . . . . . . . . . . . . . . . . . . . 143
Managing Project File Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Creating Custom Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Manipulating Custom Project Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Manipulating Custom Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Setting Up Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Setting Logic Synthesis Implementation Options . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Setting Device Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Setting Optimization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Specifying Global Frequency and Constraint Files . . . . . . . . . . . . . . . . . . . . . 158
Specifying Result Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Specifying Timing Report Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Setting Verilog and VHDL Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Specifying Attributes and Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Specifying Attributes and Directives in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . 170
Specifying Attributes and Directives in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . 171
Specifying Directives in a CDC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Specifying Attributes Using the SCOPE Editor . . . . . . . . . . . . . . . . . . . . . . . . 174
Specifying Attributes in the Constraints File . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Working with Hierarchical Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Creating Hierarchical Subprojects by Exporting Blocks . . . . . . . . . . . . . . . . . . 179
Creating Hierarchical Subprojects by Exporting Instances . . . . . . . . . . . . . . . 181
Creating Nested Subprojects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Generating Dependent File Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Working with Multiple Implementations in Hierarchical Projects . . . . . . . . . . . 194
Working with Multiple Instances and Parameterized Modules . . . . . . . . . . . . . 195
Allocating Resources for Instance-Based Subprojects . . . . . . . . . . . . . . . . . . 199
Setting Initial Timing Budgets for Instance-Based Subprojects . . . . . . . . . . . . 201
Generating Port Information for Instance-Based Subprojects . . . . . . . . . . . . . 203
Configuring Synthesis Runs for Hierarchical Projects . . . . . . . . . . . . . . . . . . . 205
Analyzing Synthesis Results for Hierarchical Projects . . . . . . . . . . . . . . . . . . . 209
Searching Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Identifying the Files to Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
LO
Contents
8 March 2014
Filtering the Files to Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Initiating the Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Search Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Archiving Files and Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Archive a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Un-Archive a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Copy a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Chapter 5: Setting up a Physical Synthesis Project
Setting up for Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Setting Options for Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Setting Synplify Premier Prototyping Tools Optimizations . . . . . . . . . . . . . . . . 228
Creating a Place and Route Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Specifying Altera Place-and-Route Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Specifying Xilinx Place-and-Route Options in a Tcl File . . . . . . . . . . . . . . . . . 237
Specifying Xilinx Place-and-Route Options in an opt File . . . . . . . . . . . . . . . . 240
Specifying Xilinx Global Placement Options . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Setting Constraints for Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Using Design Planner Floorplan Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Translating Pin Location Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Setting Physical Synthesis Constraints for Altera . . . . . . . . . . . . . . . . . . . . . . 248
Forward-Annotating Physical Synthesis Constraints . . . . . . . . . . . . . . . . . . . . . . . 249
Forward Annotating Altera Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Limitations Using the Physical Analyst and Technology View . . . . . . . . . . . . . 251
Backannotating Physical Synthesis Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Backannotating Place-and-Route Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Generating a Xilinx Coreloc Placement File . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Chapter 6: Specifying Constraints
Using the SCOPE Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Creating Constraints in the SCOPE Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Creating Constraints With the FDC Template Command . . . . . . . . . . . . . . . . 261
Specifying SCOPE Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Entering and Editing SCOPE Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Setting Clock and Path Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Defining Input and Output Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Specifying Standard I/O Pad Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Using the TCL View of SCOPE GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Guidelines for Entering and Editing Constraints . . . . . . . . . . . . . . . . . . . . . . . . 271
Contents
March 2014 9
Specifying Timing Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Defining From/To/Through Points for Timing Exceptions . . . . . . . . . . . . . . . . . 274
Defining Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Defining False Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Finding Objects with Tcl find and expand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Specifying Search Patterns for Tcl find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Refining Tcl Find Results with -filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Using the Tcl Find Command to Define Collections . . . . . . . . . . . . . . . . . . . . . 283
Using the Tcl expand Command to Define Collections . . . . . . . . . . . . . . . . . . 285
Checking Tcl find and expand Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Using Tcl find and expand in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Using Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Creating and Using SCOPE Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Creating Collections using Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Viewing and Manipulating Collections with Tcl Commands . . . . . . . . . . . . . . . 295
Converting SDC to FDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using the SCOPE Editor (Legacy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Entering and Editing SCOPE Constraints (Legacy) . . . . . . . . . . . . . . . . . . . . . 303
Specifying SCOPE Timing Constraints (Legacy) . . . . . . . . . . . . . . . . . . . . . . . 304
Defining Input and Output Constraints (Legacy) . . . . . . . . . . . . . . . . . . . . . . . 315
Defining False Paths (Legacy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Translating Altera QSF Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Specifying Xilinx Constraints (Legacy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Setting Clock Priority in Xilinx Designs (Legacy) . . . . . . . . . . . . . . . . . . . . . . . 321
Converting and Using Xilinx UCF Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Converting UCF Constraints Without Creating a Project . . . . . . . . . . . . . . . . . 325
Using Xilinx UCF Constraints in a Logic Synthesis Design . . . . . . . . . . . . . . . 326
Support for UCF Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Chapter 7: Synthesizing and Analyzing the Results
Synthesizing Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Running Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Running Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Using Up-to-date Checking for Job Management . . . . . . . . . . . . . . . . . . . . . . 337
Checking Log File Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Viewing and Working with the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Accessing Specific Reports Quickly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Accessing Results Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
LO
Contents
10 March 2014
Analyzing Results Using the Log File Reports . . . . . . . . . . . . . . . . . . . . . . . . . 352
Using the Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Checking Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Handling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Checking Results in the Message Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Filtering Messages in the Message Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Filtering Messages from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Automating Message Filtering with a Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . 361
Log File Message Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Handling Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Using Continue on Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Using Continue on Error During Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Analyzing Compilation Errors After Continue on Error . . . . . . . . . . . . . . . . . . . 368
Using Continue on Error for Compile Point Synthesis . . . . . . . . . . . . . . . . . . . 373
Validating Results for Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Analyzing Congestion After Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Chapter 8: Analyzing with HDL Analyst and FSM Viewer
Working in the Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Differentiating Between the HDL Analyst Views . . . . . . . . . . . . . . . . . . . . . . . . 387
Opening the Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Viewing Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Selecting Objects in the RTL/Technology Views . . . . . . . . . . . . . . . . . . . . . . . 394
Working with Multisheet Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Moving Between Views in a Schematic Window . . . . . . . . . . . . . . . . . . . . . . . 396
Setting Schematic View Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Managing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Exploring Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Traversing Design Hierarchy with the Hierarchy Browser . . . . . . . . . . . . . . . . 400
Exploring Object Hierarchy by Pushing/Popping . . . . . . . . . . . . . . . . . . . . . . . 401
Exploring Object Hierarchy of Transparent Instances . . . . . . . . . . . . . . . . . . . 407
Finding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Browsing to Find Objects in HDL Analyst Views . . . . . . . . . . . . . . . . . . . . . . . 408
Using Find for Hierarchical and Restricted Searches . . . . . . . . . . . . . . . . . . . . 410
Using Wildcards with the Find Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Combining Find with Filtering to Refine Searches . . . . . . . . . . . . . . . . . . . . . . 418
Using Find to Search the Output Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Crossprobing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Crossprobing within an RTL/Technology View . . . . . . . . . . . . . . . . . . . . . . . . . 421
Contents
March 2014 11
Crossprobing from the RTL/Technology View . . . . . . . . . . . . . . . . . . . . . . . . . 422
Crossprobing from the Text Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Crossprobing from the Tcl Script Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Crossprobing from the FSM Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Analyzing With the HDL Analyst Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Viewing Design Hierarchy and Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Filtering Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Expanding Pin and Net Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Expanding and Viewing Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Flattening Schematic Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Minimizing Memory Usage While Analyzing Designs . . . . . . . . . . . . . . . . . . . 445
Using the FSM Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Chapter 9: Analyzing Timing
Analyzing Timing in Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Viewing Timing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Annotating Timing Information in the Schematic Views . . . . . . . . . . . . . . . . . . 453
Analyzing Clock Trees in the RTL View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Viewing Critical Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Handling Negative Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Generating Custom Timing Reports with STA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Using Analysis Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Scenarios for Using Analysis Design Constraints . . . . . . . . . . . . . . . . . . . . . . 463
Creating an ADC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Using Object Names Correctly in the adc File . . . . . . . . . . . . . . . . . . . . . . . . . 468
Using Auto Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Results of Auto Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Using the Timing Report View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Analyzing Timing with Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Viewing Critical Paths in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Tracing Critical Paths Forward in Physical Analyst . . . . . . . . . . . . . . . . . . . . . 485
Tracing Critical Paths Backward in Physical Analyst . . . . . . . . . . . . . . . . . . . . 487
Chapter 10: Inferring High-Level Objects
Defining Black Boxes for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Instantiating Black Boxes and I/Os in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Instantiating Black Boxes and I/Os in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Adding Black Box Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
LO
Contents
12 March 2014
Adding Other Black Box Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Defining State Machines for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Defining State Machines in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Defining State Machines in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Specifying FSMs with Attributes and Directives . . . . . . . . . . . . . . . . . . . . . . . . 502
Implementing High-Reliability Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Implementing Distributed TMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Implementing Duplication with Comparison (DWC) . . . . . . . . . . . . . . . . . . . . . 510
Using Redundancy for I/O Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Using TMR or ECC for RAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Specifying Safe FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Error Monitoring for High Reliability Features . . . . . . . . . . . . . . . . . . . . . . . . . 522
Automatic RAM Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Block RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
RAM Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Inferring Block RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Inferring LUTRAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Inferring RAM with Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Distributed RAM Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Inferring Asymmetric RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Inferring Asymmetric RAM as a Black Box Model . . . . . . . . . . . . . . . . . . . . . . 546
Inferring Byte-Enable RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Inferring Byte-Wide Write Enable RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Initializing RAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Initializing RAMs in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Initializing RAMs in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Using Implicit Initial Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Inferring Shift Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Working with LPMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Instantiating Altera LPMs as Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Instantiating Altera LPMs Using VHDL Prepared Components . . . . . . . . . . . . 570
Instantiating Altera LPMs Using a Verilog Library . . . . . . . . . . . . . . . . . . . . . . 572
Chapter 11: Specifying Design-Level Optimizations
Tips for Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
General Optimization Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Optimizing for Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Optimizing for Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Contents
March 2014 13
Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Prerequisites for Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Pipelining the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Retiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Controlling Retiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Retiming Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Retiming Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
How Retiming Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
How Retiming Works With Synplify Premier Regions . . . . . . . . . . . . . . . . . . . 591
Preserving Objects from Being Optimized Away . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Using syn_keep for Preservation or Replication . . . . . . . . . . . . . . . . . . . . . . . 593
Controlling Hierarchy Flattening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Preserving Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Optimizing Fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Setting Fanout Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Controlling Buffering and Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Sharing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Inserting I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Optimizing State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Deciding when to Optimize State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Running the FSM Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Running the FSM Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Inserting Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Specifying Probes in the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Adding Probe Attributes Interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Chapter 12: Fast Synthesis
About Fast Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Using Fast Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Fast Synthesis and Other Synthesis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Chapter 13: Working with Compile Points
Compile Point Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Advantages of Compile Point Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Automatic and Manual Compile Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Nested Compile Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Compile Point Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
LO
Contents
14 March 2014
Compile Point Synthesis Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Compile Point Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Interface Logic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Interface Timing for Compile Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Compile Point Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Incremental Compile Point Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Forward-annotation of Compile Point Timing Constraints . . . . . . . . . . . . . . . . 643
Synthesizing Compile Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
The Automatic Compile Point Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
The Manual Compile Point Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Creating a Top-Level Constraints File for Compile Points . . . . . . . . . . . . . . . . 651
Defining Manual Compile Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Setting Constraints at the Compile Point Level . . . . . . . . . . . . . . . . . . . . . . . . 654
Analyzing Compile Point Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Using Automatic and Manual Compile Points Together . . . . . . . . . . . . . . . . . . 658
Using Compile Points with Other Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Combining Compile Points with Fast Synthesis . . . . . . . . . . . . . . . . . . . . . . . . 659
Combining Compile Points with Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . 660
Resynthesizing Incrementally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Resynthesizing Compile Points Incrementally . . . . . . . . . . . . . . . . . . . . . . . . . 661
Synthesizing Incrementally with Other Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Chapter 14: Working with IP Input
Generating IP with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Specifying FIFOs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Specifying RAMs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Specifying Byte-Enable RAMs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . 678
Specifying ROMs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Specifying Adder/Subtractors with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Specifying Counters with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
The Synopsys FPGA IP Encryption Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Overview of the Synopsys FPGA IP Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Encryption and Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Working with Encrypted IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Encrypting Your IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Encrypting IP with the encryptP1735.pl Script . . . . . . . . . . . . . . . . . . . . . . . . . 708
Encrypting IP with the encryptIP Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Specifying the Script Output Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Preparing the IP Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Contents
March 2014 15
Using DesignWare IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Using DesignWare Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
DW_Foundation_Arith Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Working with Synenc-encrypted IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Using Hyper Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Using Hyper Source for Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Using Hyper Source for IP Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Threading Signals Through the Design Hierarchy of an IP . . . . . . . . . . . . . . . 730
Working with Altera IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Using Altera LPMs or Megafunctions in Synthesis . . . . . . . . . . . . . . . . . . . . . . 734
Implementing Megafunctions with Clearbox Models . . . . . . . . . . . . . . . . . . . . 738
Implementing Megafunctions with Grey Box Models . . . . . . . . . . . . . . . . . . . . 748
Including Altera MegaCore IP Using an IP Package . . . . . . . . . . . . . . . . . . . . 756
Including Altera Processor Cores Generated in SOPC Builder . . . . . . . . . . . . 759
Working with SOPC Builder Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Setting up the SOPC Builder Synthesis Project . . . . . . . . . . . . . . . . . . . . . . . . 766
Defining SOPC Components as Black Boxes and White Boxes . . . . . . . . . . . 767
Importing Projects from Quartus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Importing Quartus Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Importing Quartus Designs with Megacore IPs . . . . . . . . . . . . . . . . . . . . . . . . 774
Importing Quartus Designs with Megafunctions/LPMs . . . . . . . . . . . . . . . . . . . 775
Troubleshooting Imported Quartus Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Working with Lattice IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Incorporating Vivado IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Generating Vivado IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Including Vivado IP RTL in the FPGA Synthesis Design . . . . . . . . . . . . . . . . . 782
Including IP Netlists that Were Synthesized Standalone . . . . . . . . . . . . . . . . . 785
Automatically Synthesizing and Including IP Netlists . . . . . . . . . . . . . . . . . . . . 789
Debugging XDC Constraint Conversion Messages . . . . . . . . . . . . . . . . . . . . . 793
Working with Xilinx IP Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Xilinx Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Secure and Non-secure Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
Including Xilinx Cores for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Converting Xilinx Projects with ise2syn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Converting Designs with the ise2syn Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
The ise2syn Conversion Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
Specifying EDK Cores as White Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
LO
Contents
16 March 2014
Chapter 15: Optimizing Processes for Productivity
Using Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Running Batch Mode on a Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Running Batch Mode with a Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Queuing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Working with Tcl Scripts and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Using Tcl Commands and Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Generating a Job Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Setting Number of Parallel Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Creating a Tcl Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Using Tcl Variables to Try Different Clock Frequencies . . . . . . . . . . . . . . . . . . 823
Using Tcl Variables to Try Several Target Technologies . . . . . . . . . . . . . . . . . 824
Running Bottom-up Synthesis with a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Automating Flows with synhooks.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Using Revision Control Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Chapter 16: Using Multiprocessing
Multiprocessing With Compile Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Setting Maximum Parallel Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
License Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Chapter 17: Clock Conversion
Working with Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Obstacles to Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Prerequisites for Gated Clock Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Defining Clocks Properly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Synthesizing a Gated-Clock Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Accessing the Clock Conversion Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Analyzing the Clock Conversion Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Interpreting Gated Clock Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Disabling Individual Gated Clock Conversions . . . . . . . . . . . . . . . . . . . . . . . . . 857
Instantiated Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Integrated Clock Gating Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Integrated Clock Gating Stability Latch Removal . . . . . . . . . . . . . . . . . . . . . . . 864
Using Gated Clocks for Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
OR Gates Driving Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
MUX or XOR Logic in Clock Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
Obstructions to Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Unsupported Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Other Potential Workarounds to Solve Clock-Conversion Issues . . . . . . . . . . 878
Contents
March 2014 17
Restrictions on Using Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Optimizing Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Enabling Generated-Clock Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Conditions for Generated-Clock Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 884
Generated-Clock Optimization Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Chapter 18: Floorplanning with Design Planner
Using Design Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Starting Design Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Copying Objects in the Design Planner Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 892
Controlling Pin Display in the Design Plan Editor . . . . . . . . . . . . . . . . . . . . . . . 893
Creating and Using a Design Plan File for Physical Synthesis . . . . . . . . . . . . 896
Assigning Pins and Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Assigning Pins Interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Assigning Clock Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Modifying Pin Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Using Temporary Pin Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Viewing Assigned Pins in Different Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Viewing Pin Assignment Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Working with Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Creating Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Using Region Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Moving and Sizing Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Viewing Intellectual Property (IP) Core Areas . . . . . . . . . . . . . . . . . . . . . . . . . 912
Assigning Logic to Top-level Chip Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Assigning Logic to Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Replicating Logic Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Checking Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Working with Altera Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Creating Design Planner Regions for Altera Designs . . . . . . . . . . . . . . . . . . . 920
Assigning Logic to Altera Design Planner Regions . . . . . . . . . . . . . . . . . . . . . 921
Working with Xilinx SSI Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Assigning Logic to SLR Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
SLR Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Working with Xilinx Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Creating Regions for Xilinx Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Using Process-Level Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Bit Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
LO
Contents
18 March 2014
Using Bit Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Bit Slice Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Chapter 19: Analyzing Designs in Physical Analyst
Analyzing Physical Synthesis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Analyzing Physical Synthesis Results Using Various Tools . . . . . . . . . . . . . . . 938
Running Multiple Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Checking Altera Pre-Placement Physical Synthesis Results . . . . . . . . . . . . . . 939
Using Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Opening the Physical Analyst Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Zooming in the Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Moving Between Views in the Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . 944
Using the Physical Analyst Context Window . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Displaying and Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Setting Visibility for Physical Analyst Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Displaying Instances and Sites in Physical Analyst . . . . . . . . . . . . . . . . . . . . . 948
Displaying Nets in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
Selecting Objects in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Querying Physical Analyst Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Viewing Properties in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Using Tool Tips to View Properties in Physical Analyst . . . . . . . . . . . . . . . . . . 960
Finding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Using Find to Locate Physical Analyst Objects) . . . . . . . . . . . . . . . . . . . . . . . . 962
Finding Physical Analyst Objects by Their Locations . . . . . . . . . . . . . . . . . . . . 966
Using Markers to Find Physical Analyst Objects . . . . . . . . . . . . . . . . . . . . . . . 967
Identifying Encrypted IP Objects in Physical Analyst . . . . . . . . . . . . . . . . . . . . 969
Crossprobing in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Crossprobing from the Physical Analyst View . . . . . . . . . . . . . . . . . . . . . . . . . 971
Crossprobing from a Text File to Physical Analyst . . . . . . . . . . . . . . . . . . . . . . 974
Crossprobing from the RTL View to Physical Analyst . . . . . . . . . . . . . . . . . . . 975
Crossprobing from the Technology View to Physical Analyst . . . . . . . . . . . . . 977
Analyzing Netlists in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Filtering the Physical Analyst View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Expanding Pin and Net Logic in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . 980
Expanding and Viewing Connections in Physical Analyst . . . . . . . . . . . . . . . . 985
Using Implementation Maps in Physical Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Implementation Maps Controls and Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Using the Routing Congestion Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Using the Block Component Utilization Map . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Contents
March 2014 19
Using the Block Input Utilization Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Using the Slack Distribution Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
Crossprobing from Implementation Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Chapter 20: Optimizing for Specific Targets
Optimizing Altera Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
Working with Altera PLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
Instantiating Special Buffers as Black Boxes in Altera Designs . . . . . . . . . . . . 999
Specifying Altera I/O Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Packing I/O Cell Registers in Altera Designs . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Specifying HardCopy and Stratix Companion Parts . . . . . . . . . . . . . . . . . . . . 1003
Specifying Core Voltage in Stratix III Designs . . . . . . . . . . . . . . . . . . . . . . . . 1004
Using LPMs in Simulation Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Improving Altera Physical Synthesis Performance . . . . . . . . . . . . . . . . . . . . . 1007
Working with Quartus II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Optimizing Lattice Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Instantiating Lattice Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Using Lattice GSR Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Inferring Carry Chains in Lattice XPLD Devices . . . . . . . . . . . . . . . . . . . . . . . 1013
Inferring Lattice PIC Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Controlling I/O Insertion in Lattice Designs . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Forward-Annotating Lattice Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
Optimizing Lattice iCE40 Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Using Sequential Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Using Combinational Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Handling Tristates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Handling I/Os and Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Optimizing Microsemi Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Using Predefined Microsemi Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Using Smartgen Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Working with Radhard Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Specifying syn_radhardlevel in the Source Code . . . . . . . . . . . . . . . . . . . . . . 1029
Optimizing Xilinx Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Designing for Xilinx Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Specifying Xilinx Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Specifying Global Sets/Resets and Startup Blocks . . . . . . . . . . . . . . . . . . . . 1036
Inferring Wide Adders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
Instantiating CoreGen Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Instantiating Virtex PCI Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
Packing Registers for Xilinx I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
LO
Contents
20 March 2014
Specifying Xilinx Register INIT Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Initializing Xilinx RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
Inserting Xilinx I/Os and Specifying Pin Locations . . . . . . . . . . . . . . . . . . . . . 1054
Working with Xilinx Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
Working with Xilinx Regional Clock Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Specifying RLOCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
Specifying RLOCs and RLOC_ORIGINs with the synthesis Attribute . . . . . . 1064
Using Clock Buffers in Virtex Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
Working with Clock Skews in Xilinx Virtex-5 Physical Designs . . . . . . . . . . . 1067
Instantiating Special I/O Standard Buffers for Virtex . . . . . . . . . . . . . . . . . . . 1068
Reoptimizing with EDIF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
Improving Xilinx Physical Synthesis Performance . . . . . . . . . . . . . . . . . . . . . 1070
Running Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
Working with Xilinx Place-and-Route Software . . . . . . . . . . . . . . . . . . . . . . . 1072
Chapter 21: Analyzing Power Activity
Activity Analysis Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Specifying Activity Analysis Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Assigning Activity Analysis Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Generating the SAIF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Activity Analysis Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
syn_state1_prob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
syn_trans_prob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Clock and Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Activity Analysis for Power Improvement Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Power Improvement Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Xilinx Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
XPower Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Xilinx Place and Route using SAIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
Xilinx Place and Route from Synplify Premier . . . . . . . . . . . . . . . . . . . . . . . . 1089
Chapter 22: Working with Synthesis Output
Passing Information to the P&R Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092
Specifying Pin Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092
Specifying Locations for Microsemi Bus Ports . . . . . . . . . . . . . . . . . . . . . . . . 1093
Specifying Macro and Register Placement . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Passing Technology Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Specifying Padtype and Port Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Generating Vendor-Specific Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Targeting Output to Your Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Contents
March 2014 21
Customizing Netlist Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
Invoking Third-Party Vendor Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Configuring Tool Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Invoking a Third-Party Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Chapter 23: Running Post-Synthesis Operations
Running P&R Automatically after Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Integrating Synthesis and Place-and-Route in One Run . . . . . . . . . . . . . . . . 1104
Running the Integrated Synthesis and Xilinx ISE Flow . . . . . . . . . . . . . . . . . 1105
Releasing the Synthesis License During Place and Route . . . . . . . . . . . . . . 1107
Running Altera Quartus II Incrementally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Quartus II Incremental Compilation Flow with Fast Fit . . . . . . . . . . . . . . . . . . 1108
Quartus II Incremental Compilation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Running Xilinx Vivado Place-and-Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Vivado Place-and-Route Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Setting Vivado Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
Running the Vivado Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Customizing Vivado Place and Route Options . . . . . . . . . . . . . . . . . . . . . . . . 1122
Running Vivado Incrementally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126
Running Xilinx ISE Incrementally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
Xilinx SmartGuide Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132
Xilinx Partition Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135
Xilinx Partition Flow for Versions Before ISE 12.1 . . . . . . . . . . . . . . . . . . . . . 1140
Working with the Identify Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Launching from the Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Handling Problems with Launching Identify . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Using the Identify Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Using Compile Points with the Identify Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Netlist Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
RTL-Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Specifying Netlist Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Using the edit_netlist Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
VIF Formal Verification Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Overview of the VIF Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Generating VIF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Using VIF with Cadence Conformal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160
Handling Equivalency Check Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
Simulating with the VCS Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
LO
Contents
22 March 2014
Using VCD/Identify with HDL Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Using the VCD-HDL Analyst Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Using the Identify-HDL Analyst Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Extracting VCS Test Benches for Submodules . . . . . . . . . . . . . . . . . . . . . . . 1189
Chapter 24: Verifying Results with Formality
Overview of the Formality Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196
The Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198
Verifying the Design with Formality Equivalence Checking . . . . . . . . . . . . . . 1198
Generating VIF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1201
The svf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204
Finite State Machine Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205
Verifying a Finite State Machine Design Example . . . . . . . . . . . . . . . . . . . . . 1205
RTL Code Example for a Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . 1206
FSM Tcl File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
FSM svf File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Tips and Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Guidelines for Successful Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Writing RTL for Verification used in ASIC Prototyping . . . . . . . . . . . . . . . . . . 1211
Limitations to Verification with Formality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214
Verification Mode Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215
Chapter 25: Prototyping
Partitioning ASIC Designs for Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218
Converting ASIC Designs for FPGA Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . 1220
General Guidelines for Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
Identifying FPGA-Hostile RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
Converting SoC Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Converting Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Converting Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Converting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223
Checking Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Importing VCS Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Getting an Initial Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225
Ensuring Fast Turnaround for Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227
Optimizing QoR for Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Debugging Prototype Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
Inspecting Errors Visually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
Contents
March 2014 23
Addressing Common Synthesis Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Debugging by Probing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1232
Cosimulating with UMRBus and HAPS-70/HAPS-60 . . . . . . . . . . . . . . . . . . . 1233
Running Co-Emulation with SCE-MI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
LO
Contents
24 March 2014
March 2014 25
CHAPTER 1
Introduction
This chapter provides an overview of the Synopsys
Synplify
, Synplify Pro
,
and Synplify
Premier tools for FPGA synthesis.

Synopsys FPGA and Prototyping Products, on page 26
Scope of the Document, on page 31
Getting Started, on page 32
User Interface Overview, on page 34
Throughout the documentation, features and procedures described apply to
all tools, unless specifically stated otherwise.
LO
Chapter 1: Introduction Synopsys FPGA and Prototyping Products
26 March 2014
Synopsys FPGA and Prototyping Products
The following figure displays the Synopsys FPGA and Prototyping family of
products.
FPGA Implementation Tools
The Synplify Pro and Synplify Premier products are RTL synthesis tools
especially designed for FPGAs (field programmable gate arrays) and CPLDs
(complex programmable logic devices).
Synopsys FPGA and Prototyping Products Chapter 1: Introduction
March 2014 27
Synplify Pro Synthesis Software
The Synplify Pro FPGA synthesis software is the de facto industry standard
for producing high-performance, cost-effective FPGA designs. Its unique
Behavior Extracting Synthesis Technology
(B.E.S.T.) algorithms, perform

high-level optimizations before synthesizing the RTL code into specific FPGA
logic. This approach allows for superior optimizations across the FPGA, fast
runtimes, and the ability to handle very large designs. The Synplify Pro
software supports the latest VHDL and Verilog language constructs,
including SystemVerilog and VHDL 2008. The tool is technology independent
allowing quick and easy retargeting between FPGA devices and vendors from
a single design project.
Synplify Premier Synthesis Software
The Synplify Premier functionality is a superset of the Synplify Pro tool,
providing the ultimate FPGA implementation and debug environment. It
includes a comprehensive suite of tools and technologies for advanced FPGA
designers, and also serves as the synthesis engine for ASIC prototypers
targeting single FPGA-based prototypes.
The Synplify Premier product offers both FPGA designers and ASIC proto-
typers targeting single FPGAs with the most efficient method of design imple-
mentation and debug. On the design implementation side, it includes
functionality for timing closure, logic verification, IP usage, ASIC compati-
bility, and DSP implementation, as well as a tight integration with FPGA
vendor back-end tools. On the debug side, it provides for in-system verifi-
cation of FPGAs which dramatically accelerates the debug process, and also
includes a rapid and incremental method for finding elusive design problems.
Synopsys FPGA Tool Features
This table distinguishes between major functionality in the Synplify Pro,
Synplify, Synplify Premier, and Synplify Premier with Design Planner
products.
LO
28 March 2014
Synplify Synplify
Pro
Synplify
Premier
Synplify
Premier DP
Performance
Behavior Extracting Synthesis
Technology
(BEST
)
x x x x
Vendor-Generated Core/IP
Support (certain technologies)
x x x
FSM Compiler x x x x
FSM Explorer x x x
Gated Clock Conversion x x x
Register Pipelining x x x
Register Retiming x x x
SCOPE
Constraint Entry x x x x
High reliability features x x x
Integrated place-and-route x x x x
Analysis
HDL Analyst Option x x x
Timing Analyzer
Point-to-point
x x x
FSM Viewer x x x
Crossprobing x x x
Probe Point Creation x x x
Identify Instrumentor x x x
Identify Debugger x x
Power analysis (SAIF) x x
Physical Design
Design Plan File x
Logic Assignment to Regions x
Synopsys FPGA and Prototyping Products Chapter 1: Introduction
March 2014 29
Area Estimation and Region
Capacity
x
Pin Assignment x
Physical Optimizations x
Physical Synthesis x x
Physical Analyst x x
Synopsys DesignWare
Foundation Library
x x
Runtime
Hierarchical Design x x x
Enhanced Optimization x x
Fast Synthesis x x
Multiprocessing x x
Compile on Error x x
Team Design
Mixed Language Design x x x
Compile Points x x x
Hierarchical Design x x x
True Batch Mode (Floating
licenses only)
x x x
GUI Batch Mode (Floating
licenses)
x x x x
Batch Mode P&R - x x x
Back-annotation of P&R Data - - - x
Formal Verification x Logic
synthesis
mode
Logic synthesis
mode
Identify Integration Limited x x x
Synplify Synplify
Pro
Synplify
Premier
Synplify
Premier DP
LO
30 March 2014
Back-annotation of P&R Data x
Design Environment
Text Editor View x x x x
Watch Window x x x
Message Window x x x
Tcl Window x x x
Multiple Implementations x x x
Vendor TechnologySupport x x Selected Selected
Prototyping Features
Runtime features x x
Compile Points x x x
Gated Clock Conversion x x
Compile on Error x x
Synplify Synplify
Pro
Synplify
Premier
Synplify
Premier DP
Scope of the Document Chapter 1: Introduction
March 2014 31
Scope of the Document
The following explain the scope of this document and the intended audience.
The Document Set
This user guide is part of a document set that includes a reference manual
and a tutorial. It is intended for use with the other documents in the set. It
concentrates on describing how to use the Synopsys FPGA software to
accomplish typical tasks. This implies the following:
The user guide only explains the options needed to do the typical tasks
described in the manual. It does not describe every available command
and option. For complete descriptions of all the command options and
syntax, refer to the User Interface Overview chapter in the Synopsys
FPGA Synthesis Reference Manual.
The user guide contains task-based information. For a breakdown of
how information is organized, see Getting Help, on page 32.
Audience
The Synplify, Synplify Pro, and Synplify Premier software tools are targeted
towards the FPGA system developer. It is assumed that you are knowledge-
able about the following:
Design synthesis
RTL
FPGAs
Verilog/VHDL
Physical Synthesis
LO
Chapter 1: Introduction Getting Started
32 March 2014
Getting Started
This section shows you how to get started with the Synopsys FPGA synthesis
software. It describes the following topics, but does not supersede the infor-
mation in the installation instructions about licensing and installation:
Starting the Software, on page 32
Getting Help, on page 32
Requesting Technical Support, on page 33
Starting the Software
1. If you have not already done so, install the Synopsys FPGA synthesis
software according to the installation instructions.
2. Start the software.
If you are working on a Windows platform, select
Programs->Synopsys->product version from the Start button.
If you are working on a UNIX platform, type the appropriate
command at the command line:
synplify
synplify_pro
synplify_premier
synplify_premier_dp
The command starts the synthesis tool, and opens the Project window. If
you have run the software before, the window displays the previous
project. For more information about the interface, see the User Interface
Overview chapter of the Reference Manual.
Getting Help
Before you call Synopsys Support, look through the documented information.
You can access the information online from the Help menu, or refer to the PDF
version. The following table shows you how the information is organized.
Getting Started Chapter 1: Introduction
March 2014 33
Requesting Technical Support
To request assistance from Technical Support for the Synopsys FPGA
synthesis products, use the SolvNet Online Support utility an online
web-based interface from which you can submit your request form and
attach project files. This is the preferred mechanism for contacting Technical
Support and may facilitate a faster response than requesting support
through email.
You can access SolvNet Online Support in one of these ways:
From the tool: Tech-Support->Submit Support Request. This opens a wizard
that walks you through the process of making a request and attaching
related files from your project.
From the tool: Tech-Support->Web Support.
Through the link on the web page:
https://solvnet.synopsys.com.
For help with... Refer to the...
Using software features Synopsys FPGA Synthesis User Guide
How to... Synopsys FPGA Synthesis User Guide,
application notes on the support web site
Flow information Synopsys FPGA Synthesis User Guide,
application notes on the support web site
Error messages Online help (select Help->Error Messages)
Licensing Synopsys SolvNet Website
Attributes and directives Synopsys FPGA Synthesis Reference Manual
Synthesis features Synopsys FPGA Synthesis Reference Manual
Language and syntax Synopsys FPGA Synthesis Reference Manual
Tcl syntax Online help (select Help->Tcl Help)
Tcl synthesis commands Synopsys FPGA Synthesis Reference Manual
Product updates Synopsys FPGA Synthesis Reference Manual
(Web menu commands)
LO
Chapter 1: Introduction User Interface Overview
34 March 2014
User Interface Overview
The user interface (UI) consists of a main window, called the Project view, and
specialized windows or views for different tasks. For details about each of the
features, see Chapter 2, User Interface Overview of the Synopsys FPGA
Synthesis Reference Manual. The Synplify Pro and Synplify Premier tools have
the same standard interface, while Synplify uses a different interface.
Synplify Pro and Synplify Premier Standard Interface
Tabs to access
views
Watch Window
Status
Tcl Script/Messages Window
Button Panel
Toolbars
Project Management view
Implementation Results view
User Interface Overview Chapter 1: Introduction
March 2014 35
Synplify Interface
The following figure shows you the Synplify interface.
Implementation
Menus
Toolbars
Other options
Buttons
Status
Results view
Project view
Tab to access
Project view
LO
Chapter 1: Introduction User Interface Overview
36 March 2014
March 2014 37
CHAPTER 2
FPGA Synthesis Design Flows
This describes the following tool flows:
Logic Synthesis Design Flow, on page 38
Synplify Premier Synthesis Design Flows, on page 41
Altera Physical Synthesis, on page 57
Xilinx Physical Plus, on page 66
Hierarchical Project Management Flows, on page 87
Prototyping Flow, on page 98
LO
Chapter 2: FPGA Synthesis Design Flows Logic Synthesis Design Flow
38 March 2014
Logic Synthesis Design Flow
The Synopsys FPGA tools synthesize logic by first compiling the RTL source
into technology-independent logic structures, and then optimizing and
mapping the logic to technology-specific resources. After logic synthesis, the
tool generates a vendor-specific netlist and constraint file that you can use as
inputs to the place-and-route (P&R) tool.
The following figure shows the phases and the tools used for logic synthesis
and some of the major inputs and outputs. You can use the Synplify, Synplify
Pro, or Synplify Premier synthesis software for this flow. The interactive
timing analysis, physical analysis, and backannotation steps that are shown
in gray are optional. Although the flow shows the vendor constraint files as
direct inputs to the P&R tool, you should add these files to the synthesis
project for timing black boxes.
Place & Route
Post P&R Back-annotation
Vendor Tool
RTL Compilation
Logic Synthesis
RTL
SDC
Synthesis constraints
ITA
PA
TCL
TAH
SRM
LEF
DEF
Synopsys FPGA Tool
Vendor constraints
Synthesized netlist
Logic Synthesis Design Flow Chapter 2: FPGA Synthesis Design Flows
March 2014 39
Logic Synthesis Procedure
For a design flow with step-by-step instructions based on specific design
data, download the tutorial from http://solvnet.synopsys.com. The following
steps summarize the procedure for synthesizing the design, which is also
illustrated in the figure that follows.
1. Create a project.
2. Add the source files to the project.
3. Set attributes and constraints for the design.
4. Set options for the implementation in the Implementation Options dialog
box.
5. If you are running the Synplify Premier tool in logic synthesis mode,
other modes can be set. See Fast Synthesis, on page 617 and Logic
Synthesis with Enhanced Optimization, on page 42.
6. Click Run to run logic synthesis.
7. Analyze the results, using tools like the log file, the HDL Analyst
schematic views, the Message window and the Watch Window.
After you have completed the design, you can use the output files to run
place-and-route with the vendor tool and implement the FPGA.
LO
Chapter 2: FPGA Synthesis Design Flows Logic Synthesis Design Flow
40 March 2014
The following figure lists the main steps in the flow:
SYNPLIFY & SYNPLIFY PRO
Add Source Files
Set Constraints
Set Logic Mode
Create Project
Run physical synthesis
Place and route
Set Options
SYNPLIFY PREMIER
Analyze Results
Run the Software
Add Source Files
Set Constraints
Run the Software
Create Project
Analyze Results
Place and Route
Set Options
Goals Met?
Yes
No
Goals Met?
Yes
No
Synplify Premier Synthesis Design Flows Chapter 2: FPGA Synthesis Design Flows
March 2014 41
Synplify Premier Synthesis Design Flows
Synplify Premier
With the Synplify Premier tool, you can perform logic synthesis or physical
synthesis. The physical synthesis flows include logic synthesis.
The following table lists the Synplify Premier logical and physical synthesis
flows. Some flows are only available in certain technologies.
Logic Synthesis Flows
Logic Synthesis Design Flow, on
page 38
Same as Synplify Pro logic synthesis
Logic Synthesis with Fast
Synthesis
Synplify Premier logic synthesis with fast
synthesis runtimes. For details about this flow,
see Fast Synthesis, on page 617.
Logic Synthesis with Enhanced
Optimization, on page 42
Synplify Premier logic synthesis includes
additional optimizations during logic synthesis
and provides an output netlist with better QoR
than when running basic logic synthesis.
Enhanced Optimization is turned on by default.
Design Plan-Based Logic
Synthesis, on page 44
Synplify Premier logic synthesis with placement
constraints from a floorplan file (needs Design
Planner option)
Physical Synthesis Flows
Altera Graph-Based Physical
Synthesis, on page 48
Altera only
Automated physical synthesis. This includes
the enhanced logic synthesis optimizations.
Altera Graph-Based Physical
Synthesis with Design Planner,
on page 51
Altera only
Automated physical synthesis that uses
floorplan file constraints (needs Design Planner
option)
Xilinx Physical Plus, on page 66 Xilinx only
Modular flow that allows you to separate the
logical and physical stages of the design
process, using the Process view GUI to guide
you through the steps that can or must be
executed based on updates to the input files.
LO
Chapter 2: FPGA Synthesis Design Flows Synplify Premier Synthesis Design Flows
42 March 2014
Logic Synthesis with Enhanced Optimization
Altera, Xilinx
Enhanced Optimization is a Synplify Premier feature that includes additional
optimizations during logic synthesis and provides an output netlist with
better QoR (quality of results) than basic logic synthesis.
This switch is enabled by default. If your goal is to get the same results that
you get from synthesis in the Synplify Pro tool, turn this switch off. Enhanced
Optimization is only for logic synthesis and has no effect if Physical Synthesis or
Physical Plus is enabled.
The following figure summarizes the steps in the flow. The steps are briefly
described after the figure.
Add Source Files
Set Constraints
Set Logic Mode
Create Project
Run Physical Synthesis
Place and route
Set Options
Analyze Results
Run the Software
Goals Met?
Yes
No
March 2014 43
Running Logic Synthesis with Enhanced Optimization
Physical synthesis automatically runs various logic optimizations as part of
the process. These optimizations do not run in the basic logic synthesis
process. If you want to run logic synthesis only, but want to include these
enhanced optimizations, use the following procedure.
1. Create a Synplify Premier project.
4. Set options for the implementation in the Implementation Options dialog
box.
5. Specify logic synthesis with enhanced optimizations.
Disable the Physical Synthesis or Physical Plus option, either in the
Project window or in the Implementation Options dialog box. This directs
the software to run logic synthesis only.
Check that the Auto Constrain option is off.
Make sure that Fast Synthesis is disabled, either in the Project view or
on the Options tab of the Implementation Options dialog box. The two
options are contradictory and if both options are enabled, Fast
Synthesis takes priority.
Enable Enhanced Optimization in the Device tab of the Implementation
Options dialog box. When you enable the Physical Synthesis or Physical
Plus option, the software automatically uses enhanced optimizations
as part of that flow, so you do not have to specifically enable it.
LO
44 March 2014
7. Analyze the results, using tools like the log file, the HDL Analyst
schematic views, the Message window, and the Watch Window.
After you have completed the design, you can use the output files to run
place-and-route with the vendor tool. You could also run physical
synthesis before placement and routing.
Design Plan-Based Logic Synthesis
This flow lets you use a floorplan to guide logic synthesis without running
physical synthesis. To do this, you require the Synplify Premier software with
the Design Planner option (see Chapter 18, Floorplanning with Design Planner
for details about using this tool).
The following figure shows the phases and tools used in the flow, and some of
the major inputs and outputs. The interactive timing analysis, physical
synthesis and analysis, and backannotation steps shown in gray are
optional.
March 2014 45
Running Logic Synthesis with a Design Plan
With this methodology, you use the Design Planner tool to manually create
physical constraints that assign critical path logic to specific locations on the
die to improve performance. You then use this design plan file to constrain
logic synthesis.
Route
Vendor Tool
Compile RTL
Run Design Planner
Synthesize Logic
RTL
SDC
SFP
TCL
TAH
SRM
LEF
DEF
SYNPLIFY PREMIER
Vendor
Vendor
netlist
constraints
Synthesized netlist
Interactive
Physical
Timing
Analysis
Analysis
Optional
LO
46 March 2014
The figure below shows the logic synthesis flow based on a design plan.
1. Set up the project and compile the design in logic synthesis mode.
Set up the design as described in Set up the Altera Physical Synthesis
Project, on page 58. Set up a P&R implementation.
Disable the Physical Synthesis or Physical Plus option to run the tool in
logic synthesis mode.
Compile the design.
2. Analyze timing results.
Analyze timing.
Determine which components you want to assign to regions.
Design
(
Verilog or VHDL
)
Compile Design
Yes
Target
Met?
Yes
Analyze Timing
Implement FPGA
Run Logic Synthesis
w/ DP file
Create Design Plan
(constrain critical path)
Design-Plan Based
Logic Synthesis Flow
No
(Includes P&R

following synthesis)
Optional:
Analyze Timing Target
Met?
No
March 2014 47
3. Launch the Design Planner tool ( ) and do the following:
Create regions for the critical paths and interactively assign the
critical paths to regions of the chip. See Working with Regions, on
page 907 andWorking with Altera Regions, on page 919 for details.
Obtain a size estimation for each RTL block in the design. See
Checking Utilization, on page 917 for details.
For multiple clocks, assign critical logic associated with each clock
domain (that does not meet design requirements) to a unique region
to avoid resource contention.
If you have any black boxes in your design, assign them to a region.
Designate this region as an IP block, so that the Synplify Premier
software can instantiate the black box in the vqm file. However, you
must provide the content for the black box so that the place-and-
route tool can run successfully.
For details about using Design Planner, see Floorplanning with Design
Planner, on page 889. Consult the following for more information on
how to complete the Design Plan file (sfp): Creating and Using a
Design Plan File for Physical Synthesis, on page 896, Working with
Regions, on page 907, and Assigning Pins and Clocks, on page 897.
Save the design plan file (sfp) and add it to your project.
4. Run logic synthesis.
Make sure the Physical Synthesis or Physical Plus switch is disabled, but
that the project includes the physical constraints file (sfp).
Set up the project to automatically run place-and-route after
synthesis completes. Alternatively, you can run the P&R tool in
standalone mode.
The synthesis tool honors the region placement constraints in the floor-
plan file. It treats each region you defined in the floorplan as a hard
hierarchy, and does not optimize across this boundary. When synthesis
is complete, the tool generates a structural netlist for the target
technology and a Tcl script that contains the information for forward-
annotation, like the region assignments.
The tool then launches the P&R tool, and uses the forward-annotated
constraints to direct the P&R run.
5. Analyze the timing in the Synplify Premier tool, using the log file and
analysis tools. See Checking Log File Results, on page 342, Analyzing
LO
48 March 2014
Timing in Schematic Views, on page 452, and Generating Custom Timing
Reports with STA, on page 459 for details.
If the target is met, you can continue to P&R. If not, you should re-
evaluate timing and placement. Or, you can run physical synthesis.
Altera Graph-Based Physical Synthesis
Synplify Premier graph-based physical synthesis is an automated, single-
pass flow that allows you to constrain assigned logic to specific locations, and
which optimizes the design based on this placement information. The essence
of the graph-based approach is that preexisting wires, switches and place-
ment sites used for routing an FPGA are represented as a detailed routing
resource graph. The Synplify Premier tool can then allow for delay and wire
availability, which produces more accurate results and improves timing
closure. During physical synthesis, the tool performs concurrent placement
and synthesis optimizations to ensure fast routes for critical paths. It gener-
ates a fully-placed and physically-optimized netlist ready for the vendor
place-and-route tool.
Physical synthesis does not require a design plan or place-and-route imple-
mentation. If you want to use a design plan file with this flow, see Altera
Graph-Based Physical Synthesis with Design Planner, on page 51. For graph-
based physical synthesis, the tool automatically performs placement with
backannotation during the physical synthesis run. It absorbs the core files
into the Synplify Premier database for timing, placement and optimizations.
Design Phases in Graph-based Physical Synthesis
The physical synthesis design flow consists of two phases: logic synthesis
validation, and physical synthesis.
Logic Synthesis Validation
You first run logic synthesis to ensure that the design can successfully
complete logic synthesis and place-and-route, and that it has been assigned
accurate, realistic constraints. Doing an initial logic synthesis run can save
valuable time by identifying obvious problems early in the process.
March 2014 49
The figure below shows the flow for logic synthesis validation phase.
For specific explanations of the steps shown here, see Altera Physical
Synthesis, on page 57.
Physical Synthesis
After successfully running through logic synthesis, you set up the design for
physical synthesis. Physical synthesis merges design optimization and place-
ment to generate a fully-placed, physically-optimized netlist, providing rapid
timing closure and increased timing improvement. The tool performs concur-
Source Files
(
.v /. vhd
)
No
Yes
Physical Synthesis
Logic Synthesis
Validation Phase
Set up Project
Timing Constraints
Physical Constraints
(.sdc)
Timing Report (.ta)
Log File (.srr)
Run Logic Synthesis
Validate Results
Compile
Flow
IP Cores
(Includes P&R
Ready for
physical
synthesis?
LO
50 March 2014
rent placement and optimizations based on timing constraints and the device
technology. The output netlist contains placement information. The figure
below shows the flow for the physical synthesis phase:
For specific explanations of the steps shown here, see Altera Physical
Goals
No
Yes
Implement
Physical Synthesis
Complete Logic
Timing Report (.ta)
Log File (.srr)
Analyze Results
Improve Performance
Met?
FPGA
Synthesis Validation
(Includes P&R
Phase
March 2014 51
Altera Graph-Based Physical Synthesis with Design Planner
Like the graph-based flow (Altera Graph-Based Physical Synthesis, on
page 48) this is a push-button, fully automated flow that produces a synthe-
sized design with detailed placement, but it uses a design plan file to specify
physical constraints for guiding global placement. Use this flow to improve
performance.
The design plan usually includes I/O settings and placement information for
large blocks. The tool generates placement constraints when you assign RTL
logic to ports or regions in the Design Plan view (Design Planner). These
regions constrain logic to the areas you specify on the device. During optimi-
zations, these constraints direct global placement and subsequently influ-
ence physical optimizations.
analysis, and backannotation steps that are shown in gray are optional.
LO
52 March 2014
Compile RTL
Run Design Planner
Synthesize Logic
Run Initial Placement
Route
RTL
SDC
TCL
TAH
SRM
LEF
DEF
SYNPLIFY PREMIER
Vendor Tool
Vendor
constraints
Vendor
Vendor
netlist
constraints
SFP
Synthesized netlist
Interactive
Physical
Timing
Analysis
Analysis
March 2014 53
Design Plan-based Physical Synthesis
This is an interactive flow that where you can specify physical constraints
before running physical synthesis. It requires the Design Planner option, a
tool that improves performance through physical constraints. This flow
supports certain Altera technologies. See Running Physical Synthesis with a
Design Plan, on page 54 for a procedure using this flow. For information
about using Design Planner, see Chapter 18, Floorplanning with Design
Planner.
analysis, and backannotation steps that are shown in gray are optional.
Route
Vendor Tool
Compile RTL
Run Design Planner
Synthesize Logic
RTL
SDC
SFP
TCL
TAH
SRM
LEF
DEF
SYNPLIFY PREMIER
Vendor
Vendor
netlist
constraints
Synthesized netlist
Interactive
Physical
Timing
Analysis
Analysis
LO
54 March 2014
Running Physical Synthesis with a Design Plan
In this flow, you use the Design Planner tool to manually create physical
constraints that assign critical path logic to specific locations on the die to
improve performance. You then use these constraints to drive physical
synthesis for the design.
The figure below shows the physical synthesis design-plan flow.
1. Run logic synthesis.
Set up the project for your target technology. See Set up the Altera
Physical Synthesis Project, on page 58 for details.
Synthesize the design in logic synthesis mode, using timing
constraints and no physical constraints.
Analyze Timing
Design
(
Verilog or VHDL
)
Complete
Target
Met?
No
Yes
Target
Met?
Yes
Analyze Timing
Implement FPGA
Logic Synthesis
Validation Phase
w/ DP file
Create Design Plan
(constrain critical path)
Design-Plan Based
Physical Synthesis Flow
No
(Includes P&R

March 2014 55
This phase is to determine if the design can successfully complete
synthesis and if timing performance enhancements are needed. The
logic synthesis validation phase includes running the netlist through
place-and-route after synthesis completes.
2. Analyze timing results. See Validating Results for Physical Synthesis, on
page 376 for details.
If timing goals are met, you are done. Otherwise, go to the next step.
3. Determine the critical paths from the P&R results; these are the
candidates for logic assignments to regions.
4. Bring up the Design Planner ( ) and do the following:
Create regions for the critical paths and interactively assign the
critical paths to regions of the chip. See Working with Regions, on
page 907 and Working with Altera Regions, on page 919 for details.
Obtain a size estimation for each RTL block in the design. See
Checking Utilization, on page 917 for details.
For multiple clocks, assign critical logic associated with each clock
domain (that does not meet design requirements) to a unique region
to avoid resource contention.
If you have any black boxes in your design, assign them to a region.
Designate this region as an IP block, so that the Synplify Premier
software can instantiate the black box in the vqm file. However, you
must provide the content for the black box so that the place-and-
route tool can run successfully.
For details about using Design Planner, see Floorplanning with Design
Planner, on page 889.
You can also open Physical Analyst to view the design and check critical
path placement. Consult the following sections for more information on
how to complete the Design Plan file (sfp): Creating and Using a Design
Plan File for Physical Synthesis, on page 896, Working with Regions, on
page 907, and Assigning Pins and Clocks, on page 897.
5. Save the design plan file (sfp) and add it to your project.
6. Run physical synthesis. Use the same project file that you created in
step 1 above. This time enable the Physical Synthesis switch and include
the physical constraints file (sfp). This phase also includes running the
netlist through place-and-route after synthesis completes.
LO
56 March 2014
7. Analyze the timing in the Synplify Premier tool. Use the log file and
graphical analysis tools. See Analyzing Physical Synthesis Results, on
If the target is met, you can continue to the next design phase. If not,
you should re-evaluate timing and placement. You might find there is a
new critical path or the one that is already assigned to a region that
needs tweaking. See Improving Altera Physical Synthesis Performance,
on page 1007 for more suggestions.
Altera Physical Synthesis Chapter 2: FPGA Synthesis Design Flows
March 2014 57
Altera Physical Synthesis
In addition to the graph-based physical design flow, you can use the following
Synplify Premier Altera design flows.
Altera Graph-based Physical Synthesis
The following topics provide an overview of what you need to do to run graph-
based physical synthesis in your Altera designs.
Guidelines for Physical Synthesis in Altera Designs, on page 58
Set up the Altera Physical Synthesis Project, on page 58
Run Logic Synthesis for the Altera Physical Synthesis Flow, on page 62
Validate Logic Synthesis Results for Altera Physical Synthesis, on
page 63
Run Altera Physical Synthesis, on page 63
Analyze Results of Altera Physical Synthesis, on page 63
Altera Design Flows For details, see ...
Basic logic synthesis Logic Synthesis Design Flow, on page 38
Logic synthesis with enhanced
optimization
Logic Synthesis with Enhanced Optimization,
on page 42
Logic synthesis with fast
synthesis
Fast Synthesis, on page 617
Logic synthesis with design plan Design Plan-Based Logic Synthesis, on page 44
Physical synthesis with design
plan
Design Plan-based Physical Synthesis, on
page 53
Graph-based synthesis with a
design plan
Altera Graph-Based Physical Synthesis with
Design Planner, on page 51
LO
Chapter 2: FPGA Synthesis Design Flows Altera Physical Synthesis
58 March 2014
Guidelines for Physical Synthesis in Altera Designs
Follow these guidelines for physical synthesis:
Include the entire design black boxes cannot be present. However,
Altera LPMs (Library of Parameterized Modules) or Megafunctions are
supported. See Using Altera LPMs or Megafunctions in Synthesis, on
page 734 if more information is needed.
Use the appropriate methodology defined for Altera IPs or Nios II cores in
the design. For more information, see the following:
Implementing Megafunctions with Grey Box Models, on page 748
Including Altera Processor Cores Generated in SOPC Builder, on
page 759.
Assign realistic, accurate timing constraints. Do not over-constrain the
tool. (See Improving Altera Physical Synthesis Performance, on page 1007
for tips.)
Use the top-down design methodology. (A bottom-up flow is not
supported.)
Do not use compile points with graph-based physical synthesis.
Install the recommended version of the Altera Quartus II place-and-
route tool.
Set up the Altera Physical Synthesis Project
Project setup is the first phase of the physical synthesis design process. The
project file (prj) is a collection of input files and optimization switches
required to synthesize your design. This section contains details on how to
set up the file.
1. Make sure you follow these requirements for this flow:
Make sure the design is properly constrained. (See Improving Altera
Physical Synthesis Performance, on page 1007 for tips.)
Make sure to specify I/O pin location constraints for all pins in the
design for physical synthesis.
Make sure to include any I/O constraints from the Quartus settings
file (qsf) as necessary. You can translate the I/O constraints and I/O
March 2014 59
standards to sdc format with a utility. See Translating Altera QSF
Constraints, on page 318.
If you have the Design Planner option, you can use a design plan file
(sfp) for physical synthesis.
If you are using one of the graph-based physical synthesis flows,
make sure you select a target technology that is supported. See Altera
Graph-based Physical Synthesis, on page 57.
Keep the guidelines described in Guidelines for Physical Synthesis in
Altera Designs, on page 58 in mind.
2. Create the project. If you are using a design plan file, make sure to add it
to the project.
See Setting Up HDL Source Files, on page 100 and Setting Up Project
Files, on page 136 for details.
3. Set constraints.
Compile the design. Open the SCOPE interface and set constraints.
Timing constraints specify performance goals and describe the design
environment. See Using the SCOPE Editor, on page 256 and
Specifying SCOPE Constraints, on page 263 for details.
Add physical constraints.
Translate constraints from the Quartus settings file (QSF) and
combine them with the timing constraints into a single sdc constraint
file. See Translating Altera QSF Constraints, on page 318 for details.
Check your constraints with Run->Constraint Check.
Save the constraints file and save the project file.
4. Specify the implementation options for synthesis.
Click the Implementation Options button.
LO
60 March 2014
Set implementation options on the various tabs of the dialog box as
shown in the following table. For details about setting
implementation options, refer to Setting Logic Synthesis
Implementation Options, on page 152.
Device Set technology and device mapping options.
Make sure the Disable I/O Insertion option is disabled, because
Synplify Premier physical synthesis requires this setting.
See Setting Device Options, on page 152.
Options Set optimization switches for synthesis. See Setting
Optimization Options, on page 155.
Constraints Set an overall target frequency for the design.
Select the constraint files you want to use.
See Specifying Global Frequency and Constraint Files, on
page 158.
Implementation
Results
Specify the output results directory and output file options.
See Specifying Result Options, on page 161 for details.
March 2014 61
Click OK to apply the implementation options. Save the project file.
5. Create a place-and-route implementation to automatically run the
Altera Quartus II place and route tool from the synthesis UI after
synthesis.
Make sure you have the correct version of the P&R tool and that you
have set the environment variables for the tool.
Create a P&R implementation. See Creating a Place and Route
Implementation, on page 229 for details.
Timing Report Specify the number of critical paths and start/end points to
display in the timing report.
See Specifying Timing Report Output, on page 162.
Verilog/VHDL Specify the HDL options. See Setting Verilog and VHDL
Options, on page 163.
Netlist
Restructure
Specify options for any necessary netlist optimizations, and
the netlist restructure file (nrf) for which bit slicing might
have been performed.
See Setting Synplify Premier Prototyping Tools
Optimizations, on page 228 for descriptions.
LO
62 March 2014
Specify the Place & Route Job Name. Make sure the Run Place and Route
following synthesis switch is enabled and click OK.
For Altera devices, you can alternatively choose to Use placement
constraints from physical synthesis, otherwise Quartus determines how it
handles physical constraints.
Specify the place-and-route options file. The tool automatically uses
default options located in installDirectory\lib\altera\altera_par.tcl. For
more information, see Specifying Altera Place-and-Route Options, on
page 234.Select other options for backannotation and for forward-
annotation of constraints and click OK.
Go to Implementation Options->Place and Route and enable the place-and-
route implementation that you want to use for your project.
Save the project file.
Run Logic Synthesis for the Altera Physical Synthesis Flow
If this is the first time you are running synthesis on the design, you must run
logic synthesis mode. This means that you run synthesis with the Physical
Synthesis switch disabled. You can choose to run logic synthesis in the
March 2014 63
Synplify Premier tool with the Enhanced Optimization mode or the standard logic
synthesis mode for certain Altera devices. When the Enhanced Optimization
mode is:
Enabled (box is checked in the Project view or on the Implementation
Options - Device tab) Additional optimizations are used to achieve QoR
results that exceed the standard logic synthesis QoR. This is the default.
Disabled (box is unchecked in the Project view or on the Implementation
Options - Device tab) The standard logic synthesis QoR can be
achieved.
This initial synthesis run is to determine if there are any problems that need
to be addressed before going on to the physical synthesis stage. See the first
step of Running Physical Synthesis, on page 334 for details of running logic
synthesis as part of a physical synthesis flow.
Validate Logic Synthesis Results for Altera Physical Synthesis
After doing an initial run of logic synthesis, check the results and fix any
errors you find. See Validating Results for Physical Synthesis, on page 376 for
details.
Run Altera Physical Synthesis
Once you have validated the logic synthesis run and set up the physical
constraints, you can run physical synthesis. Make sure to enable the Physical
Synthesis switch and to enable the place-and-route implementation before
clicking Run. If you are using a design plan file, you must also enable this file.
For a detailed procedure, see Running Physical Synthesis, on page 334.
Analyze Results of Altera Physical Synthesis
To determine if your design has met performance goals, use the following
Synplify Premier analysis tools to analyze any critical paths with negative
slack and identify potential solutions to improve performance:
LO
64 March 2014
Use these guidelines to analyze the results:
Log file that includes the default
timing report (srr or htm)
See Checking Log File Results, on page 342.
HDL Analyst Consists of schematic views that help you
analyze the design. See Chapter 6, Specifying
Constraints.
RTL View ( ) Select HDL Analyst->RTL->Hierarchical View or
Flattened View to display the compiled view of the
design. See Chapter 8, Analyzing with HDL
Analyst and FSM Viewer.
Technology View ( ) Select HDL Analyst ->Technology->Hierarchical View,
or ->Flattened View to display the mapped view of
the design. See Chapter 8, Analyzing with HDL
Analyst and FSM Viewer.
Physical Analyst ( ) The Physical Analyst provides a visual display of
the device, and design placement of instances
and nets. Select HDL Analyst->Physical Analyst. See
Chapter 19, Analyzing Designs in Physical
Analyst.
Timing Analyst ( ) The stand-alone timing analyzer produces
timing reports (ta) for specific reporting
requirements. See Generating Custom Timing
Reports with STA, on page 459.
Check this ... Tool
Are start and end points being
constrained by the proper
clocks?
Timing report
You can also trace the clock network using HDL
Analyst Technology view.
Is the critical path a multi-cycle
path or false path?
Timing report
HDL Analyst
Will pipelining improve results? HDL Analyst
March 2014 65
If the path is inside a state
machine, is the FSM being fully
optimized?
HDL Analyst. Open the RTL view and push down
into the state machine module to display the
FSM viewer.
Are the net delays contributing
to the highest percentage on the
critical path?
Timing report
Check the percentage breakdown of delay for
each path. Search for Total path delay.
Physical Analyst
Use it to analyze the instance placement of the
critical path.
Will physical constraints
improve results?
Physical Analyst
Use it to analyze the design.
Design Planner
Use it to assign logic to regions and generate a
design plan file.
Check this ... Tool
LO
Chapter 2: FPGA Synthesis Design Flows Xilinx Physical Plus
66 March 2014
Xilinx Physical Plus
Physical Plus is a modular design flow that let you perform the following
processes:
Supports Xilinx Virtex families (Virtex-5 and later devices).
Lets you to import UCF or NCF/XDC constraints previously applied
during Xilinx place and route (PAR).
Separates the logical and physical stages of the design process.
Is set up easily after you have run Synplify Premier logic synthesis with
Enhanced Optimization and Xilinx PAR.
Lets you create region constraints in the Design Planner.
Gives you the flexibility to choose the part of the design process for
which you can implement netlist or timing changes. To help you do this,
use the Process View in the implementation results panel of the Project
view. For more information about the Process View, see the Process
View, on page 63.
Can help to alleviate congestion for unroutable nets in a design.
Lets you use the Implementation Maps in the Physical Analyst tool to
diagnose congestion and utilization issues in your design. For more
information, see Using Implementation Maps in Physical Analyst, on
page 986.
Topics include:
Physical Plus Design Flows
Setting Up I/O and Clock Component Constraints
Creating Region Constraints
Running Physical Plus Starting from RTL
Running Physical Plus Starting from EDIF
Input/Output Files and Directory Structure
Physical Plus Dependencies
Xilinx Physical Plus Chapter 2: FPGA Synthesis Design Flows
March 2014 67
Physical Plus Design Flows
You can run Physical Plus starting from RTL or EDIF. The following figures
show these flows.
Physical Plus Starting from RTL
LO
68 March 2014
Physical Plus Starting from EDIF
March 2014 69
Setting Up I/O and Clock Component Constraints
Physical Plus requires that all I/O and clock generating components be
locked to a placement location. Clock generating components can include:
DCM/PLL/MMCM
BUFG
BUFGCTRL
ISERDES/OSERDES
IODELAY
IDELAY/ODELAY
GT
BUFR
BUFH
TEMAC
If you start Physical Plus from RTL, you must provide these pre-placed
components in the SDC/FDC file. When starting Physical Plus from EDIF,
you must provide these pre-placed components in the PDC file.
To set I/O and clock generating components, you can:
Manually enter these placement constraints using the syn_loc attribute.
For a description of this attribute, see syn_loc, on page 247.
Use the Import Xilinx Constraints utility. See Using Import Xilinx
Use an automatic placement option (Virtex-7 devices only). For more
information, see Automatic Placement Option, on page 73.
Using Import Xilinx Constraints
The Import Xilinx Constraints utility helps guide you to generate the prerequisite
placement constraints for Physical Plus. This utility uses the
Xilinx Design Check Point (DCP) database file generated after Vivado
place and route has been run. You can use either the post-place or post-
route DCP file.
LO
70 March 2014
Xilinx NDC file after you have run synthesis and ISE place and route.
The NCD file contains all placement, timing, and potential routing infor-
mation. You can use either the post-map or final NCD file. Use the post-
map NCD file if your design has routing failures.
Routed designs generate both the post-place and post-route result files.
To import Xilinx constraints, see:
Import Xilinx Constraints (Vivado), on page 70
Import Xilinx Constraints (ISE), on page 72
Import Xilinx Constraints (Vivado)
You should use Import Xilinx Constraints for Virtex-7 designs.
To do this, use the Import->Import Xilinx Constraints option from the Project view.
Select the Vivado tab on the Import Xilinx Constraints dialog box:
Add all the input EDIF files to be used in Physical Plus.
Select the Vivado post-place or post-route design checkpoint (DCP) file
from the place-and-route directory.
The DCP file contains the placement and routing information from
Vivado place and route.
Physical Plus requires that I/O and clock generating components be
locked to a placement location. The Import I/O and Clock Component Place-
ment option is enabled by default. You can either:
Enable Use for Physical Plus to select the PDC file for the imported
placement constraints.
Enable Use for Logical Synthesis to select the logic synthesis FDC file for
the imported XDC constraints, if you want to use the I/O and clock
component placement at the RTL level. You might first need to
convert the SDC file to an FDC file.
You can also chose to import RAM and DSP placements. If so, enable the
Include RAM & DSP Placement option.
Specify the location of the logic synthesis constraints (FDC) file or
physical design constraints (PDC) file to which the translated
constraints are written in the Project view.
March 2014 71
Click on the Import button. A log file opens. Verify that import Xilinx
constraints ran successfully.
At this time, the output files designName_xdc_placement.PDC and
designName_xdc_timing.PDC files are generated and added to your project. It is
highly recommended that you inspect the constraints in the PDC files and
review all warnings in the log file.
LO
72 March 2014
Import Xilinx Constraints (ISE)
Use Import Xilinx Constraints for Virtex-5 and Virtex-6 designs.
To do this, use the Import->Import Xilinx Constraints option from the Project view.
Select the ISE tab on the Import Xilinx Constraints dialog box:
Add all the input EDIF files to be used in Physical Plus.
Optionally add any user-generated UCF constraint files to the project
(not synplicity.ucf). Physical Plus requires accurate constraints for good
results. All constraints should be provided during synthesis.
Specify the location of the physical design constraints (PDC) file to which
the translated UCF constraints are written.
Physical Plus requires I/O and clock component placement. If this infor-
mation is not provided in the SDC or UCF file, add the NCD file from the
Xilinx PAR job that was run after logical synthesis. The I/O and compo-
nent placement are extracted from this NCD file.
Enable Use for Physical Plus to select the PDC file for the imported NCD
constraints.
Note: Enable Use for Logical Synthesis to select the logical synthesis SDC
file for the imported NCD constraints, if you want to use the I/O and
clock component placement at the RTL level.
The Import I/O and Clock Component Placement option is enabled by default.
You can also chose to import RAM and DSP placements. If so, enable the
Include RAM & DSP Placement option.
Click on the Import button. A log file opens. Verify that import Xilinx
constraints ran successfully.
At this time, the output files designName_ncd.PDC and designName_ucf.PDC
files are generated and added to your project. It is highly recommended that
you inspect the constraints in the PDC files and review all warnings in the log
file.
In some cases, a synplicity_unapplied.ucf file is created for UCF constraints that
cannot be imported. Manually import any constraints that are critical for
timing and placement to the PDC file for the project.
March 2014 73
Automatic Placement Option
Xilinx Virtex-7 devices
You can automatically generate the prerequisite I/O and clock component
placement. To conveniently do this:
From the Constraints tab on the Implementation Options dialog box,
select the Generate IO & Clock Generating Component Placement for Physical Plus
option.
The Tcl equivalent is
set_option -run_xilinx_io_clock_place 1 | 0
LO
74 March 2014
The run_vivado_phys.tcl script runs in the background and randomly
selects the I/O and clock generating component placements for the
design to use as input for Physical Plus.
March 2014 75
Creating Region Constraints
You can interactively create regions and assign logic to them for Xilinx
devices in the Design Planner. For information about using the Design
Planner, see Chapter 18, Floorplanning with Design Planner.
To manually create regions, you can use the syn_assign_to_region attribute. For
details, see syn_assign_to_region, on page 82.
These region constraints are forward-annotated to Physical Plus from either
the design_synplify.fdc or user-specified PDC file. The following examples show
how region constraints are formatted:
FDC (Block Region Assignment)
define_attribute {i:rgn1.flop} {syn_assign_to_region}
{SLICE_X54Y468:SLICE_X295Y558 RAMB36_X1Y94:RAMB36_X4Y110
RAMB18_X1Y188:RAMB18_X1Y188:RAMB18_X4Y221
DSP48_X2Y188:DSP48_X4Y223}
Physical Plus honors these constraints and generates components optimized
in the output netlist for place and route.
XDC (Block Region Assignment)
create_pblock rgn1
resize_pblock [get_pblocks rgn1]
-add {SLICE_X54Y468:SLICE_X295Y558}
-add {RAMB36_X1Y94:RAMB36_X4Y110}
-add {RAMB18_X1Y188:RAMB18_X4Y221}
-add {DSP48_X2Y188:DSP48_X4Y223}
add_cells_to_pblock [get_pblocks rgn1] [get_cells rgn1/flop]
-clear_locs
LO
76 March 2014
Running Physical Plus Starting from RTL
Perform the following tasks:
1. Set up the input files for logic synthesis. Define the HDL, top-level
constraints, any IP, and if required physical region constraints.
Note: Physical Plus only accepts IP cores (for example, NGC and NGO
files) that are fully mapped. It is required that the entire design be
provided in EDIF format, so make sure to run step Step 2.
2. Run logic synthesis with Enhanced Optimization on, and place and route
(PAR) the design.
Run Synplify Premier logic synthesis, but make sure that the Physical
Plus option is disabled and Enhanced Optimization is enabled. Place and
route the design.
The Xilinx Vivado place-and-route software must run through the post-
placement phase and generate the DCP file, but does not need to
complete routing to use Physical Plus. Likewise, Xilinx ISE place-and-
route software must run through the map phase without errors to
generate the NCD file, but does not need to complete routing to use
Physical Plus. Also, note that the Physical Plus process is disabled and
therefore greyed out in the Process view.
March 2014 77
An important prerequisite for starting Physical Plus from RTL is that all
I/O and clock generating components are pre-placed in the constraint
file. This prerequisite placement information is included in the
design_synplify.sdc files after logic synthesis completes. Physical Plus
uses the EDIF and design_synplify.sdc file as inputs.
3. Import Xilinx constraints to generate the constraint files needed for
Physical Plus.
To do this, see Setting Up I/O and Clock Component Constraints, on
page 69.
When you run:
Vivado, the output files designName_xdc_placement.PDC and
designName_xdc_timing.PDC files are generated and added to your
project.
ISE, the output files designName_ncd.PDC and designName_ucf.PDC
files are generated and added to your project.
4. From the Implementation Options Constraints tab, select the constraint
files to be applied for the specified implementation. Make sure that any
PDC constraint files are enabled for the implementation.
LO
78 March 2014
The Use Logical Constraints for Physical Plus option automatically forward-
annotates constraints provided for logical synthesis to Physical Plus.
The file that gets forward-annotated is named design_synplify.sdc. This
option is enabled by default.
5. Run Physical Plus. Enable the Physical Plus option using one of the
following methods:
From the Project view or the Options tab of the Implementation
Options dialog box
From the Process view, right-click on Physical Plus and select Enable
Physical Plus
6. Optionally create a PAR implementation for Physical Plus. To do this:
Select the Physical Plus implementation. Then, right-click and select
Add Placement Place & Route.
Select the Run Place & Route following synthesis option, to run PAR
automatically after synthesis.
Project View Option
right-click on Physical Plus
and select Enable
In the Process View,
Implementation Options (Options tab)
Physical Plus
March 2014 79
Select the Generate Congestion Analysis + Run Timing & Placement
Backannotation option, to backannotate timing and placement
information and automatically generate a congestion report. Click
OK.
Notice that the Place & Route Source is Physical Plus.
LO
80 March 2014
Running Physical Plus Starting from EDIF
Perform the following tasks:
1. Run logic synthesis with Enhanced Optimization on, and place and route
(PAR) the design. This generates the EDIF that is the input for Physical
Plus.
2. Import Xilinx constraints to generate the constraint files needed for
Physical Plus. Another important prerequisite for starting Physical Plus
from RTL is that all I/O and clock generating components are pre-placed
in the constraint file.
To do this, see Setting Up I/O and Clock Component Constraints, on
page 69.
When you run:
Vivado, the output files designName_xdc_placement.PDC and
designName_xdc_timing.PDC files are generated and added to your
project.
ISE, the output files designName_ncd.PDC and designName_ucf.PDC
files are generated and added to your project.
3. From the Implementation Options Constraints tab, select the constraint
files to be applied for the specified implementation. Make sure that any
PDC constraint files are enabled for the implementation.
March 2014 81
4. Run Physical Plus. Enable the Physical Plus option using one of the
following methods:
From the Project view or the Options tab of the Implementation
Options dialog box
From the Process view, right-click on Physical Plus and select Enable
Physical Plus
LO
82 March 2014
5. Optionally create a PAR implementation for Physical Plus. To do this:
Select the Physical Plus implementation. Then, right-click and select
Add Placement Place & Route.
Select the Run Place & Route following synthesis option, to run PAR
automatically after synthesis.
Select the Generate Congestion Analysis + Run Timing & Placement
Backannotation option, to backannotate timing and placement
information and automatically generate a congestion report. Click
OK.
Notice that the Place & Route Source is Physical Plus.
Project View Option
right-click on Physical Plus
and select Enable
In the Process View,
Implementation Options (Options tab)
Physical Plus
March 2014 83
Input/Output Files and Directory Structure
Note the following input/output file requirements and directory structures
generated:
For designs using ISE:
The NCD file should not be added to the Project file. Use the
Import->Import Xilinx Constraints option to extract the I/O and clock
component placement needed for Physical Plus.
UCF constraints can be added to the project using the Import->Import
Xilinx Constraints option. UCF constraints added to the project will be
passed to Xilinx PAR, but are not applied during synthesis.
LO
84 March 2014
When you use ISE, the Import Xilinx Constraints command outputs the
_ncd.pdc and _ucf.pdc files. This process translates placement and timing
constraints from the Xilinx ISE NCD UCF files to PDC files. Constraints
in the PDC file format are applied during physical synthesis.
It is highly recommended that you verify the constraints in the
_ncd.pdc and ucf.pdc files. Edit them as needed.
The PDC file uses the same format as the SDC file; the extension was
renamed to denote that this file be used in Physical Plus. You can
also add the input SDC file to Physical Plus by specifying:
add_file -placement_constraint fileName.sdc
Alternatively from the GUI, you can right-click on an input SDC file
and select Project Options from the Project view. On the File Options
dialog box, select File Type as Physical Constraints.
Physical Plus directory structures include the following:
Output files are stored in folders for the step that generated them.
Logic synthesis result files are written to the implementation folder.
When Physical Plus is enabled, a physical_plus subdirectory is
automatically created in the implementation directory and all output
files are written there. For example, output EDIF files will not be
overwritten by subsequent steps and can keep their original names.
March 2014 85
Log files (for the design.srr and design.html) are generated in the
implementation directory. If you run both logic synthesis and
Physical Plus, two reports are appended in the SRR file with the
Physical Plus log file written in the implementation directory
generated by logic synthesis. However, log files generated from the
Process steps are written to the synlog subdirectory in the
implementation directory. These files can be distinguished by the
step name being appended to the result files (for example,
_fpga_mapper.srr, _place_premap.srr, or _place_job.srr).
The top-level EDIF file contains a description string for how the tool
was synthesized. Look for Synplify Premier Enhanced or Synplify
Premier Physical Plus that can be found at the bottom of this file.
The Physical Plus congestion estimation report (congestion_est_phys.rpt)
is generated in the implementation directory. This congestion report
contains a list of high-fanout nets that can cause potential routing
congestion problems globally in the design. However, use the Routing
Congestion implementation map within the Physical Analyst tool,
which displays estimated routing congestion based on placement to
identify local routing congestion problems in the design. For details,
see Using the Routing Congestion Map, on page 989.
Physical Plus Dependencies
Here are some Physical Plus dependencies to consider:
Physical Plus runs the Synplify global placer. To run the Xilinx global
placer, you must set the following attribute in the SDC file:
define_global_attribute {syn_use_xilinx_placement} {1}
If it is paramount that routing completes but timing constraints can be
conceded somewhat; Physical Plus provides a special PDC attribute that
optimizes for routing at the expense of timing. Add the following attri-
bute to the PDC file:
define_global_attribute syn_placer_effort_level {DECONGEST}
Use this attribute for designs that are unroutable; set this attribute to
DECONGEST to determine if routing improvements are possible for the
design.
LO
86 March 2014
Use the following attribute so that Synplify global placement only places
the FIFO, RAM, and DSP blocks in the design and forward-annotates
them for PAR:
define_global_attribute syn_only_large_block_placement {1}
This can provide quality of results (QoR) improvements for the design.
Each implementation is limited to one Physical Plus run. This restriction
is based on the usage model of a single logic synthesis run followed by a
Physical Plus run. To make sure you preserve your current results, see
Saving Physical Plus Data Through Iterations, on page 86.
Saving Physical Plus Data Through Iterations
The default input for Physical Plus is the logic synthesis edf file (for example,
*/rev1/top_level.edf) for the current implementation. By default, any iteration of
Physical Plus overwrites the previous results. If you need to rerun Physical
Plus and want to preserve the current results from being overwritten, do one
of the following:
Create a new implementation and click Run. This reruns logic synthesis
and therefore has a runtime penalty.
To save on logic synthesis runtime, copy all EDIF files from the current
implementation to the new implementation. Disable logic synthesis in
the Process View.
Manually back up the results from the physical_plus and physical_pr direc-
tories and rerun the same implementation.
Hierarchical Project Management Flows Chapter 2: FPGA Synthesis Design Flows
March 2014 87
Hierarchical Project Management Flows
Some Altera, Lattice iCE40, and Xilinx Technologies
As designs grow in size and complexity, the industry uses team design and
parallel development techniques to ensure that designs are finished on time.
Typically, designs are split into smaller subprojects or blocks, and different
teams work on different blocks.
The team design approach could be either top-first or block-first. The hierar-
chical project management capabilities (HPM) in the FPGA synthesis tools
facilitate both the top-first or block-first team design approaches. See the
following for details:
Block-First Development Flow for Hierarchical Projects, on page 89
Top-First Development Flow for Hierarchical Projects, on page 90
Top-Down Synthesis for Hierarchical Projects, on page 94
Bottom-Up Synthesis for Hierarchical Projects, on page 92
Mixed Block Synthesis for Hierarchical Projects, on page 96
Hierarchical Project Flows and Compile Points
The compile point and the hierarchical project management flows are both
modular and support the team design approach, but the focus is slightly
different. Compile point flows are block-based, but hierarchical project
management flows focus on managing the entirety of the design. Hierarchical
project management can use compile points to implement a hierarchical
design.
Hierarchical project management
Hierarchical project management consists of various features and
methodologies that help you develop and automatically manage a single
FPGA project using multiple teams across different geographical areas.
These flows are intended for distributed design development, and for
parallel development of portions of the design. You create partitions at
the RTL level, but you do not have to floorplan them. The hierarchical
project management flows are modular, and can use compile points for
its block-level components. Hierarchical project management includes
features like a GUI that supports hierarchical project management and
module import and export, top-first, block-first and mixed development
flows, and both top-down and bottom-up synthesis flows (see the list in
LO
Chapter 2: FPGA Synthesis Design Flows Hierarchical Project Management Flows
88 March 2014
Hierarchical Project Management Flows, on page 87 for information on
these flows).
Compile points
Compile points implement block-based flows, based on RTL partitions
that are defined prior to synthesis. Compile points are often used to
implement incremental team design changes, or in design preservation
flows like the Xilinx Design Preservation flow. They can also be used to
reduce runtime. Depending on the tool you use, you can have manual or
automatic compile points:
Manual compile points (Synplify Pro, Synplify Premier)
You manually define these compile points and synthesize them in
logic synthesis flows. Additionally, Synplify Premier users can
improve runtime by synthesizing the compile points in parallel on
multiprocessors on a single machine.
Automatic compile points (Synplify Pro, Synplify Premier)
If you have multiple licenses, you can use this mode to speed up
runtime. The tool automatically splits the design into compile points
and runs parallel logic synthesis on multiple processors to reduce
runtime. The final design is merged back together. See The Automatic
Compile Point Flow, on page 644 for details about automatic compile
points.
March 2014 89
Block-First Development Flow for Hierarchical Projects
In this design approach, blocks are developed independently and then
stitched together at the top level. The advantage to this approach is indepen-
dence, parallel development, and fewer design constraints at the team level.
In the following example, different teams work on each block and the blocks
are then integrated into the top level.
1. Create independent projects from blocks. For each block, do the
following:
Add files.
Synthesize the block and check that results meet block-level goals.
Iterate as needed.
2. Create the top-level project.
Add top-level source files, with black boxes defined for subproject
blocks.
Compile the top level to create a hierarchical view.
3. Create and link subproject to the top level.
To create a subproject, select an instance or design block from the
Design Hierarchy view. Then, right-click and select Create Subproject
(Instance) or Create Subproject (Design Block) respectively.
To link the subproject to the top-level design, right-click and select
Insert & Link Subproject to Instance or Insert & Link Subproject to Design Block.
4. To experiment with different settings, use multiple implementations at
the subproject level or at the top level.
For details, see Working with Multiple Implementations in Hierarchical
Projects, on page 194.
5. Synthesize the top level.
Top
B2 B1
LO
90 March 2014
For top-down synthesis, the tool runs the design flat. For details
about running top-down synthesis, see Top-Down Synthesis for
Hierarchical Projects, on page 94.
For bottom-up synthesis, the tool first synthesizes the blocks and
generates output netlists for them. It then synthesizes the top level,
based on the top-level RTL files and the netlist files from the
subproject blocks.For details about running bottom-up synthesis, see
Bottom-Up Synthesis for Hierarchical Projects, on page 92.
If your design contains a combination of top-down and bottom-up
blocks, the tool first compiles the top-down blocks, then works on the
bottom-up blocks, and finally synthesizes the top level. See Mixed
Block Synthesis for Hierarchical Projects, on page 96 for details.
Top-First Development Flow for Hierarchical Projects
In this flow, you start with the top-level design and then divide it up into
subprojects (blocks). The block RTL is included in the top-level project. The
advantage to using this approach is that you can take advantage of boundary
optimizations to improve QOR.
1. Create a top-level project.
Add project files. You can have black boxes for the subproject blocks.
Compile the design.
2. Open the hierarchical view and define the subprojects.
Define the subprojects. as described in See Creating Hierarchical
Subprojects by Exporting Blocks, on page 179 and Creating
Hierarchical Subprojects by Exporting Instances, on page 181 for
information about creating the subprojects.
You must repeat the process for each subproject block you want to
create. If your top level has multiple instances of the same block with
Top
B2 B1
March 2014 91
different parameter values, you must create subprojects for each
instance as you need separate output netlists for each instance at the
top level. You do not need to create subprojects for each instance if
multiple instances have the same parameters or no parameters,
unless you want them to have their own output netlist files.
Save the top-level design.
Send out the blocks you created to be developed independently.
3. Develop each block independently. The teams must do the following for
each block they are working on:
Add source files.
Add constraints.
Synthesize the block and check that results meet block-level goals.
Iterate as needed.
4. Optionally, create multiple implementations for your hierarchical
project. You might want to do this if you want to experiment with
different settings. See Working with Multiple Implementations in
5. Synthesize the top level.
For top-down synthesis, the tool runs the design flat. For details
about running top-down synthesis, see Top-Down Synthesis for
For bottom-up synthesis, the tool first synthesizes the blocks and
generates output netlists for them. It then synthesizes the top level,
based on the top-level RTL files and the netlist files from the
subproject blocks.For details about running bottom-up synthesis, see
Bottom-Up Synthesis for Hierarchical Projects, on page 92.
If your design contains a combination of top-down and bottom-up
blocks, the tool first compiles the top-down blocks, then works on the
bottom-up blocks and finally synthesizes the top level. See Mixed
Block Synthesis for Hierarchical Projects, on page 96 for details.
LO
92 March 2014
Bottom-Up Synthesis for Hierarchical Projects
In this flow, you synthesize your design from the bottom up. This flow is
independent of the approach used to develop the design; you can use bottom-
up synthesis for a design developed with either the top-first or block-first
design approach.
1. Open the top-level project.
The top-level project can be developed from the top down or the bottom
up (see Top-First Development Flow for Hierarchical Projects, on page 90
and Block-First Development Flow for Hierarchical Projects, on page 89
for details).
2. Check that the top-level entity or module is specified in the Implementation
Options dialog box.
3. Configure the synthesis run parameters as described in Configuring
Synthesis Runs for Hierarchical Projects, on page 205.
Select Hierarchical Project Options and specify which block
implementation to run.
Set Run Type for the block to bottom_up.
March 2014 93
If necessary, synchronize block options with the top level with the
Sync all Options to Top and Syn Required Options buttons. If the block
options do not match the top-level settings, you could get errors.
Click OK.
4. If the subproject teams are not working in the default directories, do one
of the following before running synthesis:
Use source control management and update the block projects before
running top-level synthesis.
Copy the block output netlist and constraint files to the subproject
directories.
5. Synthesize the top-level design. Click Run to synthesize the top-level
design.
LO
94 March 2014
By default, the tool synthesizes the active implementations of the top
level and blocks. If you want to run all implementations, select Run->Run
all Implementations instead of clicking Run.
For the bottom-up flow, the tool does the following:
It automatically uses the latest output netlists for the subprojects
that were marked bottom-up when you configured settings for the run.
It needed, it resynthesizes the blocks and generates the output
netlists for them.
It then compiles the top level, based on the top-level RTL files and the
netlist files from the subproject blocks.
Finally, it maps the top level based on the compiled srs for the top
level.
6. Analyze the results using the log file and the RTL view, as described in
Analyzing Synthesis Results for Hierarchical Projects, on page 209.
Top-Down Synthesis for Hierarchical Projects
In this flow, you synthesize the design from the top down. Note that this flow
is independent of the approach used to develop the design; you can use top-
down synthesis for a design developed with either the top-first or block-first
approach.
The top-level project can be developed from the top down or the bottom
up (see Top-First Development Flow for Hierarchical Projects, on page 90
and Block-First Development Flow for Hierarchical Projects, on page 89
for details).
Options dialog box.
Select Hierarchical Project Options and specify which block
implementation to run.
Set Run Type for the block to top_down.
March 2014 95
Click OK.
4. Click Run to synthesize the top-level design.
For the top-down flow, the tool runs the design flat. It compiles the block
RTL and constraint files along with the top-level files, as if they were part
of the top-level project.
LO
96 March 2014
Mixed Block Synthesis for Hierarchical Projects
In this flow, you have some blocks that need to be synthesized from the top
down and others that must be synthesized from the bottom up. Note that this
flow refers to the synthesis process and is independent of the approach used
to develop the design.
The top-level project and blocks can be developed from the top down or
the bottom up (see Top-First Development Flow for Hierarchical Projects,
on page 90 and Block-First Development Flow for Hierarchical Projects,
on page 89 for details).
Options dialog box.
March 2014 97
Select Hierarchical Project Options and specify the block implementations
to run.
Set Run Type for each block appropriately. In a mixed design, some
blocks will be top_down and others bottom_up.
Click OK.
4. Click Run to synthesize the top-level design.
The synthesis tool does the following to synthesize a hierarchical design
with mixed blocks:
The tool compiles the top-down blocks to generate srs files for them.
It automatically picks up the latest output netlists for the bottom-up
blocks. If necessary, it synthesizes these blocks and generates output
netlists for them.
It then compiles the top level, using the top-level RTL files, the srs
files for the top-down blocks, and the netlist files for the bottom-up
blocks.
Finally, it maps the top level based on the compiled top level results
(srs) from the previous phase.
LO
Chapter 2: FPGA Synthesis Design Flows Prototyping Flow
98 March 2014
Prototyping Flow
The prototyping flow uses the Synplify Premier products and Identify tool set
to provide a complete design and verification environment. You can use the
flow for single FPGA prototypes. For partitioning and timing optimizations in
multi-FPGA designs, use the Certify product.
The prototyping flow provides support for the following:
Instrumentation and debug of an operating FPGA directly from the
source code.
Use of HAPS prototyping boards.
Use of numerous daughter boards.
View the internal designs at full speed.
Support gated clock conversions and DesignWare.
Debug and display results in a waveform viewer.
March 2014 99
CHAPTER 3
Preparing the Input
When you synthesize a design, you need to set up two kinds of files: HDL files
that describe your design, and project files to manage the design. This
chapter describes the procedures to set up these files and the project. It
covers the following:
Setting Up HDL Source Files, on page 100
Using Mixed Language Source Files, on page 120
Using the Incremental Compiler, on page 125
Using the Structural Verilog Flow, on page 127
Working with Constraint Files, on page 129
Using Input from Related Tools, on page 134
LO
Chapter 3: Preparing the Input Setting Up HDL Source Files
100 March 2014
Setting Up HDL Source Files
This section describes how to set up your source files; project file setup is
described in Setting Up Project Files, on page 136. Source files can be in
Verilog or VHDL. For information about structuring the files for synthesis,
refer to the Reference Manual. This section discusses the following topics:
Creating HDL Source Files, on page 100
Using the Compiler Directives Editor, on page 102
Using the Context Help Editor, on page 108
Checking HDL Source Files, on page 110
Editing HDL Source Files with the Built-in Text Editor, on page 111
Setting Editing Window Preferences, on page 114
Using an External Text Editor, on page 116
Using Library Extensions for Verilog Library Files, on page 117
Creating HDL Source Files
This section describes how to use the built-in text editor to create source
files, but does not go into details of what the files contain. For details of what
you can and cannot include, as well as vendor-specific information, see the
Reference Manual. If you already have source files, you can use the text editor
to check the syntax or edit the file (see Checking HDL Source Files, on
page 110 and Editing HDL Source Files with the Built-in Text Editor, on
page 111).
You can use Verilog or VHDL for your source files. The files have v (Verilog) or
vhd (VHDL) file extensions, respectively. With the Synplify Premier and
Synplify Pro products, you can use Verilog and VHDL files in the same
design. For information about using a mixture of Verilog and VHDL input
files, see Using Mixed Language Source Files, on page 120.
1. To create a new source file either click the HDL file icon ( ) or do the
following:
Select File->New or press Ctrl-n.
In the New dialog box, select the kind of source file you want to create,
Verilog or VHDL. Note that you can use the Context Help Editor for
Setting Up HDL Source Files Chapter 3: Preparing the Input
March 2014 101
Verilog designs that contain SystemVerilog constructs in the source
file. For more information, see Using the Context Help Editor, on
page 108.
If you are using Verilog 2001 format or SystemVerilog, make sure to
enable the Verilog 2001 or System Verilog option before you run synthesis
(Project->Implementation Options->Verilog tab). The default Verilog file
format for new projects is SystemVerilog.
Type a name and location for the file and Click OK. A blank editing
window opens with line numbers on the left.
2. Type the source information in the window, or cut and paste it. See
Editing HDL Source Files with the Built-in Text Editor, on page 111 for
more information on working in the Editing window.
For the best synthesis results, check the Reference Manual and ensure
that you are using the available constructs and vendor-specific attri-
butes and directives effectively.
3. Save the file by selecting File->Save or the Save icon ( ).
Once you have created a source file, you can check that you have the right
syntax, as described in Checking HDL Source Files, on page 110.
LO
102 March 2014
Using the Compiler Directives Editor
Synplify Premier
The Compiler Directives Editor is an advanced text file editor used for
compiler directives. The compiler directives file provides a convenient way to
specify supported directives to be added to the source code. During compila-
tion, the tool passes all active compiler directives files to the compiler.
To use the Compiler Directives Editor:
1. Use File->New and select the file type of Compiler Directives.
2. Specify a new file name and click OK.
A text editor opens for this new compiler directives (cdc) file.
3. You can specify compiler directives as follows:
Type the command; after you type three characters a popup menu
displays the compiler directives command list. Select the command.
March 2014 103
When you hover over a command, a tool tip is displayed for the
selected command. The automatic command completion for the
compiler directive values is not currently available.
For more information about the command syntax, see Compiler Direc-
tives Syntax, on page 105.
4. You can also specify a command by using the compiler directives
browser that displays a command list (the compiler directives syntax
window does not currently support the command values). Click on the
Hide Syntax Help button at the bottom of the editor window to close the
syntax help browser.
Command List Popup Menu
Command Tool Tip
LO
104 March 2014
5. When you save this file, the cdc file gets added to your project in the
Compiler Directive directory if the Add to Project option was checked on the
New dialog box. Thereafter, you can double-click on the cdc file to open
this file in the text editor.
Alternative Method for Creating the Compiler Directives File
Alternatively, you can
1. Use the New Constraint File icon ( ) to select the type of constraint file to
edit. The following dialog box is displayed.
Click on the Hide Syntax Help button to close this browser
March 2014 105
2. Click on
Compiler Directives to open the compiler directives editor
Constraint File (SCOPE) to open the FPGA SCOPE constraint editor
For information about using the FPGA SCOPE editor and compiler direc-
tives editor, see Using the SCOPE Editor, on page 256 and Using the
Compiler Directives Editor, on page 102.
Compiler Directives Syntax
Compiler directives support the following directives:
syn_black_box
syn_noprune
syn_preserve
syn_sharing
syn_rename_module
syn_unique_inst_module
These compiler directives take precedence over the RTL directives, whenever
a conflict exists.
LO
106 March 2014
Example
For example, use the syn_black_box directive to specify that a module or entity
is a black box with only its interface defined for synthesis. The contents of the
black box cannot be optimized during synthesis. This directive is associated
with a module or entity or architecture of an entity in the cdc file and not an
instance or component.
The syn_black_box directive is specified with an implicit Boolean value of 1 or
true.
VHDL
define_directive {v:libraryName.entityName(architectureName)}
{syn_black_box} {1|0}
Where:
libraryName optionally, specifies the name of the library. If undefined,
this defaults to all the design libraries.
entityName defines the name for the entity.
architectureName defines the name of the architecture for the black
box.
1|0 specify 1 to define a module or component as a black box.
VHDL objects are case insensitive.
Verilog/SystemVerilog
define_directive {v:libraryName.moduleName} {syn_black_box} {1|0}
Where:
libraryName optionally, specifies the name of the library. If undefined,
this defaults to all the design libraries.
moduleName defines the name for the module.
1/0 specify 1 to define a module or component as a black box.
Verilog objects are case sensitive.
For Verilog and VHDL examples, see Compiler Directives File Examples, on
page 12.
March 2014 107
A message is generated
if the same entity in the cdc file is found in more than one library
(warning)
if the same entity in the cdc file has more than one architecture
(warning)
for any illegal or unsupported commands found in the cdc file during
compilation (error)
Future releases will not support the define_attribute command in the cdc file
(warning) t is recommended that you use define_directive instead.
When the compiler directives cdc file is added to the Project file, you can
enable/disable a specific cdc file on the Constraints tab of the Implementation
Options panel.
LO
108 March 2014
Using the Context Help Editor
When you create or open a Verilog design file, use the Context Help button
displayed at the bottom of the window to help you code with Verilog/System-
Verilog constructs in the source file or Tcl constraint commands into your Tcl
file.
To use the Context Help Editor:
1. Click on the Context Help button to display this text editor.
March 2014 109
2. When you select a construct in the left-side of the window, the online
help description for the construct is displayed. If the selected construct
has this feature enabled, the online help topic is displayed on the top of
the window and a generic code or command template for that construct
is displayed at the bottom.
3. The Insert Template button is also enabled. When you click the Insert
Template button, the code or command shown in the template window is
inserted into your file at the location of the cursor. This allows you to
easily insert the code or command and modify it for the design that you
are going to synthesize.
4. If you want to copy only parts of the template, select the code or
command you want to insert and click Copy. You can then paste it into
your file.
LO
110 March 2014
Checking HDL Source Files
The software automatically checks your HDL source files when it compiles
them, but if you want to check your source code before synthesis, use the
following procedure. There are two kinds of checks you do in the synthesis
software: syntax and synthesis.
1. Select the source files you want to check.
To check all the source files in a project, deselect all files in the
project list, and make sure that none of the files are open in an active
window. If you have an active source file, the software only checks the
active file.
To check a single file, open the file with File->Open or double-click the
file in the Project window. If you have more than one file open and
want to check only one of them, put your cursor in the appropriate
file window to make sure that it is the active window.
2. To check the syntax, select Run->Syntax Check or press Shift+F7.
The software detects syntax errors such as incorrect keywords and
punctuation and reports any errors in a separate log file (syntax.log). If
no errors are detected, a successful syntax check is reported at the
bottom of this file.
3. To run a synthesis check, select Run->Synthesis Check or press Shift+F8.
The software detects hardware-related errors such as incorrectly coded
flip-flops and reports any errors in a separate log file (syntax.log). If there
are no errors, a successful syntax check is reported at the bottom of this
file.
4. Review the errors by opening the syntax.log file when prompted and use
Find to locate the error message (search for @E). Double-click on the 5-
character error code or click on the message text and push F1 to display
online error message help.
5. Locate the portion of code responsible for the error by double-clicking on
the message text in the syntax.log file. The Text Editor window opens the
appropriate source file and highlights the code that caused the error.
6. Repeat steps 4 and 5 until all syntax and synthesis errors are corrected.
March 2014 111
Messages can be categorized as errors, warnings, or notes. Review all
messages and resolve any errors. Warnings are less serious than errors, but
you must read through and understand them even if you do not resolve all of
them. Notes are informative and do not need to be resolved.
Editing HDL Source Files with the Built-in Text Editor
The built-in text editor makes it easy to create your HDL source code, view it,
or edit it when you need to fix errors. If you want to use an external text
editor, see Using an External Text Editor, on page 116.
1. Do one of the following to open a source file for viewing or editing:
To automatically open the first file in the list with errors, press F5.
To open a specific file, double-click the file in the Project window or
use File->Open (Ctrl-o) and specify the source file.
The Text Editor window opens and displays the source file. Lines are
numbered. Keywords are in blue, and comments in green. String values
are in red. If you want to change these colors, see Setting Editing
Window Preferences, on page 114.
2. To edit a file, type directly in the window.
This table summarizes common editing operations you might use. You
can also use the keyboard shortcuts instead of the commands.
LO
112 March 2014
3. To cut and paste a section of a PDF document, select the T-shaped Text
Select icon, highlight the text you need and copy and paste it into your
file. The Text Select icon lets you select parts of the document.
4. To create and work with bookmarks in your file, see the following table.
Bookmarks are a convenient way to navigate long files or to jump to
points in the code that you refer to often. You can use the icons in the
Edit toolbar for these operations. If you cannot see the Edit toolbar on the
far right of your window, resize some of the other toolbars.
To ... Do ...
Cut, copy, and paste;
undo, or redo an action
Select the command from the popup (hold down
the right mouse button) or Edit menu.
Go to a specific line Press Ctrl-g or select Edit->Go To, type the line
number, and click OK.
Find text Press Ctrl-f or select Edit ->Find. Type the text you
want to find, and click OK.
Replace text Press Ctrl-h or select Edit->Replace. Type the text you
want to find, and the text you want to replace it
with. Click OK.
Complete a keyword Type enough characters to uniquely identify the
keyword, and press Esc.
Indent text to the right Select the block, and press Tab.
Indent text to the left Select the block, and press Shift-Tab.
Change to upper case Select the text, and then select Edit->Advanced
->Uppercase or press Ctrl-Shift-u.
Change to lower case Select the text, and then select Edit->Advanced
->Lowercase or press Ctrl-u.
Add block comments Put the cursor at the beginning of the comment
text, and select Edit->Advanced->Comment Code or
press Alt-c.
Edit columns Press Alt, and use the left mouse button to select
the column. On some platforms, you have to use
the key to which the Alt functionality is mapped,
like the Meta or diamond key.
March 2014 113
5. To fix errors or review warnings in the source code, do the following:
Open the HDL file with the error or warning by double-clicking the file
in the project list.
Press F5 to go to the first error, warning, or note in the file. At the
bottom of the Editing window, you see the message text.
To go to the next error, warning, or note, select Run->Next Error/Warning
or press F5. If there are no more messages in the file, you see the
message No More Errors/Warnings/Notes at the bottom of the
Editing window. Select Run->Next Error/Warning or press F5 to go to the
the error, warning, or note in the next file.
To navigate back to a previous error, warning, or note, select
Run->Previous Error/Warning or press Shift-F5.
6. To bring up error message help for a full description of the error,
warning, or note:
Open the text-format log file (click View Log) and either double click on
the 5-character error code or click on the message text and press F1.
To ... Do ...
Insert a
bookmark
Click anywhere in the line you want to bookmark.
Select Edit->Toggle Bookmarks, press Ctrl-F2, or select the
first icon in the Edit toolbar.
The line number is highlighted to indicate that there is a
bookmark at the beginning of that line.
Delete a
bookmark
Click anywhere in the line with the bookmark.
Select Edit->Toggle Bookmarks, press Ctrl-F2, or select the
first icon in the Edit toolbar.
The line number is no longer highlighted after the
bookmark is deleted.
Delete all
bookmarks
Select Edit->Delete all Bookmarks, press Ctrl-Shift-F2, or select
the last icon in the Edit toolbar.
The line numbers are no longer highlighted after the
bookmarks are deleted.
Navigate a file
using
bookmarks
Use the Next Bookmark (F2) and Previous Bookmark (Shift-F2)
commands from the Edit menu or the corresponding icons
from the Edit toolbar to navigate to the bookmark
you want.
LO
114 March 2014
Open the HTML log file and click on the 5-character error code.
In the Tcl window, click the Messages tab and click on the 5-character
error code in the ID column.
7. To cross probe from the source code window to other views, open the
view and select the piece of code. See Crossprobing from the Text Editor
Window, on page 424 for details.
8. When you have fixed all the errors, select File->Save or click the Save icon
to save the file.
Setting Editing Window Preferences
You can customize the fonts and colors used in a Text Editing window.
1. Select Options->Editor Options and either Synopsys Editor or External Editor. For
more information about the external editor, see Using an External Text
Editor, on page 116.
2. Then depending on the type of file you open, you can to set the
background, syntax coloring, and font preferences to use with the text
editor.
Note: Thereafter, text editing preferences you set for this file will apply
to all files of this file type.
The Text Editing window can be used to set preferences for project files,
source files (Verilog/VHDL), log files, Tcl files, constraint files, or other
default files from the Editor Options dialog box.
3. You can set syntax colors for some common syntax options, such as
keywords, strings, and comments. For example in the log file, warnings
and errors can be color-coded for easy recognition.
Click in the Foreground or Background field for the corresponding object in
the Syntax Coloring field to display the color palette.
March 2014 115
You can select basic colors or define custom colors and add them to
your custom color palette. To select your desired color click OK.
4. To set font and font size for the text editor, use the pull-down menus.
5. Check Keep Tabs to enable tab settings, then set the tab spacing using
the up or down arrow for Tab Size.
6. Click OK on the Editor Options form.
LO
116 March 2014
Using an External Text Editor
You can use an external text editor like vi or emacs instead of the built-in text
editor. Do the following to enable an external text editor. For information
about using the built-in text editor, see Editing HDL Source Files with the
Built-in Text Editor, on page 111.
1. Select Options->Editor Options and turn on the External Editor option.
2. Select the external editor, using the method appropriate to your
operating system.
If you are working on a Windows platform, click the ... (Browse)
button and select the external text editor executable.
From a UNIX or Linux platform for a text editor that creates its own
window, click the ... Browse button and select the external text editor
executable.
From a UNIX platform for a text editor that does not create its own
window, do not use the ... Browse button. Instead type xterm -e editor.
The following figure shows VI specified as the external editor.
March 2014 117
From a Linux platform, for a text editor that does not create its own
window, do not use the ... Browse button. Instead, type gnome-terminal
-x editor. To use emacs for example, type gnome-terminal -x emacs.
The software has been tested with the emacs and vi text editors.
3. Click OK.
Using Library Extensions for Verilog Library Files
Library extensions can be added to Verilog library files included in your
design for the project. When you provide search paths to the directories that
contain the Verilog library files, you can specify these new library extensions
as well as the Verilog and SystemVerilog (.v and .sv) file extensions.
To do this:
1. Select the Verilog tab of the Implementation Options panel.
LO
118 March 2014
2. Specify the locations of the Library Directories for the Verilog library files to
be included in your design for the project.
3. Specify the Library Extensions.
Any library extensions can be specified, such as .av, .bv, .cv, .xxx, .va,
.vas (separate library extensions with a space).
The following figure shows you where to enter the library extensions on
the dialog box.
The Tcl equivalent for this example is the following command:
set_option -libext .av .bv .cv .dv .ev
For details, see libext, on page 110 in the Command Reference.
4. After you compile the design, you can verify in the log file that the library
files with these extensions were loaded and read. For example:
March 2014 119
@N: Running Verilog Compiler in SystemVerilog mode
@I::C:\dir\top.v"
@N: CG1180 :"C:\dir\top.v":8:0:8:3|Loading file
C:\dir\lib1\sub1.av from specified library directory
C:\dir\lib1
@I::"C:\dir\lib1\sub1.av"
C:\dir\lib2\sub2.bv from specified library directory
C:\dir\lib2
@I::"C:\dir\lib2\sub2.bv"
C:\dir\lib3\sub3.cv from specified library directory
C:\dir\lib3
@I::"C:\dir\lib3\sub3.cv"
C:\dir\lib4\sub4.dv from specified library directory
C:\dir\lib4
@I::"C:\dir\lib4\sub4.dv"
C:\dir\lib5\sub5.ev from specified library directory
C:\dir\lib5
@I::"C:\dir\lib5\sub5.ev"
Verilog syntax check successful!
LO
Chapter 3: Preparing the Input Using Mixed Language Source Files
120 March 2014
Using Mixed Language Source Files
Synplify Pro and Synplify Premier
With the synthesis software, you can use a mixture of VHDL and Verilog
input files in your project. For examples of the VHDL and Verilog files, see the
Reference Manual. You cannot use Verilog and VHDL files together in the
same design with the Synplify tool.
1. Remember that Verilog does not support unconstrained VHDL ports and
set up the mixed language design files accordingly.
2. If you want to organize the Verilog and VHDL files in different folders,
select Options->Project View Options and toggle on the View Project Files in
Folders option.
When you add the files to the project, the Verilog and VHDL files are in
separate folders in the Project view.
3. When you open a project or create a new one, add the Verilog and VHDL
files as follows:
Select the Project->Add Source File command or click the Add File button.
On the form, set Files of Type to HDL Files (*.vhd, *.vhdl, *.v).
Select the Verilog and VHDL files you want and add them to your
project. Click OK. For details about adding files to a project, see
Making Changes to a Project, on page 140.
Using Mixed Language Source Files Chapter 3: Preparing the Input
March 2014 121
The files you added are displayed in the Project view. This figure shows
the files arranged in separate folders.
4. When you set device options (Implementation Options button), specify the
top-level module. For more information about setting device options, see
Setting Logic Synthesis Implementation Options, on page 152.
If the top-level module is Verilog, click the Verilog tab and type the
name of the top-level module.
If the top-level module is VHDL, click the VHDL tab and type the name
of the top-level entity. If the top-level module is not located in the
default work library, you must specify the library where the compiler
can find the module. For information on how to do this, see VHDL
Panel, on page 314.
LO
122 March 2014
You must explicitly specify the top-level module, because it is the
starting point from which the mapper generates a merged netlist.
5. Select the Implementation Results tab on the same form and select one
output HDL format for the output files generated by the software. For
more information about setting device options, see Setting Logic
Synthesis Implementation Options, on page 152.
For a Verilog output netlist, select Write Verilog Netlist.
For a VHDL output netlist, select Write VHDL Netlist.
Set any other device options and click OK.
You can now synthesize your design. The software reads in the mixed
formats of the source files and generates a single srs file that is used for
synthesis.
6. If you run into problems, see Troubleshooting Mixed Language Designs,
on page 123 for additional information and tips.
Using Mixed Language Source Files Chapter 3: Preparing the Input
March 2014 123
Troubleshooting Mixed Language Designs
This section provides tips on handling specific situations that might come up
with mixed language designs.
VHDL File Order
For VHDL-only designs or mixed designs where the top level is not specified,
the FPGA synthesis tools automatically re-arrange the VHDL files so that the
VHDL packages are compiled in the correct order.
However, if you have a mixed-language design where you have specified the
top level, you must specify the VHDL file order for the tool. You only need to
do this once, by selecting the Run->Arrange VHDL files command. If you do not
do this, you get an error message
VHDL Global Signals
Currently, you cannot have VHDL global signals in mixed language designs,
because the tool only implements these signals in VHDL-only designs.
Passing VHDL Boolean Generics to Verilog Parameters
The tool infers a black box for a VHDL component with Boolean generics, if
that component is instantiated in a Verilog design. This is because Verilog
does not recognize Boolean data types, so the Boolean value must be repre-
sented correctly. If the value of the VHDL Boolean generic is TRUE and the
Verilog literal is represented by a 1, the Verilog compiler interprets this as a
black box.
To avoid inferring a black box, the Verilog literal for the VHDL Boolean
generic set to TRUE must be 1b1, not 1. Similarly, if the VHDL Boolean generic
is FALSE, the corresponding Verilog literal must be 1b0, not 0. The following
example shows how to represent Boolean generics so that they correctly pass
the VHDL-Verilog boundary, without inferring a black box.
VHDL Entity Declaration Verilog Instantiation
Entity abc is
Generic
(
Number_Bits : integer := 0;
Divide_Bit : boolean := False;
);
abc #(
.Number_Bits (16),
.Divide_Bit (1'b0)
)
LO
124 March 2014
Passing VHDL Generics Without Inferring a Black Box
In the case where a Verilog component parameter, (for example [0:0] RSR =
1'b0) does not match the size of the corresponding VHDL component generic
(RSR : integer := 0), the tool infers a black box.
You can work around this by removing the bus width notation of [0:0] in the
Verilog files. Note that you must use a VHDL generic of type integer because
the other types do not allow for the proper binding of the Verilog component.
Using the Incremental Compiler Chapter 3: Preparing the Input
March 2014 125
Using the Incremental Compiler
Synplify Premier Tools
Use the Incremental Compiler flow to significantly reduce compiler runtime
for large designs. The software recompiles only relevant files when a design
change is made and reuses the compiler database. The compiler regenerates
the SRS file only for the affected module and immediate parent module.
To run this flow, perform the following:
1. Add the Verilog or VHDL files for the design.
2. Enable the Incremental Compile option from the Verilog or VHDL tab of the
Implementation Options panel.
An SRS file is created for each design module in the synwork directory.
3. Run the compiler for the first time.
4. If a design change was made, re-run the compiler.
The compiler analyzes the database and determines whether the SRS
files are up-to-date, then only modules that have changed and the
immediate parent modules are regenerated. This can help improve the
runtime for the design.
LO
Chapter 3: Preparing the Input Using the Incremental Compiler
126 March 2014
Limitations
The incremental compiler does not support:
Configuration files included in either the Verilog or VHDL flow
Mixed HDL flows
Designs with cross module referencing (XMR)
Using the Structural Verilog Flow Chapter 3: Preparing the Input
March 2014 127
Using the Structural Verilog Flow
Synplify Pro, Synplify Premier
Microsemi and Xilinx Technologies
The synthesis tool accepts structural Verilog files as input for your design
project. The structural Verilog compiler performs syntax semantic checks
using its light-weight parser to improve runtime. This compiler does not
perform complex hardware extractions or RTL optimization operations,
therefore, the software runs fast compilation of the structural Verilog files.
The software can read these generated structural Verilog files, if they contain:
Instantiations of technology primitives
Simple assign statements
Attributes specified in Verilog 2001 and older formats
All constructs, except attributes must be specified in Verilog 95 format
To use structural Verilog input files:
1. You must specify the structural Verilog files to include in your design.
To do this, add the file to the project using one of the following methods:
Project->Add Source File or the Add File button in the Project view
Tcl command: add_file -structver fileName
This flow can contain only structural Verilog files or mixed HDL files
(Verilog/VHDL/EDF/SRS) along with structural Verilog netlist files.
However, Verilog/VHDL/EDF/SRS instances are not supported within a
structural Verilog module.
2. The structural Verilog files are added to the Structural Verilog folder in the
Project view. You can also add files to this directory, when you perform
the following:
Select the structural Verilog file.
Right-click and select File Options.
Choose Structural Verilog from the File Type drop-down menu.
LO
Chapter 3: Preparing the Input Using the Structural Verilog Flow
128 March 2014
3. Run synthesis.
The synthesis tool generates a vm or edf netlist file depending on the
technology specified. This process is similar to the default synthesis
flow.
Limitations
Limitations of the structural Verilog flow does not support the following:
RTL instances for any other file types
Hierarchical project management (HPM) flows
Complex assignments
Compiler-specific modes and switches
Working with Constraint Files Chapter 3: Preparing the Input
March 2014 129
Working with Constraint Files
Constraint files are text files that are automatically generated by the SCOPE
interface (see Specifying SCOPE Constraints, on page 263), or which you
create manually with a text editor. They contain Tcl commands or attributes
that constrain the synthesis run. Alternatively, you can set constraints in the
source code, but this is not the preferred method.
This section contains information about
When to Use Constraint Files over Source Code, on page 129
Using a Text Editor for Constraint Files (Legacy), on page 130
Tcl Syntax Guidelines for Constraint Files, on page 130
Checking Constraint Files, on page 132
Generating Constraint Files for Forward Annotation, on page 132
When to Use Constraint Files over Source Code
You can add constraints in constraint files (generated by SCOPE interface or
entered in a text editor) or in the source code. In general, it is better to use
constraint files, because you do not have to recompile for the constraints to
take effect. It also makes your source code more portable. See Using the
SCOPE Editor, on page 256 for more information.
However, if you have black box timing constraints like syn_tco, syn_tpd, and
syn_tsu, you must enter them as directives in the source code. Unlike attri-
butes, directives can only be added to the source code, not to constraint files.
See Specifying Attributes and Directives, on page 169 for more information
on adding directives to source code.
LO
Chapter 3: Preparing the Input Working with Constraint Files
130 March 2014
Using a Text Editor for Constraint Files (Legacy)
You can use the Legacy SCOPE editor for the SDC constraint files created
before release version G-2012.09. However, it is recommended that you
translate your SDC files to FDC files to enable the latest version of the SCOPE
editor and to utilize the enhanced timing constraint handling in the tool.
If you choose to use the legacy SCOPE editor, this section shows you how to
manually create a Tcl constraint file. The software automatically creates this
file if you use the legacy SCOPE editor to enter the constraints. The Tcl
constraint file only contains general timing constraints. Black box
constraints must be entered in the source code. For additional information,
see When to Use Constraint Files over Source Code, on page 129.
1. Open a file for editing.
Make sure you have closed the SCOPE window, or you could
overwrite previous constraints.
To create a new file, select File->New, and select the Constraints File
(SCOPE) option. Type a name for the file and click OK.
To edit an existing file, select File->Open, set the Files of Type filter to
Constraint Files (sdc) and open the file you want.
2. Follow the syntax guidelines in Tcl Syntax Guidelines for Constraint Files,
on page 130.
3. Enter the timing constraints you need. For the syntax, see the Reference
Manual. If you have black box timing constraints, you must enter them
in the source code.
4. You can also add vendor-specific attributes in the constraint file using
define_attribute. See Specifying Attributes in the Constraints File, on
page 177 for more information.
5. Save the file.
6. Add the file to the project as described in Making Changes to a Project,
on page 140, and run synthesis.
Tcl Syntax Guidelines for Constraint Files
This section covers general guidelines for using Tcl for constraint files:
Tcl is case-sensitive.
March 2014 131
For naming objects:
The object name must match the name in the HDL code.
Enclose instance and port names within curly braces { }.
Do not use spaces in names.
Use the dot (.) to separate hierarchical names.
In Verilog modules, use the following syntax for instance, port, and
net names:
v:cell [prefix:]objectName
Where cell is the name of the design entity, prefix is a prefix to identify
objects with the same name, objectName is an instance path with the
dot (.) separator. The prefix can be any of the following:
In VHDL modules, use the following syntax for instance, port, and net
names in VHDL modules:
v:cell [.view] [prefix:]objectName
Where v: identifies it as a view object, lib is the name of the library,
cell is the name of the design entity, view is a name for the
architecture, prefix is a prefix to identify objects with the same name,
and objectName is an instance path with the dot (.) separator. View is
only needed if there is more than one architecture for the design. See
the table above for the prefixes of objects.
Name matching wildcards are * (asterisk matches any number of
characters) and ? (question mark matches a single character). These
characters do not match dots used as hierarchy separators. For
example, the following string identifies all bits of the statereg instance in
the statemod module:
i:statemod.statereg[*]
Prefix (Lower-case) Object
i: Instance names
p: Port names (entire port)
b: Bit slice of a port
n: Net names
LO
Chapter 3: Preparing the Input Working with Constraint Files
132 March 2014
Checking Constraint Files
You can check syntax and other pertinent information on your constraint
files using the Constraint Check command. To generate a constraint report, do
the following:
1. Create a constraint file and add it to your project.
2. Select Run->Constraint Check.
This command generates a report that checks the syntax and applica-
bility of the timing constraints in the FPGA synthesis constraint files for
your project. The report is written to the projectName_cck.rpt file and lists
the following information:
Constraints that are not applied
Constraints that are valid and applicable to the design
Wildcard expansion on the constraints
Constraints on objects that do not exist
For details on this report, see Constraint Checking Report, on page 328
of the Reference Manual.
Generating Constraint Files for Forward Annotation
The tool automatically generates vendor-specific constraint files that you can
use for forward-annotation. The synthesis constraints are mapped to the
appropriate vendor constraints.You can control this process with some attri-
butes as described in the following procedure.
1. Set attributes to control forward annotation.
To forward-annotate timing constraints for Microsemi Axcelerator,
Fusion, ProASIC (500K), ProASIC Plus (PA), and ProASIC3/3E /3L
families, set the clock period, max delay, input delay, output delay,
multiple-cycle paths, and false paths in the SCOPE interface.
To forward-annotate I/O constraints (define_input_delay and
define_output_delay) to the tcl file for Altera designs or the synplicity.ucf
file for Xilinx designs, set syn_forward_io_constraints with a value of 1 on
the top level of the design or as a global attribute.
To forward-annotate clocks for Xilinx DCMs and DLLs, define the
clock at the primary inputs and any Xilinx phase shift and frequency
March 2014 133
multiplication properties you need. See Defining Other Clock
Requirements, on page 314 for details. The synthesis software
forward-annotates the DLL/DCM inputs.
To forward-annotate clocks for Altera PLLs, define the input
frequency value. See Defining Other Clock Requirements, on
page 314 for details. The synthesis software forward-annotates the
PLL inputs.
For some Lattice designs, set the -from and -to false path and multi-
cycle constraints on the Others tab of the SCOPE interface.
For details about these attributes, see the Reference Manual.
2. Select Project->Implementation Options, and check Write Vendor Constraints in
the Implementation Results tab.
Currently you can forward-annotate constraints for some vendors only.
3. Click OK and run synthesis.
The software converts the synthesis define_input_delay, define_output_delay,
define_clock (including the define_clock constraints generated by auto
constraining), define_multicycle_path, define_false_path, define_max_delay, and
global-frequency constraints into corresponding commands in the
following files:
acf file for Altera
filename_sdc.sdc file for Microsemi
synplicity.ucf file for Xilinx
$DESIGN_synplify.lpf file for Lattice
Open the Lattice ispLEVER place-and-route tool, then import the
$DESIGN_synplify.lpf file before running PAR. If a user-created lpf file
already exists, ispLEVER backs it up into lpf.bak and copies the
contents of $DESIGN_synplify.lpf into the $DESIGN.lpf file which is then
used for all computations.
See the Reference Manual for details about forward annotation.
LO
Chapter 3: Preparing the Input Using Input from Related Tools
134 March 2014
Using Input from Related Tools
The following show you how to incorporate input from other tools like System
Designer and the Synplify DSP tool.
Using Input from System Designer
You use System Designer to import and stitch together IP. To incorporate
these components in your design, include the following files generated by
System Designer in your synthesis project:
Synplify sub-library file synthesis.slib
HDL files
VHDL files in vhdl folder and Verilog files in the verilog folder in the project
directory.
Using Input from the Synphony Model Compiler Tool
The Synphony Model Compiler tool generates IP for DSP designs. Include this
in your synthesis project by adding the source files generated by these tools.
March 2014 135
CHAPTER 4
Setting up a Logic Synthesis Project
When you synthesize a design with the Synopsys FPGA synthesis tools, you
must set up a project for your design. The following describe the procedures
for setting up a project for logic synthesis:
Setting Up Project Files, on page 136
Managing Project File Hierarchy, on page 144
Setting Up Implementations, on page 150
Setting Logic Synthesis Implementation Options, on page 152
Specifying Attributes and Directives, on page 169
Working with Hierarchical Projects, on page 178
Searching Files, on page 211
Archiving Files and Projects, on page 214
To set up a physical synthesis project, you follow the steps for setting up a
logic synthesis project, and then additionally follow the procedures described
in Chapter 5, Setting up a Physical Synthesis Project.
LO
Chapter 4: Setting up a Logic Synthesis Project Setting Up Project Files
136 March 2014
Setting Up Project Files
This section describes the basics of how to set up and manage a project file
for your design, including the following information:
Creating a Project File, on page 136
Opening an Existing Project File, on page 139
Making Changes to a Project, on page 140
Setting Project View Display Preferences, on page 141
Updating Verilog Include Paths in Older Project Files, on page 143
For a specific example on setting up a project file, refer to the tutorial for the
tool you are using.
For information about working with hierarchical projects, refer to Working
with Hierarchical Projects, on page 178.
Creating a Project File
You must set up a project file for each project. A project contains the data
needed for a particular design: the list of source files, the synthesis results
file, and your device option settings. The following procedure shows you how
to set up a project file using individual commands.
1. Start by selecting one of the following: File->Build Project, File->Open Project,
or the P icon. Click New Project.
The Project window shows a new project. Click the Add File button, press
F4, or select the Project->Add Source File command. The Add Files to Project
dialog box opens.
Make sure the Look in field at the top of the form points to the right
directory. The files are listed in the box. If you do not see the files,
check that the Files of Type field is set to display the correct file type. If
you have mixed input files, follow the procedure described in Using
Mixed Language Source Files, on page 120.
Setting Up Project Files Chapter 4: Setting up a Logic Synthesis Project
March 2014 137
To add all the files in the directory at once, click the Add All button on
the right side of the form. To add files individually, click on the file in
the list and then click the Add button, or double-click the file name.
You can add all the files in the directory and then remove the ones
you do not need with the Remove button.
If you are adding VHDL files, select the appropriate library from the
the VHDL Library popup menu. The library you select is applied to all
VHDL files when you click OK in the dialog box.
Your project window displays a new project file. If you click on the plus
sign next to the project and expand it, you see the following:
A folder (two folders for mixed language designs) with the source files.
If your files are not in a folder under the project directory, you can set
this preference by selecting Options->Project View Options and checking
the View project files in folders box. This separates one kind of file from
another in the Project view by putting them in separate folders.
LO
138 March 2014
The implementation, named rev_1 by default. Implementations are
revisions of your design within the context of the synthesis software,
and do not replace external source code control software and
processes. Multiple implementations let you modify device and
synthesis options to explore design options. You can have multiple
implementations in the Synplify Premier and Synplify Pro tools, but
not in the Synplify tool. Each implementation has its own synthesis
and device options and its own project-related files.
3. Add any libraries you need, using the method described in the previous
step to add the Verilog or VHDL library file.
For vendor-specific libraries, add the appropriate library file to the
project. Note that for some families, the libraries are loaded
automatically and you do not need to explicitly add them to the
project file.
To add a third-party VHDL package library, add the appropriate vhd
file to the design, as described in step 2. Right click the file in the
Project view and select File Options, or select Project-> Set VHDL library.
Specify a library name that is compatible with the simulators. For
example, MYLIB. Make sure that this package library is before the top-
level design in the list of files in the Project view.
For information about setting Verilog and VHDL file options, see
Setting Verilog and VHDL Options, on page 163. You can also set
these file options later, before running synthesis.
For additional vendor-specific information about using vendor macro
libraries and black boxes, see Optimizing Microsemi Designs, on
page 1027, Optimizing Altera Designs, on page 998, Optimizing
March 2014 139
Lattice Designs, on page 1010, and Optimizing Xilinx Designs, on
page 1032.
For generic technology components, you can either add the
technology-independent Verilog library supplied with the software
(install_dir/lib/generic_ technology/gtech.v) to your design, or add your
own generic component library. Do not use both together as there
may be conflicts.
4. Check file order in the Project view. File order is especially important for
VHDL files.
For VHDL files, you can automatically order the files by selecting Run-
>Arrange VHDL Files. Alternatively, manually move the files in the
Project view. Package files must be first on the list because they are
compiled before they are used. If you have design blocks spread over
many files, make sure you have the following file order: the file
containing the entity must be first, followed by the architecture file, and
finally the file with the configuration.
In the Project view, check that the last file in the Project view is the
top-level source file. Alternatively, you can specify the top-level file
when you set the device options.
5. Select File->Save, type a name for the project, and click Save. The Project
window reflects your changes.
6. To close a project file, select the Close Project button or File->Close Project.
Opening an Existing Project File
There are two ways to open a project file: the Open Project and the generic File
->Open command.
1. If the project you want to open is one you worked on recently, you can
select it directly: File->Recent Projects-> projectName.
LO
140 March 2014
2. Use one of the following methods to open any project file:
The project opens in the Project window.
Making Changes to a Project
Typically, you add, delete, or replace files.
1. To add source or constraint files to a project, select the Add Files button
or Project->Add Source File to open the Select Files to Add to Project dialog box.
See Creating a Project File, on page 136 for details.
2. To delete a file from a project, click the file in the Project window, and
press the Delete key.
3. To replace a file in a project,
Select the file you want to change in the Project window.
Click the Change File button, or select Project->Change File.
In the Source File dialog box that opens, set Look In to the directory
where the new file is located. The new file must be of the same type as
the file you want to replace.
If you do not see your file listed, select the type of file you need from
the Files of Type field.
Double-click the file. The new file replaces the old one in the project
list.
Open Project Command File->Open Command
Select File->Open Project, click the
Open Project button on the left side of
the Project window, or click the
P icon.
To open a recent project, double-
click it from the list of recent
projects.
Otherwise, click the Existing Project
button to open the Open dialog box
and select the project.
Select File->Open.
Specify the correct directory in the Look
In: field.
Set File of Type to Project Files (*.prj). The
box lists the project files.
Double-click on the project you want
to open.
March 2014 141
4. To specify how project files are saved in the project, right click on a file
in the Project view and select File Options. Set the Save File option to either
Relative to Project or Absolute Path.
5. To check the time stamp on a file, right click on a file in the Project view
and select File Options. Check the time that the file was last modified.
Click OK.
Setting Project View Display Preferences
You can customize the organization and display of project files.
1. Select Options->Project View Options.
The Project View Options form opens. Available options vary, depending on
the tool. The Synplify Premier and Synplify Pro options are the same.
2. To organize different kinds of input files in separate folders, check View
Project Files in Folders.
Synplify Pro and Synplify Premier Options
Synplify Options
LO
142 March 2014
Checking this option creates separate folders in the Project view for
constraint files and source files.
3. Control file display with the following:
Automatically display all the files, by checking Show Project Library. If
this is unchecked, the Project view does not display files until you
click on the plus symbol and expand the files in a folder.
Check one of the boxes in the Project File Name Display section of the
form to determine how filenames are displayed. You can display just
the filename, the relative path, or the absolute path.
4. To view project files in customized custom folders, check View Project Files
in Custom Folders. For more information, see Creating Custom Folders, on
page 144. Type folders are only displayed if there are multiple types in a
custom folder.
Custom
Folders
March 2014 143
5. To open more than one implementation in the same Project view, check
Allow Multiple Projects to be Opened. You can only use multiple
implementations with the Synplify Pro and Synplify Premier tools.
6. Control the output file display with the following:
Check the Show all Files in Results Directory box to display all the output
files generated after synthesis.
Change output file organization by clicking in one of the header bars
in the Implementation Results view. You can group the files by type
or sort them according to the date they were last modified.
7. To view file information, select the file in the Project view, right-click,
and select File Options. For example, you can check the date a file was
modified.
Updating Verilog Include Paths in Older Project Files
If you have a project file created with an older version of the software (prior to
8.1), the Verilog include paths in this file are relative to the results directory or
the source file with the ìnclude statements. In releases after 8.1, the project
file ìnclude paths are relative to the project file only. The GUI in the more
recent releases does not automatically upgrade the older prj files to conform
to the newer rules. To upgrade and use the old project file, do one of the
following:
Manually edit the prj file in a text editor and add the following on the
line before each set_option -include_path:
set_option -project_relative_includes 1
Start a new project with a newer version of the software and delete the
old project. This will make the new prj file obey the new rule where
includes are relative to the prj file.
Project 2
Project 1
LO
Chapter 4: Setting up a Logic Synthesis Project Managing Project File Hierarchy
144 March 2014
Managing Project File Hierarchy
The following sections describe how you can create and manage customized
folders and files in the Project view:
Creating Custom Folders
Manipulating Custom Project Folders
Manipulating Custom Files
This information applies to file management; for information about managing
and working with hierarchical projects, see Working with Hierarchical
Creating Custom Folders
You can create logical folders and customize files in various hierarchy group-
ings within your Project view. These folders can be specified with any name or
hierarchy level. For example, you can arbitrarily match your operating
system file structure or HDL logic hierarchy. Custom folders are distin-
guished by their blue color.
There are several ways to create custom folders and then add files to them in
a project. Use one of the following methods:
1. Right-click on a project file or another custom folder and select Add Folder
from the popup menu. Then perform any of the following file operations:
Right-click on a file or files and select Place in Folder. A sub-menu
displays so that you can either select an existing folder or create a
new folder.
Managing Project File Hierarchy Chapter 4: Setting up a Logic Synthesis Project
March 2014 145
Note that you can arbitrarily name the folder, however do not use the
character (/) because this is a hierarchy separator symbol.
To rename a folder, right-click on the folder and select Rename from
the popup menu. The Rename Folder dialog box appears; specify a new
name.
2. Use the Add Files to Project dialog box to add the entire contents of a folder
hierarchy, and optionally place files into custom folders corresponding
to the OS folder hierarchies listed in the dialog box display.
To do this, select the Add File button in the Project view.
Select any requested folders such as dsp from the dialog box, then
click the Add button. This places all the files from the dsp hierarchy
into the custom folder you just created.
LO
146 March 2014
To automatically place the files into custom folders corresponding to
the OS folder hierarchy, check the option called Add Files to Custom
Folders on the dialog box.
By default, the custom folder name is the same name as the folder
containing files or folder to be added to the project. However, you can
modify how folders are named, by clicking on the Folders Option
button. The following dialog box is displayed.
To use:
Only the folder containing files for the folder name, click on Use OS
Folder Name.
The path name to the selected folder to determine the level of
hierarchy reflected for the custom folder path.
3. You can drag and drop files and folders from an OS Explorer application
into the Project view. This feature is available on Windows and Linux
desktops running KDE.
When you drag and drop a file, it is immediately added to the project.
If no project is open, the software creates a project.
When you drag and drop a file over a folder, it will be placed in that
folder. Initially, the Add Files to Project dialog box is displayed asking
you to confirm the files to be added to the project. You can click OK to
March 2014 147
accept the files. If you want to make changes, you can click the
Remove All button and specify a new filter or option.
Note: To display custom folders in the Project view, select the
Options->Project View Options menu, then enable/disable the check
box for View Project Files in Custom Folders on the dialog box.
Manipulating Custom Project Folders
The following procedure describes how you can remove files from folders,
delete folders, and change the folder hierarchy.
1. To remove a file from a custom folder, either:
Drag and drop it into another folder or onto the project.
Highlight the file, right-click and select Remove from Folder from the
popup menu.
Do not use the Delete (DEL) key, as this removes the file from the
project.
2. To delete a custom folder, highlight it then right-click and select Delete
from the popup menu or press the DEL key. When you delete a folder,
make one of the following choices:
Click Yes to delete the folder and the files contained in the folder from
the project.
Click No to just delete the folder.
3. To change the hierarchy of the custom folder:
Drag and drop the folder within another folder so that it is a sub-
folder or over the project to move it to the top-level.
To remove the top-level hierarchy of a custom folder, drag and drop
the desired sub-level of hierarchy over the project. Then delete the
empty root directory for the folder.
For example, if the existing custom folder directory is:
/Examples/Verilog/RTL
LO
148 March 2014
Suppose you want a single-level RTL hierarchy only, then drag and
drop RTL over the project. Thereafter, you can delete the
/Examples/Verilog directory.
Manipulating Custom Files
Additionally, you can perform the following types of custom file operations:
1. To suppress the display of files in the Type folders, right-click in the
Project view and select Project View Options or select Options->Project View
Options. Disable the option View Project Files in Type Folders on the dialog
box.
2. To display files in alphabetical order instead of project order, check the
Sort Files button in the Project view control panel. Click the down arrow
key in the bottom-left corner of the panel to toggle the control panel on
and off.
Control Panel Toggle
March 2014 149
3. To change the order of files in the project:
Make sure to disable custom folders and sorting files.
Drag and drop a file to the desired position in the list of files.
4. To change the file type, drag and drop it to the new type folder. The
software will prompt you for verification.
LO
Chapter 4: Setting up a Logic Synthesis Project Setting Up Implementations
150 March 2014
Setting Up Implementations
An implementation is a version of a project, implemented with a specific set of
constraints and other settings. A project can contain multiple implementa-
tions, each one with its own settings.
Working with Multiple Implementations
The synthesis tools let you create multiple implementations of the same
design and then compare results. This lets you experiment with different
settings for the same design. Implementations are revisions of your design
within the context of the synthesis software, and do not replace external
source code control software and processes.
1. Click the Add Implementation button or select Project->New Implementation
and set new device options (Device tab), new options (Options tab), or a
new constraint file (Constraints tab).
The software creates another implementation in the project view. The
new implementation has the same name as the previous one, but with a
different number suffix. The following figure shows two implementa-
tions, rev1 and rev2, with the current (active) implementation highlighted.
The new implementation uses the same source code files, but different
device options and constraints. It copies some files from the previous
implementation: the tlg log file, the srs RTL netlist file, and the
design_fsm.sdc file generated by FSM Explorer. The software keeps a
repeatable history of the synthesis runs.
2. Run synthesis again with the new settings.
To run the current implementation only, click Run.
To run all the implementations in a project, select Run->Run All
Implementations.
Setting Up Implementations Chapter 4: Setting up a Logic Synthesis Project
March 2014 151
You can use multiple implementations to try a different part or experi-
ment with a different frequency. See Setting Logic Synthesis Implemen-
tation Options, on page 152 for information about setting options.
The Project view shows all implementations with the active implementa-
tion highlighted and the corresponding output files generated for the
active implementation displayed in the Implementation Results view on
the right; changing the active implementation changes the output file
display. The Watch window monitors the active implementation. If you
configure this window to watch all implementations, the new implemen-
tation is automatically updated in the window.
3. Compare the results.
Use the Watch window to compare selected criteria. Make sure to set
the implementations you want to compare with the Configure Watch
command. See Using the Watch Window, on page 352 for details.
To compare details, compare the log file results.
4. To rename an implementation, click the right mouse button on the
implementation name in the project view, select Change Implementation
Name from the popup menu, and type a new name.
Note that the current UI overwrites the implementation; releases prior to
9.0 preserve the implementation to be renamed.
5. To copy an implementation, click the right mouse button on the
implementation name in the project view, select Copy Implementation from
the popup menu, and type a new name for the copy.
6. To delete an implementation, click the right mouse button on the
implementation name in the project view, and select Remove
Implementation from the popup menu.
LO
Chapter 4: Setting up a Logic Synthesis Project Setting Logic Synthesis Implementation Options
152 March 2014
Setting Logic Synthesis Implementation Options
You can set global options for your synthesis implementations, some of them
technology-specific. This section describes how to set global options like
device, optimization, and file options with the Implementation Options command.
For information about setting constraints for the implementation, see Speci-
fying SCOPE Constraints, on page 263. For information about overriding
global settings with individual attributes or directives, see Specifying Attri-
butes and Directives, on page 169.
This section discusses the following topics:
Setting Device Options, on page 152
Setting Optimization Options, on page 155
Specifying Global Frequency and Constraint Files, on page 158
Specifying Result Options, on page 161
Specifying Timing Report Output, on page 162
Setting Verilog and VHDL Options, on page 163
Setting Device Options
Device options are part of the global options you can set for the synthesis
run. They include the part selection (technology, part and speed grade) and
implementation options (I/O insertion and fanouts). The options and the
implementation of these options can vary from technology to technology, so
check the vendor chapters of the Reference Manual for information about
your vendor options.
1. Open the Implementation Options form by clicking the Implementation Options
button or selecting Project->Implementation Options, and click the Device tab
at the top if it is not already selected.
2. Select the technology, part, package, and speed. Available options vary,
depending on the technology you choose; the Synplify Premier software
supports a subset of the technologies supported by the Synplify and
Synplify Pro tools.
Setting Logic Synthesis Implementation Options Chapter 4: Setting up a Logic Synthesis Project
March 2014 153
Also, when using the Synplify Premier tool with a HAPS board, selecting
a Synopsys HAPS entry from the Technology drop-down menu automati-
cally fills in the appropriate part, package, and speed grade for the
corresponding device on the HAPS board.
Similarly, specifying a Synopsys HAPS technology with a set_option
-technology command selects the appropriate part, package, and speed
grade (for example, set_option -technology HAPS-60 selects a Virtex-6
XC6VLX760 device in an FF1760 package in speed grade 1).
3. Set the device mapping options. The options vary, depending on the
technology you choose.
If you are unsure of what an option means, click on the option to see
a description in the box below. For full descriptions of the options,
click F1 or refer to the appropriate vendor chapter in the Reference
Manual.
To set an option, type in the value or check the box to enable it.
LO
154 March 2014
For more information about setting fanout limits, pipelining, and
retiming, see Setting Fanout Limits, on page 598, Pipelining, on
page 580, and Retiming, on page 584, respectively. For details about
other vendor-specific options, refer to the appropriate vendor chapter
and technology family in the Reference Manual.
4. Set other implementation options as needed (see Setting Logic Synthesis
Implementation Options, on page 152 for a list of choices). Click OK.
5. Click the Run button to synthesize the design. The software compiles
and maps the design using the options you set.
6. To set device options with a script, use the set_option Tcl command. The
following table contains an alphabetical list of the device options on the
Device tab mapped to the equivalent Tcl commands. Because the options
are technology- and family-based, all of the options listed in the table
may not be available in the selected technology. All commands begin
with set_option, followed by the syntax in the column as shown. Check
the Reference Manual for the most comprehensive list of options for your
vendor.
Device Mapping Options Vary by Technology
March 2014 155
The following table shows a majority of the device options.
Setting Optimization Options
Optimization options are part of the global options you can set for the imple-
mentation. This section tells you how to set options like frequency and global
optimization options like resource sharing. You can also set some of these
options with the appropriate buttons on the UI.
1. Open the Implementation Options form by clicking the Implementation
Options button or selecting Project->Implementation Options, and click the
Options tab at the top.
2. Click the optimization options you want, either on the form or in the
Project view. Your choices vary, depending on the technology. If an
option is not available for your technology, it is greyed out. Setting the
option in one place automatically updates it in the other.
Option Tcl Command (set_option ...)
Annotated Properties for Analyst -run_prop_extract {1|0}
Disable I/O Insertion -disable_io_insertion {1|0}
Disable Sequential Optimizations -no_sequential_opt {1|0}
Enhanced Optimization -enhanced_optimization {1|0}
Fanout Guide -fanout_limit fanout_value
Package -package pkg_name
Part -part part_name
Resolve Mixed Drivers -resolve_multiple_driver {1|0}
Speed -speed_grade speed_grade
Technology -technology keyword
Update Compile Point Timing Data -update_models_cp {0|1}
Verification Mode -verification_mode {0|1}
LO
156 March 2014
For details about using these optimizations refer to the following
sections:
Fast Synthesis Using Fast Synthesis, on page 619
Auto Compile Point The Automatic Compile Point Flow, on page 644
Continue on Error Continue on Error, on page 158
Physical Plus Running Physical Synthesis, on page 334
FSM Compiler Optimizing State Machines, on page 605
FSM Explorer Running the FSM Explorer, on page 610
Note: Only a subset of the Xilinx, Altera, and Microsemi
technologies support the FSM Explorer option. Use the
Project->Implementation Options->Options panel to determine
if this option is supported for the device you specify in
your tool.
Resource Sharing Sharing Resources, on page 602
Pipelining Pipelining, on page 580
Implementation Options->Options Project View
Optimization Options
March 2014 157
The equivalent Tcl set_option command options are as follows:
4. Click the Run button to run synthesis.
The software compiles and maps the design using the options you set.
Retiming Retiming, on page 584
Power Optimization Power Optimization for Xilinx Designs, on page 1082
in the Reference Manual
HDL Analyst
Database Generation
HDL Analyst Database Generation, on page 158
Option set_option Tcl Command Option
Fast Synthesis -fast_synthesis {1|0}
Auto Compile Point -automatic_compile_point {1|0}
Continue on Error -continue_on_error {1|0}
Physical Plus -run_physical_plus {1|0}
FSM Compiler -symbolic_fsm_compiler {1|0}
FSM Explorer -use_fsm_explorer {1|0}
Resource Sharing -resource_sharing {1|0}
Pipelining -pipe {0|1}
Retiming -retiming {1|0}
Power Optimization -power {1|0}
HDL Analyst Database
Generation
-hdl_qload {1|0}
LO
158 March 2014
Continue on Error
The continue-on-error feature is available for users of the Synplify Premier
tool to allow the compilation process to continue for certain, non-syntax-
related compiler errors. For more information, see Using Continue on Error,
on page 366.
HDL Analyst Database Generation
By default, the software reads the entire design, performs logic optimizations
and timing propagation, and writes output to a single netlist (srs). As designs
get larger, the time to run and debug the design becomes more challenging.
The HDL Analyst Database Generation option is available for Synplify
Premier users. This options allows the compiler to pre-partition the design
into multiple modules that are written to separate netlist files (srs). To enable
this option, select the HDL Analyst Database Generation checkbox on the Options
tab of the Implementation Options dialog box. This feature improves memory
usage significantly for large designs.
This feature can also be enabled from the Tcl Script window using the
following set_option Tcl command:
set_option -hdl_qload 1
Once the HDL Analyst Database Generation option is enabled, use the Incremental
Quick Load option in the HDL Analyst tool to display the design using either a
single netlist (srs) or multiple top-level RTL module netlists (srs). The tool can
take advantage of this feature by dynamically loading only the affected design
hierarchy. For example, the hierarchy browser can expand only the lower-
level hierarchy as needed for quick load. The Incremental Quick Load option is
located on the General panel of the HDL Analyst Options dialog box. See General
Panel, on page 467.
Specifying Global Frequency and Constraint Files
This procedure tells you how to set the global frequency and specify the
constraint files for the implementation.
1. To set a global frequency, do one of the following:
Type a global frequency in the Project view.
March 2014 159
Open the Implementation Options form by clicking the Implementation
Options button or selecting Project->Implementation Options, and click the
Constraints tab.
The equivalent Tcl set_option command is -frequency frequencyValue.
You can override the global frequency with local constraints, as
described in Specifying SCOPE Constraints, on page 263. In the Synplify
Pro tool, you can automatically generate clock constraints for your
design instead of setting a global frequency. See Using Auto Constraints,
on page 469 for details.
2. To specify constraint files for an implementation, do one of the following:
Select Project->Implementation Options->Constraints. Check the constraint
files you want to use in the project.
Implementation Options->Constraints
Project View
Global Frequency and Constraints
LO
160 March 2014
From the Implementation Options->Constraints panel, you can also click to
add a constraint file.
With the implementation you want to use selected, click Add File in the
Project view, and add the constraint files you need.
To create constraint files, see Specifying SCOPE Constraints, on
page 263.
3. To remove constraint files from an implementation, do one of the
following:
Select Project->Implementation Options->Constraints. Click off the checkbox
next to the file name.
In the Project view, right-click the constraint file to be removed and
select Remove from Project.
This removes the constraint file from the implementation, but does not
delete it.
4. To specify or remove a Synplify Premier design plan (sfp), use the
techniques described in steps 2 and 3, or do the following:
Select Project->Implementation Options->Design Planning. Check the box
next to the file you want.
To delete a file, disable the check box next to the file name on the
Design Planning tab.
When the implementation is synthesized, the Synplify Premier tool uses
the region assignments in this file for the second phase of optimization
to perform physical synthesis.
March 2014 161
When you synthesize the design, the software compiles and maps the
design using the options you set.
Specifying Result Options
This section shows you how to specify criteria for the output of the synthesis
run.
1. Open the Implementation Options form by clicking the Implementation Options
button or selecting Project->Implementation Options, and click the
Implementation Results tab at the top.
2. Specify the output files you want to generate.
To generate mapped netlist files, click Write Mapped Verilog Netlist or Write
Mapped VHDL Netlist.
To generate a vendor-specific constraint file for forward annotation,
click Write Vendor Constraint File. See Generating Constraint Files for
Forward Annotation, on page 132 for more information.
3. Set the directory to which you want to write the results.
4. Set the format for the output file. The equivalent Tcl command for
scripting is project -result_format format.
LO
162 March 2014
You might also want to set attributes to control name-mapping. For
details, refer to the appropriate vendor chapter in the Reference Manual.
For certain Altera technologies (see Generating Vendor-Specific Output,
on page 1096), the vqm result format allows you to also select the version
of Quartus II you are using from the pop-up menu.
Specifying Timing Report Output
You can determine how much is reported in the timing report by setting the
following options.
1. Selecting Project->Implementation Options, and click the Timing Report tab.
2. Set the number of critical paths you want the software to report.
3. Specify the number of start and end points you want to see reported in
the critical path sections.
March 2014 163
Setting Verilog and VHDL Options
When you set up the Verilog and VHDL source files in your project, you can
also specify certain compiler options.
Setting Verilog File Options
You set Verilog file options by selecting either Project->Implementation Options->
Verilog, or Options->Configure Verilog Compiler. For information about creating
always block hierarchy for the Synplify Premier tool, see Setting Synplify
Premier Prototyping Tools Optimizations, on page 228.
LO
164 March 2014
1. Specify the Verilog format to use.
To set the compiler globally for all the files in the project, select
Project->Implementation Options->Verilog. If you are using Verilog 2001 or
SystemVerilog, check the Reference Manual for supported constructs.
To specify the Verilog compiler on a per file basis, select the file in the
Project view. Right-click and select File Options. Select the appropriate
compiler. The default Verilog file format for new projects is
SystemVerilog.
2. Specify the top-level module if you did not already do this in the Project
view.
3. To extract parameters from the source code, do the following:
Click Extract Parameters.
To override the default, enter a new value for a parameter.
The software uses the new value for the current implementation only.
Note that parameter extraction is not supported for mixed designs.
4. Type in the directive in Compiler Directives, using spaces to separate the
statements.
March 2014 165
You can type in directives you would normally enter with 'ifdef and define
statements in the code. For example, ABC=30 results in the software
writing the following statements to the project file:
set_option -hdl_define -set "ABC=30"
5. In the Include Path Order, specify the search paths for the include
commands for the Verilog files that are in your project. Use the buttons
in the upper right corner of the box to add, delete, or reorder the paths.
6. In the Library Directories, specify the path to the directory which
contains the library files for your project. Use the buttons in the upper
right corner of the box to add, delete, or reorder the paths.
LO
166 March 2014
Setting VHDL File Options
You set VHDL file options by selecting either Project->Implementation
Options->VHDL, or Options->Configure VHDL Compiler.
For VHDL source, you can specify the options described below. For informa-
tion about creating process hierarchy for the Synplify Premier tool, see Setting
Synplify Premier Prototyping Tools Optimizations, on page 228.
1. Specify the top-level module if you did not already do this in the Project
view. If the top-level module is not located in the default work library, you
must specify the library where the compiler can find the module. For
information on how to do this, see VHDL Panel, on page 314.
You can also use this option for mixed language designs or when you
want to specify a module that is not the actual top-level entity for HDL
Analyst displaying and debugging in the schematic views.
2. For user-defined state machine encoding, do the following:
Specify the kind of encoding you want to use.
Disable the FSM compiler.
When you synthesize the design, the software uses the compiler direc-
tives you set here to encode the state machines and does not run the
March 2014 167
FSM compiler, which would override the compiler directives. Alterna-
tively, you can define state machines with the syn_encoding attribute, as
described in Defining State Machines in VHDL, on page 501.
3. To extract generics from the source code, do this:
Click Extract Generic Constants.
To override the default, enter a new value for a generic.
The software uses the new value for the current implementation only.
Note that you cannot extract generics if you have a mixed language
design.
4. To push tristates across process/block boundaries, check that Push
Tristates is enabled. For details, see Push Tristates Option, on page 328
in the Reference Manual.
5. Determine the interpretation of the synthesis_on and synthesis_off
directives:
To make the compiler interpret synthesis_on and synthesis_off directives
like translate_on/translate_off, enable the Synthesis On/Off Implemented as
Translate On/Off option.
To ignore the synthesis_on and synthesis_off directives, make sure that
this option is not checked. See translate_off/translate_on, on
page 497 in the Reference Manual for more information.
LO
168 March 2014
Specifying Attributes and Directives Chapter 4: Setting up a Logic Synthesis Project
March 2014 169
Specifying Attributes and Directives
Attributes and directives are specifications that you assign to design objects
to control the way your design is analyzed, optimized, and mapped.
Attributes control mapping optimizations and directives control compiler
optimizations. Because of this difference, you must specify directives in the
source code or the compiler directives file. This table describes the methods
that are available to create attribute and directives specifications:
It is better to specify attributes in the SCOPE editor or the constraints file,
because you do not have to recompile the design first. For directives, you
must compile the design for them to take effect.
If compiler directives (cdc), SCOPE/constraints file, and the HDL source code
are specified for a design, the constraints has the highest priority when there
are conflicts. Then, the cdc compiler directives take precedence over the HDL
source code.
For further details, refer to the following:
Specifying Attributes and Directives in VHDL, on page 170
Specifying Attributes and Directives in Verilog, on page 171
Specifying Directives in a CDC File, on page 172
Specifying Attributes Using the SCOPE Editor, on page 174
Specifying Attributes in the Constraints File, on page 177
Attributes Directives
VHDL Yes Yes
Verilog Yes Yes
cdc Compiler Directives File
(Synplify Premier)
No Supported directives*
SCOPE Editor Yes No
Constraints File Yes No
* See Specifying Directives in a CDC File, on page 172
LO
Chapter 4: Setting up a Logic Synthesis Project Specifying Attributes and Directives
170 March 2014
Specifying Attributes and Directives in VHDL
You can use other methods to add attributes to objects, as listed in Specifying
Attributes and Directives, on page 169. However, you can specify directives
only in the source code. There are two ways of defining attributes and direc-
tives in VHDL:
Using the predefined attributes package
Declaring the attribute each time it is used
For details of VHDL attribute syntax, see VHDL Attribute and Directive
Syntax, on page 620in the Reference Manual.
Using the Predefined VHDL Attributes Package
The advantage to using the predefined package is that you avoid redefining
the attributes and directives each time you include them in source code. The
disadvantage is that your source code is less portable. The attributes package
is located in installDirectory/lib/vhd/synattr.vhd.
1. To use the predefined attributes package included in the software
library, add these lines to the syntax:
library synplify;
use synplify.attributes.all;
2. Add the attribute or directive you want after the design unit declaration.
declarations ;
attribute attribute_name of objectName : objectType is value ;
For example:
entity simpledff is
port (q: out bit_vector(7 downto 0);
d : in bit_vector(7 downto 0);
clk : in bit);
attribute syn_noclockbuf of clk : signal is true;
For details of the syntax conventions, see VHDL Attribute and Directive
Syntax, on page 620 in the Reference Manual.
3. Add the source file to the project.
March 2014 171
Declaring VHDL Attributes and Directives
If you do not use the attributes package, you must redefine the attributes
each time you include them in source code.
1. Every time you use an attribute or directive, define it immediately after
the design unit declarations using the following syntax:
design_unit_declaration ;
attribute attributeName : dataType ;
attribute attributeName of objectName : objectType is value ;
For example:
entity simpledff is
port (q: out bit_vector(7 downto 0);
d : in bit_vector(7 downto 0);
clk : in bit);
attribute syn_noclockbuf : boolean;
attribute syn_noclockbuf of clk :signal is true;
2. Add the source file to the project.
Specifying Attributes and Directives in Verilog
You can use other methods to add attributes to objects, as described in Speci-
fying Attributes and Directives, on page 169. However, you can specify direc-
tives only in the source code.
Verilog does not have predefined synthesis attributes and directives, so you
must add them as comments. The attribute or directive name is preceded by
the keyword synthesis. Verilog files are case sensitive, so attributes and direc-
tives must be specified exactly as presented in their syntax descriptions. For
syntax details, see Verilog Attribute and Directive Syntax, on page 423 in the
Reference Manual.
1. To add an attribute or directive in Verilog, use Verilog line or block
comment (C-style) syntax directly following the design object. Block
comments must precede the semicolon, if there is one.
Verilog Block Comment Syntax Verilog Line Comment Syntax
/* synthesis attributeName = value */
/* synthesis directoryName = value */
// synthesis attributeName = value
// synthesis directoryName = value
LO
172 March 2014
For details of the syntax rules, see Verilog Attribute and Directive
Syntax, on page 423 in the Reference Manual. The following are
examples:
module fifo(out, in) /* synthesis syn_hier = "hard */;
module b_box(out, in); // synthesis syn_black_box
2. To attach multiple attributes or directives to the same object, separate
the attributes with white spaces, but do not repeat the synthesis keyword.
Do not use commas. For example:
case state /* synthesis full_case parallel_case */;
3. If multiple registers are defined using a single Verilog reg statement and
an attribute is applied to them, then the synthesis software only applies
the last declared register in the reg statement. For example:
reg [5:0] q, q_a, q_b, q_c, q_d /* synthesis syn_preserve=1 */;
The syn_preserve attribute is only applied to q_d. This is the expected
behavior for the synthesis tools. To apply this attribute to all registers,
you must use a separate Verilog reg statement for each register and
apply the attribute.
Specifying Directives in a CDC File
Synplify Premier
A cdc file provides a convenient way to specify supported directives, without
making changes to your HDL files. You can specify the following directives on
views, entities, architectures and modules:
syn_black_box
syn_noprune
syn_preserve
syn_sharing
syn_rename_module
syn_unique_inst_module
March 2014 173
Use this procedure to create a cdc file and specify directives:
1. Create a constraints file with a cdc extension that contains the Tcl
directives you want. To use the compiler directives editor, see Using the
Compiler Directives Editor, on page 102.
2. Use the following syntax for the directives you want. Use the syntax that
matches the HDL source code you are using.
The following example sets the syn_black_box attribute on all architec-
tures of the sub entity in the MyLib library:
define_directive {v:MyLib.sub}{syn_black_box}{1}
You must specify the attribute or directive on a view (v:). The library-
Name and architectureName arguments are optional. If you do not
specify a library, the tool defaults to all design libraries. If you include an
architecture, make sure to enclose it in parentheses. Note that Verilog
objects are case-sensitive, but VHDL objects are not. See Compiler
Directives File Examples, on page 12 in the Reference Manual for
examples.
3. Add the file to your project. The tool creates a new directory in the
Project view.
Note, you can also use the set_option -compiler_constraint command to add
cdc files to your project (see set_option, on page 108 of the Reference
Manual).
4. Compile the design.
VHDL define_directive {v:[libraryName.]entityName[(architectureName)]} {directive}
{value}
Verilog define_directive {v:[libraryName.]moduleName} {directive} {value}
LO
174 March 2014
When the design is compiled, the tool passes all active cdc files to the
compiler. The compiler references the object names in these files with
the original RTL objects and assigns the corresponding directives.
Specifying Attributes Using the SCOPE Editor
The SCOPE window provides an easy-to-use interface to add any attribute.
You cannot use it for adding directives, because they must be added to the
source files. (See Specifying Attributes and Directives in VHDL, on page 170 or
Specifying Attributes and Directives in Verilog, on page 171). The following
procedure shows how to add an attribute directly in the SCOPE window.
1. Start with a compiled design and open the SCOPE window. To add the
attributes to an existing constraint file, open the SCOPE window by
clicking on the existing file in the Project view. To add the attributes to a
new file, click the SCOPE icon and click Initialize to open the SCOPE
window.
2. Click the Attributes tab at the bottom of the SCOPE window.
You can either select the object first (step 3) or the attribute first (step 4).
3. To specify the object, do one of the following in the Object column. If you
already specified the attribute, the Object column lists only valid object
choices for that attribute.
Select the type of object in the Object Filter column, and then select an
object from the list of choices in the Object column. This is the best
way to ensure that you are specifying an object that is appropriate,
with the correct syntax.
March 2014 175
Drag the object to which you want to attach the attribute from the
RTL or Technology views to the Object column in the SCOPE window.
For some attributes, dragging and dropping may not select the right
object. For example, if you want to set syn_hier on a module or entity
like an and gate, you must set it on the view for that module. The
object would have this syntax: v:moduleName in Verilog, or
v:library.moduleName in VHDL, where you can have multiple libraries.
Type the name of the object in the Object column. If you do not know
the name, use the Find command or the Object Filter column. Make
sure to type the appropriate prefix for the object where it is needed.
For example, to set an attribute on a view, you must add the v: prefix
to the module or entity name. For VHDL, you might have to specify
the library as well as the module name.
4. If you specified the object first, you can now specify the attribute. The
list shows only the valid attributes for the type of object you selected.
Specify the attribute by holding down the mouse button in the Attribute
column and selecting an attribute from the list.
If you selected the object first, the choices available are determined by
the selected object and the technology you are using. If you selected the
attribute first, the available choices are determined by the technology.
When you select an attribute, the SCOPE window tells you the kind of
value you must enter for that attribute and provides a brief description
of the attribute. If you selected the attribute first, make sure to go back
and specify the object.
5. Fill out the value. Hold down the mouse button in the Value column, and
select from the list. You can also type in a value.
6. Save the file.
LO
176 March 2014
The software creates a Tcl constraint file composed of define_attribute
statements for the attributes you specified. See How Attributes and
Directives are Specified, on page 10 of the Reference Manual for the
syntax description.
7. Add it to the project, if it is not already in the project.
Choose Project -> Implementation Options.
Go to the Constraints panel and check that the file is selected. If you
have more than one constraint file, select all those that apply to the
implementation.
The software saves the SCOPE information in a Tcl constraint file, using
define_attribute statements. When you synthesize the design, the software
reads the constraint file and applies the attributes.
March 2014 177
Specifying Attributes in the Constraints File
When you use the SCOPE window (Specifying Attributes Using the SCOPE
Editor, on page 174), the attributes are automatically written to a constraint
file using the Tcl define_attribute syntax. This is the preferred method for
defining constraints as the syntax is determined for you.
However, the following procedure explains how you can specify attributes
directly in the constraint file.
1. Open a file in a text editor.
2. Enter the desired attributes. For example,
define_attribute {objectName} attributeName value
For commands and syntax, see Summary of Attributes and Directives,
on page 13 in the Reference Manual.
3. Save the constraints in a file using the FDC file extension.
The following code excerpt provides an example of attributes defined in the
constraint file. (Some of these attributes are specific to Xilinx devices):
# Assign a location for scalar port "sel".
define_attribute {sel} xc_loc "P139"
# Assign a pad location to all bits of a bus.
define_attribute {b[7:0]} xc_loc "P14, P12, P11, P5, P21,
P18, P16, P15"
# Assign a fast output type to the pad.
define_attribute {a[5]} xc_fast 1
# Use a regular buffer instead of a clock buffer for clock "clk_slow".
define_attribute {clk_slow} syn_noclockbuf 1
# Relax timing by not buffering "clk_slow", because it is the slow clock
# Set the maximum fanout to 10000.
define_attribute {clk_slow} syn_maxfan 10000
For information about editing constraints, see Using a Text Editor for
Constraint Files (Legacy), on page 130.
LO
Chapter 4: Setting up a Logic Synthesis Project Working with Hierarchical Projects
178 March 2014
Working with Hierarchical Projects
You can use the top-down or bottom-up flows to develop hierarchical designs.
You can also use top-down or bottom-up synthesis or a combination of the
two to synthesize these designs. For more information about these flows, see
Hierarchical Project Management Flows, on page 87.
This section describes how to set up and work with hierarchical projects in
the flows mentioned above. The following topics provide more detail:
Creating Hierarchical Subprojects by Exporting Blocks, on page 179
Creating Hierarchical Subprojects by Exporting Instances, on page 181
Creating Nested Subprojects, on page 187
Generating Dependent File Lists, on page 193
Working with Multiple Implementations in Hierarchical Projects, on
page 194
Working with Multiple Instances and Parameterized Modules, on
page 195
Allocating Resources for Instance-Based Subprojects, on page 199
Setting Initial Timing Budgets for Instance-Based Subprojects, on
page 201
Generating Port Information for Instance-Based Subprojects, on
page 203
Configuring Synthesis Runs for Hierarchical Projects, on page 205
Analyzing Synthesis Results for Hierarchical Projects, on page 209
Instance-Based Subprojects and Block-Based Subprojects
A subproject created from an instance is unique and not related to any other
instances; all subproject settings only apply to the specified instance. You
can allocate resources and set timing budgets for these subprojects.
Unlike an instance-based subproject, any changes made to a block-based
subproject affect all instances of the block. You cannot assign timing budgets
or resources to block-based subprojects.
Working with Hierarchical Projects Chapter 4: Setting up a Logic Synthesis Project
March 2014 179
Creating Hierarchical Subprojects by Exporting Blocks
When you use a top-first approach to team design (Top-First Development
Flow for Hierarchical Projects, on page 90), you must partition the design and
specify subprojects. This procedure shows you how to designate a block as a
subproject; see Creating Hierarchical Subprojects by Exporting Instances, on
page 181 for information about creating subprojects based on instances.
Unlike an instance-based subproject, any changes made to a block-based
subproject affect all instances of the block.
1. Open the compiled top-level design.
You must compile the design because you cannot export subprojects
from an uncompiled design. It does not matter if the top level has black
boxes.
2. Export a subproject.
Go to the Design Hierarchy view, and right-click the block you want to
make into a subproject; then select Create Subproject (Design Block) from
the popup menu.
The Export "blockname" as subproject dialog box opens.
LO
180 March 2014
Specify a name for the project and a location.
Specify source files for the subproject. Check the selected files in the
list. The tool automatically enables needed source files from the top-
level design, but the list might not be complete. If a source file is not
listed, click the Add File button and add the missing file to the list. The
file is automatically selected when it is added with Add File. When the
tool creates the subproject, it adds the selected files to it.
You must have at least one file in order to create a subproject. Some
files may overlap with the parent project or a sibling project.
To link updates to the projects, enable the Link sub projects to the parent
project option.
Click OK.
The tool creates a new subproject for the specified block and automati-
cally links it to the top-level project. The block icon in the Design Hierarchy
view changes to a green rectangle with a P in it, to indicate that it is now
defined as a subproject. In the Project Files view, you see a Subprojects
directory that contains the new block project. The implementation
March 2014 181
options for the block project match the options of the active implementa-
tion of the parent project.
See Working with Multiple Implementations in Hierarchical Projects, on
page 194 and Working with Multiple Instances and Parameterized
Modules, on page 195 for information about creating additional imple-
mentations for the block.
3. Save the design. Until you do so, the hierarchy you created is not saved.
4. Synthesize the design, following the instructions in Top-Down Synthesis
for Hierarchical Projects, on page 94 and Bottom-Up Synthesis for
Creating Hierarchical Subprojects by Exporting Instances
When using the top-down development flow (Top-First Development Flow for
Hierarchical Projects, on page 90) you can also generate hierarchy by
separating an instance into an independent subproject, instead of a block
(Creating Hierarchical Subprojects by Exporting Blocks, on page 179). The
following procedure describes how to export instances for a hierarchical
project and then synthesize the design.
An instance-based subproject is not related to any other instances, so any
changes made to an instance-based subproject only affect that instance.
LO
182 March 2014
1. Load the design for your hierarchical project. Once loaded, run Compile
Only from the Run menu.
You must compile the design because you cannot export subprojects
from an uncompiled design.
2. Create the subproject.
Click on the Design Hierarchy tab, which shows both the design blocks
and instances for your design.
March 2014 183
Expand the hierarchy if needed, right-click the instance you want
and select Create Subproject (Instance).
Select the input files required for this instance. By default, the
synthesis tool picks the required RTL files, but can miss auxiliary
files such as ìnclude files that define macros or packages. You must
manually add these files by checking the corresponding check box.
LO
184 March 2014
The instance is highlighted and marked with a green icon [P] ( )
for the subproject. The subproject name is the instance name with
the hierarchical path for that instance.
March 2014 185
3. Save the design.
Until you save the design, the hierarchy you created is not written to the
disk or saved as part of the project.
4. Repeat the previous steps for each hierarchical instance to export.
The Project Files view shows that each exported instance has become an
independent subproject, identified by the green icon.
5. Edit synthesis options for the subprojects, as needed.
In the Project Files view, right-click the project file, select Hierarchical
Project Options from the pull-down menu.
LO
186 March 2014
In the window that opens, change options for any of the subprojects,
as needed. For example, you can change Run Type from bottom_up to
top_down.
Click OK.
6. Synthesize the design by clicking the Run button.
March 2014 187
Each exported instance is treated as a subproject and linked to the top-
level module. Alternatively, you can select which instances to link for the
exported block. Exported blocks for this example are ablock_inst_b2_a2
and bblock_inst_c1.
Any instances that are not exported are linked to the module definition
in the top-level project.
You can view the dependent files for a subproject or generate a list of
them, as described in Generating Dependent File Lists, on page 193.
7. Analyze your synthesis results in the HDL Analyst views, as described in
Creating Nested Subprojects
With hierarchical design, you can have subprojects that contain other
subprojects. You can use the block and instance exporting techniques to
recursively export parts of the design as subprojects.
LO
188 March 2014
The following procedure shows how to export nested subprojects, and is
based on a design containing three instances of ablock. The ablock module
instantiates two bblock instances (b1, b2), bblock instantiates two instances of
cblock (c1, c2), and cblock instantiates two instances of dblock (d1, d2).
1. Load the top-level project and compile it with Run->Compile Only.
You must compile the design before you can export an instance as a
subproject. The Design Hierarchy tab and the RTL view show the a1, a2,
and a3 instances at ablock at the top level.
2. Create a subproject.
In the Design Hierarchy view, right-click an instance (a3) and select one
of the Create Subproject commands. For details about using them to
export subprojects, see Creating Hierarchical Subprojects by
March 2014 189
Exporting Blocks, on page 179 and Creating Hierarchical Subprojects
by Exporting Instances, on page 181.
A dialog box shows you the files needed for the selected instance. Edit
the list as needed to reflect the file list for the instance. For details,
see Generating Dependent File Lists, on page 193.
Click OK. The view now shows a green P icon next to the instance to
indicate it is an exported subproject.
The Project Files view shows the newly-created subproject. It has its
own implementation, separate from the top-level implementation.
3. Save the design.
LO
190 March 2014
Until you save the design, the subproject you just created is not written
to disk.
4. Create a subproject within a subproject.
Compile the subproject under which you want to create another
subproject (a3), by selecting the subproject implementation and
selecting Run->Compile Only.
You must compile again at this level, because you cannot export a
subproject from an uncompiled design, and at this point the a3
subproject is not compiled.
In the Design Hierarchy view, right-click an instance and select one of
the Create Subproject commands to export it. You can select any
instance in the hierarchy. The following figure shows the current
subproject expanded, the next level skipped (bblock), and a cblock
instance selected from two levels below:
March 2014 191
Check that the list of dependent files for the instance is accurate in
the window that opens, and click OK when you are done. The Design
Hierarchy and Project Files views reflect the creation of a new cblock
subproject under the parent ablock subproject.
5. Save the design.
6. Compile and map the entire design by selecting the top-level
implementation and clicking Run.
The top-level RTL shows exported subprojects in green, to indicate that
they were exported. The following figure shows the a3 instance that was
exported from the top level.
LO
192 March 2014
The RTL view indicates exported subprojects relative to the current level.
If you push into the a3 instance from the top level, and then descend
into the bblock instance, the exported cblock instance is not in green,
because the reference point is the top level. However, if you select the
ablock subproject and then generate an RTL view, the cblock instance is in
green when you push down to it. This is because the cblock instance was
exported relative to the ablock subproject.
cblock from Top Level
cblock from ablock
March 2014 193
Generating Dependent File Lists
The compiler automatically generates a comprehensive list of the dependent
files for a subproject when you create it, and displays the files from the parent
project in a window like this one:
There are two ways to explicitly generate a list of dependent files for a project:
1. Select an instance in the Design Hierarchy view and then select Generate
Dependent File List from the popup menu.
2. Right-click an instance or block in the RTL view, and select Generate
Dependent File List from the popup menu.
LO
194 March 2014
This command writes the list of dependent files to a text file in the dm subdi-
rectory under the project directory, and opens the text file. Dependent files
include the following files:
Language standard and compiled library information files
All required dependent (child) and referencing (parent) files
Library and include directory paths
The path order for any include files
Working with Multiple Implementations in Hierarchical Projects
The following procedure show you how to work with multiple implementa-
tions in hierarchical projects. For example, you might want to create multiple
implementations with different run configurations if you are experimenting
with different implementation options.
1. Open the top-level hierarchical project and compile it (F7).
This updates the hierarchical project views.
2. To add an implementation to the top-level project or a block-level
project, do the following in the Project Files view:
Right-click the top level or the block and select Add Implementation.
Set the new implementation options you want.
3. To add subproject implementations to the top-level project, do one of the
following:
In the Project Files view, right-click a top-level implementation and
select Add Subproject Implementations.
Select a top-level implementation in the Project Files view. Select the
Project-> Add Subproject Implementation command.
The tool automatically adds a new implementation to each defined
subproject, and updates the top-level implementation to use the new
block implementations. The new block implementations are based on
the selected top-level implementation.
4. To specify which implementation to run, do the following:
Select Project->Edit Run Configuration.
March 2014 195
In the dialog box, set Implementation to the block implementation you
want to synthesize. To prevent synthesis from being run set this
option to <off>. If there are red cells in the table, synchronize options
across implementations as needed with the Sync buttons. Click OK.
To run all implementations, select the Run->Run all Implementations
instead of clicking the Run button to synthesize.
By default the tool runs the active implementation.
Working with Multiple Instances and Parameterized Modules
A module can have various parameters, such as SIZE or WIDTH. When
multiple instances of a module have different parameter values, they are
called parameterized modules. The following procedure shows you how to
work with multiple instantiations of parameterized modules.
1. Create your design and instantiate the parameterized modules.
In the design example used to illustrate this procedure, cblock is instanti-
ated four times. The instantiations have different values defined for
DWIDTH and USE_AND:
include meminfo.h
parameter USE_AND = 1;
//parameter USE_AND = 0;
//parameter DWIDTH = 2;
parameter DWIDTH = 6;
The following table shows the parameter values for the four cblock
instances in the design. It also shows that there are three unique sets of
parameters between the instances; cblock_1 and cblock_3 share the same
parameter set.
cblock Instances USE_AND DWIDTH Parameter Set
cblock_1 0 6 1
cblock_2 1 6 2
cblock_3 0 6 1
dblock_4 1 2 3
LO
196 March 2014
2. Export one instance of the parameterized module.
Compile the design.
Open the Design Hierarchy tab, and select one instance of the
parameterized module. You can select any instance of the module in
the design to export.
Export the subproject by right-clicking the module and selecting the
appropriate Create Subproject command.
The tool creates the subprojects based on the export option you
selected. Instance-based export results in a single subproject that
only affects the selected module. A block-based export creates a
single subproject that affects all instances of the module. For
parameterized modules exported as blocks, the tool creates a single
subproject with multiple implementations, one for each unique
parameter set.
If required, add any additional files needed for the subproject to the
automatically generated list that displays, and click OK.
To ... Export Command
Work on a specific instantiation without
affecting other instantiations
Create Subproject from Instance
Handle multiple instantiations together,
and fine-tune a few instances
Create Subproject from Block
March 2014 197
After you set the files for the subproject, the module is marked with a
green icon in the Design Hierarchy view. Module-based subprojects are
denoted by rev_#(%), as shown in the following figure, where cblock
was exported as a module.
LO
198 March 2014
Check the Project Files view. It shows that a subproject was created
for cblock, and that it is a parameterized implementation:
3. Click the Save All icon ( ) in the top bar to save all the exported
subproject and project file information.
4. Set options and constraints for synthesis.
For instance-based subprojects, the options and constraints only apply
to the selected instance. For module-based subprojects, the options and
constraints affect all instances of the module.
5. Run the project.
All exported subprojects are synthesized from the bottom up by default.
If you want to allow the subproject to be optimized, you can change the
default, as described in Configuring Synthesis Runs for Hierarchical
March 2014 199
6. If you make changes to parameters in a design, do the following:
Right-click the top-level project implementation and select Subproject
Parameter Sync.
Rerun synthesis.
Allocating Resources for Instance-Based Subprojects
You can automatically allocate RAM and DSP resources among the subproj-
ects in your design by using the following procedure:
1. Create a hierarchical subproject from scratch. It is important that you
start with a new design.
Create the top-level project.
Optionally, specify RAM and DSP resource limits at the top level with
the syn_allowed_resources attribute. If none are specified, the tool uses
the defaults for the technology.
Compile the design.
Create instance-based subprojects. You cannot set timing budgets for
block-based subprojects. See Creating Hierarchical Subprojects by
Exporting Instances, on page 181 for details.
Save the design.
2. To specify resources for a subproject, follow these steps:
Right-click a subproject or anywhere in the Design Hierarchy view
and select Allocate Timing and Resource Budgets (Beta). The Tcl equivalent
for this command is generate_instance_constraints.
In the window that opens, enable the checkbox in the Resource
column for the subproject.
LO
200 March 2014
Click Generate.
The synthesis tool estimates the RAM and DSP resources to the
subproject based on the top-level specification or default and writes
them out in an fdc file for the subproject.
3. Optionally, open the fdc file and edit the resource limits set with
syn_allowed_resources for the subproject.
4. Synthesize the design.
The tool honors any resource allocation parameters set with the
syn_allowed_resources attribute. You can set this attribute at the top level
or the subproject level. The tool does not consider black boxes during
resource allocation, so you might want to account for resource usage by
black boxes when you set resource limits. The tool automatically
accounts for resource usage in IPs, based on their netlists.
If you do not explicitly specify the resource limits with the
syn_allowed_resources attribute, the tool uses the defaults defined for
the technology.
If syn_allowed_resources is defined at both the subproject and top
levels, resource allocation is determined by the methodology used for
synthesis. If you synthesize from the bottom up, the tool bases
March 2014 201
resource allocation on the subproject limits, but it uses the top-level
resource limits if the design is synthesized from the top down. See
Configuring Synthesis Runs for Hierarchical Projects, on page 205 for
information about synthesis choices for hierarchical projects.
5. Check the resource usage sections of the subproject and top level log
files to ensure that your design is not over-utilized.
Setting Initial Timing Budgets for Instance-Based Subprojects
When you first create a hierarchical design with instance-based subprojects,
you can automatically allocate timing budgets for the subprojects using the
following procedure.
Set the top-level constraints.
Compile the design.
Create the instance-based subproject. You cannot set timing budgets
for block-based subprojects. See Creating Hierarchical Subprojects
by Exporting Instances, on page 181 for details.
Save the design.
2. To specify timing budgets for the subproject, follow these steps:
Right-click a subproject or anywhere in the Design Hierarchy view
and select Allocate Timing and Resource Budgets. The Tcl equivalent for
this command is generate_instance_constraints.
In the window that opens, make sure the checkboxes in the Timing
Budgets column are enabled for the subprojects.
LO
202 March 2014
Click Generate.
The synthesis tool generates an initial constraints file for the subproject,
based on the top-level constraints and the optimized slack across the
whole design. It assigns timing paths in the subproject a percentage of
the clock period.
The supported constraints are create_clock, create_generated_clock,
group_path, set_clock_latency, set_clock_uncertainty, set_false_path,
set_input_delay, set_max_delay, set_min_delay, set_multicycle_path, and
set_output_delay. However, this command does not currently support the -
through option for timing exceptions like false paths and multicycle
delays; for these constraints use -from and -to as much as possible.
The tool automatically accounts for IP timing, based on their netlists,
but it has a limitation with ngc cores in subprojects.
3. Open the subproject constraint file created in the previous step, and
check the constraints.
Edit them if needed. You can also add other constraints to the
subproject as needed.
4. Synthesize the design from the bottom up.
March 2014 203
The tool synthesizes the subprojects based on the timing constraints
defined for them.
5. Check timing results in the subproject and top-level log files.
Generating Port Information for Instance-Based Subprojects
You can automatically generate port context information. Port context infor-
mation communicates the connectivity at the instance boundary, and
includes information such as unused ports, and whether the ports are tied to
a constant. Use the following procedure to specify the port information:
Compile the design.
Create an instance-based subproject. You cannot set timing budgets
for block-based subprojects. See Creating Hierarchical Subprojects
by Exporting Instances, on page 181 for details.
2. To extract port context information for a subproject, follow these steps:
Right-click on an instance for the subproject in the Design Hierarchy
view and select Allocate Timing and Resource Budgets. The Tcl equivalent
for this command is generate_instance_constraints.
In the window that opens, enable the checkbox in the Port Context
column for the instanced-based subproject.
LO
204 March 2014
Click Generate.
A dialog box appears notifying you that the port context srs file will
be added to the instance-based subproject. Click OK.
From the Project Files tab, you can see that the context data netlist was
added to the subproject.
When you open the srs file, a blackbox port connectivity module is
created for the instance-based subproject to help synthesis perform
optimizations. This file contains the connectivity information of the ring
around the instance. The design_generate_instance_constraints.srr file in the
March 2014 205
synlog directory reports the port connections to GND and VCC, and
reports unused ports.
3. Save the design.
4. Synthesize the design from the bottom up.
The tool synthesizes the subprojects based on the port context defined
for the instance-based subprojects. In bottom-up flows, the instance
inherits the context information.
Configuring Synthesis Runs for Hierarchical Projects
Before you synthesize the hierarchical project, set options for the synthesis
run. This procedure shows you how to use the Hierarchical Project Options
command and set synthesis options for the top level design or for the blocks.
You can set different run configurations for different implementations.
1. Select the Hierarchical Project Options command.
Select the top level or the block in the Project Files view.
Either right-click and select Hierarchical Project Options from the popup
menu or select Project->Hierarchical Project Options.
LO
206 March 2014
2. Set options in the dialog box that opens:
In the block column, set Implementations to the implementation you
want to run. If you do not want to synthesize a block, set it to <off>.
When you set a block to <off>, that subproject is treated as a black
box.
March 2014 207
Set Run Type for the block to reflect how you want it synthesized:
top_down or bottom_up. For details of the differences, see Bottom-Up
Synthesis for Hierarchical Projects, on page 92 and Top-Down
Synthesis for Hierarchical Projects, on page 94.
Set any other implementation options you want for the synthesis run.
3. If necessary, synchronize the top-level and block settings. If you see a
red cell in the table, it means that option must be synchronized before
synthesis.
The following figure shows that pink highlighting in the device option
field. This indicates that you must synchronize the subproject with the
top level setting. The Disable I/O Insertion option is yellow and synchroniza-
tion with the top level is optional.
LO
208 March 2014
Click the Synchronize All Options with Top Level button at the bottom of the
box to match the required block device settings to the settings at the
top level. If the required device options match, this button is grayed
out and unavailable.
4. Click OK.
See Bottom-Up Synthesis for Hierarchical Projects, on page 92, Top-
Down Synthesis for Hierarchical Projects, on page 94 and Mixed Block
Synthesis for Hierarchical Projects, on page 96 for details.
March 2014 209
Analyzing Synthesis Results for Hierarchical Projects
After synthesizing a hierarchical project, you can analyze the results as
described below.
1. To view the synthesis results, check the RTL view.
The following figure of the top-level RTL view shows the linked netlists
from subprojects.
This is an example of an RTL view of the subprojects:
LO
210 March 2014
2. Check the log file for hierarchical reports for each subproject.
3. For resource usage, check the corresponding sections in the top-level
and subproject log files.
Searching Files Chapter 4: Setting up a Logic Synthesis Project
March 2014 211
Searching Files
A find-in-files feature is available to perform string searches within a speci-
fied set of files. Advantages to using this feature include:
Ability to restrict the set of files to be searched to a project or implemen-
tation.
Ability to cross probe the search results.
The find-in-files feature uses a dialog box to specify the search pattern, the
criteria for selecting the files to be searched, and any search options such as
match case or whole word. The files that meet the criteria are searched for the
pattern, and a list of the files containing the search pattern are displayed at
the bottom of the dialog box.
To use the find-in-files feature, open the Find in Files dialog box by selecting
Edit->Find in Files and enter the search pattern in the Find what field at the top of
the dialog box.
LO
Chapter 4: Setting up a Logic Synthesis Project Searching Files
212 March 2014
Identifying the Files to Search
The Find In section at the top of the dialog box identifies the files to be
searched:
Project Files searches the files included in the selected project (use the
drop-down menu to select the project). By default, the files in the active
project are searched. The files can reside anywhere on the disk; any
project include files are also searched.
Implementation Directory searches all files in the specified implemen-
tation directory (use the drop-down menu to select the implementation).
By default, the files in the active implementation are searched. You can
search all implementations by selecting <All Implementations> from the
drop-down menu. If Include sub-folders for directory searches is also selected,
all files in the implementation directory hierarchy are searched.
Subproject searches all files of a subproject included in the top-level
project file, when Include SubProject files is selected.
Directory searches all files in the specified directory (use the browser
button to select the directory). If Include sub-folders for directory searches is
also selected, all files in the directory hierarchy are searched.
All of the above selection methods can be applied concurrently when
searching for a specified pattern.
The Result Window selection is used after any of the above selection methods to
search the resulting list of files for a subsequent sub-pattern.
Filtering the Files to Search
A file filter allows the file set to be searched to be further restricted based on
the matching of patterns entered into the File filter field.
A pattern without a wildcard or a . (period) is interpreted as a filename
extension. For example, sdc restricts the search to only constraint files.
Multiple patterns can be specified using a semicolon delimiter. For
example, v;vhd restricts the files searched to only Verilog and VHDL files.
Wildcard characters can be used in the pattern to match file names. For
example, a*.vhd restricts the files searched to VHDL files that begin with
an a character.
Searching Files Chapter 4: Setting up a Logic Synthesis Project
March 2014 213
Leaving the File filter field empty searches all files that meet the Find In
criteria.
The Match Case, Whole Word, and Regular Expressions search options can be
used to further restrict searches.
Initiating the Search
After entering the search criteria, click the Find button to initiate the search.
All matches found are listed in the results area at the bottom of the dialog
box; the status line just below the Find button reports the number of matches
found in the indicated number of files and the total number of files searched.
While the find operation is running, the status line is continually updated
with how many matches are found in how many files and how many files are
being searched.
Search Results
The search results are displayed is the results window at the bottom of the
dialog box. For each match found, the entire line of the file is the displayed in
the following format:
fullpath_to_file(lineNumber): matching_line_text
For example, the entry
C:\Designs\leon\dcache.vhd(487): wdata := r.wb.data1;
indicates that the search pattern (data1) was found on line 487 of the
dcache.vhd file.
To open the target file at the specified line, double-click on the line in the
results window.
LO
Chapter 4: Setting up a Logic Synthesis Project Archiving Files and Projects
214 March 2014
Archiving Files and Projects
Use the archive utility to archive, extract (unarchive), or copy design projects.
Archived files are in a proprietary format and saved to a file name using the
sar extension. The archive utility is available through the Project menu in the
GUI or using the project command in the Tcl window.
Whenever you have a sar file that contains relative or absolute include paths
for the files in the project, use the _SEARCHFILENAMEONLY_ directive to have
the compiler remove the relative/absolute paths from the 'include and search
only for the file names. Otherwise, you may have problems using the archive
utility. For details, see _SEARCHFILENAMEONLY_ Directive, on page 326.
This document provides a description of how to use the utility.
Archive a Project
Un-Archive a Project
Copy a Project
Archive a Project
Use the archive utility to store the files for a design project into a single
archive file in a proprietary format (sar). You can archive an entire project or
selected files from a project. If you want to create a copy of a project without
archiving the files, see Copy a Project, on page 221.
Here are the steps to create an archive:
1. In the Project view, select Project->Archive Project to bring up the wizard.
The Tcl command equivalent is project -archive. For a complete description
of the project Tcl command options for archiving, see project, on page 83
of the Reference Manual.
The archive utility automatically runs a syntax check on the active
project (Run->Syntax Check command) to ensure that a complete list of
project files is generated. If you have Verilog 'include files in your project,
the utility includes the complete list of Verilog files. It also checks the
syntax automatically for each implementation in the project to ensure
that the file list is complete for each implementation as well. The wizard
displays the name of the project to archive, the top-level directory where
the project file is located (root directory), and other information.
Archiving Files and Projects Chapter 4: Setting up a Logic Synthesis Project
March 2014 215
2. Do the following on the first page of the wizard:
Fill in Destination File with a location for the archive file.
Set Archive Style. You can archive all the project files with all the
implementations or selectively archive files and implementations
To archive only the active implementation, enable Active Implementation.
To selectively archive files, enable Customized file list, click Next, and use
the check boxes to include files in or exclude files from the archive.
Use the Add Extra Files button on the this page to include additional
files in the project.
3. Click Next.
If you did not select Customized file list, the tool summary displays all the
files in the archive and shows the full uncompressed file size as shown
in step 5 (the actual size is smaller after the archiving operation as there
is no duplication of files). When you select Customized file list, the following
interim menu is displayed to allow you to exclude specific file from the
archive.
LO
216 March 2014
4. Click next to advance to the next screen (step 3).
March 2014 217
5. Verify that the current archive contains the files that you want, then
click Archive which creates the project archive sar file. If the list of files is
incorrect, click Back and include/exclude any desired files.
6. Click Archive if you are finished. The synthesis tool reports the archive
success and the path location of the archive file.
If you intend to transfer the archive file to one of the Synopsys FTP sites, see
Submit Support Request Command, on page 474 of the Command Reference.
LO
218 March 2014
Un-Archive a Project
Uses this procedure to extract design project files from an archive file (sar).
1. In the Project view, select Project->Un-Archive Project to display the wizard
The Tcl command equivalent is project -unarchive. For a complete descrip-
tion of the project Tcl command options for archiving, see project, on
page 83 of the Reference Manual.
2. In the wizard, enter the following:
Name of the sar file containing the project files.
Name of project to extract (un-archive). This field is automatically
extracted from the sar file and cannot be changed.
Pathname of directory in which to write the project files (destination).
Click Next.
March 2014 219
3. Make sure all the files that you want to extract are checked and
references to these files are resolved.
If there are files in the list that you do not want to include when the
project is un-archived, uncheck the box next to the file. The un-
checked files will be commented out in the project file (prj) when
project files are extracted.
If you need to resolve a file in the project before un-archiving, click
the Resolve button and fill out the dialog box.
If you want to replace a file in the project, click the Change button and
fill out the dialog box. Put the replacement files in the directory you
specify in Replace directory. You can replace a single file, any
unresolved files, or all the files. You can also undo the replace
operation.
LO
220 March 2014
4. Click Next and verify that the project files you want are displayed in the
Un-Archive Summary.
5. If you want to load this project in the UI after files have been extracted,
enable the Load project into Synplify Pro after un-archiving option.
6. When the Add extra input path to project file option is enabled, the archive
utility finds all include files and copies them into a directory called
extra_input. This directory is added to the unarchived project file.
March 2014 221
The Tcl command equivalent is set_option -include_path "./extra_input/".
If the archive files contain relative or absolute include paths, the
_SEARCHFILENAMEONLY_ directive can have the compiler remove the
relative/absolute paths from the 'include and search only for the file
names. To use the _SEARCHFILENAMEONLY_ directive, all include files
must have unique names. For details, see _SEARCHFILENAMEONLY_
Directive, on page 326.
7. Click Un-Archive.
A message dialog box is displayed while the files are being extracted.
8. If the destination directory already contains project files with the same
name as the files you are extracting, you are prompted so that the
existing files can be overwritten by the extracted files.
Copy a Project
Use this utility to create an unarchived copy of a design project. You can copy
an entire project or just selected files from the project. However, if you want
to create an archive of the project, where the entire project is stored as a
single file, see Archive a Project, on page 214.
Here are the steps to create a copy of a design project:
1. From the Project view, select Project->Copy Project.
The Tcl command equivalent is project -copy. For a complete description of
the project Tcl command options for archiving, see project, on page 83 of
the Reference Manual.
This command automatically runs a syntax check on the active project
(Run->Syntax Check command) to ensure that a complete list of project
files is generated. If you have Verilog include files in your project, they
are included. The utility runs this check for each implementation in the
LO
222 March 2014
project to ensure that the file list is complete for each implementation
and then displays the wizard, which contains the name of the project
and other information.
2. Do the following in the wizard:
Specify the destination directory where you want to copy the files.
Select the files to copy. You can choose to copy all the project files;
one or more individual files, input files only, or customize the list to
be copied.
To specify a custom list of files, enable Customized file list. Use the check
boxes to include or exclude files from the copy. Enable SRS if you
want to copy all srs files (RTL schematics). You cannot enable the
Source Files option if you select this. Use the Add Extra Files button to
include additional files in the project.
March 2014 223
Click Next.
LO
224 March 2014
3. Do the following:
Verify the copy information.
Enter a destination directory. If the directory does not exist it will be
created.
Click Copy.
This creates the project copy.
March 2014 225
CHAPTER 5
Setting up a Physical Synthesis Project
The process to set up a traditional physical synthesis project is the same as
for a logic synthesis project, but it requires a few additional steps. The
following describe the additional steps needed to set up a physical synthesis
project:
Setting up for Physical Synthesis, on page 226
Setting Options for Physical Synthesis, on page 228
Setting Constraints for Physical Synthesis, on page 246
Forward-Annotating Physical Synthesis Constraints, on page 249
Backannotating Physical Synthesis Constraints, on page 252
LO
Chapter 5: Setting up a Physical Synthesis Project Setting up for Physical Synthesis
226 March 2014
Setting up for Physical Synthesis
This figure summarizes the steps for setting up a physical synthesis project.
The shaded boxes are either optional steps, or steps that are specific to a flow
or certain technologies. Although the figure makes a distinction between
setting options or constraints for logic synthesis and physical synthesis, you
can actually define both types of options at the same time.
See the following for details about physical synthesis setup:
For information about ... See ...
Implementation options Setting Options for Physical Synthesis, on
page 228
Constraints Setting Constraints for Physical Synthesis, on
page 246
Create project
Set implementation options
for logic synthesis
Set implementation options
for physical synthesis
Set constraints for logic
synthesis
Set constraints for physical
synthesis
Create a floorplan file
(Design Planner flows)
Create a P&R options file
(Altera & Xilinx)
Create a P&R
implementation (if needed)
Setting up for Physical Synthesis Chapter 5: Setting up a Physical Synthesis Project
March 2014 227
Creating floorplan files Using Design Planner Floorplan Constraints, on
page 246
Creating P&R
implementations
Creating a Place and Route Implementation, on
page 229
Creating P&R options files Specifying Altera Place-and-Route Options, on
page 234
Specifying Xilinx Place-and-Route Options in a Tcl
File, on page 237
For information about ... See ...
LO
Chapter 5: Setting up a Physical Synthesis Project Setting Options for Physical Synthesis
228 March 2014
Setting Options for Physical Synthesis
After you have set up logic synthesis options for the implementation with the
Implementation Options command (see Setting Options for Physical Synthesis, on
page 228), you can set other options specific to physical synthesis.
The following describe them:
Setting Synplify Premier Prototyping Tools Optimizations, on page 228
Creating a Place and Route Implementation, on page 229
Specifying Altera Place-and-Route Options, on page 234
Specifying Xilinx Place-and-Route Options in a Tcl File, on page 237
Specifying Xilinx Place-and-Route Options in an opt File, on page 240
Specifying Xilinx Global Placement Options, on page 245
Setting Synplify Premier Prototyping Tools Optimizations
Synplify Premier
You can set these options if you have bit-sliced your design or for other
restructuring operations.
1. Select Project->Implementation Options, and click on the GCC & Prototyping
Tools tab.
2. To reduce the number of ports, eliminate feedthrough routes through
modules by enabling Feedthrough Optimization.
3. To reduce area, enable Constant Propagation.
Setting Options for Physical Synthesis Chapter 5: Setting up a Physical Synthesis Project
March 2014 229
Where possible, this option eliminates the logic used when constant
inputs to logic cause their outputs to be constant. It is sometimes
possible to eliminate this type of logic altogether during optimization.
4. To provide more granularity for applying a design plan to large modules
at the always block or process level, enable Create Always/Process Level
Hierarchy. Use this option with the Synplify Premier DP tool only.
Currently a design plan can be applied to either modules or to individual
gates, registers, and so on. For a module that is too large to fit in a row
or defined region, you might need an extra level of granularity which is
not as detailed as a gate-level description. This option creates an
additional, intermediate level of hierarchy to which you can apply a
design plan.
For example, in Verilog, the always block becomes a module with the
signals in the sensitivity list becoming inputs of the module and the
signals that get their values set becoming outputs of the modules.
Similarly, in VHDL, a process becomes a module. You might find that it is
easier to apply a design plan to these always blocks/processes.
5. To remove unnecessary and redundant logic in the netlist, enable
Optimize Netlist.
6. To group Altera Stratix MAC configurations together into one MAC
block, enable Create MAC Hierarchy.
Creating a Place and Route Implementation
For Altera, Microsemi, and Xilinx technologies, the Synplify Pro and Synplify
Premier tools allows you to run a place-and-route implementation after
synthesis completes. The following steps show you how to manually create a
place-and-route implementation.
1. Make sure you have the correct version of the P&R tool installed, and
that all variables for the tool have been set.
Check the release notes for version information. Select Help->Online
Documents->release_notes.pdf and go to Third Party Tool Versions.
For Microsemi technologies, set the Microsemi ALSDIR and PATH
environment variables to point to a valid installation of the place and
route tool.
LO
230 March 2014
For Altera technologies, set the QUARTUS_ROOTDIR and PATH
environment variables to point to a valid installation of the place and
route tool.
For Xilinx technologies, set the XILINX and PATH environment
variables to point to a valid installation of the place and route tool.
The Synplify Premier UI automatically sets the PAR_BELDLYRPT
environment variable to 1. This environment variable is set so that
the Xilinx place-and-route placement file (xdl) is generated with a
particular format. The software uses this xdl file to backannotate the
placement information
2. To create a place-and-route implementation, do one of the following:
Click on the Add P& R Implementation button from the Project view.
Select an implementation in the Project view, then right-click and
select Add New Place & Route Job.
The Add New Place and Route Task dialog box opens. The available options
differ slightly, depending on the technology.
March 2014 231
3. Set the options you need. Available place-and-route options vary
depending on the synthesis tool and technology.
Specify the Place & Route Job Implementation. The default is pr_n. Avoid
using spaces in the implementation name.
Enable Run Place and Route following synthesis.
Enable Run Timing & Placement Backannotation + Generate Congestion
Analysis Report.
Select a place-and-route options file. If you do not specify one, the
tool uses the settings in the default file.
LO
232 March 2014
For Altera and Xilinx designs, refer to the information in Specifying
Altera Place-and-Route Options, on page 234 or Specifying Xilinx
Place-and-Route Options in a Tcl File, on page 237 for details. For
Xilinx designs, you can also override global placement options with
an environment variable, as described in Specifying Xilinx Global
Placement Options, on page 245.
For Xilinx designs, you can run the SmartGuide flow. Enable the
Smart Guide option.
If you are going to run Synplify Premier physical synthesis, you can
choose to backannotate data for Xilinx technologies. See
Backannotating Place-and-Route Data, on page 252 for details.
For Xilinx designs, you can automatically generate a coreloc file with
backannotated data after place-and-route. See Generating a Xilinx
Coreloc Placement File, on page 253 for more information.
For physical synthesis with Altera Stratix IV GT, Stratix IV, Stratix III,
Stratix II GX, or Stratix II devices you can select the Use placement
constraints from physical synthesis. See Forward Annotating Altera
4. Enable the Run Place & Route following synthesis option. Click OK if you are
not setting the options described in the next step.
This creates the place-and-route implementation under the current
synthesis implementation. Currently, you cannot change the location of
the P&R directory.
Conversely, if you do not want to create a place-and-route implementa-
tion, disable the Run Place & Route following synthesis option.
Microsemi install_dir/lib/microsemi/microsemi_par.opt
Altera install_dir/lib/altera/altera_par.tcl
Xilinx
install_dir/lib/xilinx/xilinx_par.opt
1
install_dir/lib/xilinx/xilinx_par5.opt
2
1. Used with Xilinx Virtex-4 and earlier devices
2. Used with Xilinx Spartan-6 and Virtex-5 and later devices
March 2014 233
5. For Xilinx and Altera technologies, you can also do the following:
Specify a place-and-route options file. If you do not specify one, the
tool automatically uses the default options.
You can change or override the default options. See Specifying Altera
Place-and-Route Options, on page 234 and Specifying Xilinx Place-
and-Route Options in a Tcl File, on page 237 for details.
Backannotate constraints to the P&R tool. See Backannotating Place-
and-Route Data, on page 252 for details.
Forward-annotate constraints from the P&R tool. See Forward
Annotating Altera Constraints, on page 249.
Click OK.
6. Select the implementation in the Project view to see the place-and-route
implementation.
To create subsequent place-and-route implementations, select the
place-and-route implementation, right-click, and select Add Place & Route
Job. You can repeat the preceding steps to add as many P&R implemen-
tations as you need.
Enable the P&R implementation you want to use, if you have not
already done so (Implementation Options->Place and Route tab).
Place and Route implementation
LO
234 March 2014
Click the Run button, or right-click in the Project view and select Run
Place & Route Job from the popup menu.
If the synthesis implementation associated with the place-and-route
implementation has not been synthesized, Run Place & Route Job invokes
synthesis as well. After synthesis, the place-and-route tool is automati-
cally run. If you have a Xilinx design and have specified an options file,
the software uses these options during place-and-route.
8. To run in batch mode, do this:
Create a place-and-route implementation, as described previously.
Use the -run all command. If the synthesis implementation is selected
the software only runs synthesis; you must run place-and-route
separately. Otherwise, make the current implementation the place-
and-route implementation before issuing the batch command.
Specifying Altera Place-and-Route Options
This section shows you how to customize your Altera place-and-route run by
specifying a place-and-route options file or tcl script. You can use either the
default file or create a custom file.
1. To use the default place-and-route options, click the Add P&R
Implementation button in the Project view and select Standard Options File in
the dialog box. Click OK.
March 2014 235
The software uses the options in the altera_par.tcl file which is located in
the installation directory.
2. To use an existing options file (.tcl script):
Click the Add P&R Implementation button in the Project view.
Click Existing Options File. Select the file name in the next dialog box,
and click Open.
Return to the Add New Place & Route Task dialog box and make sure the
correct options file is selected. Click OK.
3. To create a new place-and-route options file:
Click the Add P&R Implementation button in the Project view. In the
dialog box, click Create New Options File. Specify the file name in the
next dialog box, and click OK.
A text window opens with the default options file. This file is
automatically added to the project.
Edit the default options to customize this options file. For more
information about the contents of this file, see Options in the Altera
Place-and-Route Options File, on page 236.
Save the file.
Return to the Add New Place & Route Task dialog box, and make sure the
options file you created is selected.
LO
236 March 2014
Select Run Place & Route following synthesis. Click OK.
The software uses the options file to place and route the design after
synthesis.
4. View the results.
Select the P&R implementation in the Project view. The result files are
displayed in the Implementation Results view.
View the log file quartus.log for information about the run.
Options in the Altera Place-and-Route Options File
To customize the Altera place-and-route options file, you can edit the default
options file (altera_par.tcl). This file contains the options for the following place-
and-route processes:
Fitter Options
Timing Analyzer Options
Analysis & Synthesis Options
Fitter Options
Edit the following default fitter options for the Quartus process shown below.
Timing Analyzer Options
Edit the following default timing analyzer options for the Quartus process
shown below.
March 2014 237
Analysis & Synthesis Options
Edit the following default analysis and synthesis options for the Quartus
process shown below.
Specifying Xilinx Place-and-Route Options in a Tcl File
The following procedure shows you how to customize your Xilinx place-and-
route run by specifying an ISE place-and-route Tcl file. You can also use a Tcl
file to specify options for Vivado. For information about specifying Vivado
place-and-route options in a Tcl file, see Customizing Vivado Place and Route
For the ISE options, you can use the default Tcl file or create a custom file.
This file uses the Xilinx xtclsh flow, which is the recommended methodology. If
you must use the old Xilinx xflow, refer to the procedure in Specifying Xilinx
Place-and-Route Options in an opt File, on page 240.
1. To use the default place-and-route options, do the following:
Click the Add P&R Implementation button in the Project view and select
Standard Options File in the dialog box.
Click OK.
By default, the software uses the Tcl file located in the installation direc-
tory. This file is used by the Xilinx xtclsh executable to run the P&R tool.
LO
238 March 2014
2. To use an existing Tcl options file, do the following:
Click Existing Options File. Select the file you want, and click Open.
Right-click the implementation, select Add New Place & Route Job, and
make sure the correct options file is selected. Click OK.
3. To create a new place-and-route Tcl file, do this:
Click Create New Options File. Specify a file name and click Open. The
tool generates a default Tcl file and automatically adds it to the
project.
A text window opens with the default Tcl file options.
4. Edit the file.
Edit the default options to customize this file.
Save the file.
5. Synthesize, place, and route the design.
Right-click the implementation, select Add New Place & Route Job, and
make sure the Tcl file is selected.
The software uses the Tcl file to place and route the design after
synthesis.
View the log file xflow.log for information about the run.
Sample run_ise.tcl File
The following example shows the place-and-route options file used in the
Xilinx xtclsh (run_ise.tcl) flow.
#################################################
### SET DESIGN VARIABLES ###
#################################################
set DesignName "adder"
set FamilyName "VIRTEX6"
March 2014 239
set DeviceName XC6VLX760"
set PackageName FF1760"
set SpeedGrade "-1"
set TopModule ""
set EdifFile "D:/adder/adder.edf"
#################################################
### SET FLOW ###
#################################################
set Flow "Standard"
#################################################
### SET POWER OPTION ###
#################################################
set Power "0"
#################################################
### PROJECT SETUP ###
#################################################
if {![file exists $DesignName.xise]} {
project new $DesignName.xise
project set family $FamilyName
project set device $DeviceName
project set package $PackageName
project set speed $SpeedGrade
xfile add $EdifFile
if {[file exists synplicity.ucf]} { xfile add synplicity.ucf }
} else {
project open $DesignName.xise}
#################################################
### STANDARD ###
#################################################
if { $Flow == "Standard" } {
project set "Netlist Translation Type" "Timestamp"
project set "Other NGDBuild Command Line Options" "-verbose"
project set "Generate Detailed MAP Report" TRUE
project set {Place & Route Effort Level (Overall)} "High"}
#################################################
### FAST ###
#################################################
if { $Flow == "Fast" } {
project set {Place & Route Effort Level (Overall)} "Standard"}
#################################################
### SMARTGUIDE ###
#################################################
LO
240 March 2014
if { $Flow == "SmartGuide" } {
project set "Use Smartguide" TRUE
project set "SmartGuide Filename" $DesignName\_guide.ncd
project set {Place & Route Effort Level (Overall)} "High"}
#################################################
### SMARTGUIDE FAST ###
#################################################
if { $Flow == "SmartGuideFast" } {
project set "Use Smartguide" TRUE
project set "SmartGuide Filename" $DesignName\_guide.ncd
project set "Netlist Translation Type""Timestamp"
project set {Place & Route Effort Level (Overall)} "Standard"}
#################################################
### EXECUTE ISE PLACE & ROUTE ###
#################################################
file delete -force $DesignName\_xdb
project open $DesignName.xise
process run "Implement Design" -force rerun_all
## process run "Generate Programming File"
#################################################
### EXECUTE POWER OPTION ###
#################################################
if { $Power == "1" } {
exec xpwr -v $DesignName.ncd $DesignName.pcf}
project close
Specifying Xilinx Place-and-Route Options in an opt File
If you are using the old Xilinx xflow, you specify P&R options in a opt file
instead of a Tcl file, which is the recommended methodology (see Specifying
Xilinx Place-and-Route Options in a Tcl File, on page 237.)
1. To use the default place-and-route options, do the following:
Click the Add P&R Implementation button in the Project view and select
Standard Options File in the dialog box.
Click OK.
By default, the software uses the opt file located in the installation direc-
tory, which is used by the xflow executable to run the P&R tool.
March 2014 241
2. To use an existing options file, do the following:
Click Implementation Options, go to the Device tab, and enable Use Xilinx
Xflow. By default, the synthesis tools use the xtclsh executable and the
corresponding Tcl options file, so you must explicitly turn on the Use
Xilinx Xflow option to use Xflow.
Click Existing Options File. Select the opt file you want to use and click
Open.
Select the implementation in the project view, right-click and select
Add Place & Route Job. In the dialog box, check that the correct options
file is selected. Click OK.
3. To create a new place-and-route options file, do this:
Select File->New. Set the file type to Xilinx Option File, type a file name.,
enable the Add to Project option, and click OK. This file is automatically
added to the project.
A text window opens with the options file.
4. Edit the file.
Edit the default options to customize this options file. For more
information about the contents of this file, see Options in the Xilinx
Place-and-Route Options File, on page 242.
Save the file.
Return to the Add New Place & Route Task dialog box, and make sure the
options file you created is selected.
LO
242 March 2014
The software uses the options file to place and route the design after
synthesis.
View the log file xflow.log for information about the run.
Options in the Xilinx Place-and-Route Options File
To customize the Xilinx place-and-route options file, you can edit the default
options file (xilinx_par.opt or xilinx_par5.opt). This file contains the options for the
following place-and-route processes:
Translator Options
Mapper Options
Place-and-Route Options
Post Place-and-Route Timing Report Options
Bitgen Generation Options
Translator Options
Edit the following default translator options for the ngdbuild command as
shown below.
########################
## Translator Options ##
########################
## Type "ngdbuild -h" for a detailed list of ngdbuild command line options
########################
Program ngdbuild
-intstyle xflow; # Message Reporting Style: ise, xflow, or silent
-nt timestamp;# NGO File generation. Regenerate only when
# source netlist is newer than existing
# NGO file (default)
<userdesign>; # User design - pick from xflow command line
<design>.ngd; # Name of NGD file. Filebase same as design filebase
##-p <partname>;# Partname to use - picked from xflow command line
##-sd source_dir; #Add "source_dir" to the list of directories
## #to search when resolving netlist file references
-uc synplicity.ucf; #Use specified "User Constraint File".
March 2014 243
## #The file <design_name>.ucf is used by default
## #if it is found in the local directory.
##-insert_keep_hierarchy; # Retain hierarchy identified by
individual source input netlists
End Program ngdbuild
Mapper Options
Edit the following default mapper options for the map command as shown
below.
####################
## Mapper Options ##
####################
## Type "map -h <architecture>" for a detailed list of map command
line options
####################
Program map
#-cm area; # Cover mode.
#-pr b; # Pack internal flops/latches into input(i), output (o),
# or both (b) types of IOBs.
#-k 4; # Function size for covering combinational logic.
#-c 100; # Pack unrelated logic into clbs.
-t 1; # Timing-driven cost table entry.
-w; # overwrite existing ncd file
-o <design>_map.ncd; # Output Mapped ncd file
<inputdir><design>.ngd; # Input NGD file
<inputdir><design>.pcf; # Physical constraints file
END Program map
Note that in the xilinx_par5.opt file for Virtex-5 devices and later, the following
option is set:
-t 1 # Timing-driven cost table entry.
Place-and-Route Options
Edit the following default place-and-route options for the par command as
shown below.
###########################
## Place & Route Options ##
###########################
## Type "par -h" for a detailed list of par command line options
###########################
Program par
-w; # Overwrite existing placed and routed ncd
-ol high; # Overall effort level
#-t 1; # Placer cost table entry.
LO
244 March 2014
#-xe c;
<design>_map.ncd; # Input mapped NCD file
<inputdir><design>.ncd; # Output placed and routed NCD
<inputdir><design>.pcf; # Input physical constraints file
END Program par
Post Place-and-Route Timing Report Options
Edit the following default post place-and-route timing report options for the
post_par_trce command as shown below.
####################################
## Post PAR Timing Report Options ##
####################################
## Type trce -h for detailed list of trce command line options
####################################
Program post_par_trce
-intstyle xflow;
-e 100;
<inputdir><design>.ncd;
<inputdir><design>.pcf;
-o <design>.twr;
END Program post_par_trce
Bitgen Generation Options
Edit the following default bit generation options for the bitgen command as
shown below.
#######################
## Bitgen Generation ##
#######################
## Type "bitgen -h" for detailed list of bitgen command line options
## Uncomment following commands to generate a bitstream
#######################
##Program bitgen
##-intstyle xflow;
##<inputdir><design>.ncd;
##-l; # Create logic allocation file
##-w; # Overwrite existing output file
##-m; # Create mask file
##<inputdir><design>.bit;
##<inputdir><design>.pcf;
##END Program bitgen
March 2014 245
Specifying Xilinx Global Placement Options
For graph-based physical synthesis in Xilinx designs, you can override the
default values for global placement in the options file.
1. Create a file with your preferred global placement options.
2. Use the SYN_XILINX_GLOBAL_PLACE_OPT environment variable to point
to your options file:
SYN_XILINX_GLOBAL_PLACE_OPT ="C:/Temp/test.opt"
LO
Chapter 5: Setting up a Physical Synthesis Project Setting Constraints for Physical Synthesis
246 March 2014
Setting Constraints for Physical Synthesis
The following describe how to set up various constraints for physical
synthesis. Some procedures are technology-specific or may apply only if you
are using Design Planner.
Using Design Planner Floorplan Constraints, on page 246
Setting Physical Synthesis Constraints for Altera, on page 248
For additional information on translating Altera QSF and Xilinx UCF
constraints to the synthesis sdc format, see Translating Altera QSF
Constraints, on page 318 and Converting and Using Xilinx UCF Constraints,
on page 325, respectively.
Using Design Planner Floorplan Constraints
For physical synthesis flows that with Design Planner, use the floorplan
constraints you generated to drive synthesis. You can use the following
procedure before logic synthesis, because you only need a compiled design.
1. Start with a compiled design.
The Design Planner flows are only supported for Altera and Xilinx
technologies.
2. Floorplan the design with Design Planner, and assign RTL modules,
paths or components to regions on the device. See
Chapter 18, Floorplanning with Design Planner for details.
3. Add the floorplan file to the design.
After floorplanning, add the design plan file (sfp) to the project.
Enable the file in the Implementation Options ->Design Planning tab.
4. Run synthesis.
You can run the preliminary logic synthesis step of the physical
synthesis flows, or you can run physical synthesis. When you run
Setting Constraints for Physical Synthesis Chapter 5: Setting up a Physical Synthesis Project
March 2014 247
physical synthesis, the placement constraints from the sfp file are
honored.
Note: Identify is compatible with the Synplify Premier tool. However,
Identify instrumentation does not support designs that use
constraints with floorplanning.
Translating Pin Location Files
You can automatically convert Altera and Xilinx place-and-route pin location
constraint files to SCOPE constraint files (sdc) with the Run->Translate Vendor IO
command.
1. Select Run ->Translate Vendor IO.
2. Enter the name of the Altera pin or Xilinx pad file you want to translate.
3. Type a name for the sdc constraint file you want to create.
4. Click on Add to Project, as appropriate, then click OK.
The pin locations from the files are translated into SDC constraints. If
you add the constraint file to the project, it can be used for design
planning and synthesis. Note that if there are pin assignment conflicts
between SDC constraints and pin locations assigned in Design Planner,
the SDC constraints take precedence. For another method to assign
pins, see Assigning Pins Interactively, on page 897.
LO
Chapter 5: Setting up a Physical Synthesis Project Setting Constraints for Physical Synthesis
248 March 2014
Setting Physical Synthesis Constraints for Altera
The following procedure describes the general procedure for setting up
physical synthesis constraints for Altera designs.
1. Create a constraints file, as described in Using the SCOPE Editor
(Legacy), on page 301, and add it to your project.
Use timing constraints to specify performance goals for the design and
describe the environment.
2. Translate Altera QSF constraints, as described in Translating Altera
QSF Constraints, on page 318.
3. Select Run->Constraint Check to check the constraints in the constraints
file. See Tcl Syntax Guidelines for Constraint Files, on page 130.
bility of the timing constraints in the sdc files for your project. The report
is written to the project_name_cck.rpt file.
4. If you are using Design Planner, create a floorplan file and add it to your
project. See Using Design Planner Floorplan Constraints, on page 246
for details.
Forward-Annotating Physical Synthesis Constraints Chapter 5: Setting up a Physical Synthesis
Project
March 2014 249
Forward-Annotating Physical Synthesis Constraints
For more information about forward-annotating Altera physical constraints,
see:
Forward Annotating Altera Constraints
Limitations Using the Physical Analyst and Technology View
Forward Annotating Altera Constraints
You can choose to forward annotate physical constraints from the Synplify
Premier physical synthesis tool, or else, let the Quartus II place-and-route
tool determine how to handle the physical constraints. Forward-annotation is
only available for Altera Stratix IV GT, Stratix IV, Stratix III, Stratix II GX, or
Stratix II devices. Use the following procedure.
New Implementation
Do the following for a new implementation:
1. Enable the Physical Synthesis switch.
If the switch is disabled, physical synthesis optimizations are performed
but placement constraints will not be forward annotated.
2. Click on the Add P&R Implementation button from the Project view or right-
click and select Add Place & Route Task from the popup menu to create a
new P&R implementation.
3. On the Add New Place & Route Task dialog box, enable or disable the Use
placement constraints from physical synthesis option. By default, this option is
enabled.
The Physical Synthesis switch must be enabled to use this option. When
this option is disabled, physical synthesis optimizations are performed
LO
Chapter 5: Setting up a Physical Synthesis Project Forward-Annotating Physical Synthesis
Constraints
250 March 2014
Existing Implementation
Do the following for an existing place-and-route implementation:
1. Enable the Physical Synthesis switch.
If the switch is disabled, physical synthesis optimizations are performed
2. In the Project view, select the place-and-route implementation, then
right-click and select P&R Options from the popup menu.
3. Enable or disable the Use placement constraints from physical synthesis option
from the popup dialog box. By default, this option is enabled.
Project View Button
Implementation Pop-up Menu
OR
Right-click on
Add Place and Route Job
or
P&R Options
Forward-Annotating Physical Synthesis Constraints Chapter 5: Setting up a Physical Synthesis
Project
March 2014 251
Note: When implementing physical synthesis for Altera designs, only
certain placement constraints such as RAMs, DSPs and critical
paths are forward-annotated for placement and routing. See
Limitations Using the Physical Analyst and Technology View, on
page 251
Limitations Using the Physical Analyst and Technology View
Since all Altera placement constraints are not forward-annotated after
running physical synthesis, the instance locations in the Quartus II place-
and-route output file (tan.rpt) might differ from locations in the Physical
Analyst and HDL Technology views. The place-and-route tool matches
locations in the physical constraints file (plc.tcl), for which the Synplify
Premier tool forward-annotates only RAMS, DSPs, and critical paths.
LO
Chapter 5: Setting up a Physical Synthesis Project Backannotating Physical Synthesis Constraints
252 March 2014
Backannotating Physical Synthesis Constraints
For more accurate results, you can resynthesize your design using place-and-
route data from the back-end tools. Refer to the following topics:
Backannotating Place-and-Route Data
Generating a Xilinx Coreloc Placement File
Backannotating Place-and-Route Data
You can also choose to back annotate place-and-route data which provides
accurate timing and placement information during physical synthesis.
However, this option is only applicable for Xilinx technologies.
Use the following procedure to backannotate place-and-route data. Do not
backannotate designs that contain IP cores.
New Implementation
Do the following for a new place-and-route implementation:
1. Click on the Add P&R Implementation button from the Project view.
2. On the Add New Place & Route Task dialog box, enable the Run Backannotation
after Place & Route option.
Existing Implementation
Do the following for an existing place-and-route implementation:
1. In the Project view, select the place-and-route implementation, then
right-click and select P&R Options from the popup menu.
2. Enable the Smart Guide option from the popup dialog box to run the
SmartGuide flow.
3. Enable the Run Backannotation after Place & Route option from the popup
dialog box.
Backannotating Physical Synthesis Constraints Chapter 5: Setting up a Physical Synthesis Project
March 2014 253
Generating a Xilinx Coreloc Placement File
You can use the Synplify Premier tool to generate a coreloc constraint file that
contains the placement for all anchor or core instances in the design, like
I/Os and BUFs. You can pass this file to the P&R tool for backannotation.
Using core location constraints ensures that block and I/O placement are
equivalent when you compare logic and physical synthesis. Include the
coreloc.sdc file to both logic and physical synthesis runs. This placement
information is also very useful for timing convergence. By stabilizing block
and I/O locations, you eliminate any changes to results that stem from place-
ment variations when running small designs.
Right-click on
Add Place & Route Job
Project View Button
Implementation Pop-up Menu
OR
or
P&R Options
LO
Chapter 5: Setting up a Physical Synthesis Project Backannotating Physical Synthesis Constraints
254 March 2014
To generate a coreloc file, do the following:
1. Before you run synthesis, make sure to enable the Run Backannotation after
Place & Route switch when you create the place-and-route implementation
before running synthesis.
The filename_coreloc.sdc file is generated during place-and-route backan-
notation and is written to the results directory. The filename is the same
base name as the EDIF output netlist (filename.edf).
2. After the synthesis run, when the file has been generated, add the
filename_coreloc.sdc file to your project.
To guarantee consistent and stable comparisons, include the coreloc.sdc
file to both logic and physical synthesis runs.
3. Re-run synthesis.
March 2014 255
CHAPTER 6
Specifying Constraints
This chapter describes how to specify constraints for your design. It covers
the following:
Using the SCOPE Editor, on page 256
Specifying SCOPE Constraints, on page 263
Specifying Timing Exceptions, on page 274
Finding Objects with Tcl find and expand, on page 280
Using Collections, on page 289
Converting SDC to FDC, on page 299
Using the SCOPE Editor (Legacy), on page 301
Translating Altera QSF Constraints, on page 318
Specifying Xilinx Constraints (Legacy), on page 320
Converting and Using Xilinx UCF Constraints, on page 325
The following chapters discuss related information:
Chapter 4, Constraints (Reference Manual) for an overview of constraints
Chapter 5, , (Reference Manual) for a description of the SCOPE editor
LO
Chapter 6: Specifying Constraints Using the SCOPE Editor
256 March 2014
Using the SCOPE Editor
The SCOPE (Synthesis Constraints OPtimization Environment
) presents a
spreadsheet-like editor with a number of panels for entering and managing
timing constraints and synthesis attributes. The SCOPE GUI is good for
editing most constraints, but there are some constraints (like black box
constraints) which can only be entered as directives in the source files. The
SCOPE GUI also includes an advanced text editor that can help you edit
constraints easily.
These constraints are saved to the FPGA Design Constraint (FDC) file. The
FDC file contains Synopsys SDC Standard timing constraints (for example,
create_clock, set_input_delay, and set_false_path), along with the non-timing
constraints (design constraints) (for example, define_attribute,
define_scope_collection, and define_io_standard). When working with these
constraints, use the following processes:
For existing designs, run the sdc2fdc script to translate legacy SDC
constraints and create a constraint file that contains Synopsys SDC
standard timing constraints and design constraints. For details about
this script, see Converting SDC to FDC, on page 299.
For new designs, use the SCOPE editor. See Creating Constraints in the
SCOPE Editor, on page 256 for more information.
For new designs, use the create_fdc_template Tcl command. See Creating
Constraints With the FDC Template Command, on page 261 for details.
Creating Constraints in the SCOPE Editor
The following procedure shows you how to use the SCOPE editor to create
constraints for the FDC constraint file.
1. To create a new constraint file, follow these steps:
Compile the design (F7).
Open the SCOPE window by:
Clicking the SCOPE icon in the toolbar ( ).
This brings up the New Constraint File dialog box; then, select FPGA
Design Constraints (Synplify Premier tool only).
OR
Using the SCOPE Editor Chapter 6: Specifying Constraints
March 2014 257
Pressing Ctrl-n or selecting File -> New. This brings up the New dialog
box; then, select file type of FPGA Design Constraints (Synplify Premier
tool only) and specify a new file name.
Both of these methods open the SCOPE editor GUI.
2. To open an existing file, do one of the following:
Double-click the file from the Project view.
Press Ctrl-o or select File->Open. In the dialog box, set the kind of file
you want to open to Constraint Files (SCOPE) (fdc), and double-click to
select the file from the list.
An empty SCOPE spreadsheet window opens. The tabs along the bottom of
the SCOPE window list the different kinds of constraints you can add. For
each kind of constraint, the columns contain specific data.
Using the SCOPE ICON Using File->New
(Displays in Synplify Premier Tool Only)
LO
258 March 2014
3. Select if you want to apply the constraint to the top-level or for modules
from the Current Design option drop-down menu located at the top of the
SCOPE editor.
4. You can enter or edit the following types of constraints:
Timing constraints on the Clocks, Generated Clocks, Inputs/Outputs,
Registers, or Delay Paths tab.
Design constraints on the Collections, Attributes, I/O Standards, or
Compile Points tab.
For details about these constraints, see Specifying SCOPE Constraints,
on page 263.
For information about ways to enter constraints within the SCOPE
editor, see Guidelines for Entering and Editing Constraints, on
page 271.
March 2014 259
5. The free form constraint editor is located in the TCL View tab, which is
the last tab in SCOPE. The text editor has a help window on the right-
hand side. For more information about this text editor, see Using the
TCL View of SCOPE GUI, on page 269.
6. Click on the Check Constraints button to run the constraint checker. The
output provides information on how the constraints are interpreted by
the tool.
All constraint information is saved in the same FPGA Design Constraint file
(FDC) with clearly marked beginning and ending for each section. Do not
manually modify these pre-defined SCOPE sections.
LO
260 March 2014
The following example shows the contents of an FDC file.
March 2014 261
Creating Constraints With the FDC Template Command
Use the Tcl command create_fdc_template to create an initial constraint file (fdc)
for your specific design. This command lets you specify port clocks, I/O
delays, and initial set_clock_groups for the clocks for which text headers are
generated that can help guide you when creating this constraint.
The following procedure shows you how to create constraints in the FDC
constraints file with the create_fdc_template command:
1. Create a project for your design.
3. At the command line, for example, you can specify the following:
create_fdc_template -period 10 -out_delay 1.5
The command automatically updates your project to reflect the new
constraint file(s). Do Ctrl+s to save the new settings.
4. If you open the SCOPE editor, you can check that the clock period and
output delay values were added to the constraint file as shown in the
following figure.
Constraint File Added to the Project
LO
262 March 2014
5. Each port clock includes a set_clock_groups header with details displayed
in the TCL View, which can help you determine whether clocks have been
optimized away or if there are any derived clocks.
However, if there is only one clock port and no derived clocks, no explicit
clock groups are created since they are not needed, as shown below.
For details about the command syntax, see create_fdc_template, on
page 40.
6. You can continue using the SCOPE editor to create other constraints.
7. Save the constraint file.
Specifying SCOPE Constraints Chapter 6: Specifying Constraints
March 2014 263
Specifying SCOPE Constraints
Timing constraints define the performance goals for a design. The FPGA
synthesis tool supports a subset of the Synopsys SDC Standard timing
constraints (for example, create_clock, set_input_delay, and set_false_path). For
additional support, see Synopsys Standard Timing Constraints, on page 264.
Design constraints let you add attributes, define collections and specify
constraints for them, and select specific I/O standard pad types for your
design.
You can define both timing and design constraints in the SCOPE editor. For
the different types of constraints, see the following topics:
Entering and Editing SCOPE Constraints
Setting Clock and Path Constraints
Defining Input and Output Constraints
Specifying Standard I/O Pad Types
To set constraints for timing exceptions like false paths and multicycle paths,
see Specifying Timing Exceptions, on page 274.
For information about collections, see Using Collections, on page 289.
Entering and Editing SCOPE Constraints
This section contains a description of the timing and design constraints you
can enter in the SCOPE GUI that are saved to an FDC file. The SCOPE timing
constraint panels include:
SCOPE Panel See ... Tcl Commands
Clocks Clocks create_clock
set_clock_groups
set_clock_latency
set_clock_uncertainty
Generated Clocks Generated Clocks create_generated_clock
Collections Collections define_scope_collection
LO
Chapter 6: Specifying Constraints Specifying SCOPE Constraints
264 March 2014
Synopsys Standard Timing Constraints
The FPGA synthesis tools support Synopsys standard timing constraints for a
subset of the clock definition (Clocks and Generated Clocks), I/O delay
(Inputs/Outputs), and timing exception constraints (Delay Paths). For complete
information about using the FPGA timing constraints with your project, see:
For specific information on individual constraint options and
arguments, see the Synthesis Commands PDF document at
https://solvnet.synopsys.com/dow_retrieve/G-2012.06/manpages/ni/syn2.pdf.
For information on which options and arguments are supported, see the
SDC Standard for FPGA Synthesis document on SolvNet.
For general information on the Design Constraints Format, see the
Using the Synopsys Design Constraints Format Application Note on
SolvNet.
Inputs/Outputs Inputs/Outputs set_input_delay
set_output_delay
Registers Registers set_reg_input_delay
set_reg_output_delay
Delay Paths Delay Paths set_false_path
set_max_delay
set_multicycle_path
Attributes Attributes define_attribute
define_global_attribute
I/O Standards I/O Standards define_io_standard
Compile Points Compile Points define_compile_point
define_current_design
TCL View TCL View --
SCOPE Panel See ... Tcl Commands
March 2014 265
The following table summarizes how to set different clock and path
constraints from the SCOPE window.
To define ... Pane Do this to set the constraint ...
Clocks Clock Select the clock object (Clock).
Specify a clock name (Clock Alias), if required.
Type a period (Period).
Change the rise and fall edge times for the clock.
waveforms of the clock in nanoseconds, if needed.
Change the default clock group, if needed.
Check the Enabled box.
See Defining Clocks, on page 307 for information
about clock attributes.
Generated
Clocks
Generated
Clocks
Select the generated clock object.
Specify the master clock source (a clock source pin in
the design).
Specify whether to use invert for the generated clock
signal.
Specify whether to use: edges, divide_by, or multiply_by.
Input/output
delays
Inputs/
Outputs
See Defining Input and Output Constraints (Legacy),
on page 315 for information about setting I/O
constraints.
Maximum
path delay
Delay Paths Select the Delay Type path of Max Delay.
Select the start/from point for either a port or register
(From/Through). See Defining From/To/Through Points
for Timing Exceptions, on page 274 for more
information.
Select the end/to point for either an output port or
register. Specify a through point for a net or
hierarchical port/pin (To/Through).
Set the delay value (Max Delay).
Multicycle
paths
Delay Paths See Defining Multicycle Paths, on page 278.
LO
266 March 2014
False paths Delay Paths See Defining False Paths, on page 279 for details.
Global
attributes
Attributes Set Object Type to <global>.
Select the object (Object).
Set the attribute (Attribute) and its value (Value).
Attributes Attributes Do either of the following:
Select the type of object (Object Type).
March 2014 267
Defining Input and Output Constraints
In addition to setting I/O delays in the SCOPE window as described in Setting
Clock and Path Constraints, on page 305, you can also set the Use clock period
for unconstrained IO option.
Open the SCOPE window, click Inputs/Outputs, and select the port (Port).
You can set the constraint for
All inputs and outputs (globally in the top-level netlist)
For a whole bus
For single bits
You can specify multiple constraints for the same port. The software
applies all the constraints; the tightest constraint determines the worst
slack. If there are multiple constraints from different levels, the most
specific overrides the more global. For example, if there are two bit
constraints and two port constraints, the two bit constraints override
the two port constraints for that bit. The other bits get the two port
constraints.
Specify the constraint value in the SCOPE window:
Select the type of delay: input or output (Type).
Type a delay value (Value).
Check the Enabled box, and save the constraint file in the project.
Make sure to specify explicit constraints for each I/O path you want to
constrain.
To determine how the I/O constraints are used during synthesis, do the
following:
Select Project->Implementation Options, and click Constraints.
To use only the explicitly defined constraints disable Use clock period for
unconstrained IO.
To synthesize with all the constraints, using the clock period for all
I/O paths that do not have an explicit constraint enable Use clock
period for unconstrained IO.
Synthesize the design. When you forward-annotate the constraints,
the constraints used for synthesis are forward-annotated for place-
and-route.
LO
268 March 2014
Input or output ports with explicitly defined constraints, but without a
reference clock (-ref option) are included in the System clock domain and
are considered to belong to every defined or inferred clock group.
If you do not meet timing goals after place-and-route and you need to
adjust the input constraints; do the following:
Open the SCOPE window with the input constraint.
Use the set_clock_route_delay command to translates the -route option
for the constraint, so that you can specify the actual route delay in
nanoseconds, as obtained from the place-and-route results. Adding
this constraint is equivalent to putting a register delay on the input
register.
Resynthesize your design.
Specifying Standard I/O Pad Types
You can specify a standard I/O pad type to use in the design. The equivalent
Tcl command is define_io_standard.
1. Open the SCOPE window and go to the I/O Standard tab.
2. In the Port column, select the port. This determines the port type in the
Type column.
3. Enter an appropriate I/O pad type in the I/O Standard column. The
Description column shows a description of the I/O standard you selected.
For details of supported I/O standards, see Industry I/O Standards, on
page 227.
4. Where applicable, set other parameters like drive strength, slew rate,
and termination.
You cannot set these parameter values for industry I/O standards
whose parameters are defined by the standard.
The software stores the pad type specification and the parameter values
in the syn_pad_type attribute. When you synthesize the design, the I/O
specifications are mapped to the appropriate I/O pads within the
technology.
March 2014 269
Using the TCL View of SCOPE GUI
The TCL View of the SCOPE GUI is an advanced text file editor used for FPGA
timing and design constraints. This text editor provides the following capabil-
ities:
Uses dynamic keyword expansion and tool tips for commands that
Automatically completes the command from a popup list
Displays complete command syntax as a tool tip
Displays parameter options for the command from a popup list
Includes a keyword command syntax help
Checks command syntax and uses color indicators that
Validates commands and command syntax
Distinguishes between FPGA design constraints and SCOPE legacy
constraints
Allows for standard editor commands, such as copy, paste,
comment/un-comment a group of lines, and highlighting of keywords
To use the TCL View of the SCOPE GUI:
1. Click on the TCL View of the SCOPE GUI.
2. You can specify FPGA design constraints as follows:
Type the command; after you type three characters a popup menu
displays the design constraint command list. Select a command.
When you type a dash (-), the options popup menu list is displayed.
Select an option.
When you hover over a command, a tool tip is displayed for the
selected commands.
LO
270 March 2014
3. You can also specify a command by using the constraints browser that
displays a constraints command list and associated syntax.
Double-click on the specified constraint to add the command to the
editor window.
Then, use the constraint syntax window to help you specify the
options for this command.
Click on the Hide Syntax Help button at the bottom of the editor window
to close the syntax help browser.
Command List Popup Menu
Options List Popup Menu
Command Tool Tip
March 2014 271
4. When you save this file, the constraint file is added to your project in the
Constraint directory if the Add to Project option is checked on the New
dialog box. Thereafter, you can double-click on the FDC constraint file to
open it in the text editor.
Guidelines for Entering and Editing Constraints
1. Enter or edit constraints as follows:
For attribute cells in the spreadsheet, click in the cell and select from
the pull-down list of available choices.
For object cells in the spreadsheet, click in the cell and select from
the pull-down list. When you select from the list, the objects
automatically have the proper prefixes in the SCOPE window.
Click on the Hide Syntax Help button
to close this browser
LO
272 March 2014
Alternatively, you can drag and drop an object from an HDL Analyst
view into the cell, or type in a name. If you drag a bus, the software
enters the whole bus (busA). To enter busA[3:0], select the appropriate
bus bits before you drag and drop them. If you drag and drop or type
a name, make sure that the object has the proper prefix identifiers:
For cells with values, type in the value or select from the pull-down
list.
Click the check box in the Enabled column to enable the constraint or
attribute.
Make sure you have entered all the essential information for that
constraint. Scroll horizontally to check. For example, to set a clock
constraint in the Clocks tab, you must fill out Enabled, Clock, Period,
and Clock Group. The other columns are optional. For details about
setting different kinds of constraints, go to the appropriate section
listed in Specifying SCOPE Constraints, on page 263.
2. For common editing operations, refer to this table:
Prefix Identifiers Description for ...
v:design_name hierarchies or views (modules)
c:clock_name clocks
i:instance_name instances (blocks)
p:port_name ports (off-chip)
t:pin_name hierarchical ports, and pins of instantiated cells
b:name bits of a bus (port)
n:net_name internal nets
To ... Do ...
Cut, copy, paste,
undo, or redo
Select the command from the popup (hold down the
right mouse button to get the popup) or from the
Edit menu.
March 2014 273
3. Edit your constraint file if needed. If your naming conventions do not
match these defaults, add the appropriate command specifying your
naming convention to the beginning of the file, as shown in these
examples:
Copy the same value
down a column
Select Fill Down (Ctrl-d) from the Edit or popup menus.
Insert or delete rows Select Insert Row or Delete Rows from the Edit or
popup menus.
Find text Select Find from the Edit or popup menus. Type the text
you want to find, and click OK.
Default You use Add this to your file
Hierarchy separator A.B Slash: A/B set_hierarchy_separator {/}
Naming bit 5 of bus ABC ABC[5] Underscore bus_naming_style {%s_%d}
Naming row 2 bit 3 of
array ABC [2x16]
ABC [2] [3] Underscore
ABC[2_3]
bus_dimension_separator_style {_}
To ... Do ...
LO
Chapter 6: Specifying Constraints Specifying Timing Exceptions
274 March 2014
Specifying Timing Exceptions
You can specify the following timing exception constraints, either from the
SCOPE interface or by manually entering the Tcl commands in a file:
Multicycle Paths Paths with multiple clock cycles.
False Paths Clock paths that you want the synthesis tool to ignore
during timing analysis and assign low (or no) priority during optimiza-
tion.
Max Delay Paths Point-to-point delay constraints for paths.
The following shows you how to specify timing exceptions in the SCOPE GUI.
For the equivalent Tcl syntax, see Chapter 2, Tcl Commands in the Reference
Manual.
Defining From/To/Through Points for Timing Exceptions, on page 274
Defining Multicycle Paths, on page 278
Defining False Paths, on page 279
For information about resolving timing exception conflicts, see Conflict
Resolution for Timing Exceptions, on page 244 in the Reference Manual.
Defining From/To/Through Points for Timing Exceptions
For multi-cycle path, false path, and maximum path delay constraints, you
must define paths with a combination of From/To/Through points. Whenever the
tool encounters a conflict in the way timing-exception constraints are written,
see Conflict Resolution for Timing Exceptions, on page 244 to determine how
resolution occurs based on the priorities defined.
The following guidelines provide details for defining these constraints. You
must specify at least one From, To, or Through point.
In the From field, identify the starting point for the path. The starting
point can be a clock, input or bidirectional port, or register. Only black
box output pins are valid. To specify multiple starting points:
Such as the bits of a bus, enclose them in square brackets: A[15:0] or
A[*].
Select the first start point from the HDL Analyst view, then drag and
drop this instance into the From cell in SCOPE. For each subsequent
Specifying Timing Exceptions Chapter 6: Specifying Constraints
March 2014 275
instance, press the Shift key as you drag and drop the instance into
the From cell in SCOPE. For example, valid Tcl command format
include:
set_multicycle_path -from {i:aq i:bq} 2
set_multicycle_path -from [i:aq i:bq} -through {n:xor_all} 2
In the To field, identify the ending point for the path. The ending point
can be a clock, output or bidirectional port, or register. Only black box
input pins are valid. To specify multiple ending points, such as the bits
of a bus, enclose them in square brackets: B[15:0].
A single through point can be a combinational net, hierarchical port or
instantiated cell pin. To specify a net:
Click in the Through field and click the arrow. This opens the Product of
Sums (POS) interface.
Either type the net name with the n: prefix in the first cell or drag the
net from an HDL Analyst view into the cell.
Click Save.
For example, if you specify n:net1, the constraint applies to any path
passing through net1.
To specify an OR when constraining a list of through points, you can type
the net names in the Through field or you can use the POS UI. To do this:
Click in the Through field and click the arrow. This opens the Product of
Sums interface.
Either type the first net name in a cell in a Prod row or drag the net
from an HDL Analyst view into the cell. Repeat this step along the
same row, adding other nets in the Sum columns. The nets in each
row form an OR list.
LO
276 March 2014
Alternatively, select Along Row in the SCOPE POS interface. In an HDL
Analyst view, select all the nets you want in the list of through points.
Drag the selected nets and drop them into the POS interface. The tool
fills in the net names along the row. The nets in each row form an OR
list.
Click Save.
The constraint works as an OR function and applies to any path passing
through any of the specified nets. In the example shown in the previous
figure, the constraint applies to any path that passes through net1 or
net2.
To specify an AND when constraining a list of through points, type the
names in the Through field or do the following:
Open the Product of Sums interface as described previously.
Either type the first net name in the first cell in a Sum column or drag
the net from an HDL Analyst view into the cell. Repeat this step down
the same Sum column.
March 2014 277
Alternatively, select Down Column in the SCOPE POS interface. In an
HDL Analyst view, select all the nets you want in the list of through
points. Drag the selected nets and drop them into the POS interface.
The tool fills in the net names down the column.
The constraint works as an AND function and applies to any path
passing through all the specified nets. In the previous figure, the
constraint applies to any path that passes through net1 and net3.
To specify an AND/OR constraint for a list of through points, type the
names in the Through field (see the following figure) or do the following:
Create multiple lists as described previously.
Click Save.
LO
278 March 2014
In this example, the synthesis tool applies the constraint to the paths
through all points in the lists as follows:
net1 AND net3
OR net1 AND net4
OR net2 AND net3
OR net2 AND net4
Defining Multicycle Paths
To define a multicycle path constraint, use the Tcl set_multicycle_path
command, or select the SCOPE Delay Paths tab and do the following;
1. From the Delay Type pull-down menu, select Multicycle.
2. Select a port or register in the From or To columns, or a net in the Through
column. You must set at least one From, To, or Through point. You can use
a combination of these points. See Defining From/To/Through Points
for Timing Exceptions, on page 274 for more information.
3. Select another port or register if needed (From/To/Through).
4. Type the number of clock cycles or nets (Cycles).
5. Specify the clock period to use for the constraint by going to the Start/End
column and selecting either Start or End.
If you do not explicitly specify a clock period, the software uses the end
clock period. The constraint is now calculated as follows:
multicycle_distance = clock_distance + (cycles -1) * reference_clock_period
In the equation, clock_distance is the shortest distance between the
triggering edges of the start and end clocks, cycles is the number of
clock cycles specified, and reference_clock_period is either the specified
start clock period or the default end clock period.
6. Check the Enabled box.
March 2014 279
Defining False Paths
You define false paths by setting constraints explicitly on the Delay Paths tab
or implicitly on the Clock tab. See Defining From/To/Through Points for
Timing Exceptions, on page 274 for object naming and specifying through
points.
To define a false path between ports or registers, select the SCOPE Delay
Paths tab, and do the following:
From the Delay Type pull-down menu, select False.
Use the pull-down to select the port or register from the appropriate
column (From/To/Through).
The software treats this as an explicit false constraint and assigns it the
highest priority. Any other constraints on this path are ignored.
To define a false path between two clocks, select the SCOPE Clocks tab,
and assign the clocks to different clock groups:
The software implicitly assumes a false path between clocks in different
clock groups. This false path constraint can be overridden by a
maximum path delay constraint, or with an explicit constraint.
To set an implicit false path on a path to/from an I/O port, do the
following:
Select Project->Implementation Options->Constraints.
Disable Use clock period for unconstrained IO.
LO
Chapter 6: Specifying Constraints Finding Objects with Tcl find and expand
280 March 2014
Finding Objects with Tcl find and expand
The Tcl find and expand commands are powerful search tools that you can use
to quickly identify the objects you want. The following sections describe how
to use these commands effectively:
Specifying Search Patterns for Tcl find, on page 280
Refining Tcl Find Results with -filter, on page 282
Using the Tcl Find Command to Define Collections, on page 283
Using the Tcl expand Command to Define Collections, on page 285
Checking Tcl find and expand Results, on page 286
Using Tcl find and expand in Batch Mode, on page 287
Once you have located objects with the find or expand commands, you can
group them into collections, as described in Using Collections, on page 289,
and apply constraints to all the objects in the collection at the same time.
Specifying Search Patterns for Tcl find
The usage tips in the following table apply for Tcl find search patterns, regard-
less of whether you specify the find command in the SCOPE window or as a
Tcl command. For full details of the command syntax, refer to Tcl Find
Syntax, on page 179 of the Reference Manual.
Finding Objects with Tcl find and expand Chapter 6: Specifying Constraints
March 2014 281
Case rules Use the case rules for the language from which the object
was generated:
VHDL: case-insensitive
Verilog: case-sensitive. Make sure that the object name
you type in the SCOPE window matches the Verilog
name.
For mixed language designs, use the case rules for the
parent module. The top level for this example is VHDL,
so the following command finds any object in the current
view that starts with either a or A:
find {a*} -nocase
Pattern matching You have two pattern-matching choices:
Specify the -regexp argument, and then use regular
expressions for pattern matching.
Do not specify -regexp, and use only the * and ?
wildcards for pattern matching.
For hierarchical instance names that use dots as
separators, the dots must be escaped with a backward
slash (\). For example: abc\.d.
Scope of the search The scope of the search varies, depending on where you
enter the command. If you enter it in the SCOPE
environment, the scope of the search is the entire
database, but if it is entered in the Tcl window, the
default scope of the search is the current HDL Analyst
view. See Comparison of Methods for Defining
Collections, on page 289 for a list of the differences.
To set the scope to include the hierarchial levels below
the current view in HDL Analyst, use the -hier argument.
This example finds all objects below the current view that
begin with a:
find {a*} -hier
Restricting search by
type of object
Use the -object_type argument. The following command
finds all nets that contain syn:
find -net {*syn*}
Restricting search by
object property
Use the -filter option, as described in Refining Tcl Find
Results with -filter, on page 282.
LO
282 March 2014
Refining Tcl Find Results with -filter
The -filter option of the find command lets you further refine the objects located
by the find command, according to their properties. When used with other
commands, it can be a powerful tool for generating statistics and for evalua-
tion. To filter your find results, follow these steps:
1. Enable property annotation.
Select Project->Implementation Options. On the Device tab, enable Annotated
Properties for Analyst. Alternatively, use the equivalent Tcl command:
set_option -run_prop_extract 1.
Compile or synthesize the design. After compilation, the tool
annotates the design with properties that you can specify with the -
filter option, like clock pins.
2. Specify the command using the find pattern as usual, and then specify
the -filter option as the last argument:
find searchPattern -filter expression
find searchPattern -filter !expression
With this command, the tool first finds objects that match the find search-
Pattern, and then further filters the found objects the according to the
property criteria specified in -filter expression. Use the ! character before
expression if you want to select objects that do not match the properties
specified in the filter expression.
expression can be a property name, specified as @propertyName, or a
property name and value pair, specified as @propertyName operator value.
March 2014 283
The following example finds registers in the current view that are
clocked by myclk:
find -seq {*} -filter {@clock==myclk}
For further information about the command, see the following:
Examples of Useful Find -filter Commands
Using the Tcl Find Command to Define Collections
It is recommended that you use the SCOPE window rather than the Tcl
window described here to specify the find command, for the reasons described
in Comparison of Methods for Defining Collections, on page 289.
The Tcl find command returns a collection of objects. If you want to create a
collection of connectivity-based objects, use the Tcl expand command instead
of find (Specifying Search Patterns for Tcl find, on page 280). This section lists
some tips for using the Tcl find command.
For ... See
Tips on using find search
patterns
Specifying Search Patterns for Tcl find, on
page 280
find syntax details find, on page 178 in the Reference Manual
find -filter syntax details find -filter, on page 189in the Reference Manual
To find ... Use a command like this example ...
Instances by slack value set slack [find hier inst {*} filter @slack <= {-1.000}]
Instances with negative slack set negFF [find hier inst {*} filter @slack <= {0.0}]
Instances within a slack
range
set slackRange [find hier inst {*} filter @slack <=
{-1.000} && @slack >= {+1.000}]
Pins by fanout value set pinResult [find pin *.CE hier filter {@fanout > 15
&& @slack < 0.0} -print]
Sequential elements within a
clock domain
set clk1FF [find hier -seq * filter {@clock==clk1]
Sequential components by
primitive type
set fdrse [find hier seq {*} filter @view=={FDRSE}
LO
284 March 2014
1. Create a collection by typing the set command and assigning the results
to a variable. The following example finds all instances with a primitive
type DFF and assigns the collection to the variable $result:
set result [find -hier -inst {*} -filter @ view == DFF]
The result is a random number like s:49078472, which is the collection of
objects found. The following table lists some usage tips for specifying the
find command. For full details of the syntax, refer to Tcl Find Syntax, on
2. Check your find constraints. See Checking Tcl find and expand Results,
on page 286.
3. Once you have defined the collection, you can view the objects in the
collection, using one of the following methods, which are described in
more detail in Viewing and Manipulating Collections with Tcl
Commands, on page 295:
Print the collection using the -print option to the find command.
Print the collection without carriage returns or properties, using c_list.
Print the collection in columns, with optional properties, using c_print.
4. To manipulate the objects in the collection, use the commands
described in Viewing and Manipulating Collections with Tcl Commands,
on page 295.
5. Combine the Tcl find command with other commands:
To ... Combine with ...
Create or copy objects; create collections set
define_collection
Generate reports for evaluation c_list
c_print
Generate statistics c_info
March 2014 285
Using the Tcl expand Command to Define Collections
The Tcl expand command returns a list of objects that are logically connected
between the specified expansion points. This section contains tips on using
the Tcl expand command to generate a collection of objects that are related by
their connectivity. For the syntax details, refer to expand, on page 195 in the
Reference Manual.
1. Specify at least one from, to, or thru point as the starting point for the
command. You can use any combination of these points.
The following example expands the cone of logic between reg1 and reg2.
expand -from {i:reg1} -to {i:reg2}
If you only specify a thru point, the expansion stops at sequential
elements. The following example finds all elements in the transitive
fanout and transitive fanin of a clock-enable net:
expand -thru {n:cen}
2. To specify the hierarchical scope of the expansion, use the -hier
argument.
If you do not specify this argument, the command only works on the
current view. The following example expands the cone of logic to reg1,
including instances below the current level:
expand -hier -to {i:reg1}
If you only specify a thru point, you can use the -level argument to specify
the number of levels of expansion. The following example finds all
elements in the transitive fanout and transitive fanin of a clock-enable
net across one level of hierarchy:
expand -thru {n:cen} -level 1
3. To restrict the search by type of object, use the -object_type argument.
The following command finds all pins driven by the specified pin.
expand -pin -from {t:i_and3.z}
4. To print a list of the objects found, either use the -print argument to the
expand command, or use the c_print or c_list commands (see Creating
Collections using Tcl Commands, on page 292).
LO
286 March 2014
Checking Tcl find and expand Results
You must check the validity of the find constraints you set. Use the methods
described below.
1. Run the Constraints Checker, either from the UI or at the command
line:
From the UI, select Run->Constraint Check.
At the command line specify the -run constraint_check option to the
synthesis tool command. For example: synplify_pro -batch design.prj -run
constraint_check.
If there are issues, the tool reports them in the design_cck.rpt report
file. Check the Summary and Inapplicable Constraints sections in this file.
2. To list objects selected by the find or expand commands, use one of these
methods:
List the results by specifying the -print option to the command.
List the results with the c_list command.
Print out the results one item per line, using the c_print command.
3. To visually validate the objects selected by the find or expand commands,
do the following:
Run the command and save the results as a collection.
On the SCOPE Collections tab, select the collection.
Right-click and choose Select in Analyst. The objects in the collection
are highlighted in the RTL view. The example below shows high
fanout nets that drive more than 20 destinations.
March 2014 287
Using Tcl find and expand in Batch Mode
When you use the Tcl find command in batch mode, you must specify the
open_design command before the find or expand commands.
1. Create the Tcl file to be run in batch mode, making sure that the
open_design command precedes the find/expand commands you want.
This batch script uses the find command to find DSP48Es and negative
slack, and then writes out the results to separate text files:
open_design implementation_a/top.srm
set find_DSP48Es [find -hier inst{*} -filter @view == {DSP48E*}]
set find_negslack [find -hier seq inst {*} -filter @slack
< {-0.0}]
LO
288 March 2014
c_print $find_DSP48Es -file DSP48Es.txt
c_print -prop slack -prop view $find_negslack -file negslack.txt
You cannot include the Tcl find command in Timing Analyzer scripts.
Instead, run Tcl Find to TXT command and use the results.
2. Run the script at the command line. For example, if the file created in
step 1 was called analysis.tcl, specify it at the command line, as shown
below:
synplify_pro -batch analysis.tcl
The tool generates two text files as specified, with the results of the two
searches. The DSP48s.txt file lists the DSP48Es, and the negslack.txt file
lists the instances with negative slack.
Using Collections Chapter 6: Specifying Constraints
March 2014 289
Using Collections
A collection is a defined group of objects. The advantage offered by collections
is that you can operate on all the objects in the collection at the same time. A
collection can consist of a single object, multiple objects, or even other collec-
tions. You can either define collections in the SCOPE window or type the
commands in the Tcl script window.
Creating and Using SCOPE Collections, on page 290
Creating Collections using Tcl Commands, on page 292
Viewing and Manipulating Collections with Tcl Commands, on page 295
Comparison of Methods for Defining Collections
You can enter the find and expand Tcl commands that are used to define
collections in either the Tcl script window or in the SCOPE window. It is
recommended that you use the SCOPE interface for the reasons outlined
below:
In the design shown below, if you push down into B, and then type find -
hier a* in the Tcl window, the command finds a3 and a4. However if you cut
and paste the same command into the SCOPE Collections tab, your results
would include a1, a2, a3, and a4, because the SCOPE interface uses the top-
level database and searches the entire hierarchy.
SCOPE Window Tcl Window
Database
used
Top level; includes all
objects.
See the example below.
Current Analyst view, which might be a
lower-level view. If the current view is the
Technology view after mapping, objects
might be renamed, replicated, or removed.
Persistence Collection saved in
project file.
Collection only valid for the current
session; you must redefine it the next time
you open the project.
Constraints Can apply to collection. Cannot apply to collection.
LO
Chapter 6: Specifying Constraints Using Collections
290 March 2014
Creating and Using SCOPE Collections
The following procedure shows you how to define collections in the SCOPE
window. The SCOPE method is preferred over typing the commands in the Tcl
window (Creating Collections using Tcl Commands, on page 292) for the
reasons described in Comparison of Methods for Defining Collections, on
page 289.
1. Define a collection by doing the following:
Open the SCOPE window and click the Collections tab.
In the Name column, type a name for the collection.
In the Command column, enter the command. See the Command
Reference for complete syntax details. Additional information about
specifying search patterns is described in Specifying Search Patterns
for Tcl find, on page 280.
You can also paste in a command. If you cut and paste a Tcl Find
command from the Tcl window into the SCOPE Collections tab,
remember that the SCOPE interface works on the top-level database,
while the find command in the Tcl window works on the current level
displayed in the Analyst view.
Objects in a collection do not have to be of the same type. The
collections shown in the preceding figure do the following:
a2
Top
B
a1
a3 a4
March 2014 291
The collections you define appear in the SCOPE pull-down object
lists, so you can use them to define constraints.
You can crossprobe the objects selected by the find and expand
commands by right-clicking and choosing Select in Analyst column. The
schematic views highlight the objects located by these commands.
For other viewing operations, see Viewing and Manipulating
Collections with Tcl Commands, on page 295.
2. To create a collection that is made up of other collections, do this:
Define the collections as described in the previous step. These
collections must be defined before you can concatenate them or add
them together in a new collection.
To concatenate collections or add to collections, type a name for the
new collection in the Name column. Type the appropriate operator
command like c_union or c_diff in the Command column. See Creating
Collections using Tcl Commands, on page 292 for a list of available
commands and the Command Reference for their syntax.
The software saves the collection information in the constraint file for
the project.
3. To apply constraints to a collection do the following:
Define a collection as described in the previous steps.
Go to the appropriate SCOPE tab and specify the collection name
where you would normally specify the object name. Collections
defined in the SCOPE interface are available from the pull-down
object lists. The following figure shows the collections defined in step
1 available for setting a false path constraint.
Collection Finds ...
find_all All components in the module endpMux
find_reg All registers in the module endpMux
find_comb All combinatorial components under endpMux
LO
292 March 2014
Specify the rest of the constraint as usual. The software applies the
constraint to all the objects in the collection.
Example: Attribute Attached to a Collection
The following example shows the xc_area_group attribute applied to $find_reg,
which results in all the registers in this collection being placed in the same
region. Check the srr file, the netlist, and if you are using Synplify Premier
Design Planner view to see that the attribute is honored.
Creating Collections using Tcl Commands
This section describes how to use the Tcl collection commands at the
command line or in a script instead of entering them in the SCOPE window
(Creating and Using SCOPE Collections, on page 290). There are differences
in operation depending on where the collection commands are entered, and it
is recommended that you use the SCOPE window, for the reasons described
in Comparison of Methods for Defining Collections, on page 289.
For details of the syntax for the commands described here, refer to Collec-
tions, on page 210 in the Reference Manual.
March 2014 293
1. To create a collection using a Tcl command line command, name it with
the set command and assign it to a variable.
A collection can consist of individual objects, Tcl lists (which can consist
of a single element), or other collections. You can embed the Tcl find and
expand commands in the set command to locate objects for the collection
(see Using the Tcl Find Command to Define Collections, on page 283
and Specifying Search Patterns for Tcl find, on page 280). The following
example creates a collection called my_collection which consists of all the
modules (views) found by the embedded find command:
set my_collection [find -view {*} ]
2. To create collections derived from other collections, do the following:
Define a new variable for the collection.
Create the collection with one of the operator commands from this
table:
3. If your Tcl collection includes instances that use special characters,
make sure to use extra curly braces or use a backslash to escape the
special character.
To ... Use this command. ..
Add objects to a collection c_union. See Examples: c_union
Command, on page 294
Concatenate collections c_union. See Examples: c_union
Command, on page 294.
Isolate differences between
collections
c_diff. See Examples: c_diff Command, on
page 294.
Find common objects between
collections
c_intersect. See Examples: c_intersect
Find objects that belong to just
one collection
c_symdiff. See Examples: c_symdiff
Curly Braces{} define_scope_collection GRP_EVENT_PIPE2 {find -seq
{EventMux\[2\].event_inst?_sync[*]} -hier}
define_scope_collection mytn {find -inst {i:count1.co[*]}}
Backslash Escape
Character (\)
define_scope_collection mytn {find -inst i:count1.co\[*\]}
LO
294 March 2014
Once you have created a collection, you can do various operations on the
objects in the collection (see Viewing and Manipulating Collections with Tcl
Commands, on page 295), but you cannot apply constraints to the collection.
Examples: c_union Command
This example adds the reg3 instance to collection1, which contains reg1 and
reg2 and names the new collection sumCollection.
set sumCollection [c_union $collection1 {i:reg3}]
c_list $sumCollection
{"i:reg1" "i:reg2" "i:reg3"}
If you added reg2 and reg3 with the c_union command, the command removes
the redundant instances (reg2) so that the new collection would still consist of
reg1, reg2, and reg3.
This example concatenates collection1and collection2 and names the new collec-
tion combined_collection:
set combined_collection [c_union $collection1 $collection2]
Examples: c_diff Command
This example compares a list to a collection (collection1) and creates a new
collection called subCollection from the list of differences:
set collection1 {i:reg1 i:reg2}
set subCollection [c_diff $collection1 {i:reg1}]
c_print $subCollection
"i:reg2"
You can also use the command to compare two collections:
set reducedCollection [c_diff $collection1 $collection2]
Examples: c_intersect Command
collection called interCollection from the objects that are common:
set interCollection [c_intersect $collection1 {i:reg1 i:reg3}]
c_print $interCollection
"i:reg1"
March 2014 295
set common_collection [c_intersect $collection1 $collection2]
Examples: c_symdiff Command
collection called diffCollection from the objects that are different. In this case,
reg1 is excluded from the new collection because it is in the list and collection1.
set diffCollection [c_symdiff $collection1 {i:reg1 i:reg3}]
c_list $diffCollection
{"i:reg2" "i:reg3"}
set symdiff_collection [c_symdiff $collection1 $collection2]
Examples: Names with Special Characters
Your instance names might include special characters, as for example when
your HDL code uses a generate statement. If your instance names have special
characters, do the following:
Make sure that you include extra curly braces {}, as shown below:
define_scope_collection GRP_EVENT_PIPE2 {find -seq
{EventMux\[2\].event_inst?_sync[*]} -hier}
define_scope_collection mytn {find -inst {i:count1.co[*]}}
Alternatively, use a backslash to escape the special character:
define_scope_collection mytn {find -inst i:count1.co\[*\]}
Viewing and Manipulating Collections with Tcl Commands
The following section describes various operations you can do on the collec-
tions you defined. For full details of the syntax, see Collections, on page 210
1. To view the objects in a collection, use one of the methods described in
subsequent steps:
Select the collection in an HDL Analyst view (step 2).
LO
296 March 2014
Print the collection without carriage returns or properties (step 3).
Print the collection in columns (step 4).
Print the collection in columns with properties (step 5).
2. To select the collection in an HDL Analyst view, type select <collection>.
For example, select $result highlights all the objects in the $result collec-
tion.
3. To print a simple list of the objects in the collection, uses the c_list
command, which prints a list like the following:
{i:EP0RxFifo.u_fifo.dataOut[0]} {i:EP0RxFifo.u_fifo.dataOut[1]}
{i:EP0RxFifo.u_fifo.dataOut[2]} ...
The c_list command prints the collection without carriage returns or
properties. Use this command when you want to perform subsequent
Tcl commands on the list. See Example: c_list Command, on page 298.
4. To print a list of the collection objects in column format, use the c_print
command. For example, c_print $result prints the objects like this:
{i:EP0RxFifo.u_fifo.dataOut[0]}
5. To print a list of the collection objects and their properties in column
format, use the c_print command as follows:
Annotate the design with a full list of properties by selecting Project-
>Implementation Options, going to the Device tab, and enabling Annotated
Properties for Analyst. Synthesize the design. If you do not enable the
annotation option, properties like clock pins will not be annotated as
properties.
Check the properties available by right-clicking on the object in the
HDL Analyst view and selecting Properties from the popup menu. You
see a window with a list of the properties that can be reported.
In the Tcl window, type the c_print command with the -prop option. For
example, typing c_print -prop slack -prop view -prop clock $result lists the
objects in the $result collection, and their slack, view and clock
properties.
March 2014 297
Object Name slack view clock
{i:EP0RxFifo.u_fifo.dataOut[0]} 0.3223 "FDE" clk
{i:EP0TxFifo.u_fifo.dataOut[0]} 0.1114 "FDE" clk
{i:EP0TxFifo.u_fifo.dataOut[1]} 0.1114 "FDE" clk
To print out the results to a file, use the c_print command with the -file
option. For example, c_print -prop slack -prop view -prop clock $result -file
results.txt writes out the objects and properties listed above to a file
called results.txt. When you open this file, you see the information in a
spreadsheet format.
6. You can do a number of operations on a collection, as listed in the
following table. For details of the syntax, see Collections, on page 210 in
To ... Do this ...
Copy a collection Create a new variable for the copy and copy the original
collection to it with the set command. When you make
changes to the original, it does not affect the copy, and
vice versa.
set my_collection_copy $my_collection
List the objects in a
collection
Use the c_print command to view the objects in a
collection, and optionally their properties, in column
format:
"v:top"
"v:block_a"
"v:block_b"
Alternatively, you can use the -print option to an
operation command to list the objects.
LO
298 March 2014
Example: c_list Command
The following provides a practical example of how to use the c_list command.
This example first finds all the CE pins with a negative slack that is less than
0.5 ns and groups them in a collection:
set get_components_list [c_list [find -hier -pin {*.CE} -filter
@slack < {0.5}]]
The c_list command returns a list:
{t:EP0RxFifo.u_fifo.dataOut[0].CE}
{t:EP0RxFifo.u_fifo.dataOut[1].CE}
{t:EP0RxFifo.u_fifo.dataOut[2].CE} ..
You can use the list to find the terminal (pin) owner:
proc terminal_to_owner_instance {terminal_name terminal_type} {
regsub -all $terminal_type$ $terminal_name {} suffix
regsub -all {^t:} $suffix {i:} prefix
return $prefix
}
foreach get_component $get_components_list {
append owner [terminal_to_owner_instance $get_component {.CE}]
" "
}
puts "terminal owner is $owner"
This returns the following, which shows that the terminal (pin) has been
converted to the owning instance:
terminal owner is i:EP0RxFifo.u_fifo.dataOut[0]
i:EP0RxFifo.u_fifo.dataOut[1] i:EP0RxFifo.u_fifo.dataOut[2]
Generate a Tcl list
of the objects in a
collection
Use the c_list command to view a collection or to convert
a collection into a Tcl list. You can manipulate a Tcl list
with standard Tcl commands. In addition, the Tcl
collection commands work on Tcl lists.
This is an example of c_list results:
{"v:top" "v:block_a" "v:block_b"}
Alternatively, you can use the -print option to an
operation command to list the objects.
To ... Do this ...
Converting SDC to FDC Chapter 6: Specifying Constraints
March 2014 299
Converting SDC to FDC
The sdc2fdc Tcl shell command translates legacy FPGA timing constraints to
Synopsys FPGA timing constraints. From the Tcl command line in the
synthesis tool, the sdc2fdc command scans the input SDC files and attempts
to convert constraints for the implementation.
To run the sdc2fdc Tcl shell command:
1. Load your Project file.
2. From the Tcl command line, type:
sdc2fdc
3. Check the constraint results directory for details about this translation.
4. The new constraints file is automatically updated for your project. Save
the new settings.
The constraint results directory is created at
projectDir/FDC_constraints/implName
This directory includes the following results files:
topLevel_translated.fdc Contains the Synopsys FPGA design
constraints (FPGA design constraints and the Synopsys standard
timing constraints)
topLevel|compilePoint_translate.log Contains details about the
translation. Translation error messages explain issues and how to fix
them. Any translation errors not addressed when you run synthesis
appear in the SRR log file, but does not stop synthesis from running.
5. Open the FDC file resulting from translation in the FPGA SCOPE editor
to check these constraints and make any changes to them.
6. Run the constraints checker.
7. Save this version of the FDC to run synthesis.
For information about the FDC file, see FDC Constraints, on page 168.
LO
Chapter 6: Specifying Constraints Converting SDC to FDC
300 March 2014
Note: Since the basic Synplify product does not have a Tcl window, you must
run sdc2fdc from a command shell in batch mode. The syntax is:
synplify -batch test.prj -tclcmd "sdc2fdc -batch"
For details about the translated files and troubleshooting guidelines, see
sdc2fdc Conversion, on page 172.
Using the SCOPE Editor (Legacy) Chapter 6: Specifying Constraints
March 2014 301
Using the SCOPE Editor (Legacy)
You can use the Legacy SCOPE editor for the SDC constraint files created
before release version G-2012.09. However, it is recommended that you
translate your SDC files to FDC files to enable the latest version of the SCOPE
editor and to utilize the enhanced timing constraint handling in the tool. The
latest version of the SCOPE editor automatically formats timing constraints
using Synopsys Standard syntax (such as create_clock, and set_multicyle_path).
To do this, add your SDC constraint files to your project and run the following
at the command line:
% sdc2fdc
This feature translates all SDC files in your project.
If you choose to do so, the following procedure shows you how to use the
legacy SCOPE editor to create constraints for the constraint file (SDC).
1. Open an existing file for editing.
Make sure you have closed the SCOPE window, or you could
overwrite previous constraints.
Double-click on an existing constraint file (sdc) in the project.
Select File->Open, set the Files of Type filter to Constraint Files (sdc) and
open the file you want.
2. Enter the timing or design constraints you need.
Use SCOPE ... To Define ...
Clocks Clock frequencies
define_clock. See Defining Clocks, on page 307
for additional information.
Clock frequency other than the one implied by
the signal on the clock pin
syn_reference_clock (attribute). See Defining
Clocks, on page 307 for additional information
Clock domains with asymmetric duty cycles
define_clock. See Defining Clocks, on page 307
for additional information
LO
Chapter 6: Specifying Constraints Using the SCOPE Editor (Legacy)
302 March 2014
Clock to Clock Edge-to-edge clock delays
define_clock_delay. See Defining Clocks, on
page 307 for additional information
Collections Set constraints for a group of objects you have
defined as a collection with the Tcl command.
Inputs/Outputs Speed up paths feeding into a register
define_reg_input_delay.
Speed up paths coming from a register
define_reg_output_delay.
Registers Input delays from outside the FPGA
define_input_delay. See Defining Input and
Output Constraints (Legacy), on page 315 for
additional information
Output delays from your FPGA
define_output_delay. See Defining Input and
Output Constraints (Legacy), on page 315 for
additional information
Delay Paths Paths with multiple clock cycles
define_multicycle_path. See Defining Multicycle
Paths, on page 278 for additional information
False paths (certain technologies)
define_false_path. See Defining False Paths
(Legacy), on page 316 for additional
information.
Path delays
define_path_delay. See Defining
From/To/Through Points for Timing
Exceptions, on page 274 for additional
information
Attributes Assign attributes for objects specifying their
values
March 2014 303
Entering and Editing SCOPE Constraints (Legacy)
Enter constraints directly in the SCOPE window. You can use the Initialize
Constraint panel to enter default constraints, and then use the direct method
to modify, add, or delete constraints.
The tool also lets you add constraints automatically. For information about
auto constraints, see Using Auto Constraints, on page 469.
1. Click the appropriate tab at the bottom of the window to enter the kind
of constraint you want to create:
I/O Standards Define an I/O standard for ports
Compile Points Specify compile points for your design
Other Enter newly-supported constraints for advanced
users.
To define ... Click ...
Clock frequency for a clock signal output of clock divider logic
A specific clock frequency that overrides the global frequency
Clocks
Edge-to-edge clock delay that overrides the automatically
calculated delay.
Clock to
Clock
Constraints for a group of objects you have defined as a
collection with the Tcl command. For details, see Creating and
Using SCOPE Collections, on page 290.
Collections
Input/output delays that model your FPGA input/output
interface with the outside environment
Inputs/
Outputs
Delay constraints for paths feeding into/out of registers Registers
Paths that require multiple clock cycles Delay Paths
Paths to ignore for timing analysis (false paths) Delay Paths
Maximum delay for paths Delay Paths
Attributes, like syn_reference_clock, that were not entered in the
source files
Attributes
LO
304 March 2014
The SCOPE window displays columns appropriate to the kind of
constraint you picked. You can now enter constraints using the wizard,
or work directly in the SCOPE window.
2. Save the file by clicking the Save icon and naming the file.
The software creates a TCL constraint file (sdc). See Working with
Constraint Files, on page 129 for information about the commands in
this file.
3. To apply the constraints to your design, you must add the file to the
project now or later.
Add it immediately by clicking Yes in the prompt box that opens after
you save the constraint file.
Add it later, following the procedure for adding a file described in
Making Changes to a Project, on page 140.
Specifying SCOPE Timing Constraints (Legacy)
You can define timing constraints in the SCOPE GUI, which automatically
generates a Tcl constraints file, or manually with a text editor, as described in
Using a Text Editor for Constraint Files (Legacy), on page 130.
The SCOPE GUI is much easier to use, and you can define various timing
constraints in it. For the equivalent Tcl syntax, see Chapter 2, Tcl Commands
in the Reference Manual. See the following for different timing constraints:
Entering Default Constraints, on page 305
I/O standards for any port in the I/O Standard panel of the
SCOPE window.
I/O Standard
Compile points in a top-level constraint file. See Synthesizing
Compile Points, on page 644 for more information about
compile points.
Compile
Points
Place and route tool constraints
Other constraints not used for synthesis, but which are passed
to other tools. For example, multiple clock cycles from a
register or input pin to a register or output pin
Other
To define ... Click ...
March 2014 305
Setting Clock and Path Constraints, on page 305
Defining Clocks, on page 307
Defining Input and Output Constraints (Legacy), on page 315
Specifying Standard I/O Pad Types, on page 268
To set constraints for timing exceptions like false paths and multicycle paths,
see Specifying Timing Exceptions, on page 274.
For information about physical constraints, see Setting Constraints for
Physical Synthesis, on page 246
Entering Default Constraints
To edit or set individual constraints, or to create constraints in the Other tab,
work directly in the SCOPE window (Setting Clock and Path Constraints, on
page 305). For auto constraints in the Synplify Pro tool, see Using Auto
Constraints, on page 469. To apply the constraints, add the file to the project
according to the procedure described in Making Changes to a Project, on
page 140. The constraints file has an sdc extension. See Working with
Constraint Files, on page 129 for more information about constraint files.
The following table summarizes how to set different clock and path
constraints from the SCOPE window. For information about setting compile
point constraints or attributes, see Synthesizing Compile Points, on page 644
for more information about compile points and Specifying Attributes Using
the SCOPE Editor, on page 174. For information about setting default
constraints, see Entering Default Constraints, on page 305.
LO
306 March 2014
Clocks Clock Select the clock object (Clock).
Specify a clock name (Clock Alias), if required.
Type a frequency value (Frequency) or a period (Period).
Change the default Duty Cycle or set Rise/Fall At, if
needed.
Change the default clock group, if needed
See Defining Clocks, on page 307 for information
about clock attributes.
Virtual
clocks
Clock Set the clock constraints as described for clocks, above.
Check the Virtual Clock box.
Route delay Clock
Inputs/
Outputs
Registers
Specify the route delay in nanoseconds. Refer to
Defining Clocks, on page 307, Defining Input and
Output Constraints (Legacy), on page 315 and the
Register Delays section of this table details.
Edge-to-edge
clock delay
Clock to
Clock
Select the starting edge for the delay constraint (From
Clock Edge).
Select the ending edge for the constraint (To Clock Edge).
Enter a delay value.
Mark the Enabled check box.
Input/output
delays
Inputs/
Outputs
See Defining Input and Output Constraints (Legacy),
on page 315 for information about setting I/O
constraints.
Register
delays
Registers Select the register (Register).
Select the type of delay, input or output (Type).
If you do not meet timing goals after place-and-route,
adjust the clock constraint as follows:
In the Route column for the constraint, specify the
actual route delay (in nanoseconds), as obtained from
the place-and-route results. Adding this constraint is
equivalent to putting a register delay on that input
register.
March 2014 307
Defining Clocks
Clock frequency is the most important timing constraint, and must be set
accurately. If you are planning to auto constrain your design (Using Auto
Constraints, on page 469), do not define any clocks. The following procedures
show you how to define clocks and set clock groups and other constraints
that affect timing:
Defining Clock Frequency, on page 308
Constraining Clock Enable Paths, on page 312
Maximum
path delay
Delay Path Select the Delay Type path of Max Delay.
Select the port or register (From/Through). See Defining
From/To/Through Points for Timing Exceptions, on
page 274 for more information.
Select another port or register if needed (To/Through).
Set the delay value (Max Delay).
Multi-cycle
paths
Delay Paths See Defining Multicycle Paths, on page 278.
False paths Delay Paths
Clock to
Clock
See Defining False Paths (Legacy), on page 316 for
details.
Global
attributes
Attributes Set Object Type to <global>.
Attributes Attributes Do either of the following:
Select the type of object (Object Type).
Other Other Type the TCL command for the constraint (Command).
Enter the arguments for the command (Arguments).
LO
308 March 2014
Defining Other Clock Requirements, on page 314
Defining Clock Frequency
This section shows you how to define clock frequency either through the GUI
or in a constraint file. See Defining Other Clock Requirements, on page 314
for other clock constraints. If you want to use auto constraints, do not define
your clocks.
1. Define a realistic global frequency for the entire design, either in the
Project view or the Constraints tab of the Implementation Options dialog box.
This target frequency applies to all clocks that do not have specified
clock frequencies. If you do not specify any value, a default value of 1
MHz (or 1000 ns clock period) applies to all timing paths whenever the
clock associated with both start and end points of the path is not speci-
fied. Each clock that uses the global frequency is assigned to its own
clock group. See Defining Other Clock Requirements, on page 314 for
more information about clock group settings.
The global frequency also applies to any purely combinatorial paths. The
following figure shows how the software determines constraints for
specified and unspecified start or end clocks on a path:
If clkA is ... And clkB is ... The effect for logic C is ...
Undefined Defined The path is unconstrained unless you specify that
clkB be constrained to the inferred clock domain for
clkA
clkA
clkB
Logic
C
A
B
March 2014 309
2. Define frequency for individual clocks on the Clocks tab of the SCOPE
window (define_clock constraint).
Specify the frequency as either a frequency in the Frequency column
(-freq Tcl option) or a time period in the Period column (-period Tcl
option). When you enter a value in one column, the other is
calculated automatically.
For asymmetrical clocks, specify values in the Rise At (-rise) and Fall At
(-fall) columns. The software automatically calculates and fills out the
Duty Cycle value.
The software infers all clocks, whether declared or undeclared, by
tracing the clock pins of the flip-flops. However, it is recommended that
you specify frequencies for all the clocks in your design. The defined
frequency overrides the global frequency. Any undefined clocks default
to the global frequency.
3. Define internal clock frequencies (clocks generated internally) on the
SCOPE Clocks tab (define_clock constraint). Apply the constraint
according to the source of the internal clock.
Defined Undefined The path is unconstrained unless you specify that
clkA be constrained to the inferred clock domain for
clkB.
Defined Defined For related clocks in the same clock group, the
relationship between clocks is calculated; all other
paths between the clocks are treated as false paths.
Undefined Undefined The path is unconstrained.
Source Add SCOPE constraint/define_clock to ...
Register Register.
Instance, like a PLL
or clock DLL
Instance. If the instance has more than one clock
output, apply the clock constraints to each of the
output nets, making sure to use the n: prefix (to
signify a net) in the SCOPE table.
Combinatorial logic Net. Make sure to use the n: prefix in the SCOPE
interface.
LO
310 March 2014
4. For signals other than clocks, define frequencies with the
syn_reference_clock attribute. You can add this attribute on the SCOPE
Attributes tab, as follows:
Define a dummy clock on the Clocks tab (define_clock constraint).
Add the syn_reference_clock attribute (Attributes tab) to the affected
registers to apply the clock. In the constraint file, you can use the Find
command to find all registers enabled by a particular signal and then
apply the attribute:
define_clock -virtual dummy -period 40.0
define_attribute {find seq * -hier filter @(enable == en40)}
syn_reference_clock dummy
In earlier releases, limited clocking resources might have forced you to
use an enable signal as a clocking signal, and use the syn_reference_clock
attribute to define an enable frequency. However, because of changes in
the reporting of clock start and end points, it is recommended that you
use a multicycle path constraint instead for designs that use an enable
signal and a global clock, and where paths need to take longer than one
clock cycle. See Constraining Clock Enable Paths, on page 312 for a
detailed explanation.
Note: This method is often used for designs that have an enable signal
and a global clock, and where paths need to take longer than one clock
cycle. The registers in the design are actually connected to the global
clock, however, the tool treats the registers as having a virtual clock at
the frequency of the enable signal.
Using this method to constrain paths for technologies with clock buffer
delays requires careful analysis with the Timing Analysis Reports (STA).
The virtual clock does not include clock buffer delays. However, non-
virtual clocks that pass through clock buffers do include clock buffer
delays. The register that generates the enable signal is on the non-
virtual clock domain, whereas the registers connected to the enable
signal are on the virtual clock domain. Timing analysis shows that the
enable signal is on the path between the non-virtual and virtual clock
domains. For the actual design, the enable signal is on a path in the
non-virtual clock domain. Any paths between virtual and non-virtual
clocks are reported with a clock buffer delay on the non-virtual clock.
This may result in the critical path reporting negative slack.
In the following example, the path comes from a register on a non-
virtual clock and goes to a register on a virtual clock.
March 2014 311
Path information for path number 1:
Requested Period:3.125
- Setup time: 0.229
= Required time: 2.896
- Propagation time: 1.448
- Clock delay at starting point: 1.857
= Slack (critical: -0.409
Number of logic level(s): 0
Starting point: SourceFlop / Q
Ending point: DestinationFlop / CE
The start point is clocked by Non-VirtualClock [rising] on pin C
The end point is clocked by VirtualClock [rising] on pin C
The path is reported with a negative slack of -0.49.
Timing analysis specifies a Clock delay at starting point that is the delay in
the clock buffers of the non-virtual clock, but not a Clock delay at ending
point. In the actual design, this delay exists at the end point. Since the
clock end point is a virtual clock, the clock buffer delay creates a
negative slack that does not exist in the actual design.
It is recommended that you use a multicycle path constraint instead to
constrain all registers driven by the enable signal in the design.
5. For Altera PLLs and Xilinx DCMs and DLLs, define the clock at the
primary inputs.
For Altera PLLs, you must define the input frequency, because the
synthesis software does not use the input value you specified in the
Mega wizard software. The synthesis tool assigns all the PLL outputs
to the same clock group. It forward-annotates the PLL inputs.
If needed, use the Xilinx properties directly to define the DCMs and
DLLs. The synthesis software assigns defined DCMs and DLLs to the
same clock group, because it considers these clocks to be related. It
forward-annotates the DLL/DCM inputs. The following shows some
examples of the properties you can specify
DLLs Phase shift and frequency multiplication properties like
duty_cycle_correction and clkdv_divide
DCMs DCM properties like clkfx_multiply and clkfx_divide
LO
312 March 2014
6. After synthesis, check the Performance Summary section of the log file for a
list of all the defined and inferred clocks in the design.
7. If you do not meet timing goals after place-and-route, adjust the clock
constraint as follows:
Open the SCOPE window with the clock constraint.
In the Route column for the constraint, specify the actual route delay
(in nanoseconds), as obtained from the place-and-route results.
Adding this constraint is equivalent to putting a register delay on all
the input registers for that clock.
Constraining Clock Enable Paths
You might use an enable signal as a clocking signal if you have limited
clocking resources. If the enable is slower than the clock, you can ensure
more accuracy by defining the enable frequency separately, instead of
slowing down the clock frequency. If you slow down the clock frequency, it
affects all other registers driven by the clock, and can result in longer run
times as the tool tries to optimize a non-critical path.
There are two ways to define clock enables:
By setting a multicycle path constraint to constrain all flip-flops driven
by the clock enable signal (see Defining Multicycle Paths, on page 278).
This is the recommended method. You must use this method for the
more recent Xilinx Virtex technologies.
Using the syn_reference_clock attribute, as described in step 4 of Defining
Clock Frequency, on page 308. Although this method was used in earlier
releases, it is not recommended any more because of changes in the way
the clock start and end points are reported. In particular, it is not
recommended for the more recent Xilinx Virtex technologies, as critical
paths could be reported with negative slack. An explanation of the clock
start and end points reporting follows.
Clock Domains for Clock Enables Defined with syn_reference_clock
When you use the syn_reference_clock attribute to constrain an enable signal,
you are telling the tool to treat the flip-flops as if they had a virtual clock at
the frequency of the enable signal, when the flip-flops are actually connected
to the global clock. This could result in critical paths being reported with
negative slack.
March 2014 313
The flip-flop that generates the enable signals is in the non-virtual clock
domain.The flip-flops that are connected to the enable signal are in the
virtual clock domain. The timing analyst considers the enable signal to be on
a path that goes between a non-virtual clock domain and a virtual clock
domain. In the actual circuit, the enable signal is on a path within a non-
virtual clock domain. The timing analyst reports any paths between virtual
and non-virtual clocks with a clock buffer delay on the non-virtual clock. This
is why critical paths might be reported with negative slack.
If you use this method to constrain paths in a technology that includes clock
buffer delays, you must carefully analyze the timing analysis reports. The
virtual clock does not include clock buffer delays, but any non-virtual clock
that passes through clock buffers will include clock buffer delays.
The following is an example report of a path from a clock enable, starting
from a flip-flop on a non-virtual clock to a flip-flop on a virtual clock. The
path is reported with a negative slack of -0.49.
Requested Period: 3.125
- Setup time: 0.229
= Required time:2.896
- Clock delay at starting point: 1.857
= Slack (critical) : -0.409
Starting point:SourceFlop/ Q
Ending point:DestinationFlop / CE
The start point is clocked by Non-VirtualClock [rising]on pin C
The end point is clocked by VirtualClock [rising] on pin C
This timing analysis report includes a Clock delay at starting point, but does not
include Clock delay at ending point. The clock delay at the starting point is the
delay in the clock buffers of the non-virtual clock. In the actual circuit, this
delay would also be at the ending point and not affect the calculation of slack.
However as the ending clock is a virtual clock, the clock buffer delay ends up
creating a negative slack that does not exist in the actual circuit.
This report is a result of defining the clock enables with the syn_reference_clock
attribute. This is why it is recommended that you use multicycle paths to
constrain all the flip-flops driven by the enable signal.
LO
314 March 2014
Defining Other Clock Requirements
Besides clock frequency (described in Defining Clock Frequency, on
page 308), you can also set other clock requirements, as follows:
If you have limited clock resources, define clocks that do not need a
clock buffer by attaching the syn_noclockbuf attribute to an individual
port, or the entire module/architecture.
Define the relationship between clocks by setting clock domains. By
default, each clock is in a separate clock group named default_clkgroup<n>
with a sequential number suffix.
On the SCOPE Clocks tab, group related clocks by putting them into
the same clock group. Use the Clock Group field to assign all related
clocks to the same clock group.
Make sure that unrelated clocks are in different clock groups. If you
do not, the software calculates timing paths between unrelated clocks
in the same clock group, instead of treating them as false paths.
Input and output ports that belong to the System clock domain are
considered a part of every clock group and will be timed. See Defining
Input and Output Constraints (Legacy), on page 315 for more
information.
The software does not check design rules, so it is best to define the
relationship between clocks as completely as possible.
Define all gated clocks with the define_clock constraint.
Avoid using gated clocks to eliminate clock skew. If possible, move the
logic to the data pin instead of using gated clocks. If you do use gated
clocks, you must define them explicitly, because the software does not
propagate the frequency of clock ports to gated clocks.
To define a gated clock, attach the define_clock constraint to the clock
source, as described above for internal clocks. To attach the constraint
to a keepbuf (a keepbuf is a placeholder instance for clocks generated from
combinatorial logic), do the following:
Attach the syn_keep attribute to the gated clock to ensure that it
retains the same name through changes to the RTL code.
Attach the define_clock constraint to the net or pin connected to the
keepbuf instance generated for the gated clock.
March 2014 315
Specify edge-to-edge clock delays on the Clock to Clock tab
(define_clock_delay).
After synthesis, check the Performance Summary section of the log file for a
list of all the defined and inferred clocks in the design.
Defining Input and Output Constraints (Legacy)
In addition to setting I/O delays in the SCOPE window as described in Setting
Clock and Path Constraints, on page 305, you can also set the Use clock period
for unconstrained IO option.
Open the SCOPE window, click Inputs/Outputs, and select the port (Port).
You can set the constraint for
All inputs and outputs (globally in the top-level netlist)
For a whole bus
For single bits
You can specify multiple constraints for the same port. The software
applies all the constraints; the tightest constraint determines the worst
slack. If there are multiple constraints from different levels, the most
specific overrides the more global. For example, if there are two bit
constraints and two port constraints, the two bit constraints override
the two port constraints for that bit. The other bits get the two port
constraints.
Specify the constraint value in the SCOPE window:
Select the type of delay: input or output (Type).
Check the Enabled box, and save the constraint file in the project.
Make sure to specify explicit constraints for each I/O path you want to
constrain.
To determine how the I/O constraints are used during synthesis, do the
following:
Select Project->Implementation Options, and click Constraints.
To use only the explicitly defined constraints disable Use clock period for
unconstrained IO.
LO
316 March 2014
To synthesize with all the constraints, using the clock period for all
I/O paths that do not have an explicit constraint enable Use clock
period for unconstrained IO.
Synthesize the design. When you forward-annotate the constraints,
the constraints used for synthesis are forward-annotated for place-
and-route.
Input or output ports with explicitly defined constraints, but without a
reference clock (-ref option) are included in the System clock domain and
are considered to belong to every defined or inferred clock group.
If you do not meet timing goals after place-and-route and you need to
adjust the input constraints; do the following:
Open the SCOPE window with the input constraint.
In the Route column for the input constraint, specify the actual route
delay in nanoseconds, as obtained from the place-and-route results.
Adding this constraint is equivalent to putting a register delay on the
input register.
Defining False Paths (Legacy)
You define false paths by setting constraints explicitly on the Delay Paths tab
or implicitly on the Clock and Clock to Clock tabs. See Defining
From/To/Through Points for Timing Exceptions, on page 274 for object
naming and specifying through points.
To define a false path between ports or registers, select the SCOPE Delay
Paths tab, and do the following:
From the Delay Type pull-down menu, select False.
Use the pull-down to select the port or register from the appropriate
column (From/To/Through).
The software treats this as an explicit false constraint and assigns it the
highest priority. Any other constraints on this path are ignored.
To define a false path between two clocks, select the SCOPE Clocks tab,
and assign the clocks to different clock groups:
March 2014 317
The software implicitly assumes a false path between clocks in different
clock groups. This false path constraint can be overridden by a
maximum path delay constraint, or with an explicit constraint.
To define a false path between two clock edges, select the SCOPE Clock to
Clock tab, and do the following:
Specify one clock as the starting clock edge (From Clock Edge).
Specify the other clock as the ending clock edge (To Clock Edge).
Click in the Delay column, and select false.
Use this technique to specify a false path between any two clocks,
regardless of clock groups. This constraint can be overridden by a
maximum delay constraint on the same path
To override an implicit false path between any two clocks described
previously, set an explicit constraint between the clocks by selecting the
SCOPE Clock to Clock tab, and doing the following:
Specify the starting (From Clock Edge) and ending clock edges (To Clock
Edge).
Specify a value in the Delay column.
The software treats this as an explicit constraint. You can use this
method to constrain a path between any two clocks, regardless of
whether they belong to the same clock group.
To set an implicit false path on a path to/from an I/O port, do the
following:
Select Project->Implementation Options->Constraints.
Disable Use clock period for unconstrained IO.
LO
Chapter 6: Specifying Constraints Translating Altera QSF Constraints
318 March 2014
Translating Altera QSF Constraints
If you have an Altera Quartus Settings File (QSF) with I/O constraints, you
can use the legacy qsf2sdc translator and the following procedure to translate
these constraints to the sdc format and use the translated constraints to drive
synthesis. For example, you can translate the I/O constraints and use it for
physical synthesis.
If you want to convert an entire Quartus project to a synthesis project, use
the qsf2syn utility and the procedure described in Importing Projects from
Quartus, on page 769.
1. Run the qsf2sdc utility.
Make sure the input QSF file has a qsf extension.
From the command line, run the translator on the QSF file. The
translator is in the bin directory: install_dir/bin/qsf2sdc.exe. Use the
following syntax:
installDir/bin/qsf2sdc -iqsf constraintsFile.qsf
-osdc constraintsFile.sdc
[-oqsf residualConstraintsFile>.qsf] [-all]
[-silent]
The translator generates a constraint file in the sdc format, which
contains the I/O constraints from the qsf file that are relevant to
synthesis. It ignores the other back-end constraints in the file. See
qsf2sdc Conversion, on page 178 in the Reference Manual for details of
the syntax and a list of supported pin location and I/O constraints.
2. After translating the constraints, edit the new sdc file.
Visually inspect the translated file.
The original qsf commands are written as comments in the new sdc
file so that you can validate the translated constraints. Constraints
which were successfully translated are specified as Supported.
However, constraints which were unsuccessfully translated are
specified as Unsupported. Use the -silent option to suppress all the
#Supported and #Unsupported messages in the sdc file.
Manually edit the sdc file to complete the translation of constraints,
as necessary.
Translating Altera QSF Constraints Chapter 6: Specifying Constraints
March 2014 319
Optionally, use the -all option to convert any instances with location
assignments. By default, only pin location assignments and IO
standards are automatically converted.
3. To run physical synthesis, create a single sdc file that contains all of the
constraints.
Include timing constraints created previously into the sdc file
containing the translated physical constraints. Make sure that all of
the following types of constraints are combined into the sdc file
Timing Constraints:
Clock
Clock-to-clock
IO delays
IO standard, drive, slew and pull-up/pull-down
Multi-cycle and false paths
Max-delay paths
DCM parameters
Include any physical constraints you have, like syn_loc constraints on
I/O pins and pad types.
Include any synthesis attributes from logic synthesis, such as
syn_ramstyle, into the sdc file.
4. Edit the original qsf file.
Remove all translated constraints from the original qsf file.
If there are any untranslated QSF commands left in the file, add the
qsf file to your project. The file must have the same base name as the
vqm netlist so that the Altera P&R tool can source the file.
5. Run a constraint check by selecting Run->Constraint Check.
bility of the timing constraints in any sdc files for your project. The
report is written to the projectName_cck.rpt file.
6. Add the generated sdc file to the project, and use it to drive synthesis.
LO
Chapter 6: Specifying Constraints Specifying Xilinx Constraints (Legacy)
320 March 2014
Specifying Xilinx Constraints (Legacy)
For Xilinx designs, you can import Xilinx constraints from a ucf file in
addition to specifying constraints within the synthesis tool. In the output
files, the synthesis tool separates the timing constraints from the physical
constraints. Timing constraints are written to the synplicity.ucf file and physical
constraints to the design.ncf file, as shown in this figure:
1. To specify user constraints, double-click on an existing sdc constraint
file.
See Entering and Editing SCOPE Constraints (Legacy), on page 303 for
details on how to specify constraints.
2. To use constraints from a Xilinx UCF file, use the procedures described
in Converting and Using Xilinx UCF Constraints, on page 325.
The synthesis tool writes out the timing constraints and physical
constraints into separate files:
synplicity.ucf Contains all timing constraints, whether user-specified or
translated from a ucf file
<design>.ncf Contains all physical constraints
UCF
ucf2sdc
User constraints
Synthesis SDC Constraints
Timing
synplicity.ucf <design>.ncf
Physical
Specifying Xilinx Constraints (Legacy) Chapter 6: Specifying Constraints
March 2014 321
4. Use synplicity.ucf and design.ncf as input to the Xilinx place-and-route tool.
Update scripts or older par_opt files if needed to ensure that these files
are used to drive place-and-route.
Setting Clock Priority in Xilinx Designs (Legacy)
You use the syn_clock_priority attribute to set clock priority and resolve clock
conflicts in Xilinx designs. You can use this attribute effectively to override
DCM clocks, and to resolve paths with timing conflicts. You set the attribute
by specifying a positive value for the clock, with 1 being the highest priority.
define_attribute {n:u_fx_clkrstgen.clk_100_dcm}
{syn_clock_priority} {1}
Note: Use the syn_clock_priority attribute only with Xilinx devices, when
you are running the ISE place-and-route tool. For Vivado place
and route, however, Xilinx 7 Series devices do not support this
attribute and must not be used.
For details about the attribute and how it is forward-annotated, refer to
syn_clock_priority, on page 101 of the Reference Manual.
The following sections discuss how to use the attribute to override DCM
clocks and resolve paths with multiple timing specifications:
Overriding DCM Clocks, on page 321
Specifying Clock Priority for BUFG and BUFGMUX Elements, on
page 323
Defining a False Path for Xilinx BUFGMUX_CTRL, on page 324
Overriding DCM Clocks
When you override DCM clocks with declared clocks, ISE does not honor this.
Instead of manually editing the UCF file, you can use the syn_clock_priority
attribute to assign a priority to a particular clock. The tool forward-annotates
the clock priority as a TIMESPEC or PERIOD statement in the ucf file. For
details, see Effect of syn_clock_priority, on page 104 of the Reference Manual
for details.
LO
322 March 2014
1. If you want to override a DCM or other derived clock with a user-defined
clock, set syn_clock_priority when you are prompted to do so.
The tool automatically prompts you to do this.
If the override clock is in a different group from the DCM source clock,
the tool adds TIGs to the UCF between (from/to and to/from) the DCM
source clock net and the DCM output net where the overriding clock is
defined.
2. If you also set a priority for the override clock at the DCM output, make
sure that the priority of the DCM input clock is lower than the priority
on the override clock.
You must do this because DCM derived clocks inherit the priority of the
DCM base clock. If you do not ensure that the DCM input clock has a
lower priority, the tool will forward-annotate it instead of the override
clock.
3. To correctly specify the syn_clock_priority attribute to a derived clock
output of a DCM, apply it immediately at the output where the derived
clock is created.
To set syn_clock_priority for the DCM CLKFX output in the following figure,
you must specify the following syntax in the sdc file:
define_attribute {n:dcm_module_b.clk0fx} {syn_clock_priority} {1}
Specifying Xilinx Constraints (Legacy) Chapter 6: Specifying Constraints
March 2014 323
4. For DCMs with dual output clock pins, specify which clock is to be
forward-annotated by setting the clock priority, unless the input clock
select pin of the DCM is tied high or low and indicates an explicit choice.
For DCMs with dual input clock pins, only one of the clocks is propa-
gated through the DCM to create the derived clocks in ISE. This is true
even if the two clocks on these pins are unrelated. So, unless the input
clock select pin explicitly indicates the choice. If the input clock select
pin is tied high or low, you do not need to set clock priority, because
there is no clock conflict.
Specifying Clock Priority for BUFG and BUFGMUX Elements
The FPGA synthesis tools allow multiple clocks to propagate along a single
net, through unate logic or through a mux. The Xilinx ISE does not do this, so
you must indicate clock priority in case of conflict with the syn_clock_priority
attribute.
1. If you want to specify clock priority on a path with BUFGMUX
components, set syn_clock_priority.
In some cases, the tool generates a warning and prompts you to do this
when it detects multiple timing on a path.
2. If you set a priority for both the nets driving the data inputs of a
BUFGMUX, make sure that one has a higher priority than the other.
The tool only propagates the clock with the highest priority values
through the mux. If you set the same value on both mux inputs, you see
a warning message in the log file.
3. To specify clock priority for a BUFG on a derived clock, specify the
syn_clock_priority directly on the BUFG, as shown in this example:
define_clock {i:CLK_BUF0FB} -name {i:CLK_BUF0FB} -freq 100
-clockgroup clk0_derived_clock
define_clock {i:CLK_BUF0} -name {i:CLK_BUF0} -freq 30
-clockgroup clk0fx_derived_clock
define_attribute {i:CLK_BUF0} {syn_clock_priority} {1}
define_attribute {i:CLK_BUF0FB} {syn_clock_priority} {1}
You cannot set this attribute on any other instances except BUFGs.
LO
324 March 2014
Defining a False Path for Xilinx BUFGMUX_CTRL
BUFGMUX_CTRL is a wrapper around a Xilinx BUFGCTRL primitive. It consists of
a clock buffer with two clock inputs, one clock output, and a select line. The
tool does not consider the BUFGMUX_CTRL a sequential element and does not
perform timing analysis on this path.
If you want to define a false path constraint for BUFGMUX_CTRL and forward-
annotate it, do the following:
1. Specify TIG (timing ignore) constraints on both the S0 and S1 pins of the
BUFGCTRL beneath the BUFGMUX_CTRL, as in this example:
PIN "BUFGMUX_CTRL_inst/BUFGCTRL.S0" TIG;
PIN "BUFGMUX_CTRL_inst/BUFGCTRL.S1" TIG;
You must apply the constraint to the BUFGCTRL pins, not the wrapper.
Although you can set the constraint on the clock enable pins, it is
recommended that you set it on the select pins, because this allows you
to switch between the clock inputs without any glitches in setup/hold
times.
2. Save the constraints in a separate ucf file.
3. Add the file to the project.
4. Synthesize as usual.
The tool forward-annotates the constraints you specified to the place-
and-route tool.
Converting and Using Xilinx UCF Constraints Chapter 6: Specifying Constraints
March 2014 325
Converting and Using Xilinx UCF Constraints
As you iterate through the flow, you might want to use Xilinx UCF
constraints to guide synthesis. To do this, you must translate the UCF
constraints into SDC constraints that the synthesis tools can use. This is
primarily used to move a Synplify Pro project to the Synplify Premier
synthesis tool to run physical synthesis by converting the project and the
UCF constraints.
The following procedures show you how to use the GUI commands and
convert the UCF constraints from a logic synthesis design into a physical
synthesis design, and forward-annotate them for place-and-route. The first
procedure describes how to deal with UCF constraints if you do not want to
create a project.
Converting UCF Constraints Without Creating a Project, on page 325
Using Xilinx UCF Constraints in a Logic Synthesis Design, on page 326
Support for UCF Conversion, on page 329
These procedures do not describe how to translate UCF constraints from a
Xilinx project into a synthesis project. For that information, see Converting
Xilinx Projects with ise2syn, on page 800.
Converting UCF Constraints Without Creating a Project
If you want to use UCF constraints but do not want to create a new project to
do so (Using Xilinx UCF Constraints in a Logic Synthesis Design, on
page 326), you must translate the UCF constraints manually. If you just add
the UCF file to the project, the UCF constraints will be passed to the Xilinx
tool, but the place-and-route tool might not honor them because object
names might not match after synthesis. To ensure that the UCF constraints
are used, do the following:
1. Manually convert the UCF constraints to SDC constraints.
2. Add the sdc file to the project and run synthesis.
3. Run place-and-route.
The synthesis tool correctly forward-annotates the sdc constraints that
you converted in step 1. The Xilinx tool runs place-and-route tool using
the forward-annotated constraints.
LO
Chapter 6: Specifying Constraints Converting and Using Xilinx UCF Constraints
326 March 2014
Using Xilinx UCF Constraints in a Logic Synthesis Design
You can run logic synthesis in the Synplify Pro tool or in the Synplify Premier
tool in logic synthesis mode. The following procedure shows you how to use
Xilinx UCF constraints for a logic synthesis run with either of the tools.
1. Start with the Xilinx constraint files to be translated.
You can use the following kinds of files:
These files must refer to design objects in the mapped synthesis tool
database so as to be consistent with subsequent synthesis runs. If
you use a UCF file that refers to XST design objects, naming might be
inconsistent. You can have multiple constraint files, one for the top-
level, and others for blocks. See Supported Input Files for UCF
Conversion, on page 329 for details about the input files.
Add all Xilinx constraint files to be converted to the logic synthesis
project.
Add the corresponding netlist files to the project, along with the
constraint file.
2. Do an initial synthesis run.
Set up a P&R implementation.
Synthesize the design and run P&R.
Check the log files for any constraint-related warnings and fix them
before proceeding.
3. Select Project->Convert Vendor Constraints to open the UCF to SDC Conversion
dialog box.
UCF Top-level constraint file, with corresponding EDIF file (edf)
NCF Block-level constraint file, with corresponding EDIF file (edn, edf,
ngc, or ngo)
XCF Block-level constraint file, with corresponding EDIF file (ngc or ngo)
March 2014 327
4. Specify the translation options:
Specify a name for the new project in Project Name.
Set a location for the new project in Project Location.
In the Constraint Files section, enable the files you want to use. This
section lists the files you added to the project in step 2. If you do not
have corresponding EDIF files for the constraint files you enable, you
see warning messages in the box at the bottom of the dialog box.
Enable Run Constraints Checker after Conversion and Invoke Report File.
Click the Convert button in the upper right.
The tool uses information from the project srd file and translates the
constraints in the input files, using a separate process for the top
level and for each block. It then creates a new project. Note that it
does not delete the original project or files, but creates a new one. See
LO
328 March 2014
Generated Files after UCF Conversion, on page 330 for names and
descriptions of the files generated after conversion.
Finally, it runs the constraints checker and reports any Xilinx
constraints that cannot be translated. See Support for UCF
Conversion, on page 329 for information about supported and
unsupported constraints.
Check the ucf2sdc.log file for any errors or warnings.
5. To use the generated sdc file to drive synthesis for the new project, do
the following:
Open the sdc file and check it. Edit it if necessary. You can also
rename this file.
Make sure the file is added to the project.
Run logic synthesis by clicking Run.
6. After logic synthesis, you can do either or both of the following:
Use the newly-generated project and the sdc files with translated
constraints for synthesis.
Use the synplicity.ucf and unsupported.ucf files for Xilinx P&R. You can
use the ucf2sdc.log file and the unsupported.ucf file to manually
translate any remaining constraints.
March 2014 329
Support for UCF Conversion
For procedures on converting UCF constraints, see the methods listed
Converting and Using Xilinx UCF Constraints, on page 325. The following
describe what the software supports when translating UCF constraints to
SDC.
Supported Input Files for UCF Conversion, on page 329
Generated Files after UCF Conversion, on page 330
Supported UCF Constraints, on page 331
Supported Input Files for UCF Conversion
The synthesis software can translate Xilinx constraints from UCF, NCF, and
XCF files with the Project->Convert Vendor Constraints command. The UCF file is
for the top-level design, and the XCF and NCF files are for blocks. The
following table lists support criteria for each of these formats:
UCF You can only have UCF files for the top-level project.
Paths referring to elements must start at the top level.
The UCF file must be one written for the Synopsys FPGA synthesis netlist.
If it is an XST netlist, object names may not match.
The Convert Vendor Constraints command does not convert constraints if the
ucf file was generated by the Synopsys FPGA tools. It ignores everything
after the following comment line:
# Constraints generated by Synplify Pro maprc, Build number
The tool notifies you that it is ignoring these comments, and puts the
unconverted constraints in the design_unsupported.ucf file.
If you want to convert constraints from a Synopsys ucf file, delete the
comment line.
NCF You can only use block-level NCF files.
A project can have multiple NCF files.
Each NCF file must have a corresponding edn, edf, ngc, or ngo file with
the same name.
XCF You can only use block-level XCF files.
A project can have multiple XCF files.
Each XCF file must have a corresponding ngc or ngo file with the same
name.
LO
330 March 2014
Generated Files after UCF Conversion
The tool creates these files after UCF conversion:
ucf2sdc.log Log file that contains messages after ucf conversion
completes.
prjFile_conv.prj The default name for the new project that was generated.
ucfFile_conv.sdc Contains converted Xilinx constraints for logic synthesis.
The tool generates a corresponding sdc file for each input
ucf file. The name for this file is derived from the input
UCF file name.
synplify.ucf After logic synthesis, this one file contains all the
supported input Xilinx constraints in the ucf format.
Unsupported constraints are in a separate file.
After physical synthesis, this one file contains both
supported and unsupported constraints in the ucf
format.
unsupported.ucf File that contains all the unsupported Xilinx constraints
in the ucf format after logic synthesis. This can include
any physical constraints not used for synthesis.
Top.prj
For further synthesis
Top.srd
Top.ucf
Top.srs
IP1.ngc
IP1.xcf
Top.srs
IP2.edn
IP2.ncf
Top_conv.prj
Top_conv.sdc
Top_unsupported.ucf
ucf2sdc.log
IP1_conv.sdc
IP1_unsupported.ucf
ucf2sdc.log
IP2_conv.sdc
IP2_unsupported.ucf
ucf2sdc.log
March 2014 331
The next figure shows how the project-level input files are handled in a post-
translation synthesis run:
Supported UCF Constraints
The UCF converter supports the following types of constraints:
FF RAM ROM DSP Net Inst View Collection Port Pin
PERIOD Yes Yes Yes Yes
FROM/TO Yes Yes Yes Yes Yes Yes Yes Yes Yes
TIG Yes Yes Yes Yes Yes Yes Yes Yes Yes
OFFSET Yes Yes Yes Yes Yes Yes Yes Yes Yes
TNM
TNM_NET
TIMEGRP
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
LOC Yes Yes Yes Yes Yes Yes Yes Yes Yes
IO PROPS Yes Yes Yes Yes
General
PROPs
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Top.v
Top.sdc
Top_conv.sdc
Top_unsupported.ucf
1P1.ngc
IP1_conv.sdc
IP1_unsupported.ucf
Top.edf
synplicity.ucf
Top.prj
For P&R
1P2.edn
IP2._conv.sdc
IP2_unsupported.ucf
Logical
and
Physical
Synthesis
LO
332 March 2014
Unsupported UCF Constraints
Currently, the UCF converter does not handle the following:
Back-annotated netlists from the physical synthesis flow.
Case-sensitive matching on instance and net names. For example: aBc.
Nets driven by LUTs, except for nets that source OPADs.
Collections that include inferred RAMs or DSPs. The tool cannot
guarantee that inferred components match.
The MAXDELAY constraint.
The UCF converter does not currently convert the following keywords:
Unsupported Keywords Description
BRAMS_PORT[A/B] Predefined keyword
INPUT_JITTER, PRIORITY, DATAPATHONLY TIMESPEC constraint
RISING, FALLING TIMEGRP constraint
CLOSED, OPEN AREA_GROUP constraint
HIGH, LOW, VALID OFFSET constraint
March 2014 333
CHAPTER 7
Synthesizing and Analyzing the Results
This chapter describes how to run synthesis, and how to analyze the log file
generated after synthesis. See the following:
Synthesizing Your Design, on page 334
Checking Log File Results, on page 342
Handling Messages, on page 356
Using Continue on Error, on page 366
Validating Results for Physical Synthesis, on page 376
Analyzing Congestion After Logic Synthesis, on page 378
LO
Chapter 7: Synthesizing and Analyzing the Results Synthesizing Your Design
334 March 2014
Synthesizing Your Design
Once you have set your constraints, options, and attributes, running
synthesis is a simple one-click operation. See the following:
Running Logic Synthesis, on page 334
Running Physical Synthesis, on page 334
Using Up-to-date Checking for Job Management
Running Logic Synthesis
When you run logic synthesis, the tool compiles the design and then maps it
to the technology target you selected.
1. If you want to compile your design without mapping it, select Run->
Compile Only or press F7.
A compiled design has the RTL mapping, and you can view the RTL view.
You might want to just compile the design when you are not ready to
synthesize the design, but when you need to use a tool that requires a
compiled design, like the SCOPE interface.
2. To synthesize the logic, set all the options and attributes you want, and
then click Run.
3. To run logic synthesis as the initial phase of physical synthesis, see
Running Physical Synthesis, on page 334.
You can now run physical synthesis as described in Running Physical
Running Physical Synthesis
When you run physical synthesis, the tool not only compiles the design and
maps it to the technology target you selected, but also uses placement infor-
mation to concurrently optimize and synthesize your design. Regardless of
the flow you are using, run physical synthesis in two phases. First, run logic
synthesis and fix any issues that come up. Then run physical synthesis.
Synthesizing Your Design Chapter 7: Synthesizing and Analyzing the Results
March 2014 335
1. Run logic synthesis as the initial phase of physical synthesis, by doing
the following:
Set the options and attributes you want for physical synthesis,
making sure to set up P&R to run automatically after synthesis.
Disable the Physical Plus switch either in the Project view or from the
Implementation Options dialog box (Implementation Options->Options).
Click Run to run logic synthesis.
The Synplify Premier tool goes through compiling and mapping phases.
When logical synthesis completes, Done! (or Warnings!) displays in the
Project view. Output results files are shown in the right pane of the
Project view.
Note: The physical synthesis flow runs the Synplify global placer by
default. To run the Xilinx global placer, use the
syn_use_xilinx_placement attribute.
2. Make adjustments to your design as needed.
Check the output files and analyze the results.
Fix any errors.
See Validating Results for Physical Synthesis, on page 376 for details.
3. Set options for the physical synthesis run.
Set any other physical constraints.
Enable the Physical Plus switch either in the Project view or from the
Implementation Options dialog box (Implementation Options->Options).
LO
336 March 2014
If you want a different directory for your physical synthesis results,
click on the Implementation Options->Implementation Results tab and specify
a new name for the implementation.
Make sure the place-and-route implementation is enabled
(Implementation Options->Place and Route tab).
If you are using a Design Planner flow, click on the Design Planning tab
and enable the desired design plan file (sfp) if needed.
You do not need a design plan file to run graph-based physical
synthesis. However, if you are using a graph-based flow and want to
use a design plan file, use the procedure described in Creating and
Using a Design Plan File for Physical Synthesis, on page 896.
For older Altera technologies, you must create a design plan (sfp) to
run physical synthesis. See Chapter 18, Floorplanning with Design
Planner for more information.
March 2014 337
Click OK in the Implementation Options dialog box.
4. Run physical synthesis by clicking Run.
The tool performs optimizations using placement-aware synthesis.
Synthesis and placement are integrated by performing concurrent place-
ment and optimization based on timing constraints and device
technology.
Using Up-to-date Checking for Job Management
Synthesis is becoming more complex and consists of running many jobs.
Often, part or all of the job flow is already up-to-date and rerunning the job
may not be necessary. For large designs that may take hours to run, up-to-
date checking can reduce the time for rerunning jobs.
Up-to-date checking is run for all synthesis design flows. However, for the
Hierarchical Project Management flows, up-to-date checking is an essential
feature. For example, if a project contains four sub-projects and only one
project is modified, then the other three projects do not need to be rerun. This
saves in overall runtime.
Up-to-date checking includes the following:
The GUI launches mapper modules (pre-mapping and technology
mapping) and saves the intermediate netlists and log files in the synwork
and synlog folders, respectively.
After each individual module run completes, the GUI optionally copies
the contents of these intermediate log files from the synlog folder and
adds them to the Project log file (rev_1/projectName.srr). To set this option,
see Copy Individual Job Logs to the SRR Log File, on page 339.
If you re-synthesize the design and there are no changes to the inputs
(HDL, constraints, and Project options):
The GUI does not rerun pre-mapping and technology mapping and no
new netlist files are created.
In the HTML log file, the GUI adds a link that points to the existing
pre-mapping and mapping log files from the previous run. Double-
click on this link (@L: indicates the link) to open the new text file
window.
LO
338 March 2014
If you open the text log file, the link is a relative path to the
implementation folder for the pre-mapping and mapping log files from
the previous run.
Note: Also, the GUI adds a note that indicates mapping will not be re-
run and to use the Run->Resynthesize All option in the Project view
to force synthesis to be run again.
As the job is running, you can click in the job status field of the Project view
to bring up the Job Status display. When you rerun synthesis, the job status
identifies which modules (pre-mapping or mapping) are up-to-date.
March 2014 339
See also:
Copy Individual Job Logs to the SRR Log File
Limitations and Risks
Copy Individual Job Logs to the SRR Log File
By default, up-to-date checking uses links in the log file (srr) to individual job
logs. To change this option so that individual job logs are always appended to
the main log file (srr), do the following:
1. Select Options->Project View Options from the Project menu.
2. On the Project View Options dialog box, scroll down to the Use links in SRR log
file to individual job logs option.
3. Use the pull-down menu, and select off.
Job Status for Synthesis Run
Job Status for Re-synthesis Run
LO
340 March 2014
Limitations and Risks
Up-to-date checking limitations and risks include the following:
Compiler up-to-date checks are done internally by the compiler and with
no changes to the compiler reporting structure.
GUI up-to-date checks use timestamp information of its input files to
decide when mapping is re-run. Be aware that:
The GUI uses netlist files (srs and srd) from the synwork folder for
timestamp checks. If you delete an srs file from the implementation
folder, this does not trigger compiler or mapper re-runs. You must
delete netlist files from the synwork folder instead.
The copy command behaves differently on Windows and Linux. On
Windows, the timestamp does not change if you copy a file from one
March 2014 341
directory to another. But on Linux (and MKS shell), the timestamp
information gets changed.
If your Project file includes ngc or ngo cores, up-to-date checking does
not work. This condition always triggers a rerun, even when nothing
is changed in your design. The Xilinx ngc2edif utility converts the
ngc/ngo to edif and the timestamp is always the latest.
When running a design, the up-to-date checking feature automatically
determines if the design needs to be re-synthesized. However, when you
modify constraints in a Tcl file sourced within the constraints file, the
software is not aware of these changes and does not force the design to
be re-synthesized.
LO
Chapter 7: Synthesizing and Analyzing the Results Checking Log File Results
342 March 2014
Checking Log File Results
You can check the log file for information about the synthesis run. In
addition, the Synplify Pro and Synplify Premier interfaces have a Tcl Script
window, that echoes each command as it is run. The following describe
different ways to check the results of your run:
Viewing and Working with the Log File, on page 342
Accessing Specific Reports Quickly, on page 346
Accessing Results Remotely, on page 348
Analyzing Results Using the Log File Reports, on page 352
Using the Watch Window, on page 352
Checking Resource Usage, on page 354
Viewing and Working with the Log File
The log file contains the most comprehensive results and information about a
synthesis run. The default log file is in HTML format, but there is a text
version available too.
For Synplify Pro or Synplify Premier users who only want to check a few
critical performance criteria, it is easier to use the Watch Window (see Using
the Watch Window, on page 352) instead of the log file. For details, read
through the log file.
1. To open the log file, use one of these listed methods, according to the
format you want:
HTML Select View->Log File.
Click the View Log button in the Project window.
Double-click the designName.htm file in the Implementation Results
view.
Text Double-click the designName.srr file in the Implementation Results view.
To set the text file version to open by default instead of the HTML
version, select Options->Project View Options, and toggle off the View log
file in HTML option.
Checking Log File Results Chapter 7: Synthesizing and Analyzing the Results
March 2014 343
The log file lists the compiled files, details of the synthesis run, and
includes color-coded errors, warnings and notes, and a number of
reports. For information about the reports, see Analyzing Results Using
the Log File Reports, on page 352.
2. Navigate the log file to view specific pieces of information.
For quicker access to specific log information, use alternative access
methods, described in Accessing Specific Reports Quickly, on page 346
instead of the ones described here.
Use the panel on the left of the HTML log file to navigate to the section
you want. You can use the Find button and the search field at the
bottom of this panel to search the headings.
LO
344 March 2014
To search the body of the log file, use Control-f or the Edit->Find
command. See Viewing and Working with the Log File, on page 342 for
details.
To add bookmarks or for general information about working in an
editing window, see Editing HDL Source Files with the Built-in
Text Editor, on page 111.
The areas of the log file that are most important are the warning
messages and the timing report. The log file includes a timing report
that lists the most critical paths. The synthesis products also let you
generate a report for a path between any two designated points, see
Generating Custom Timing Reports with STA, on page 459. The following
table lists places in the log file you can use when searching for informa-
tion.
To find ... Search for ...
Notes @N or look for blue text
Warnings and errors @W and @E, or look for purple and red
text respectively
Performance summary Performance Summary
The beginning of the timing report START TIMING REPORT
March 2014 345
3. Resolve any errors and check all warnings.
You must fix errors, because you cannot synthesize a design with errors.
Check the warnings and make sure you understand them. See Checking
Results in the Message Viewer, on page 356 for information. Notes are
informational and usually can be ignored. For details about
crossprobing and fixing errors, see Handling Warnings, on page 366,
Editing HDL Source Files with the Built-in Text Editor, on page 111, and
Crossprobing from the Text Editor Window, on page 424.
If you see Automatic dissolve at startup messages, you can usually ignore
them. They indicate that the mapper has optimized away hierarchy
because there were only a few instances at the lower level.
4. If you are trying to find and resolve warnings, you can bookmark them
as shown in this procedure:
Select Edit->Find or press Ctrl-f.
Type @W as the criteria on the Find form and click Mark All. The
software inserts bookmarks at every line with a warning. You can
now page through the file from bookmark to bookmark using the
commands in the Edit menu or the icons in the Edit toolbar. For more
information on using bookmarks, see Editing HDL Source Files with
the Built-in Text Editor, on page 111.
5. To crossprobe from the log file to the source code, click on the file name
in the HTML log file or double-click on the warning text (not the ID code)
in the ASCII text log file.
Detailed information about slack
times, constraints, arrival times,
etc.
Interface Information
Resource usage Resource Usage Report. See Checking
Resource Usage, on page 354.
Gated clock conversions Gated clock report
To find ... Search for ...
LO
346 March 2014
Accessing Specific Reports Quickly
The log file contains all the results from the synthesis run, but you might
want to hone in on specific information. Instead of browsing the log file to find
the information you need, you can use the techniques described below:
1. To quickly view specific pieces of log information, go to the Project Status
window and click the appropriate links to display the corresponding
reports or specific parts of the log file.
The Detailed Report links display parts of the log file, and the other links
go to special view windows for different kinds of reports. See The Project
Results View, on page 55 for more information about different reports
that can be accessed from the Project Results view.
Timing reports Click Detailed Report or Timing Report View in the Timing
Summary panel.
Log at different stages Click Detailed Report in the Run Status panel.
Area reports Click Detailed Report or Hierarchical Area Report in the
Area Summary panel.
High reliability reports Click Detailed Report in the High Reliability Report panel.
Optimizations Click Detailed Report in the Optimizations Summary
panel.
March 2014 347
2. To view timing information, use one of these methods:
Synplify Premier
Access the Timing Report section of the log file from the Run Status panel
in the Project Status window, as described in the previous step.
Synplify Premier
Click the T icon in the toolbar to open the Timing view.
Set important timing parameters to monitor in the Watch window,
like slack and frequency. See Using the Watch Window, on page 352
for details.
Click View Log in the Project view and navigate to the appropriate
section in the log file.
3. To view messages, use any of the following methods
From the Run Status panel in the Project Status window, click the link
that lists the number of errors, warnings, or notes at different design
stages. The Message window opens. Click the message ID to get more
information about the error and how to fix it.
This is the quickest method to narrow down the list of messages and
access the one you want.
The numbers of notes, errors, and warnings reported in the Run Status
panel might not match the numbers displayed in the Messages
window if the design contains compile points. The numbers reported
are for the top level.
Click the Messages tab at the bottom of the Project view to open a
window with a list of all the notes, errors and warnings. See Checking
Results in the Message Viewer, on page 356 for more information
about using this window.
LO
348 March 2014
Open the log file, locate the message, and click the message ID. The
log file includes all the results from the run, so it could be harder to
locate the message you want.
Accessing Results Remotely
You can access the log file results remotely from various mobile devices. For
example, you can use this feature to run synthesis for jobs with long
runtimes and then check the results of the synthesis run later from
anywhere. The Project Status report files can be accessed from any browser
without bringing up the synthesis tool.
To access the log file remotely, do the following:
1. Select Options->Project Status Page Location from the Project menu and
select the implementation for which you want the reports.
March 2014 349
2. Set the location for storing the project status page, using either of these
methods:
Enable Save to different location and specify a path for the location of the
status page. This allows you to save the status reports in different
locations.
LO
350 March 2014
Use an environment variable by enabling Use Environment Variable
SYNPLIFY_REMOTE_REPORT_LOCATION.
If you use this option, you must restart the tool the first time, since
the environment variable is not applied dynamically. This option
always saves the status report to the location indicated by the
variable.
Windows Enable Use Environment Variable SYNPLIFY_REMOTE_REPORT_LOCATION.
Specify the variable name SYNPLIFY_REMOTE_REPORT_LOCATION
and the location you want from the Control Panel on the Edit User
Variable dialog box.
Linux Specify setenv SYNPLIFY_REMOTE_REPORT_LOCATION pathLocation
in the .cshrc file.
Enable Use Environment Variable SYNPLIFY_REMOTE_REPORT_LOCATION.
March 2014 351
3. Click OK.
4. Run synthesis.
The status reports are saved to the location you specified for your
project. For example:
C:\synResults\tutorial\rev_1
5. Access the location you set up from any browser on a mobile device (for
example, a smart phone or tablet).
Access the location you set in the previous steps.
Open the projectName/implementationName/index.html file with any
browser.
Your company may need to set up a location on its internal internet,
where the status reports can be saved and later accessed with a URL
address.
LO
352 March 2014
Analyzing Results Using the Log File Reports
The log file contains technology-appropriate reports like timing reports,
resource usage reports, and net buffering reports, in addition to any notes,
errors, and warning messages.
1. To analyze timing results, do the following:
View the Timing Report (Performance Summary section of the log file)
and check the slack times. See Handling Negative Slack, on page 458
for details.
Check the detailed information for the critical paths, including the
setup requirements at the end of the detailed critical path
description. You can crossprobe and view the information graphically
and determine how to improve the timing.
In the HTML log file, click the link to open up the HDL Analyst view
for the path with the worst slack.
To generate Synplify Premier or Synplify Pro timing information about a
path between any two designated points, see Generating Custom Timing
Reports with STA, on page 459.
2. To check buffers, do the following:
Check the report by going to the Net Buffering Report section of the log
file.
Check the number of buffers or registers added or replicated and
determine whether this fits into your design optimization strategy.
3. To check logic resources, check the Resource Usage Report section at the
end of the log file, as described in Checking Resource Usage, on
page 354.
Using the Watch Window
The Watch window provides a more convenient viewing mechanism than the
log file for quickly checking key performance criteria or comparing results
from different runs. Its limitation is that it only displays certain criteria. If you
need details, use the log file, as described in Viewing and Working with the
Log File, on page 342.
March 2014 353
1. Open the Watch window, if needed, by checking View->Watch Window.
If you open an existing project, the Watch window shows the parameters
set the last time you opened the window.
2. If you need a larger window, either resize the window or move the Watch
Window as described below.
Hold down Ctrl or Shift, click on the window, and move it to a position
you want. This makes the Watch window an independent window,
separate from the Project view.
To move the window to another position within the Project view, right-
click in the window border and select Float in Main Window. Then move
the window to the position you want, as described above.
See Watch Window, on page 67 in the Reference Manual for information
about the popup menu commands.
3. Select the log parameter you want to monitor by clicking on a line and
selecting a parameter from the resulting popup menu.
The software automatically fills in the appropriate value from the last
synthesis run. You can check the clock requested and estimated
frequencies, the clock requested and estimated periods, the slack, and
some resource usage criteria.
4. To compare the results of two or more synthesis runs, do the following:
If needed, resize or move the window as described above.
Click the right mouse button in the window and select Configure Watch
from the popup.
Click Watch Selected Implementations and either check the
implementations you want to compare or click Watch All
LO
354 March 2014
Implementations. Click OK. The Watch window now shows a column for
each implementation you selected.
In the Watch window, set the parameters you want to compare.
The software shows the values for the selected implementations side by
side. For more information about multiple implementations, see Tips for
Optimization, on page 576.
Checking Resource Usage
Each FPGA architecture has a certain number of dedicated FPGA resources.
Use the Resource Usage section of the log file to check whether you are
exceeding the available resources.
1. Go to the Resource Usage report at the end of the log file (srr).
2. Check the number and types of components used to determine if you
have used too much of your resources.
The following is an example:
Resource Usage Report for top
Mapping to part: xc4vlx15sf363-10
Register bits not including I/Os: 15000 (122%)
Block Rams: 48 of 48 (100%)
DSP48s: 24 of 32 (75%)
Mapping Summary:
Total LUTs: 14740 (120%)
3. For Altera and Xilinx designs, you can also check the hierarchical area
report (projectName.areasrr).
This file contains the percentage utilization for various elements in the
design. See Hierarchical Area Report, on page 322 in the Reference
Manual for more about this file.
March 2014 355
If your design is overutilized, you can manage usage with resource-specific
attributes like syn_ramstyle, syn_dspstyle, and so on. For hierarchical designs
you can set limits with attributes like syn_allowed_resources or the Allocate
Timing and Resource Budgets command.
LO
Chapter 7: Synthesizing and Analyzing the Results Handling Messages
356 March 2014
Handling Messages
This section describes how to work with the error messages, notes, and
warnings that result after a run. See the following for details:
Checking Results in the Message Viewer, on page 356
Filtering Messages in the Message Viewer, on page 358
Filtering Messages from the Command Line, on page 360
Automating Message Filtering with a Tcl Script, on page 361
Log File Message Controls, on page 363
Handling Warnings, on page 366
Checking Results in the Message Viewer
The Tcl Script window includes a Message Viewer. By default, the Tcl window
is in the lower left corner of the main window. This procedure shows you how
to check results in the message viewer.
1. If you need a larger window, either resize the window or move the Tcl
window. Click in the window border and move it to a position you want.
You can float it outside the main window or move it to another position
within the main window.
2. Click the Messages tab to open the message viewer.
The window lists the errors, warnings, and notes in a spreadsheet
format. See Message Viewer, on page 71 in the Reference Manual for a
full description of the window.
Handling Messages Chapter 7: Synthesizing and Analyzing the Results
March 2014 357
3. To reduce the clutter in the window and make messages easier to find
and understand, use the following techniques:
Use the color cues. For example, when you have multiple synthesis
runs, messages that have not changed from the previous run are in
black; new messages are in red.
Enable the Group Common IDs option in the upper right. This option
groups all messages with the same ID and puts a plus symbol next to
the ID. You can click the plus sign to expand grouped messages and
see individual messages.
There are two types of message groups:
- The same warning or note ID appears in multiple source files
indicated by a dash in the source files column.
- Multiple warnings or notes in the same line of source code indicated
by a bracketed number.
Sort the messages. To sort by a column header, click that column
heading. For example, click Type to sort the messages by type. For
example, you can use this to organize the messages and work
through the warnings before you look at the notes.
To find a particular message, type text in the Find field. The tool finds
the next occurrence. You can also click the F3 key to search forward,
and the Shift-F3 key combination to search backwards.
LO
358 March 2014
4. To filter the messages, use the procedure described in Filtering
Messages in the Message Viewer, on page 358. Crossprobe errors from
the message window:
If you need more information about how to handle a particular
message, click the message ID in the ID column. This opens the
documentation for that message.
To open the corresponding source code file, click the link in the Source
Location column. Correct any errors and rerun synthesis. For
warnings, see Handling Warnings, on page 366.
To view the message in the context of the log file, click the link in the
Log Location column.
Filtering Messages in the Message Viewer
The Message viewer lists all the notes, warnings, and errors. It is not available
with the Synplify tool. The following procedure shows you how to filter out the
unwanted messages from the display, instead of just sorting it as described in
Checking Results in the Message Viewer, on page 356. For the command line
equivalent of this procedure, see Filtering Messages from the Command Line,
on page 360.
1. Open the message viewer by clicking the Messages tab in the Tcl window
as previously described.
2. Click Filter in the message window.
The Warning Filter spreadsheet opens, where you can set up filtering
expressions. Each line is one filter expression.
3. Set your display preferences.
March 2014 359
To hide your filtered choices from the list of messages, click Hide Filter
Matches in the Warning Filter window.
To display your filtered choices, click Show Filter Matches.
4. Set the filtering criteria.
Set the columns to reflect the criteria you want to filter. You can
either select from the pull-down menus or type your criteria. If you
have multiple synthesis runs, the pull-down menu might contain
selections that are not relevant to your design.
The first line in the following example sets the criteria to show all
warnings (Type column) with message ID FA188 (ID). The second set of
criteria displays all notes that begin with MF.
Use multiple fields and operators to refine filtering. You can use
wildcards in the field, as in line 2 of the example. Wildcards are case-
sensitive and space-sensitive. You can also use ! as a negative
operator. For example, if you set the ID in line 2 to !MF*, the message
list would show all notes except those that begin with MF.
Click Apply when you have finished setting the criteria. This
automatically enables the Apply Filter button in the messages window,
and the list of messages is updated to match the criteria.
The synthesis tool interprets the criteria on each line in the Warning
Filter window as a set of AND operations (Warning and FA188), and the
lines as a set of OR operations (Warning and FA188 or Note and MF*).
To close the Warning Filter window, click Close.
5. To save your message filters and reuse them, do the following:
Save the project. The synthesis tool generates a Tcl file called
projectName.pfl (Project Filter Log) in the same location as the main
project file. The following is an example of the information in this file:
LO
360 March 2014
log_filter -hide_matches
log_filter -field type==Warning
-field message==*Una*
-field source_loc==sendpacket.v
-field log_loc==usbHostSlave.srr
-field report=="Compiler Report"
log_filter -field type==Note
log_filter -field id==BN132
log_filter -field id==CL169
log_filter -field message=="Input *"
log_filter -field report=="Compiler Report"
When you want to reuse the filters, source the projectName.pfl file.
You can also include this file in a synhooks Tcl script to automate your
process.
Filtering Messages from the Command Line
The following procedure shows you how to use Tcl commands to filter out
unwanted messages. If you want to use the GUI, see Filtering Messages in the
Message Viewer, on page 358.
1. Type your filter expressions in the Tcl window using the log_filter
command. For details of the syntax, see log_filter, on page 75 in the
Reference Manual.
For example, to hide all the notes and print only errors and warnings,
type the following:
log_filter enable
log_filter hide_matches
log_filter field type==Note
2. To save and reuse the filter commands, do the following:
Type the log_filter commands in a Tcl file.
Source the file when you want to reuse the filters you set up.
3. To print the results of the log_filter commands to a file, add the log_report
command at the end of a list of log_filter commands.
log_report -print filteredMsg.txt
March 2014 361
This command prints the results of the preceding log_filter commands to
the specified text file, and puts the file in the same directory as the main
project file. The file contains the filtered messages, for example:
@N MF138 Rom slaveControlSel_1 mapped in logic. Mapper Report
wishbonebi.v (156) usbHostSlave.srr (819) 05:22:06 Mon Oct 18
@N(2) MO106 Found ROM, 'slaveControlSel_1', 15 words by 1 bits
Mapper Report wishbonebi.v (156) usbHostSlave.srr (820)
05:22:06 Mon Oct 18
@N MO106 Found ROM, 'slaveControlSel_1', 15 words by 1 bits Mapper
Report wishbonebi.v (156) usbHostSlave.srr (820) 05:22:06 Mon
Oct 18
@N MF138 Rom hostControlSel_1 mapped in logic. Mapper Report
wishbonebi.v (156) usbHostSlave.srr (821) 05:22:06 Mon Oct 18
@N MO106 Found ROM, 'hostControlSel_1', 15 words by 1 bits Mapper
Report wishbonebi.v (156) usbHostSlave.srr (822) 05:22:06 Mon
Oct 18
@N Synthesizing module writeUSBWireData Compiler Report
writeusbwiredata.v (59) usbHostSlave.srr (704) 05:22:06 Mon Oct 18
Automating Message Filtering with a Tcl Script
The following example shows you how to use a synhooks Tcl script to automat-
ically load a message filter file when a project opens and to send email with
the messages after a run.
1. Create a message filter file like the following. (See Filtering Messages in
the Message Viewer, on page 358 or Filtering Messages from the
Command Line, on page 360 for details about creating this file.)
log_filter -clear
log_filter -hide_matches
log_filter -field report=="VIRTEX2P MAPPER"
log_filter -field type==NOTE
log_filter -field message=="Input *"
log_filter -field message=="Pruning *"
puts "DONE!"
2. Copy the synhooks.tcl file and set the environment variable as described
in Automating Flows with synhooks.tcl, on page 826.
3. Edit the synhooks.tcl file so that it reads like the following example. For
syntax details, see synhooks File Syntax, on page 770 in the Reference
Manual.
LO
362 March 2014
The following loads the message filter file when the project is opened.
Specify the name of the message filter file you created in step 1. Note
that you must source the file.
proc syn_on_open_project {project_path} {
set filter filterFilename
puts "FILTER $filter IS BEING APPLIED"
source d:/tcl/filters/$filterFilename
}
Add the following to print messages to a file after synthesis is done:
proc syn_on_end_run {runName run_dir implName} {
set warningFileName "messageFilename"
if {$runName == "synthesis"} {
puts "Mapper Done!"
log_report -print $warningFileName
set f [open [lindex $warningFileName] r]
set msg ""
while {[gets $f warningLine]>=0} {
puts $warningLine
append msg $warningLine\n
}
close $f
Continue by specifying that the messages be sent in email. You can
obtain the smtp email packages off the web.
source "d:/tcl/smtp_setup.tcl"
proc send_simple_message {recipient email_server subject body}{
set token [mime::initialize -canonical text/plain -string
$body]
mime::setheader $token Subject $subject
smtp::sendmessage $token -recipients $recipient -servers
$email_server
mime::finalize $token
}
puts "Sending email..."
send_simple_message {address1,address2}
yourEmailServer subjectText> emailText
}
}
When the script runs, an email with all the warnings from the synthesis
run is automatically sent to the specified email addresses.
March 2014 363
Log File Message Controls
The log file message control feature allows messages in the current session to
be elevated in severity (for example, promoted to an error from a warning),
lowered in severity (for example, demoting a warning to a note), or suppressed
from the log file after the next run through the Log File Filter dialog box. This
dialog box is displayed by opening the log file in HTML mode and selecting
Log File Message Filter from the popup menu with the right mouse button.
Log File Filter Dialog Box
The Log File Filter dialog box is the primary control for changing a message
priority or suppressing a message. When you initially open the dialog box, all
of the messages from the log (srr) file for the active implementation are
displayed in the upper section and the lower section is empty. To use the dialog
box:
1. Select (highlight) the message to be promoted, demoted, or suppressed
from the messages displayed in the upper section.
LO
364 March 2014
2. Select the Suppress Message, Make Error, Make Warning, or Make Note button
to move the selected message from the upper section to the lower
section. The selected message is repopulated in the lower section with
the Override column reflecting the disposition of the message according
to the button selected.
Allowed Severity Changes
Allowed severity levels and preference settings for warning, note, and
advisory messages are:
Promote warning to error, note to warning, note to error
Demote warning to note
Suppress suppress warning, suppress note, suppress advisory
Note: Normal error messages (messages generated by default) cannot
be suppressed or changed to a lesser severity level.
When using the dialog box:
Use the control and shift keys to select multiple messages.
If an srr file is not present (for example, if you are starting a new project)
the table will be empty. Run the design at least once to generate an srr
file.
Clicking the OK button saves the message status changes to the project-
Name.pfl file in the project directory.
Message Reporting
The compiler and mapper must be rerun before the impact of the message
status changes can be seen in the updated log file.
When a projectName.pfl input file is present at the start of the run, the
message-status changes in the file are forwarded to the mapper and compiler
which generate an updated log file. Depending on the changes specified:
If an ID is promoted to an error, the mapper/compiler stops execution at
the first occurrence of the message and prints the message in the
@E:msgID :messageText format
March 2014 365
If an ID is promoted to a warning, the mapper/compiler prints the
message in the @W:msgID :messageText format.
If an ID is demoted to a note, the mapper/compiler prints the message
in the @N:msgID :messageText format.
If an ID is suppressed, the mapper/compiler excludes the message from
the srr file.
Note: The online, error-message help documentation is unchanged by
any message modification performed by the filtering mechanism.
If a message is initially categorized as a warning in the synthesis
tool, it continues to be reported as a warning in error-message
help irrespective its promotion/demotion status.
Updating the projectName.pfl file
The projectName.pfl file in the top-level project directory stores the user
message filter settings from the Log File Filter dialog box for that project. This
file can be edited with a text editor. The file entry syntax is:
message_override -suppress ID [ID ...] | -error ID [ID ...] | -warning ID [ID ...]
| -note ID [ID ...]
For example, to override the default message definition for note FX702 as a
warning, enter:
message_override -warning FX702
Note: After editing the pfl file, close and reopen the project to update
the overrides.
LO
Chapter 7: Synthesizing and Analyzing the Results Using Continue on Error
366 March 2014
Handling Warnings
If you get warnings (@W prefix) after a synthesis run, do the following:
Read the warning message and decide if it is something you need to act
on, or whether you can ignore it.
If the message is not self-explanatory or if you are unsure about how to
handle the error, click the message ID in either the message window or
HTML log file or double click the message ID in the ASCII text log file.
These actions take you to online information about the condition that
generated the warning.
Using Continue on Error
The Continue on Error (CoE) feature significantly reduces the overall synthesis
runtime by reducing the number of synthesis iterations. This can be a signif-
icant advantage in prototyping and the handling of large designs. The CoE
functionality varies with the synthesis tool:
In a Synplify Premier design, the Continue on Error option allows the
compilation process to continue for certain non-syntax compiler errors.
By default, the compiler stops the compilation process as soon as it
encounters an error in the design. As a result, a design with multiple
problems can require many iterations to identify and correct all the
issues. Multiple iterations lead to long turn-around times, especially
with complex designs with lengthy compilation times.
In both Synplify Pro and Synplify Premier designs, this option allows
mapping to continue even if there are compile points with errors.
The following procedures describe how to use various aspects of this feature:
Using Continue on Error During Compilation, on page 367
Analyzing Compilation Errors After Continue on Error, on page 368
Using Continue on Error for Compile Point Synthesis, on page 373
Using Continue on Error Chapter 7: Synthesizing and Analyzing the Results
March 2014 367
Using Continue on Error During Compilation
Synplify Premier
This procedure shows you how to use the Continue on Error feature to reduce
compiler iterations.
1. Enable the Continue on Error option for the design, using one of the
following methods:
Enable Continue On Error on the Options tab of the Implementation Options
dialog box.
Enable Continue on Error on the left side of the Project view.
Enter this command in the Tcl Script window:
set_option -continue_on_error 1
If you are working on a compile point design, select Options->Configure
Compile Point Process and enable Continue on Error. See Using Continue on
Error for Compile Point Synthesis, on page 373 for more information.
The compiler first parses the syntax and checks for syntax errors. If any
are encountered, it errors out. You must fix these errors before rerun-
ning compilation. Typical syntax errors are RTL code errors, and include
typos in keywords, missing semicolons, mismatched begin and end
brackets, or wrong syntax for functions, procedures, or tasks.
For the remaining stages of compilation (see Compilation Process and
CoE, on page 368 for details), the compiler does not halt when it
encounters an error but completes a one-pass compilation, and reports
LO
368 March 2014
all the errors it finds together. These non-syntax errors are related to
synthesis, and include out-of-range access, missing function or task
definitions, improper port or generics mappings, and coding from which
sequential elements cannot be extracted.
3. Analyze and fix any errors before proceeding with synthesis.
4. Synthesize the design, and analyze and fix any compile point errors
identified after mapping.
Compilation Process and CoE
The Continue on Error feature works in the latter three stages of the compilation
process, as described in the following table. It does not work in the first
phase, when syntax errors are identified.
If errors are found in the latter three stages, these errors must be corrected
before any subsequent synthesis operations can be performed.
Analyzing Compilation Errors After Continue on Error
Synplify Premier
This procedure shows you how to analyze errors identified after using Continue
on Error at the compilation stage, as described in Using Continue on Error
During Compilation, on page 367. These errors are non-syntax errors; the
syntax errors must be fixed before compiling with Continue on Error.
1. Check the log file for error messages.
Syntax
Check/Parse
The compiler parses all files in the project and reports the syntax
errors found in each file. If errors are found, the compilation
process terminates at this point and does not continue to the next
stage. Any errors reported during this stage must be corrected
before compilation can advance.
Elaboration/Sizing If a compilation error is encountered at any of these stages, the
design unit containing the errors is converted to a black box. The
compiler continues the processing of the remaining design units
and reports any errors found. It automatically continues to the
next compilation stage.
Hardware
Generation
Optimization
March 2014 369
If you get a message about missing modules, include them before rerun-
ning compilation. You can define modules as black boxes with the Set as
Black Box command in the Design Hierarchy view.
2. Check Run Status in the Project View tab for compiler errors.
The red box in the report shown below indicates that there are seven
compiler errors. For a complete example, see Example of Hierarchical
Error Reporting, on page 371.
You can either view the messages in the Message window, or click the
Detailed report link to get more information.
3. Check all modules that were black-boxed by CoE. You can use the
following techniques to identify the modules in the RTL view:
Check all red modules in the RTL view. The view highlights all
modules with errors in red. If the module retains its original module
name, the error is fully contained in the module. If the module name
has an _error suffix, the error has to do with port mismatches with the
parent module. In the latter case, the parent module is black-boxed
by CoE.
LO
370 March 2014
Use the Tcl find command to search for modules with the
is_error_blackbox property. The CoE functionality attaches this property
to all modules with errors. For example, these commands lists all
modules with errors and instances with errors, respectively:
get_prop -prop inst_of [find -hier -inst * -filter @is_error_blackbox==1]
c_list [find -hier -inst * -filter @is_error_blackbox==1]
4. After you have identified all the errors, either fix them or isolate them.
If you cannot immediately fix the errors, you can export the affected
modules as subprojects and fix them later. You can define these
modules as black boxes with the Set as Black Box command in the Design
Hierarchy view.
5. Re-compile the design and proceed with synthesis.
You can either synthesize the error-free modules only and then merge
them into the final netlist, or you can synthesize the entire design with
black boxes for the modules with errors to be resolved.
You must deal with all CoE-identified compiler errors before proceeding
with any subsequent synthesis operations.
March 2014 371
Example of Hierarchical Error Reporting
This Verilog example has two sub-modules, as shown below:
The code highlighted in red indicates the locations of the errors after compila-
tion with CoE:
module sub2 (input d,rst,set,clk,
output reg q,
input [7:0]in, input [2:0] raddr, waddr,
output [7:0] out3,
input [3:0] a, b,
output reg [4:0] q1);
nomodule i0(in, clk);
always@(posedge clk)
begin
if(clk)
q = d << -3;
end
reg [7:0] mem [7:0];
initial
begin
$readmemb("data.dat",in);
end
always @(posedge clk)
mem[waddr] <= in;
assign out3 = mem[raddr];
wire [2:0] temp;
begin
q1 <= temp | a;
end
assign temp = a ** b;
endmodule
LO
372 March 2014
module sub1 (input d,rst,set,clk,
output reg q,
output [7:0] out3,
input [3:0] a, b,
begin
q <= data1 | test; // 2 errors reported
end
reg q;
begin
if (rst)
q <= 1'b0;
else
q = d;
end
sub2 u1 (.*);
endmodule
module top (input d,rst,set,clk,
output reg q,
output [7:0] out3,
input [3:0] a, b,
sub1 u2 (.*);
endmodule
The following figure shows the corresponding error messages in the Messages
window after this example is compiled with Continue on Error.
March 2014 373
Using Continue on Error for Compile Point Synthesis
By default, the tool stops the synthesis process if it encounters an error
within a compile point. If you enable the Continue on Error feature on a compile
point design, the tool black-boxes any compile points with errors and
continues to synthesize the rest of the design without generating an error.
The following procedure describes the details, which varies according to the
synthesis tool used.
1. Enable Continue on Error for compile-point synthesis in one of the following
ways:
Enable Continue on Error on the Options tab of the Implementation Options
dialog box.
Enable Continue on Error on the left side of the Project view.
Enter a set_option -continue_on_error option with a value of 1 at the Tcl
script prompt.
Select Options->Configure Compile Point Process from the top menu and
enable the Continue on Error checkbox.
LO
374 March 2014
2. If you are using the Synplify Pro software, compile the design and
ensure it is error-free before continuing. You can skip this step if you are
using the Synplify Premier tool.
The Synplify Pro CoE functionality does not extend to ignoring compiler
errors, but only affects technology mapping. You must identify and fix
compiler errors before running synthesis with CoE.
3. Synthesize the design. The CoE functionality differs, according to the
tool used for synthesis.
With Synplify Premier logic synthesis, the CoE functionality ignores
certain compiler errors and continues to compile and map the design.
For details about Compile on Error and compilation, refer to Using
Continue on Error During Compilation, on page 367. The effect of CoE
on the mapper is the same as described below, for Synplify Pro
synthesis.
With Synplify Pro logic synthesis, the CoE functionality only affects
the mapper, not the compiler.
After compilation, the synthesis tools black-box compile points with
errors and continue to synthesize other compile points. The following
figure shows the black_box property attached to a compile point.
March 2014 375
The tool reports warnings like the following in the log file for the
ignored errors:
@W:: m1.v(1) | Mapping of compile point m1 - Unsuccessful
@W:: m1.v(1) | Converting compile point m1 as black_box -
as continue_on_error is set
Information about converted compile points is also reported in the
Compile Points Summary:
4. Identify and fix errors before re-synthesizing the design.
See Analyzing Compilation Errors After Continue on Error, on page 368
for some information about analysis. Here are some techniques to
continue synthesizing your design:
Designate the error modules as compile points and re-run synthesis.
In a hierarchical design, export the error module as a sub-project and
fix the problem in isolation.
In a hierarchical design, designate the error module as a compile
point or a black box in the parent project.
LO
Chapter 7: Synthesizing and Analyzing the Results Validating Results for Physical Synthesis
376 March 2014
Validating Results for Physical Synthesis
Use the following checklist to validate the results of logic synthesis in your
physical design flows. These points apply to physical design flows for Altera
technologies.
1. Check that the logic synthesis run was successful. Check the following:
The Physical Synthesis switch was disabled.
Logic synthesis completed successfully.
Check the log file, as described in Checking Log File Results, on
page 342.
2. Check that you used the correct version of the place-and-route tool. See
the Release Notes, Help->Online Documents->release_notes.pdf->Third Party Tool
Versions for information.
3. Check for black boxes. Search the synthesis srr log file for black box.
A design that contains black boxes errors out in the tool and should be
eliminated from the design.
4. Check for combinational feedback loops. Search the synthesis srr log
file for Found combinational loop.
Combinational loops cause random timing analysis results that invali-
date any comparison and should be eliminated from the design.
5. Make sure the clock constraints are correct. Check the Clock Relationships
table in the srr log file.
6. Check that the forward annotated timing constraints are consistent with
the post place-and-route timing constraints.
7. Are the false and multi-cycle paths constraints correctly defined in the
sdc file? Ensure that the back-annotation timing report (srr log file in
the PAR directory) matches the report file.
The file varies, depending on the vendor:
Altera forward annotation file .tcl
Altera report file .tan.rpt
Validating Results for Physical Synthesis Chapter 7: Synthesizing and Analyzing the Results
March 2014 377
For Altera designs, there are a couple of additional points to check:
1. Check that the clocks are routed on global resources.
Check the Clock Path Skew numbers in the report file.
Clocks routed on general routing resources usually result in large
skews. Because the tool does not take clock skew into account, large
skews can degrade the quality of results (QoR) and result in poor
timing correlation. The name of the report file varies, depending on
the vendor:
Altera report file .tan.rpt
LO
Chapter 7: Synthesizing and Analyzing the Results Analyzing Congestion After Logic Synthesis
378 March 2014
Analyzing Congestion After Logic Synthesis
Synplify Premier
Xilinx Virtex-6 and later devices
When you run congestion analysis after logic synthesis, you check a conges-
tion report that lets you analyze congested designs early in the design
process. This improves your turnaround time. Th3 report provides congestion
analysis and possible fixes for congestion problems, after running logic
synthesis and Xilinx place and route when the design is fully placed. This
feature can provide better routability for the design.
The Congestion Analysis Report can be applied in the following scenarios:
After you have run logic synthesis. If place and route is run from:
Within the synthesis tool, set the following options on the place-and-
route dialog box: Run Place & Route after Synthesis and Run Timing &
Placement Backannotation + Generate Congestion Analysis Report.
Analyzing Congestion After Logic Synthesis Chapter 7: Synthesizing and Analyzing the Results
March 2014 379
The Congestion Analysis Report automatically gets generated after
place and route is run.
Outside the synthesis tool, you can specify the externally generated
NCD file.
After you run physical synthesis or Physical Plus, the Congestion
Analysis Report is automatically generated.
To generate the Congestion Analysis Report when you run place and route
from outside the synthesis tool, use the following procedure:
1. To run the Congestion Analysis report for the active implementation,
select the Analysis->Generate Congestion Analysis menu option.
LO
380 March 2014
Specify the input P&R NCD file.
Specify the output file location for the congestion report.
Click the Generate button.
2. Click the View button to look at the results.
Congestion analysis produces the following output:
- Log file Output <design>_congestion_est.rpt
- Congestion displayed in the Physical Analyst Implementation Maps
For details, see Using the Congestion Analysis Report, on page 380 and
Displaying Congestion in the Physical Analyst, on page 382.
Using the Congestion Analysis Report
Open the Congestion Analysis Report from the:
Synthesis tool GUI after running the Congestion Analysis Report.
Log file (<design>_congestion_est.rpt) located in the current Implementation
Results directory.
Click on the Congestion Estimate Report link from the contents panel of the
HTML log file.
March 2014 381
The Congestion Analysis Report contains the following information:
Path location of the NCD file used to generate the congestion report.
Slices occupiednumber of slices and its utilization
LUT utilization
Number of unique control sets
Percentage of matched backannotated instances after they have been
placed from the NCD file. The predictions for congestion are more
accurate if this percentage is greater than 90%.
Prediction of congestion:
Estimated global congestion [High|Medium|Low]
Estimated local congestion [High|Medium|Low]
Top ten high fanout nets contributing to congestionnets displayed
with net name, driver, and fanout number
LO
382 March 2014
The following example shows the Estimated Routing Congestion Report
with HIGH routing congestion and recommends ways to alleviate this
congestion.
########################################################################
###### Estimated Routing Congestion Report ######
########################################################################
Congestion report for Xilinx NCD file:
/slowfs/sbg_builds3/FastSynthesis/TesedaDataV6/external_par/external.ncd
Congestion report for Physical Plus
Matched Instances: 65510 out of 65510 (100.00%)
Occupied Slices: 10558 out of 37680 (28.02%)
Lut Usage: 19932 out of 150720 (13.22%)
Number of unique control sets: 140
Fanout Nets Avg-WireUsage
0 - 3 59769 8.07
4 - 9 4257 20.86
10 - 24 671 34.66
25 - 49 254 110.28
> 49 210 128.65
Synplify Premier estimates HIGH routing congestion based on the estimated overall wire
usage. To alleviate routing congestion:
- Consider inserting up to two BUFGs on the top two high-fanout signals using
syn_insert_buffer attribute
- Consider forcing replication on high-fanout signals using syn_maxfan attribute
- Consider running Synplify Premier Physical Plus in decongest mode with
syn_placer_effort_level=DECONGEST attribute if the design fails to route
#======================================================================#
# Top 10 high-fanout nets #
#======================================================================#
Net: reset_n_i, Driven by Instance: reset_n_i, Fanout = 3316, WireUsage= 308
Net: SYS_MasterSync[1], Driven by Instance: SYS_MasterSync[1], Fanout = 1978, WireUsage= 131
Net: cpu_dr.ff1_i[15], Driven by Instance: ff1_0_RNILTB5[15], Fanout = 1805, WireUsage= 219
Net: SYS2x_load, Driven by Instance: SYS2x_load, Fanout = 1539, WireUsage= 149
Net: SYS_WaveForm_time[4], Driven by Instance:SYS_WaveForm_time[4],Fanout = 1538, WireUsage= 95
Net: BS1.reset_i_i, Driven by Instance: ff1_RNI6CE7[15], Fanout = 1386, WireUsage= 263
Net: SYS_smode, Driven by Instance: SYS_smode, Fanout = 1281, WireUsage= 150
Net: idelay_rst_idle_r17,Driven by Instance:tap_counter_RNI18PF_o6[1], Fanout = 1134,
WireUsage= 293
Net: sys2x_dr.ff1[15], Driven by Instance: ff1_0[15], Fanout = 1046, WireUsage= 149
Net: SYS_sflag[3], Driven by Instance: SYS_sflag[3], Fanout = 1025, WireUsage= 120
Displaying Congestion in the Physical Analyst
The output of the Congestion Analysis results updates the existing SRM file
with backannotated placement information. The Physical Analyst tool can be
opened using this SRM file to display the congestion Implementation Map.
The following Estimated Routing Congestion Report shows HIGH local
congestion hot spots in the design but only MEDIUM routing congestion. The
report recommends that you use the Routing Implementation Map in the
Physical Analyst tool to help you eliminate congestion for the design.
March 2014 383
The following example shows the Routing Implementation Map for the design.
For more information about Physical Analyst Implementation Maps, see
Using Implementation Maps in Physical Analyst, on page 986.
LO
384 March 2014
March 2014 385
CHAPTER 8
Analyzing with HDL Analyst and FSM Viewer
This chapter describes how to analyze logic in the HDL Analyst and FSM
Viewer. These tools are only available in the Synplify Pro and Synplify Premier
products, though you can purchase HDL Analyst as an option to the base
Synplify product.
See the following for detailed procedures:
Working in the Schematic Views, on page 386
Exploring Design Hierarchy, on page 400
Finding Objects, on page 408
Crossprobing, on page 421
Analyzing With the HDL Analyst Tool, on page 429
Using the FSM Viewer, on page 446
For information about analyzing timing, see Chapter 9, Analyzing Timing. For
information about using Synplify Premier Physical Analyst tool, see
Chapter 19, Analyzing Designs in Physical Analyst.
LO
Chapter 8: Analyzing with HDL Analyst and FSM Viewer Working in the Schematic Views
386 March 2014
Working in the Schematic Views
The HDL Analyst includes the RTL and Technology views, which are
schematic views used to graphically analyze your design. In the Synplify
product, these views are part of the optional HDL Analyst package. The RTL
view is available after a design is compiled; the Technology view is available
after a designed has been synthesized and contains technology-specific
primitives. In the Synplify Premier product, a RTL Floorplan view is available
after a floorplan has been created with physical constraint regions and
synthesized for the device.
For detailed descriptions of these views, see Chapter 2 of the Reference
Manual. This section describes basic procedures you use in the RTL and
Technology views. The information is organized into these topics:
Differentiating Between the HDL Analyst Views, on page 387
Opening the Views, on page 387
Viewing Object Properties, on page 389
Selecting Objects in the RTL/Technology Views, on page 394
Working with Multisheet Schematics, on page 395
Moving Between Views in a Schematic Window, on page 396
Setting Schematic View Preferences, on page 397
Managing Windows, on page 399
For information on specific tasks like analyzing critical paths, see the
following sections:
Exploring Object Hierarchy by Pushing/Popping, on page 401
Exploring Object Hierarchy of Transparent Instances, on page 407
Browsing to Find Objects in HDL Analyst Views, on page 408
Working in the Schematic Views Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 387
Differentiating Between the HDL Analyst Views
Opening the Views
The procedure for opening an RTL or Technology view is similar; the main
difference is the design stage at which these views are available.
1. Start at the appropriate design stage:
RTL View Technology View
Generated after compilation. Generated after mapping.
Technology-independent components at a
high level of abstraction, like adders,
registers, large muxes, and state machines.
Synplify Premier
The RTL floorplan view includes logic
assigned to physical constraint regions.
Technology-specific promitives like
look-up tables, cascade and carry
chains, muxes and flip-flops.
srs database (Synopsys proprietary). srm database (Synopsys proprietary).
RTL view Start with a compiled design.
Technology view Start with a mapped (synthesized) design.
Synplify Premier
Floorplan view
Start with a synthesized design that has been floorplanned
with physical constraint regions
LO
388 March 2014
2. Open the view as described in this table:
All RTL and Technology views have the schematic on the right and a
pane on the left that contains a hierarchical list of the objects in the
design. This pane is called the Hierarchy Browser. The bar at the top of
contains additional information. See Hierarchy Browser, on page 79 in
the Reference Manual for a description of the Hierarchy Browser.
Hierarchical RTL or
Technology view
Use one of these methods:
Select HDL Analyst->RTL->Hierarchical View.
Click the RTL View icon ( ) (a plus sign inside a
circle).
Double-click the srs file in the Implementation
Results view.
To open a flattened RTL view, select HDL Analyst->RTL-
>Flattened View.
Hierarchical
Technology view
Use one of these methods:
Select HDL Analyst ->Technology->Hierarchical View.
Click the Technology View icon (NAND gate icon ).
Double-click the srm file in the Implementation
Results view.
Flattened RTL or
Technology view
Select HDL Analyst->RTL->Flattened View or HDL Analyst->
Technology->Flattened View
Floorplan view Use one of these methods:
Select HDL Analyst->RTL->Floorplanned View.
Double-click the partitioned netlist (srp) file from the
Implementation Results view.
March 2014 389
Viewing Object Properties
There are a few ways in which you can view the properties of objects.
1. To temporarily display the properties of a particular object, hold the
cursor over the object. A tooltip temporarily displays the information. at
the cursor and in the status bar at the bottom of the tool window.
2. Select the object, right-click, and select Properties. The properties and
their values are displayed in a table.
If you select an instance, you can view the properties of the associated
pins by selecting the pin from the list. Similarly, if you select a port, you
can view the properties on individual bits.
RTL View
Technology View
LO
390 March 2014
3. To flag objects by property, follow these steps:
Open an RTL or Technology view.
Select Options->HDL Analyst Options->Visual Properties, and select the
properties you want to view from the pull-down list. Some properties
are only available in certain views.
Close the HDL Analyst Options dialog box.
Set this field to the pin
name to see pin properties
March 2014 391
Enable View->Visual Properties. If you do not enable this, the software
does not display the property flags in the schematics. The tool uses a
rectangular flag with the property name and value to annotate all
objects in the current view that have the specified property. Different
properties use different colors, so you can enable and view many
properties at the same time.
Example: Slow and New Properties
The slow property is useful for analyzing your critical path, because it denotes
objects that do not meet the timing criteria. The following figure shows a
filtered view of a critical path, with slow instances flagged in blue.
The New property helps with debugging because it quickly identifies objects
that have been added to the current schematic with commands like Expand.
You can step through successive filtered views to determine what was added
at each step.
The next figure expands one of the pins from the previous filtered view. The
new instance added to the view has two flags: new and slow.
Slow property
LO
392 March 2014
Using the orig_inst_of Property for Parameterized Modules
The compiler automatically uniquifies parameterized modules or instances.
Properties are available to identify the RTL names of both uniquified and
original modules or instances.
inst_of property identifies module or instance by uniquified name
orig_inst_of property identifies module or instance by its original name
before it was uniquified
In the following example, the top-level module (top) instantiates the module
sub multiple times using different parameter values. The compiler uniquifies
the module sub as sub_3s, sub_1s, and sub_4s.
Top.v
module top (input clk, [7:0] din, output [7:0] dout);
sub #(.W(3)) UUT1 (.clk, .din(din[2:0]), .dout(dout[2:0]));
sub #(.W(1)) UUT2 (.clk, .din(din[3]), .dout(dout[3]));
sub #(.W(4)) UUT3 (.clk, .din(din[7:4]), .dout(dout[7:4]));
endmodule
module sub #(parameter W = 0) (
input clk,
input [W-1:0] din,
output logic [W-1:0] dout );
March 2014 393
begin
dout <= din;
end
endmodule
RTL View
TCL Command Example
Use the get_prop command with the orig_inst_of property to identify the
original RTL name for the module:
% get_prop -prop orig_inst_of {v:sub_3s}
sub
% get_prop -prop orig_inst_of {i:UUT3}
sub
LO
394 March 2014
Selecting Objects in the RTL/Technology Views
For mouse selection, standard object selection rules apply: In selection mode,
the pointer is shaped like a crosshair.
The HDL Analyst view highlights selected objects in red. If the object you
select is on another sheet of the schematic, the schematic tracks to the
appropriate sheet. If you have other windows open, the selected object is
highlighted in the other windows as well (crossprobing), but the other
windows do not track to the correct sheet. Selected nets that span different
hierarchical levels are highlighted on all the levels. See Crossprobing, on
page 421 for more information about crossprobing.
Some commands affect selection by adding to the selected set of objects: the
Expand commands, the Select All commands, and the Select Net Driver and Select
Net Instances commands.
To select ... Do this ...
Single objects Click on the object in the RTL or Technology schematic, or click
the object name in the Hierarchy Browser.
Multiple objects Use one of these methods:
Draw a rectangle around the objects.
Select an object, press Ctrl, and click other objects you want to
select.
Select multiple objects in the Hierarchy Browser. See
Browsing With the Hierarchy Browser, on page 408.
Use Find to select the objects you want. See Using Find for
Hierarchical and Restricted Searches, on page 410.
Objects by type
(instances,
ports, nets)
Use Edit->Find to select the objects (see Browsing With the Find
Command, on page 409), or use the Hierarchy Browser, which
lists objects by type.
All objects of a
certain type
(instances,
ports, nets)
To select all objects of a certain type, do either of the following:
Right-click and choose the appropriate command from the
Select All Schematic/Current Sheet popup menus.
Select the objects in the Hierarchy Browser.
No objects
(deselect all
currently
selected objects)
Click the left mouse button in a blank area of the schematic or
click the right mouse button to bring up the pop-up menu and
choose Unselect All. Deselected objects are no longer
highlighted.
March 2014 395
Working with Multisheet Schematics
The title bar of the RTL or Technology view indicates the number of sheets in
that schematic. In a multisheet schematic, nets that span multiple sheets are
indicated by sheet connector symbols, which you can use for navigation.
1. To reduce the number of sheets in a schematic, select Options->HDL
Analyst Options and increase the values set for Sheet Size Options - Instances
and Sheet Size Options - Filtered Instances. To display fewer objects per sheet
(increase the number of sheets), increase the values.
These options set a limit on the number of objects displayed on an unfil-
tered and filtered schematic sheet, respectively. A low Filtered Instances
value can cause lower-level logic inside a transparent instance to be
displayed on a separate sheet. The sheet numbers are indicated inside
the empty transparent instance.
2. To navigate through a multisheet schematic, refer to this table. It
summarizes common operations and ways to navigate.
To view ... Use one of these methods ...
Next sheet or
previous sheet
Select View->Next/Previous Sheet.
Press the right mouse button and draw a horizontal mouse
stroke (left to right for next sheet, right to left for previous
sheet).
Click the icons: Next Sheet ( ) or Previous Sheet ( )
Press Shift-right arrow (Next Sheet) or Shift-left arrow (Previous sheet).
Navigate with View->Back and View ->Forward if the next/previous
sheets are part of the display history.
A specific sheet
number
Select View->View Sheets and select the sheet.
Click the right mouse button, select View Sheets from the popup
menu, and then select the sheet you want.
Press Ctrl-g and select the sheet you want.
Lower-level logic
of a transparent
instance on
separate sheets
Check the sheet numbers indicated inside the empty
transparent instance. Use the sheet navigation commands like
Next Sheet or View Sheets to move to the sheet you need.
LO
396 March 2014
Moving Between Views in a Schematic Window
When you filter or expand your design, you move through a number of
different design views in the same schematic window. For example, you might
start with a view of the entire design, zoom in on an area, then filter an object,
and finally expand a connection in the filtered view, for a total of four views.
1. To move back to the previous view, click the Back icon or draw the
appropriate mouse stroke.
The software displays the last view, including the zoom factor. This does
not work in a newly generated view (for example, after flattening)
because there is no history.
All objects of a
certain type
To highlight all the objects of the same type in the schematic,
right-click and select the appropriate command from the Select
All Schematic popup menu.
To highlight all the objects of the same type on the current
sheet, right-click and select the appropriate command from the
Select All Sheet popup menu.
Selected items
only
Filter the schematic as described in Filtering Schematics, on
page 433.
A net across
sheets
If there are no sheet numbers displayed in a hexagon at the
end of the sheet connector, select Options ->HDL Analyst Options
and enable Show Sheet Connector Index. Right-click the sheet
connector and select the sheet number from the popup as
shown in the following figure.
To view ... Use one of these methods ...
Sheet Connector Symbol
Sheet connector with multisheet popup menu Connected sheet numbers
March 2014 397
2. To move forward again, click the Forward icon or draw the appropriate
mouse stroke.
The software displays the next view in the display history.
Setting Schematic View Preferences
You can set various preferences for the RTL and Technology views from the
user interface.
1. Select Options->HDL Analyst Options. For a description of all the options on
this form, see HDL Analyst Options Command, on page 466 in the
Reference Manual.
2. The following table details some common operations:
Some of these options do not take effect in the current view, but are
visible in the next schematic view you open.
3. To view hierarchy within a cell, enable the General->Show Cell Interiors
option.
To ... Do this ...
Display the Hierarchy Browser Enable Show Hierarchy Browser (General tab).
Control crossprobing from an
object to a P&R text file
Enable Enhanced Text Crossprobing. (General
tab)
Determine the number of
objects displayed on a sheet.
Set the value with Maximum Instances on the
Sheet Size tab. Increase the value to display
more objects per sheet.
Determine the number of
objects displayed on a sheet in
a filtered view.
Set the value with Maximum Filtered Instances
on the Sheet Size tab. Increase the number to
display more objects per sheet. You cannot
set this option to a value less than the
Maximum Instances value.
LO
398 March 2014
4. To control the display of labels, first enable the Text->Show Text option,
and then enable the Label Options you want. The following figure
illustrates the label that each option controls.
For a more detailed information about some of these options, see
Schematic Display, on page 131 in the Reference Manual.
5. Click OK on the HDL Analyst Options form.
The software writes the preferences you set to the ini file, and they
remain in effect until you change them.
Show Cell Interior off Show Cell Interior on
Show
Show Symbol Name
Show Pin Name
Show Conn Name
Show Port Name
March 2014 399
Managing Windows
As you work on a project, you open different windows. For example, you
might have two Technology views, an RTL view, and a source code window
open. The following guidelines help you manage the different windows you
have open. For information about cycling through the display history in a
single schematic, see Moving Between Views in a Schematic Window, on
page 396.
1. Toggle on View->Workbook Mode.
Below the Project view, you see tabs like the following for each open
view. The tab for the current view is on top. The symbols in front of the
view name on the tab help identify the kind of view.
2. To bring an open view to the front, if the window is not visible, click its
tab. If part of the window is visible, click in any part of the window.
If you previously minimized the view, it will be in minimized form.
Double-click the minimized view to open it.
3. To bring the next view to the front, click Ctrl-F6 in that window.
4. Order the display of open views with the commands from the Window
menu. You can cascade the views (stack them, slightly offset), or tile
them horizontally or vertically.
5. To close a view, press Ctrl-F4 in that window or select File->Close.
LO
Chapter 8: Analyzing with HDL Analyst and FSM Viewer Exploring Design Hierarchy
400 March 2014
Exploring Design Hierarchy
Schematics generally have a certain amount of design hierarchy. You can
move between hierarchical levels using the Hierarchy Browser or Push/Pop
mode. For additional information, see Analyzing With the HDL Analyst Tool,
on page 429. The topics include:
Traversing Design Hierarchy with the Hierarchy Browser, on page 400
Exploring Object Hierarchy by Pushing/Popping, on page 401
Exploring Object Hierarchy of Transparent Instances, on page 407
Traversing Design Hierarchy with the Hierarchy Browser
The Hierarchy Browser is the list of objects on the left side of the RTL and
Technology views. It is best used to get an overview, or when you need to
browse and find an object. If you want to move between design levels of a
particular object, Push/Pop mode is more direct. Refer to Exploring Object
Hierarchy by Pushing/Popping, on page 401 for details.
The hierarchy browser allows you to traverse and select the following:
Instances and submodules
Ports
Internal nets
Clock trees (in an RTL view)
The browser lists the objects by type. A plus sign in a square icon indicates
that there is hierarchy under that object and a minus sign indicates that the
design hierarchy has been expanded. To see lower-level hierarchy, click on
the plus sign for the object. To ascend the hierarchy, click on the minus sign.
Exploring Design Hierarchy Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 401
Refer to Hierarchy Browser Symbols, on page 80 in the Reference Manual for
an explanation of the symbols.
Exploring Object Hierarchy by Pushing/Popping
To view the internal hierarchy of a specific object, it is best to use Push/Pop
mode or examine transparent instances, instead of using the Hierarchy
Browser described in Traversing Design Hierarchy with the Hierarchy
Browser, on page 400. You can access Push/Pop mode with the Push/Pop
Hierarchy icon, the Push/Pop Hierarchy command, or mouse strokes.
When combined with other commands like filtering and expansion
commands, Push/Pop mode can be a very powerful tool for isolating and
analyzing logic. See Filtering Schematics, on page 433, Expanding Pin and Net
Logic, on page 435, and Expanding and Viewing Connections, on page 439 for
details about filtering and expansion. See the following sections for informa-
tion about pushing down and popping up in hierarchical design objects:
Pushing into Objects, on page 402, next
Popping up a Hierarchical Level, on page 405
Click to expand and see
lower-level hierarchy
Click to collapse list
LO
402 March 2014
Pushing into Objects
In the schematic views, you can push into objects and view the lower-level
hierarchy. You can use a mouse stroke, the command, or the icon to push
into objects:
1. To move down a level (push into an object) with a mouse stroke, put
your cursor near the top of the object, hold down the right mouse
button, and draw a vertical stroke from top to bottom. You can push
into the following objects; see step 3 for examples of pushing into
different types of objects.
Hierarchical instances. They can be displayed as pale yellow boxes
(opaque instances) or hollow boxes with internal logic displayed
(transparent instances). You cannot push into a hierarchical instance
that is hidden with the Hide Instance command (internal logic is
hidden).
Technology-specific primitives. The primitives are listed in the
Hierarchy Browser in the Technology view, under Instances - Primitives.
Inferred ROMs and state machines.
The remaining steps show you how to use the icon or command to push
into an object.
Hierarchical object Press right mouse button and draw downward
to push into an object
March 2014 403
2. Enable Push/Pop mode by doing one of the following:
Select View->Push/Pop Hierarchy.
Right-click in the Technology view and select Push/Pop Hierarchy from
the popup menu.
Click the Push/Pop Hierarchy icon ( ) in the toolbar (two arrows
pointing up and down).
Press F2.
The cursor changes to an arrow. The direction of the arrow indicates the
underlying hierarchy, as shown in the following figure. The status bar at
the bottom of the window reports information about the objects over
which you move your cursor.
3. To push (descend) into an object, click on the hierarchical object. For a
transparent instance, you must click on the pale yellow border. The
following figure shows the result of pushing into a ROM.
When you descend into a ROM, you can push into it one more time to
see the ROM data table. The information is in a view-only text file called
rom.info.
LO
404 March 2014
Similarly, you can push into a state machine. When you push into an
FSM from the RTL view, you open the FSM viewer where you can graph-
ically view the transitions. For more information, see Using the FSM
Viewer, on page 446. If you push into a state machine from the
Technology view, you see the underlying logic.
March 2014 405
Popping up a Hierarchical Level
1. To move up a level (pop up a level), put your cursor anywhere in the
design, hold down the right mouse button, and draw a vertical mouse
stroke, moving from the bottom upwards.
LO
406 March 2014
The software moves up a level, and displays the next level of hierarchy.
2. To pop (ascend) a level using the commands or icon, do the following:
Select the command or icon if you are not already in Push/Pop mode.
See Pushing into Objects, on page 402for details.
Move your cursor to a blank area and click.
3. To exit Push/Pop mode, do one of the following:
Click the right mouse button in a blank area of the view.
Deselect View->Push/Pop Hierarchy.
Deselect the Push/Pop Hierarchy icon.
Press F2.
Press the right mouse button
and draw an upward stroke to
pop up a level
March 2014 407
Exploring Object Hierarchy of Transparent Instances
Examining a transparent instance is one way of exploring the design
hierarchy of an object. The following table compares this method with
pushing (described in Exploring Object Hierarchy by Pushing/Popping, on
page 401).
Pushing Transparent Instance
User
control
You initiate the operation
through the command or
icon.
You have no direct control; the transparent
instance is automatically generated by
some commands that result in a filtered
view.
Design
context
Context lost; the lower-
level logic is shown in a
separate view
Context maintained; lower-level logic is
displayed inside a hollow yellow box at the
hierarchical level of the parent.
LO
Chapter 8: Analyzing with HDL Analyst and FSM Viewer Finding Objects
408 March 2014
Finding Objects
In the schematic views, you can use the Hierarchy Browser or the Find
command to find objects, as explained in these sections:
Browsing to Find Objects in HDL Analyst Views, on page 408
Using Find for Hierarchical and Restricted Searches, on page 410
Using Wildcards with the Find Command, on page 413
Using Find to Search the Output Netlist, on page 418
For information about the Tcl Find command, which you use to locate objects,
and create collections, see find, on page 178 in the Reference Manual.
Browsing to Find Objects in HDL Analyst Views
You can always zoom in to find an object in the RTL and Technology
schematics. The following procedure shows you how to browse through
design objects and find an object at any level of the design hierarchy. You can
use the Hierarchy Browser or the Find command to do this. If you are familiar
with the design hierarchy, the Hierarchy Browser can be the quickest method
to locate an object. The Find command is best used to graphically browse and
locate the object you want.
Browsing With the Hierarchy Browser
1. In the Hierarchy Browser, click the name of the net, port, or instance
you want to select.
The object is highlighted in the schematic.
2. To select a range of objects, select the first object in the range. Then,
scroll to display the last object in the range. Press and hold the Shift key
while clicking the last object in the range.
The software selects and highlights all the objects in the range.
3. If the object is on a lower hierarchical level, do either of the following:
Expand the appropriate higher-level object by clicking the plus
symbol next to it, and then select the object you want.
Finding Objects Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 409
Push down into the higher-level object, and then select the object
from the Hierarchy Browser.
The selected object is highlighted in the schematic. The following
example shows how moving down the object hierarchy and selecting an
object causes the schematic to move to the sheet and level that contains
the selected object.
4. To select all objects of the same type, select them from the Hierarchy
Browser. For example, you can find all the nets in your design.
Browsing With the Find Command
1. In a schematic view, select HDL Analyst->Find or press Ctrl-f to open the
Object Query dialog box.
2. Do the following in the dialog box:
Select objects in the selection box on the left. You can select all the
objects or a smaller set of objects to browse. If length makes it hard to
read a name, click the name in the list to cause the software to
display the entire name in the field at the bottom of the dialog box.
Expand Instances
and select an
object on a lower
hierarchical level.
Schematic pushes
down to the correct
level to show the
selected object.
LO
410 March 2014
Click the arrow to move the selected objects over to the box on the
right.
The software highlights the selected objects.
3. In the Object Query dialog box, click on an object in the box on the right.
The software tracks to the schematic page with that object.
Using Find for Hierarchical and Restricted Searches
You can always zoom in to find an object in the RTL and Technology
schematics or use the Hierarchy Browser (see Browsing to Find Objects in
HDL Analyst Views, on page 408). This procedure shows you how to use the
Find command to do hierarchical object searches or restrict the search to the
current level or the current level and its underlying hierarchy.
Note that Find only adds to the current selection; it does not deselect anything
that is already selected. you can use successive searches to build up exactly
the selection you need, before filtering.
1. If needed, restrict the range of the search by filtering the view.
See Viewing Design Hierarchy and Context, on page 430 and Filtering
Schematics, on page 433 for details. With a filtered view, the software
only searches the filtered instances, unless you set the scope of the
search to Entire Design, as described below, in which case Find searches
the entire design.
You can use the filtering technique to restrict your search to just one
schematic sheet. Select all the objects on one sheet and filter the view.
Continue with the procedure.
2. To further restrict the range of the search, hide instances you do not
need.
You can do this in addition to filtering the view, or instead of filtering the
view. Hidden instances and their hierarchy are excluded from the
search. When you have finished the search, use the Unhide Instances
command to make the hierarchy visible again.
3. Open the Object Query dialog box.
March 2014 411
Do one of the following: right click in the RTL or Technology view and
select Find from the popup menu, press Ctrl-f, or click the Find icon
( ).
Reposition the dialog box so you can see both your schematic and the
dialog box.
4. Select the tab for the type of object. The Unhighlighted box on the left lists
all objects of that type (instances, symbols, nets, or ports).
For fastest results, search by Instances rather than Nets. When you select
Nets, the software loads the whole design, which could take some time.
5. Click one of these buttons to set the hierarchical range for the search:
Entire Design, Current Level & Below, or Current Level Only, depending on the
hierarchical level of the design to which you want to restrict your search.
The range setting is especially important when you use wildcards. See
Effect of Hierarchy and Range on Wildcard Searches, on page 413 for
details. Current Level Only or Current Level & Below are useful for searching
filtered schematics or critical path schematics.
The lower-level details of a transparent instance appear at the current
level and are included in the search when you set it to Current Level Only.
To exclude them, temporarily hide the transparent instances, as
described in step 2.
LO
412 March 2014
Use Entire Design to hierarchically search the whole design. For large
hierarchical designs, reduce the scope of the search by using the
techniques described in the first step.
The Unhighlighted box shows available objects within the scope you set.
Objects are listed in alphabetical order, not hierarchical order.
6. To search for objects in the mapped database or the output netlist, set
the Name Space option.
The name of an object might be changed because of synthesis optimiza-
tions or to match the place-and-route tool conventions, so that the
object name may no longer match the name in the original netlist.
Setting the Name Space option ensures that the Find command searches
the correct database for the object. For example, if you set this option to
Tech View, the tool searches the mapped database (srm) for the object
name you specify. For information about using this feature to find
objects from an output netlist, see Using Find to Search the Output
Netlist, on page 418.
7. Do the following to select objects from the list. To use wildcards in the
selection, see the next step.
Click on the objects you want from the list. If length makes it hard to
read a name, click the name in the list to cause the software to
display the entire name in the field at the bottom of the dialog box.
Click Find 200 or Find All. The former finds the first 200 matches, and
then you can click the button again to find the next 200.
Click the right arrow to move the objects into the box on the right, or
double-click individual names.
The schematic displays highlighted objects in red.
8. Do the following to select objects using patterns or wildcards.
Type a pattern in the Highlight Wildcard field. See Using Wildcards with
the Find Command, on page 413 for a detailed discussion of
wildcards.
The Unhighlighted list shows the objects that match the wildcard
criteria. If length makes it hard to read a name, click the name in the
list to cause the software to display the entire name in the field at the
bottom of the form.
March 2014 413
Click the right arrow to move the selections to the box on the right, or
double-click individual names. The schematic displays highlighted
objects in red.
You can use wildcards to avoid typing long pathnames. Start with a
general pattern, and then make it more specific. The following example
browses and uses wildcards successively to narrow the search.
Note that there are some differences when you specify the find command
in the RTL view, Technology view, or the constraint file.
9. You can leave the dialog box open to do successive Find operations. Click
OK or Cancel to close the dialog box when you are done.
For detailed information about the Find command and the Object Query
dialog box, see Find Command (HDL Analyst), on page 255 of the Reference
Manual.
Using Wildcards with the Find Command
Use the following wildcards when you search the schematics:
Effect of Hierarchy and Range on Wildcard Searches
The asterisk and question mark wildcards do not cross hierarchical bound-
aries, but search each level of hierarchy individually with the search pattern.
This default is affected by the following:
Hierarchical separators
Find all instances three levels down *.*.*
Narrow search to find instances that begin with i_ i_*.*.*
Narrow search to find instances that begin with un2 after the
second hierarchy separator
i_*.*.un2*
* The asterisk matches any sequence of characters.
? The question mark matches any single character.
. The dot explicitly matches a hierarchy separator, so type one dot for each level
of hierarchy. To use the dot as a pattern and not a hierarchy separator, type a
backslash before the dot: \.
LO
414 March 2014
Dots match hierarchy separators, unless you use the backslash escape
character in front of the dot (\.). Hierarchical search patterns with a dot
(l*.*) are repeated at each level included in the scope. If you use the *.*
pattern with Current Level, the software matches non-hierarchical names
at the current level that include a dot.
Search range
The scope of the search determines the starting point for the searches.
Some times the starting point might make it appear as if the wildcards
cross hierarchical boundaries. If you are at 2A in the following figure
and the scope of the search is set to Current Level and Below, separate
searches start at 2A, 3A1, and 3A2. Each search does not cross hierar-
chical boundaries. If the scope of the search is Entire Design, the wildcard
searches run from each hierarchical point (1, 2A, 2B, 3A1, 3A2, 3B1,
3B2, and 3B3). The result of an asterisk search (*) with Entire Design is a
list of all matches in the design, regardless of the current level.
See Wildcard Search Examples, on page 415 for examples.
How a Wildcard Search Works
1. The starting point of a wildcard search depends on the range set for the
search.
2A
1
2B
3B3
3B2 3B1
3A2
3A1
Entire Design
Current
Level and
Below
Current
Level
March 2014 415
2. The software applies the wildcard pattern to all applicable objects within
the range. For Current Level and Current Level and Below, the current level
determines the starting point.
Dots match hierarchy separators, unless you use the backslash escape
character in front of the dot (\.). Hierarchical search patterns with a dot
(l*.*) are repeated at each level included in the scope. See Effect of
Hierarchy and Range on Wildcard Searches, on page 413 and Wildcard
Search Examples, on page 415 for details and examples, respectively. If
you use the *.* pattern with Current Level, the software matches non-
hierarchical names at the current level that include a dot.
Wildcard Search Examples
The figure shows a design with three hierarchical levels, and the table shows
the results of some searches on this design.
Entire Design Starts at top level and uses the pattern to search from that
level. It then moves to any child levels below the top level and
searches them. The software repeats the search pattern at
each hierarchical point in the design until it searches the
entire design.
Current Level Starts at the current hierarchical level and searches that level
only. A search started at 2A only covers 2A.
Current Level
and Below
Starts at the current hierarchical level and searches that level.
It then moves to any child levels below the starting point and
conducts separate searches from each of these starting points.
2A
1
2B
3B3
3B2 3B1
3A2
3A1
LO
416 March 2014
Difference from Tcl Search
In a simple Tcl search like the one used by ISE in UCF files, no character
(except the backslash, \) has special meaning. This means that the asterisk
matches everything in a string. The FPGA synthesis tools and Synopsys
TimeQuest and Design Compiler products confine the simple search to within
one level of hierarchy. The following command searches each level of
hierarchy individually for the specified pattern:
find hier *abc*addr_reg[*]
Scope Pattern Starting
Point
Finds Matches in ...
Entire
Design
* 3A1 1, 2A, 2B, 3A1, 3A2, 3B1, 3B2, and 3B3 (* at all
levels)
*.* 2B 2A and 2B (*.* from 1)
3A1, 3A2, 3B1, 3B2, and 3B3 (*.* from 2A and
2B)
No matches in 1 (because of the hierarchical dot),
unless a name includes a non-hierarchical dot.
Current
Level
* 1 1 only (no hierarchical boundary crossing)
*.* 2B 2B only. No search of lower levels even though
the dot is specified, because the scope is Current
Level. No matches, unless a 2B name includes a
non-hierarchical dot.
Current
Level and
Below
* 2A 2A only (no hierarchical boundary crossing)
*.* 1 2A and 2B (*.* from 1)
3A1, 3A2, 3B1, 3B2, and 3B3 (*.* from 2A and
2B)
No matches from 1, because the dot is specified.
*.* 2B 3B1, 3B2, and 3B3 (*.* from 2B)
*.* 3A2 No matches (no hierarchy below 3A2)
*.*.* 1 3A1, 3A2, 3B1, 3B2, and 3B3 (*.*.* from 1)
Search ends because there is no hierarchy two
levels below 2A and 2B.
March 2014 417
If you want to go through the hierarchy, you must add the hierarchy separa-
tors to the search pattern:
find {*.*.abc.*.*.addr_reg[*]}
The following shows the equivalent SDC commands to the simple Tcl
searches in UCF:
Find Command Differences in HDL Analyst Views and Constraint File
There are some slight differences when you use the Find command in the RTL
view, Technology view, and the constraint files:
You cannot use find to search for bit registers of a bit array in the RTL or
Technology views, but you can specify it in a constraint file, where the
following command will work:
find seq {i:modulex_inst.qb[7]}
In a HDL Analyst view, you cannot find {i:modulex_inst.qb[7]}, but you can
specify and find {i:modulex_inst.qb[7:0]}.
By default, the following Tcl command does not find objects in the RTL
view, although it does find objects in the Technology view:
hier seq * -filter @clock == clk75
To make this work in an RTL view, you must turn on Annotated Properties
for Analyst in the Device tab of the Implementation Options dialog box, recom-
pile the design, and then open a new RTL view.
UCF SDC Equivalent
INST *ctrlfifo*" TNM = FIFO_GRP";_ set FIFOS [find hier -inst {i:*ctrlfifo*}]
INST *ctrlfifo" TNM = FIFO_GRP";_ set FIFOS [find hier -inst {i:*ctrlfifo}]
INST ctrlfifo*" TNM = FIFO_GRP";_ set FIFOS [find hier -inst * -filter
@hier_rtl_name == ctrlfifo*]
INST ctrlfifo*hier_inst" TNM =
FIFO_GRP";_
set FIFOS [find hier -inst * -filter
@hier_rtl_name == ctrlfifo*hier_inst]
LO
418 March 2014
Combining Find with Filtering to Refine Searches
You can combine the Find command with the filtering commands to better
effect. Depending on what you want to do, use the Find command first, or a
filtering command.
1. To limit the range of a search, do the following:
Filter the design.
Use the Find command on the filtered view, but set the search range
to Current Level Only.
2. Select objects for a filtered view.
Use the Find command to browse and select objects.
Filter the objects to display them.
Using Find to Search the Output Netlist
When the synthesis tool creates an output netlist like a vqm or edf file, some
names are optimized for use in the P&R tool. When you debug your design for
place and route looking for a particular object, use the Name Space option in
the Object Query dialog box to locate the optimized names in the output netlist.
The following procedure shows you how to locate an object, highlight and
filter it in the Technology view, and crossprobe to the source code for editing.
1. Select the output netlist file option in the Implementations Results tab of the
Implementation Options dialog box.
2. After you synthesize your design, open your output netlist file and select
the name of the object you want to find.
March 2014 419
3. Copy the name and open a Technology view.
4. In the Technology view, press Ctrl-f or select Edit->Find to open the Object
Query dialog box and do the following:
Paste the object name you copied into the Highlight Search field.
Set the Name Space option to Netlist and click Find All.
Copy Name
Search by Tech View Search by Netlist
LO
420 March 2014
If you leave the Name Space option set to the default of Tech View, the
tool does not find the name because it is searching the mapped
database instead of the output netlist.
Double click the name to move it into the Highlighted field and close the
dialog box.
In the Technology view, the name is highlighted in the schematic.
5. Select HDL Analyst->Filter Schematic to view only the highlighted portion of
the schematic.
The tooltip shows the equivalent name in the Technology view.
6. Double click on the filtered schematic to crossprobe to the
corresponding code in the HDL file.
compare_output_NE0(C_0)
slow
Alias: compare_output_NE0_cZ
Filtered View
Crossprobing Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 421
Crossprobing
Crossprobing is the process of selecting an object in one view and having the
object or the corresponding logic automatically highlighted in other views.
Highlighting a line of text, for example, highlights the corresponding logic in
the schematic views. Crossprobing helps you visualize where coding changes
or timing constraints might help to reduce area or improve performance.
You can crossprobe between the RTL view, Technology view, the FSM Viewer,
the log file, the source files, and some external text files from place-and-route
tools. However, not all objects or source code crossprobe to other views,
because some source code and RTL view logic is optimized away during the
compilation or mapping processes.
This section describes how to crossprobe from different views. It includes the
following:
Crossprobing within an RTL/Technology View, on page 421
Crossprobing from the RTL/Technology View, on page 422
Crossprobing from the Text Editor Window, on page 424
Crossprobing from the Tcl Script Window, on page 427
Crossprobing from the FSM Viewer, on page 428
Crossprobing within an RTL/Technology View
Selecting an object name in the Hierarchy Browser highlights the object in
the schematic, and vice versa.
Selected Object Highlighted Object
Instance in schematic (single-click) Module icon in Hierarchy Browser
Net in schematic Net icon in Hierarchy Browser
Port in schematic Port icon in Hierarchy Browser
Logic icon in Hierarchy Browser Instance in schematic
Net icon in Hierarchy Browser Net in schematic
Port icon in Hierarchy Browser Port in schematic
LO
Chapter 8: Analyzing with HDL Analyst and FSM Viewer Crossprobing
422 March 2014
In this example, when you select the DECODE module in the Hierarchy
Browser, the DECODE module is automatically selected in the RTL view.
Crossprobing from the RTL/Technology View
1. To crossprobe from an RTL or Technology views to other open views,
select the object by clicking on it.
The software automatically highlights the object in all open views. If the
open view is a schematic, the software highlights the object in the
Hierarchy Browser on the left as well as in the schematic. If the
highlighted object is on another sheet of a multi-sheet schematic, the
view does not automatically track to the page. If the crossprobed object
is inside a hidden instance, the hidden instance is highlighted in the
schematic.
If the open view is a source file, the software tracks to the appropriate
code and highlights it. The following figure shows crossprobing between
the RTL, Technology, and Text Editor (source code) views.
March 2014 423
2. To crossprobe from the RTL or Technology view to the source file when
the source file is not open, double-click on the object in the RTL or
Technology view.
Double-clicking automatically opens the appropriate source code file
and highlights the appropriate code. For example, if you double-click an
object in a Technology view, the HDL Analyst tool automatically opens
an editor window with the source code and highlights the code that
contains the selected register.
The following table summarizes the crossprobing capability from the RTL or
Technology view.
RTL View
Technology View
Text Editor
LO
424 March 2014
Crossprobing from the Text Editor Window
To crossprobe from a source code window or from the log file to an RTL,
Technology, or FSM view, use this procedure. You can use this method to
crossprobe from any text file with objects that have the same instance names
as in the synthesis software. For example, you can crossprobe from place-
and-route files. See Example of Crossprobing a Path from a Text File, on
page 425 for a practical example of how to use crossprobing.
1. Open the RTL, FSM, or Technology view to which you want to
crossprobe.
2. To crossprobe from an error, warning, or note in the html log file, click
on the file name to open the corresponding source code in another Text
Editor window; to crossprobe from a text log file, double-click on the text
of the error, warning, or note.
From To Procedure
RTL Source code Double-click an object. If the source code file is not
open, the software opens the Text Editor window to
the appropriate section of code. If the source file is
already open, the software scrolls to the correct
section of the code and highlights it.
RTL Technology The Technology view must be open. Click the object
to highlight and crossprobe.
RTL FSM Viewer Synplify Pro, Synplify Premier
The FSM view must be open. The state machine
must be coded with a onehot encoding style. Click
the FSM to highlight and crossprobe.
Technology Source code If the source code file is already, open, the software
scrolls to the correct section of the code and
highlights it.
If the source code file is not open, double-click an
object in the Technology view to open the source
code file.
Technology RTL The RTL view must be open. Click the object to
highlight and crossprobe.
March 2014 425
3. To crossprobe from a third-party text file (not source code or a log file),
select Options->HDL Analyst Options->General, and enable Enhanced text
crossprobing.
4. Select the appropriate portion of text in the Text Editor window. In some
cases, it may be necessary to select an entire block of text to crossprobe.
The software highlights the objects corresponding to the selected code in
all the open windows. For example, if you select a state name in the
code, it highlights the state in the FSM viewer. If an object is on another
schematic sheet or on another hierarchical level, the highlighting might
not be obvious. If you filter the RTL or schematic view (right-click in the
source code window with the selected text and select Filter Schematic from
the popup menu), you can isolate the highlighted objects for easy
viewing.
Example of Crossprobing a Path from a Text File
This example selects a path in a log file and crossprobes it in the Technology
view. You can use the same technique to crossprobe from other text files like
place-and-route files, as long as the instance names in the text file match the
instance names in the synthesis tool.
1. Open the log file, the RTL, and Technology views.
2. Select the path objects in the log file.
Select the column by pressing Alt and dragging the cursor to the end
of the column. On the Linux platform, use the key to which the Alt
function is mapped; this is usually the Ctrl-Alt key combination.
To select all the objects in the path, right-click and choose Select in
Analyst from the popup menu. Alternatively, you can select certain
objects only, as described next.
The software selects the objects in the column, and highlights the path
in the open RTL and Technology views.
LO
426 March 2014
To further filter the objects in the path, right-click and choose Select
From from the popup menu. On the form, check the objects you want,
and click OK. Only the corresponding objects are highlighted.
Technology View
Text Editor
March 2014 427
3. To isolate and view only the selected objects, do this in the Technology
view: press F12, or right-click and select the Filter Schematic command
from the popup menu.
You see just the selected objects.
Crossprobing from the Tcl Script Window
Crossprobing from the Tcl script window is useful for debugging error
messages.
To crossprobe from the Tcl Script window to the source code, double-click a
line in the Tcl window. To crossprobe a warning or error, first click the
Messages tab and then double-click the warning or error. The software opens
the relevant source code file and highlights the corresponding code.
LO
428 March 2014
Crossprobing from the FSM Viewer
You can crossprobe to the FSM Viewer if you have the FSM view open. You
can crossprobe from an RTL, Technology, or source code window.
To crossprobe from the FSM Viewer, do the following:
1. Open the view to which you want to crossprobe: RTL/Technology view,
or the source code file.
2. Do the following in the open FSM view:
For FSMs with a onehot encoding style, click the state bubbles in the
bubble diagram or the states in the FSM transition table.
For all other FSMs, click the states in the bubble diagram. You
cannot use the transition table because with these encoding styles,
the number of registers in the RTL or Technology views do not match
the number of registers in the FSM Viewer.
The software highlights the corresponding code or object in the open
views. You can only crossprobe from a state in the FSM table if you used
a onehot encoding style.
Analyzing With the HDL Analyst Tool Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 429
Analyzing With the HDL Analyst Tool
The HDL Analyst tool is a graphical productivity tool that helps you visualize
your synthesis results. It consists of RTL-level and technology-primitive level
schematics that let you graphically view and analyze your design.
RTL View
Using BEST
(Behavior Extracting Synthesis Technology) in the RTL

view, the software keeps a high-level of abstraction and makes the RTL
view easy to view and debug. High-level structures like RAMs, ROMs,
operators, and FSMs are kept as abstractions in this view instead of
being converted to gates. You can examine the high-level structure, or
push into a component and view the gate-level structure.
Technology View
The software uses module generators to implement the high-level struc-
tures from the RTL view, and maps them to technology-specific
resources.
To analyze information, compare the current view with the information in the
RTL/Technology view, the log file, the FSM view, and the source code, you
can use techniques like crossprobing, flattening, and filtering. See the
following for more information about analysis techniques.
Viewing Design Hierarchy and Context, on page 430
Filtering Schematics, on page 433
Expanding Pin and Net Logic, on page 435
Expanding and Viewing Connections, on page 439
Flattening Schematic Hierarchy, on page 440
Minimizing Memory Usage While Analyzing Designs, on page 445
For additional information about navigating the HDL Analyst views or using
other techniques like crossprobing, see the following:
Working in the Schematic Views, on page 386
Exploring Design Hierarchy, on page 400
LO
Chapter 8: Analyzing with HDL Analyst and FSM Viewer Analyzing With the HDL Analyst Tool
430 March 2014
Viewing Design Hierarchy and Context
Most large designs are hierarchical, so the synthesis software provides tools
that help you view hierarchy details or put the details in context. Alterna-
tively, you can browse and navigate hierarchy with Push/Pop mode, or flatten
the design to view internal hierarchy.
This section describes how to use interactive hierarchical viewing operations
to better analyze your design. Automatic hierarchy viewing operations that
are built into other commands are described in the context in which they
appear. For example, Viewing Critical Paths, on page 455 describes how the
software automatically traces a critical path through different hierarchical
levels using hollow boxes with nested internal logic (transparent instances) to
indicate levels in hierarchical instances.
1. To view the internal logic of primitives in your design, do either of the
following:
To view the logic of an individual primitive, push into it. This
generates a new schematic view with the internal details. Click the
Back icon to return to the previous view.
To view the logic of all primitives in the design, select Options->HDL
Analyst Options->General, and enable Show Cell Interior. This command
lets you see internal logic in context, by adding the internal details to
the current schematic view and all subsequent views. If the view is
too cluttered with this option on, filter the view (see Filtering
Schematics, on page 433) or push into the primitive. Click the Back
icon to return to the previous view after filtering or pushing into the
object.
The following figure compares these two methods:
Result of pushing into a primitive (new view
of lower-level logic)
Result of enabling Show Cell Interior
option (same view with internal logic)
March 2014 431
2. To hide selected hierarchy, select the instance whose hierarchy you
want to exclude, and then select Hide Instances from the HDL Analyst menu
or the right-click popup menu in the schematic view.
You can hide opaque (solid yellow) or transparent (hollow) instances.
The software marks hidden instances with an H in the lower left. Hidden
instances are like black boxes; their hierarchy is excluded from filtering,
expanding, dissolving, or searching in the current window, although
they can be crossprobed. An instance is only hidden in the current view
window; other view windows are not affected. Temporarily hiding unnec-
essary hierarchy focuses analysis and saves time in large designs.
Before you save a design with hidden instances, select Unhide Instances
from the HDL Analyst menu or the right-click popup menu and make the
hidden internal hierarchy accessible again. Otherwise, the hidden
instances are saved as black boxes, without their internal logic.
Conversely, you can use this feature to reduce the scope of analysis in a
large design by hiding instances you do not need, saving the reduced
design to a new name, and then analyzing it.
3. To view the internal logic of a hierarchical instance, you can push into
the instance, dissolve the selected instance with the Dissolve Instances
command, or flatten the design. You cannot use these methods to view
the internal logic of a hidden instance.
H indicates a
hidden instance
LO
432 March 2014
4. If the result of filtering or dissolving is a hollow box with no internal
logic, try either of the following, as appropriate, to view the internal
hierarchy:
Select Options->HDL Analyst Options->Sheet Size and increase the value of
Maximum Filtered Instances. Use this option if the view is not too
cluttered.
Use the sheet navigation commands to go to the sheets indicated in
the hollow box.
If there is too much internal logic to display in the current view, the
software puts the internal hierarchy on separate schematic sheets. It
displays a hollow box with no internal logic and indicates the schematic
sheets that contain the internal logic.
5. To view the design context of an instance in a filtered view, select the
instance, right-click, and select Show Context from the popup menu.
The software displays an unfiltered view of the hierarchical level that
contains the selected object, with the instance highlighted. This is useful
when you have to go back and forth between different views during
analysis. The context differs from the Expand commands, which show
connections. To return to the original filtered view, click Back.
Pushing into
an instance
Generates a view that shows only the internal logic. You do not
see the internal hierarchy in context. To return to the previous
view, click Back. See Exploring Object Hierarchy by
Pushing/Popping, on page 401 for details.
Flattening
the entire
design
Opens a new view where the entire design is flattened, except
for hidden hierarchy. Large flattened designs can be
overwhelming. See Flattening Schematic Hierarchy, on
page 440 for details about flattening designs.
Because this is a new view, you cannot use Back to return to
the previous view. To return to the top-level unflattened
schematic, right-click in the view and select Unflatten Schematic.
Flattening
an instance
by dissolving
Generates a view where the hierarchy of the selected instances
is flattened, but the rest of the design is unaffected. This
provides context. See Flattening Schematic Hierarchy, on
page 440 for details about dissolving instances.
March 2014 433
Filtering Schematics
Filtering is a useful first step in analysis, because it focuses analysis on the
relevant parts of the design. Some commands, like the Expand commands,
automatically generate filtered views; this procedure only discusses manual
filtering, where you use the Filter Schematic command to isolate selected
objects. See Chapter 3 of the Reference Manual for details about these
commands.
This table lists the advantages of using filtering over flattening:
1. Select the objects that you want to isolate. For example, you can select
two connected objects.
If you filter a hidden instance, the software does not display its internal
hierarchy when you filter the design. The following example illustrates
this.
2. Select the Filter Schematic command, using one of these methods:
Select Filter Schematic from the HDL Analyst menu or the right-click
popup menu.
Click the Filter Schematic icon (buffer gate) ( ).
Filter Schematic Command Flatten Commands
Loads part of the design; better
memory usage
Loads entire design
Combine filtering with Push/Pop
mode, and history buttons (Back
and Forward) to move freely
between hierarchical levels
Must use Unflatten Schematic to return to top
level, and flatten the design again to see lower
levels. Cannot return to previous view if the
previous view is not the top-level view.
LO
434 March 2014
Press F12.
Press the right mouse button and draw a narrow V-shaped mouse
stroke in the schematic window. See Help->Mouse Stroke Tutor for
details.
The software filters the design and displays the selected objects in a
filtered view. The title bar indicates that it is a filtered view. Hidden
instances have an H in the lower left. The view displays other hierar-
chical instances as hollow boxes with nested internal logic (transparent
instances). For descriptions of filtered views and transparent instances,
see Filtered and Unfiltered Schematic Views, on page 124 and Trans-
parent and Opaque Display of Hierarchical Instances, on page 129 in
the Reference Manual. If the transparent instance does not display
internal logic, use one of the alternatives described in Viewing Design
Hierarchy and Context, on page 430, step 4.
3. If the filtered view does not display the pin names of technology
primitives and transparent instances that you want to see, do the
following:
Select Options->HDL Analyst Options->Text and enable Show Pin Name.
To temporarily display a pin name, move the cursor over the pin. The
name is displayed as long as the cursor remains over the pin.
Alternatively, select a pin. The software displays the pin name until
you make another selection. Either of these options can be applied to
Filtered view
March 2014 435
individual pins. Use them to view just the pin names you need and
keep design clutter to a minimum.
To see all the hierarchical pins, select the instance, right-click, and
select Show All Hier Pins.
You can now analyze the problem, and do operations like the following:
4. To return to the previous schematic view, click the Back icon. If you
flattened the hierarchy, right-click and select Unflatten Schematic to return
to the top-level unflattened view.
For additional information about filtering schematics, see Filtering
Schematics, on page 433 and Flattening Schematic Hierarchy, on page 440.
Expanding Pin and Net Logic
When you are working in a filtered view, you might need to include more logic
in your selected set to debug your design. This section describes commands
that expand logic fanning out from pins or nets; to expand paths, see
Expanding and Viewing Connections, on page 439.
Use the Expand commands with the Filter Schematic, Hide Instances, and Flatten
commands to isolate just the logic that you want to examine. Filtering
isolates logic, flattening removes hierarchy, and hiding instances prevents
their internal hierarchy from being expanded. See Filtering Schematics, on
page 433 and Flattening Schematic Hierarchy, on page 440 for details.
1. To expand logic from a pin hierarchically across boundaries, use the
following commands.
Trace paths, build up logic See Expanding Pin and Net Logic, on page 435
and Expanding and Viewing Connections, on
page 439
Filter further Select objects and filter again
Find objects See Finding Objects, on page 408
Flatten, or hide and flatten See Flattening Schematic Hierarchy, on
page 440. You can hide transparent or opaque
instances.
Crossprobe from filtered
view
See Crossprobing from the RTL/Technology
View, on page 422
LO
436 March 2014
The software expands the logic as specified, working on the current level
and below or working up the hierarchy, crossing hierarchical bound-
aries as needed. Hierarchical levels are shown nested in hollow
bounding boxes. The internal hierarchy of hidden instances is not
displayed.
For descriptions of the Expand commands, see HDL Analyst Menu, on
2. To expand logic from a pin at the current level only, do the following:
Select a pin, and go to the HDL Analyst->Current Level menu or the right-
click popup menu->Current Level.
Select Expand or Expand to Register/Ports. The commands work as
described in the previous step, but they do not cross hierarchical
boundaries.
3. To expand logic from a net, use the commands shown in the following
table.
To expand at the current level and below, select the commands from
the HDL Analyst->Hierarchical menu or the right-click popup menu.
To expand at the current level only, select the commands from the
HDL Analyst->Current Level menu or the right-click popup menu->Current
Level.
To ... Do this (HDL Analyst->Hierarchical/Popup menu) ...
See all cells connected
to a pin
Select a pin and select Expand. See Expanding
Filtered Logic Example, on page 437.
See all cells that are
connected to a pin,
up to the next register
Select a pin and select Expand to Register/Port. See
Expanding Filtered Logic to Register/Port Example,
on page 438.
See internal cells
connected to a pin
Select a pin and select Expand Inwards. The software
filters the schematic and displays the internal cells
closest to the port. See Expanding Inwards
Example, on page 438.
March 2014 437
Expanding Filtered Logic Example
To ... Do this ...
Select the driver of
a net
Select a net and select Select Net Driver. The result is a
filtered view with the net driver selected (Selecting the Net
Driver Example, on page 439).
Trace the driver, across
sheets if needed
Select a net and select Go to Net Driver. The software shows
a view that includes the net driver.
Select all instances on
a net
Select a net and select Select Net Instances. You see a filtered
view of all instances connected to the selected net.
LO
438 March 2014
Expanding Filtered Logic to Register/Port Example
Expanding Inwards Example
March 2014 439
Selecting the Net Driver Example
Expanding and Viewing Connections
This section describes commands that expand logic between two or more
objects; to expand logic out from a net or pin, see Expanding Pin and Net
Logic, on page 435. You can also isolate the critical path or use the Timing
Analyst to generate a schematic for a path between objects, as described in
Analyzing Timing in Schematic Views, on page 452.
Use the following path commands with the Filter Schematic and Hide Instances
commands to isolate just the logic that you want to examine. The two
techniques described here differ: Expand Paths expands connections between
selected objects, while Isolate Paths pares down the current view to only
display connections to and from the selected instance.
For detailed descriptions of the commands mentioned here, see Commands
That Result in Filtered Schematics, on page 150 in the Reference Manual.
1. To expand and view connections between selected objects, do the
following:
Select two or more points.
To expand the logic at the current level only, select HDL Analyst->
Current Level->Expand Paths or popup menu->Current Level Expand Paths.
To expand the logic at the current level and below, select HDL Analyst->
Hierarchical->Expand Paths or popup menu->Expand Paths.
LO
440 March 2014
2. To view connections from all pins of a selected instance, right-click and
select Isolate Paths from the popup menu.
Unlike the Expand Paths command, the connections are based on the
schematic used as the starting point; the software does not add any
objects that were not in the starting schematic.
Flattening Schematic Hierarchy
Flattening removes hierarchy so you can view the logic without hierarchical
levels. In most cases, you do not have to flatten your hierarchical schematic
to debug and analyze your design, because you can use a combination of
Starting Point The Filtered View Traces Paths (Forward and Back) From All
Pins of the Selected Instance...
Filtered view Traces through all sheets of the filtered view, up to the next
port, register, hierarchical instance, or black box.
Unfiltered view Traces paths on the current schematic sheet only, up to the
next port, register, hierarchical instance, or black box.
March 2014 441
filtering, Push/Pop mode, and expanding to view logic at different levels.
However, if you must flatten the design, use the following techniques., which
include flattening, dissolving, and hiding instances.
1. To flatten an entire design down to logic cells, use one of the following
commands:
For an RTL view, select HDL Analyst->RTL->Flattened View. This flattens
the design to generic logic cells.
For a Technology view, select Flattened View or Flattened to Gates View
from the HDL Analyst->Technology menu. Use the former command to
flatten the design to the technology primitive level, and the latter
command to flatten it further to the equivalent Boolean logic.
The software flattens the top-level design and displays it in a new
window. To return to the top-level design, right-click and select Unflatten
Schematic.
Unless you really require the entire design to be flattened, use Push/Pop
mode and the filtering commands (Filtering Schematics, on page 433) to
view the hierarchy. Alternatively, you can use one of the selective
flattening techniques described in subsequent steps.
2. To selectively flatten transparent instances when you analyze critical
paths or use the Expand commands, select Flatten Current Schematic from
the HDL Analyst menu, or select Flatten Schematic from the right-click
popup menu.
The software generates a new view of the current schematic in the same
window, with all transparent instances at the current level and below
flattened. RTL schematics are flattened down to generic logic cells and
Technology views down to technology primitives. To control the number
of hierarchical levels that are flattened, use the Dissolve Instances
command described in step 4.
If your view only contains hidden hierarchical instances or pale yellow
(opaque) hierarchical instances, nothing is flattened. If you flatten an
unfiltered (usually the top-level design) view, the software flattens all
hierarchical instances (transparent and opaque) at the current level and
below. The following figure shows flattened transparent instances.
LO
442 March 2014
Because the flattened view is a new view, you cannot use Back to return
to the unflattened view or the views before it. Use Unflatten Schematic to
return to the unflattened top-level view.
3. To selectively flatten the design by hiding instances, select hierarchical
instances whose hierarchy you do not want to flatten, right-click, and
select Hide Instances. Then flatten the hierarchy using one of the Flatten
commands described above.
Use this technique if you want to flatten most of your design. If you want
to flatten only part of your design, use the approach described in the
next step.
When you hide instances, the software generates a new view where the
hidden instances are not flattened, but marked with an H in the lower
left corner. The rest of the design is flattened. If unhidden hierarchical
instances are not flattened by this procedure, use the Flattened View or
Flattened to Gates View commands described in step 1 instead of the Flatten
Flatten Schematic
flattens unhidden
transparent instance.
Hidden transparent
instance is not
flattened.
Flatten Schematic
flattens unhidden
transparent instance.
Opaque hierarchical
instance is unaffected.
March 2014 443
Current Schematic command described in step 2, which only flattens trans-
parent instances in filtered views.
You can select the hidden instances, right-click, and select Unhide
Instances to make their hierarchy accessible again. To return to the
unflattened top-level view, right-click in the schematic and select
Unflatten Schematic.
4. To selectively flatten some hierarchical instances in your design by
dissolving them, do the following:
If you want to flatten more than one level, select Options->HDL Analyst
Options and change the value of Dissolve Levels. If you want to flatten
just one level, leave the default setting.
Select the instances to be flattened.
Right-click and select Dissolve Instances.
The results differ slightly, depending on the kind of view from which you
dissolve instances.
The following figure illustrates this.
Starting View Software Generates a ...
Filtered Filtered view with the internal logic of dissolved instances
displayed within hollow bounding boxes (transparent
instances), and the hierarchy of the rest of the design
unchanged. If the transparent instance does not display
internal logic, use one of the alternatives described in step 4
of Viewing Design Hierarchy and Context, on page 430. Use
the Back button to return to the undissolved view.
Unfiltered New, flattened view with the dissolved instances flattened in
place (no nesting) to Boolean logic, and the hierarchy of the
rest of the design unchanged. Select Unflatten Schematic to
return to the top-level unflattened view. You cannot use the
Back button to return to previous views because this is a new
view.
LO
444 March 2014
Use this technique if you only want to flatten part of your design while
retaining the hierarchical context. If you want to flatten most of the
design, use the technique described in the previous step. Instead of
dissolving instances, you can use a combination of the filtering
commands and Push/Pop mode.
Dissolved logic for prgmcntr shown flattened in context when you start from an unfiltered view
Dissolved logic for prgmcntr shown nested when started from filtered view
March 2014 445
Minimizing Memory Usage While Analyzing Designs
When working with large hierarchical designs, use the following techniques
to use memory resources efficiently.
Before you do any analysis operations such as searching, flattening,
expanding, or pushing/popping, hide (HDL Analyst->Hide Instances) the
hierarchical instances you do not need. This saves memory resources,
because the software does not load the hierarchy of the hidden
instances.
Temporarily divide your design into smaller working files. Before you do
any analysis, hide the instances you do not need. Save the design. The
srs and srm files generated are smaller because the software does not
save the hidden hierarchy. Close any open HDL Analyst windows to free
all memory from the large design. In the Implementation Results view,
double-click one of the smaller files to open the RTL or Technology
schematic. Analyze the design using the smaller, working schematics.
Filter your design instead of flattening it. If you must flatten your design,
hide the instances whose hierarchy you do not need before flattening, or
use the Dissolve Instances command. See Flattening Schematic Hierarchy,
on page 440 for details. For more information on the Expand Paths and
Isolate Paths commands, see RTL and Technology Views Popup Menus, on
When searching your design, search by instance rather than by net.
Searching by net loads the entire design, which uses memory.
Limit the scope of a search by hiding instances you do not need to
analyze. You can limit the scope further by filtering the schematic in
addition to hiding the instances you do not want to search.
LO
Chapter 8: Analyzing with HDL Analyst and FSM Viewer Using the FSM Viewer
446 March 2014
Using the FSM Viewer
The FSM viewer displays state transition bubble diagrams for
FSMs in the design, along with additional information about the FSM. You
can use this viewer to view state machines implemented by either the FSM
Compiler or the FSM Explorer. For more information, see Running the FSM
Compiler, on page 606 and Running the FSM Explorer, on page 610, respec-
tively.
1. To start the FSM viewer, open the RTL view and either
Select the FSM instance, click the right mouse button and select View
FSM from the popup menu.
Push down into the FSM instance (Push/Pop icon).
The FSM viewer opens. The viewer consists of a transition bubble
diagram and a table for the encodings and transitions. If you used
Verilog to define the FSMs, the viewer displays binary values for the
state machines if you defined them with the define keyword, and actual
names if you used the parameter keyword.
Using the FSM Viewer Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 447
2. The following table summarizes basic viewing operations.
This figure shows you the mapping information for a state machine. The
Transitions tab shows you simple equations for conditions for each state.
The RTL Encodings tab has a State column that shows the state names in
the source code, and a Registers column for the corresponding RTL
encoding. The Mapped Encoding tab shows the state names in the code
mapped to actual values.
To view ... Do ...
from and to states, and conditions
for each transition
Click the Transitions tab at the
bottom of the table.
the correspondence between the
states and the FSM registers in the
RTL view
Click the RTL Encoding tab.
the correspondence between the
states and the registers in the
Technology View
Click the Mapped Encodings tab
(available after synthesis).
only the transition diagram without
the table
Select View->FSM table or click the
FSM Table icon. You might have to
scroll to the right to see it.
LO
448 March 2014
3. To view just one selected state,
Select the state by clicking on its bubble. The state is highlighted.
Click the right mouse button and select the filtering criteria from the
popup menu: output, input, or any transition.
The transition diagram now shows only the filtered states you set. The
following figure shows filtered views for output and input transitions for
one state.
States and Conditions
Mapped Encoding RTL Encoding
Using the FSM Viewer Chapter 8: Analyzing with HDL Analyst and FSM Viewer
March 2014 449
Similarly, you can check the relationship between two or more states by
selecting the states, filtering them, and checking their properties.
4. To view the properties for a state,
Select the state.
Click the right mouse button and select Properties from the popup
menu. A form shows you the properties for that state.
To view the properties for the entire state machine like encoding style,
number of states, and total number of transitions between states,
deselect any selected states, click the right mouse button outside the
diagram area, and select Properties from the popup menu.
5. To view the FSM description in text format, select the state machine in
the RTL view and View FSM Info File from the right mouse popup. This is
an example of the FSM Info File, statemachine.info.
State Machine: work.Control(verilog)-cur_state[6:0]
No selected encoding - Synplify will choose
Number of states: 7
Number of inputs: 4
Inputs:
0: Laplevel
1: Lap
2: Start
3: Reset
Clock: Clk
CountCont state filtered by output transitions
CountCont state filtered by input transitions
LO
450 March 2014
Transitions: (input, start state, destination state)
-100 S0 S6
--10 S0 S2
---1 S0 S0
-00- S0 S0
--10 S1 S3
-100 S1 S2
-000 S1 S1
---1 S1 S0
--10 S2 S5
-000 S2 S2
-100 S2 S1
---1 S2 S0
-100 S3 S5
-000 S3 S3
--10 S3 S1
---1 S3 S0
-000 S4 S4
--1- S4 S0
-1-- S4 S0
---1 S4 S0
-000 S5 S5
-100 S5 S4
--10 S5 S2
---1 S5 S0
1--0 S6 S6
---1 S6 S0
0--- S6 S0
March 2014 451
CHAPTER 9
Analyzing Timing
This chapter describes typical analysis tasks. It describes graphical analysis
with the HDL Analyst tool as well as interpretation of the text log file. It covers
the following:
Analyzing Timing in Schematic Views, on page 452
Generating Custom Timing Reports with STA, on page 459
Using Analysis Design Constraints, on page 462
Using Auto Constraints, on page 469
Using the Timing Report View, on page 474
Analyzing Timing with Physical Analyst, on page 482
LO
Chapter 9: Analyzing Timing Analyzing Timing in Schematic Views
452 March 2014
Analyzing Timing in Schematic Views
You can use the HDL Analyst and Timing Analyst functionality to analyze
timing. This section describes the following:
Viewing Timing Information, on page 452
Annotating Timing Information in the Schematic Views, on page 453
Analyzing Clock Trees in the RTL View, on page 455
Viewing Critical Paths, on page 455
Handling Negative Slack, on page 458
Viewing Timing Information
Some commands, like Show Critical Path, Hierarchical Critical Path, Flattened Critical
Path, automatically enable Show Timing Information and display the timing infor-
mation. The following procedure shows you how to do so manually.
1. To analyze timing, enable HDL Analyst->Show Timing Information.
This displays the timing numbers for all instances in a Technology view.
It shows the following:
Delay This is the first number displayed.
Combinational logic
This first number is the cumulative path delay to the output of
the instance, which includes the net delay of the output.
Flip-flops
This first number is the path delay attributed to the flip-flop. The
delay can be associated with either the input or output path,
whichever is worse, because the flip-flop is the end of one path
and the start of another.
Slack
Time
This is the second number, and it is the slack time of the worst
path that goes through the instance. A negative value indicates
that timing constraints can not be met.
Analyzing Timing in Schematic Views Chapter 9: Analyzing Timing
March 2014 453
Annotating Timing Information in the Schematic Views
You can annotate the schematic views with timing information for the compo-
nents in the design. Once the design is annotated, you can search for these
properties and their associated instances.
1. On the Device tab of the Implementation Options dialog box, enable Annotated
Properties for Analyst.
For each synthesis implementation and each place-and-route imple-
mentation, the tool generates properties and stores them in two files
located in the project folder:
2. To view the annotated timing, open an RTL or Technology view.
3. To view the timing information from another associated implementation,
do the following:
Open an RTL or Technology view. It displays the timing information
for that implementation.
Select HDL Analyst->Select Timing, and select another implementation
from the list. The list contains the main implementation and all
.sap Synplify Annotated Properties
Contains the annotated design properties generated after compilation,
like clock pins.
.tap Timing Annotated Properties
Contains the annotated timing properties generated after compilation.
LO
454 March 2014
associated place-and-route implementations. The timing numbers in
the current Analyst view change to reflect the numbers from the
selected implementation.
In the following example, an RTL View shows timing data from the test
implementation and the test/pr_1 (place and route) implementation.
4. Once you have annotated your design, you can filter searches using
these properties with the find command.
Use the find -filter {@propName>=propValue} command for the searches.
See Find Filter Properties, on page 190 in the Reference Manual for a
list of properties. For information about the find command, see find,
Precede the property name with the @ symbol.
For example to find fanouts larger than 60, specify find -filter {@fanout>=60}.
March 2014 455
Analyzing Clock Trees in the RTL View
To analyze clock trees in the RTL view, do the following:
1. In the Hierarchy Browser, expand Clock Tree, select all the clocks, and
filter the design.
The Hierarchy Browser lists all clocks and the instances that drive them
under Clock Tree. The filtered view shows the selected objects.
2. If necessary, use the filter and expand commands to trace clock
connections back to the ports and check them.
For details about the commands for filtering and expanding paths, see
Filtering Schematics, on page 433, Expanding Pin and Net Logic, on
page 435 and Expanding and Viewing Connections, on page 439.
3. Check that your defined clock constraints cover the objects in the
design.
If you do not define your clock constraints accurately, you might not get
the best possible synthesis optimizations.
Viewing Critical Paths
The HDL Analyst tool makes it simple to find and examine critical paths and
the relevant source code. The following procedure shows you how to filter and
analyze a critical path. You can also use the procedure described in Gener-
ating Custom Timing Reports with STA, on page 459 to view this and other
paths.
1. If needed, set the slack time for your design.
Select HDL Analyst->Set Slack Margin.
To view only instances with the worst-case slack time, enter a zero.
To set a slack margin range, type a value for the slack margin, and
click OK. The software gets a range by subtracting this number from
the slack time, and the Technology view displays instances within
this range. For example, if your slack time is -10 ns, and you set a
slack margin of 4 ns, the command displays all instances with slack
times between -6 ns and -10 ns. If your slack margin is 6 ns, you see
all instances with slack times between -4 ns and -10 ns.
LO
456 March 2014
2. Display the critical path using one of the following methods. The
Technology view displays a hierarchical view that highlights the
instances and nets in the most critical path of your design.
To generate a hierarchical view of the critical path, click the Show
Critical Path icon (stopwatch icon ( ), select HDL Analyst->Technology-
>Hierarchical Critical Path, or select the command from the popup menu.
This is a filtered view in the same window, with hierarchical logic
shown in transparent instances. History commands apply, so you
can return to the previous view by clicking Back.
To flatten the hierarchical critical path described above, right-click
and select Flatten Schematic. The software generates a new view in the
current window, and flattens only the transparent instances needed
to show the critical path; the rest of the design remains hierarchical.
Click Back to go the top-level design.
To generate a flattened critical path in a new window, select HDL
Analyst->Technology->Flattened Critical Path. This command uses more
memory because it flattens the entire design and generates a new
view for the flattened critical path in a new window. Click Back in this
window to go to the flattened top-level design or to return to the
previous window.
Flattened Critical Path
Hierarchical Critical Path
March 2014 457
3. Use the timing numbers displayed above each instance to analyze the
path. If no numbers are displayed, enable HDL Analyst->Show Timing
Information. Interpret the numbers as follows:
4. View instances in the critical path that have less than the worst-case
slack time. For additional information on handling slack times, see
Handling Negative Slack, on page 458.
If necessary change the slack margin and regenerate the critical path.
5. Crossprobe and check the RTL view and source code. Analyze the code
and the schematic to determine how to address the problem. You can
add more constraints or make code changes.
6. Click the Back icon to return to the previous view. If you flattened your
design during analysis, select Unflatten Schematic to return to the top-level
design.
There is no need to regenerate the critical path, unless you flattened
your design during analysis or changed the slack margin. When you
flatten your design, the view is regenerated so the history commands do
not apply and you must click the Critical Path icon again to see the critical
path view.
7. Rerun synthesis, and check your results.
If you have fixed the path, the window displays the next most critical
path when you click the icon.
Repeat this procedure and fix the design for the remaining critical paths.
When you are within 5-10 percent of your desired results, place and
route your design to see if you meet your goal. If so, you are done. If your
vendor provides timing-driven place and route, you might improve your
results further by adding timing constraints to place and route.
8.8, 1.2
Delay
For combinational logic, it is the cumulative delay to
the output of the instance, including the net delay of
the output. For flip-flops, it is the portion of the path
delay attributed to the flip-flop. The delay can be
associated with either the input path or output path,
whichever is worse, because the flip-flop is the end of
one path and the start of another.
Slack time
Slack of the worst path that
goes through the instance. A
negative value indicates that
timing has not been met.
LO
458 March 2014
Handling Negative Slack
Positive slack time values (greater than or equal to 0 ns) are good, while
negative slack time values (less than 0 ns) indicate the design has not met
timing requirements. The negative slack value indicates the amount by which
the timing is off because of delays in the critical paths of your design.
The following procedure shows you how to add constraints to correct negative
slack values. Timing constraints can improve your design by 10 to 20
percent.
1. Display the critical path in a filtered Technology view.
For a hierarchical critical path, either click the Critical Path icon, select
HDL Analyst->Show Critical Path, or select HDL Analyst->Technology->
Hierarchical Critical Path.
For a flat path, select HDL Analyst->Technology->Flattened Critical Path.
2. Analyze the critical path.
Check the end points of the path. The start point can be a primary
input or a flip-flop. The end point can be a primary output or a
flip-flop.
Examine the instances. Use the commands described in Expanding
Pin and Net Logic, on page 435 and Expanding and Viewing
Connections, on page 439. For more information on filtering
schematics, see Filtering Schematics, on page 433.
3. Determine whether there is a timing exception, like a false or multicycle
path. If this is the cause of the negative slack, set the appropriate timing
constraint.
If there are fewer start points, pick a start point to add the constraint. If
there are fewer end points, add the constraint to an end point.
4. If your design does not meet timing by 20 percent or more, you may
need to make structural changes. You could do this by doing either of
the following:
Enabling options like pipelining (Pipelining, on page 580), retiming
(Retiming, on page 584), or resource sharing (Sharing Resources, on
page 602).
Modifying the source code.
5. Rerun synthesis and check your results.
Generating Custom Timing Reports with STA Chapter 9: Analyzing Timing
March 2014 459
Generating Custom Timing Reports with STA
The log file generated after synthesis includes a timing report and default
timing information. Use the stand-alone timing analyst (STA) when you need
to generate a customized timing report (ta) for the following situations:
You need more details about a specific path
You want results for paths other than the top five timing paths (log file
default)
You want to modify constraints and analyze, without resynthesizing. See
Using Analysis Design Constraints, on page 462 for details.
The following procedure shows you how to generate a custom report:
1. Select Analysis->Timing Analyst or click on the Timing Analyst icon( ).
If you are working in Physical Synthesis mode, make sure that the Physical
Synthesis switch is still enabled when you run stand alone timing
analysis to ensure proper results.
2. Fill in the parameters.
You can type in the from/to or through points, or you can cut and paste
or drag and drop valid objects from the Technology view (not the RTL
view) into the fields. See Timing Report Generation Parameters, on
page 408 in the Reference Manual for details on timing analysis
parameters and how they can be filtered.
Set options for clock reports as needed.
Specify a name for the output timing report (ta).
LO
Chapter 9: Analyzing Timing Generating Custom Timing Reports with STA
460 March 2014
3. Click Generate to run the report.
The software generates a custom report file called projectName.ta, located
in the implementation directory (the directory you specified for synthesis
results). The software also generates a corresponding output netlist file,
with an srm extension.
4. Analyze results.
View the report (Open Report) in the Text Editor. The following figure is
a sample report showing analysis results based on maximum delay
for the worst paths.
Generating Custom Timing Reports with STA Chapter 9: Analyzing Timing
March 2014 461
View the netlist (View Critical Path) in a Technology view. This
Technology view, labeled Timing View in the title bar, shows only the
paths you specified in the Timing Analyst dialog box. Note that the
Timing Analyst and Show Critical Path commands (and equivalent icons
and shortcuts) are disabled whenever the Timing View is active.
LO
Chapter 9: Analyzing Timing Using Analysis Design Constraints
462 March 2014
Using Analysis Design Constraints
Besides generating custom timing reports (see Generating Custom Timing
Reports with STA, on page 459), you can also use the Stand-alone Timing
Analyst to create constraints in an adc file. You can use these constraints to
experiment with different timing values, or to add or modify timing
constraints.
The advantage to using analysis design constraints (ADC) is that you do not
have to resynthesize the whole design. This reduces debugging time because
you can get a quick estimate, or try out different values. The Standalone
Timing Analyst (STA) puts these constraints in an Analysis Design
Constraints file (adc). The process for using this file is summarized in the
following flow diagram:
See the following for details:
Scenarios for Using Analysis Design Constraints, on page 463
Creating an ADC File, on page 464
Using Object Names Correctly in the adc File, on page 468
Using Analysis Design Constraints Chapter 9: Analyzing Timing
March 2014 463
Scenarios for Using Analysis Design Constraints
The following describe situations where you can effectively use adc
constraints to debug, explore options or modify constraints. For details about
creating these constraints, see Creating an ADC File, on page 464.
What-if analysis of design performance
If your design meets the target frequency, you can use adc constraints to
analyze higher target frequencies, or analyze performance of a module in
a different design/technology/target device.
Constraints on enable registers
Similarly, you can apply syn_reference_clock on enable registers to analyze
if the enables have a regular pattern like clock, or if they operate on a
frequency other than clock. For example:
Adding additional timing exceptions
When you analyze the results of the first synthesis run, you often find
functional or clock-to-clock timing exceptions, and you can handle these
with adc constraints. For example:
Applying false paths on synchronization circuitry
Adding false paths between clocks belonging to different clock groups
You must add these constraints to see more critical paths in the design.
The adc constraints let you add these constraints on the fly, and helps
you debug designs faster.
Modifying timing exceptions that were previously applied
For example you might want to set a multicycle path constraint for a
path that was defined as a false path in the constraint file or vice versa.
To modify the timing exception, you must first ignore or reset the timing
exception that was set in the constraint file, as described in Using
Analysis Design Constraints, on page 462, step 3.
FDC create_clock {clk} name {clk} freq 100 clockgroup
clk_grp_0
ADC define_attribute {n:en} syn_reference_clock {clk2}
create_clock {clk2} name {clk2} freq 50 clockgroup
clk_grp_1
LO
464 March 2014
Creating an ADC File
The following procedure explains how to create an adc file.
1. Select File->New.
2. Do the following in the dialog box that opens:
Select Analysis Constraint File.
Type a name and location for the file. The tool automatically assigns
the adc extension to the filename.
Enable Add to Project, and click OK. This opens the text editor where
you can specify the new constraints.
3. Type in the constraints you want and save the file. Remember the
following when you enter the constraints:
Keep in mind that the original fdc file has already been applied to the
design. Any timing exception constraints in this file must not conflict
with constraints that are already in effect. For example, if there is a
March 2014 465
conflict when multiple timing exceptions (false path, path delay, and
multicycle timing constraints) are applied to the same path, the tool
uses this order to resolve conflicts: false path, multicycle path, max
delay. See Conflict Resolution for Timing Exceptions, on page 244 for
details about how the tool prioritizes timing exceptions.
The object names must be mapped object names, so use names from
the Technology view, not names from the RTL view. Unlike the
constraint file (RTL view), the adc constraints apply to the mapped
database because the database is not remapped with this flow. For
more information, see Using Object Names Correctly in the adc File, on
page 468.
If you want to modify an existing constraint for a timing exception,
you must first reset the original fdc constraint, and then apply the
new constraint. In the following example the multicycle path
constraint was changed to 3:
When you are done, save and close the file. This adds the file to your
project.
Original FDC set_multicycle_path to [get_cells{a_reg*}] 2
ADC reset_path to {get_cells{a_reg*}]
set_multicycle_path to [get_cells{a_reg*}] 3
LO
466 March 2014
You can create multiple adc files for different purposes. For example,
you might want to keep timing exception constraints, I/0 constraints,
and clock constraints in separate files. If you have an existing adc file,
use the Add File command to add this file to your project. Select
Analysis Design Constraint Files (*.adc) as the file type.
4. Run timing analysis.
Select Analysis->Timing Analyst or click the Timing Analyst icon ( ).
The Timing Analyst window will look like the example below, with
pointers to the srm file, the original fdc and the new adc files you
created.
March 2014 467
If you have multiple adc files, enable the ones you want.
If you have a previous run and want to save that report, type a new
name for the output ta file. If you do not specify a name, the tool
overwrites the previous report.
Fill in other parameters as appropriate, and click Generate.
The tool runs static timing analysis in the same implementation direc-
tory as the original implementation. The tool applies the adc constraints
on top of the fdc constraints. Therefore, adc constraints affect timing
results only if there are no conflicts with fdc constraints.
The tool generates a timing report called *_adc.ta and an *_adc.srm file by
default. It does not change any synthesis outputs, like the output netlist
or timing constraints for place and route.
LO
468 March 2014
5. Analyze the results in the timing report and *_adc.srm file.
6. If you need to resynthesize after analysis, add the adc constraints as an
fdc file to the project and rerun synthesis.
Using Object Names Correctly in the adc File
Constraints and collections applied in the constraint file reference the
RTL-level database. Synthesis optimizations such as retiming and replication
can change object names during mapping because objects may be merged.
The standalone timing analyst does not map objects. It just reads the
gate-level object names from the post-mapping database; this is reflected in
the Technology view. Therefore, you must define objects either explicitly or
with collections from the Technology view when you enter constraints into the
adc file. Do not use RTL names when you create these constraints (see
Creating an ADC File, on page 464 for details of that process).
Example
Assume that register en_reg is replicated during mapping to reduce fanout.
Further, registers en_reg and en_reg_rep2 connect to register dataout[31:0]. In
this case, if you define the following false path constraint in the adc file, then
the standalone timing analyzer does not automatically treat paths from the
replicated register en_reg_rep2 as false paths.
set_false_path -from {{i:en_reg}} -to {{i:dataout[31:0]}}
Unlike constraints in the fdc file, you must specify this replicated register
explicitly or as a collection. Only then are all paths properly treated as false
paths. So in this example, you must define the following constraints in the
adc file:
set_false_path -from {{i:en_reg}} -to {{i:dataout[31:0]}}
set_false_path -from {{i:en_reg_rep2}}
-to {{i:dataout[31:0]}}
or
define_scope_collection en_regs {find -seq {i:en_reg*}
-filter (@name == en_reg || @name == en_reg_rep2)}
set_false_path -from {{$en_regs}} -to {{i:dataout[31:0]}}
Using Auto Constraints Chapter 9: Analyzing Timing
March 2014 469
Using Auto Constraints
You can use auto constraints in the Synplify Pro and Synplify Premier tools,
however, the Physical Synthesis option must be disabled in the Synplify Premier
product.
Auto constraining lets you synthesize with automatic constraints as a first
step to get an idea of what you can achieve. Automatic constraints generate
the fastest design implementation, so they force the timing engine to work
harder. Based on the results from auto-constraining, you can refine the
constraints manually later. For an explanation of how auto constraints work,
see Results of Auto Constraints, on page 471
1. To automatically constrain your design, first do the following:
Set your device to a technology that supports auto-constraining. With
supported technologies, the Auto Constrain button under Frequency in
the Project view is available.
Do not define any clocks. If you define clocks using the SCOPE
window or a constraint file, or set the frequency in the Project view,
the software uses the user-defined create_clock constraints instead of
auto constraints.
Make sure any multi-cycle or false path constraints are specified on
registers.
2. Enable the Auto Constrain button on the left side of the Project view.
Alternatively, select Project->Implementation Options->Constraints, and enable
the Auto Constrain option there.
LO
Chapter 9: Analyzing Timing Using Auto Constraints
470 March 2014
3. If you want to auto constrain I/O paths, select Project->Implementation
Options->Constraints and enable Use Clock Period for Unconstrained IO.
If you do not enable this option, the software only auto constrains flop-
to-flop paths. Even when the software auto constrains the I/O paths, it
does not generate these constraints for forward-annotation.
The software puts each clock in a separate clock group and adjusts the
timing of each clock individually. At different points during synthesis it
adjusts the clock period of each clock to be a target percentage of the
current clock period, usually 15% - 25%.
After the clocks, the timing engine constrains I/O paths by setting the
default combinational path delay for each I/O path to be one clock
period.
The software writes out the generated constraints in a file called
AutoConstraint_designName.sdc in the run directory. It also forward-
annotates these constraints to the place-and-route tools.
5. Check the results in AutoConstraint_designName.sdc and the log file. To
open the constraint file as a text file, right-click on the file in the
Implementation Results view and select Open as Text.
March 2014 471
The flop-to-flop constraints use syntax like the following:
create_clock -name {c:leon|clk} -period 13.327 -clockgroup
Autoconstr_clkgroup_0 -rise 0.000 -fall 6.664 -route 0.000
6. You can now add this generated constraint file to the project and rerun
synthesis with these constraints.
Results of Auto Constraints
This section contains information about the following:
Stages of the Auto Constrain Algorithm, on page 471
I/O Constraints, Timing Exceptions, DLLs, DCMs, and PLLs, on
page 472
Reports and Forward-annotation, on page 472
Repeatability of Results, on page 473
Stages of the Auto Constrain Algorithm
To auto constrain, do not define any clocks. When you enable the Auto
Constrain option, the synthesis software goes through these stages:
1. It infers every clock in the design.
2. It puts each clock in its own clock group.
3. It invokes mapper optimizations in stages and generates the best
possible synthesis results.
Clocks derived from DCM/PLLs will be in the clock group of the
parent clock (DCM/PLL input clock).
You should only use Auto Constrain early in the synthesis process to get
a general idea of how fast your design runs. This option is not meant
to be a substitute for declaring clocks.
4. For each clock, including the system clock, the software maintains a
negative slack of between 15 and 25 percent of the requested frequency.
LO
Chapter 9: Analyzing Timing Using Auto Constraints
472 March 2014
I/O Constraints, Timing Exceptions, DLLs, DCMs, and PLLs
The auto constrain algorithm infers all the clocks, because none are defined.
It handles the following timing situations as described below:
I/O constraints
You can auto constrain I/O paths as well as flop-to-flop paths by
selecting Project->Implementation Options->Constraints and enabling Use Clock
Period for Unconstrained IO. The software does not write out these I/O
constraints.
Timing exceptions like multicycle and false paths
The auto constraint algorithm honors SCOPE multicycle and false path
constraints that are specified as constraints on registers.
Altera PLLs and Xilinx DCMs and DLLs
The software infers the input frequency and derives the outputs. The
inputs and outputs are put in the same clock group because they are
considered to be synchronized clocks that are related to each other. Note
that the auto constrain algorithm might not preserve the exact relation-
ship between the input and outputs (2x, for example) depending on the
other logic around it.
Auto Constrain Limitations
The Auto Constrain feature has the following limitations:
Does not respect the vendor-provided maximum frequency constraints
for clock generators (DCMs and DLLs).
Over constrains designs with output critical paths.
Reports and Forward-annotation
In the log file, the software reports the Requested and Estimated Frequency or
Requested and Estimated Period and the negative slack for each clock it infers.
The log file contains all the details.
The software also generates a constraint file in the run directory called
AutoConstraint_designName.sdc, which contains the auto constraints generated.
The following is an example of an auto constraint file:
#Begin clock constraint
March 2014 473
create_clock -name {c:leon|clk} -period 13.327 -rise 0.000 -fall
6.664
#End clock constraint
The software forward-annotates the create_clock constraints, writing out the
appropriate file for the place-and-route tool.
Repeatability of Results
If you use the requested frequency resulting from the Auto constrain option as
the requested frequency for a regular synthesis run, you might not get the
same results as you did with auto constraints. This is because the software
invokes the mapper optimizations in stages when it auto constrains. The
results from a previous stage are used to drive the next stage. As the interim
optimization results vary, there is no guarantee that the final results will stay
the same.
LO
Chapter 9: Analyzing Timing Using the Timing Report View
474 March 2014
Using the Timing Report View
Synplify Premier
Altera, Xilinx
The Timing Report View displays timing reports, lets you view and query
critical timing paths, and correlate your timing results. You can compare
synthesis timing results with P&R Static Timing Analysis (STA) results and
determine if paths for timing end points, start points, and requested periods
match.
You can either view the synthesis timing results alone, or in a composite view
where they are correlated with the place-and-route timing results. The
following sections describe the details:
Viewing and Analyzing the Synthesis Timing Report, on page 475
Viewing and Analyzing the P&R Timing and Correlation Report, on
page 477
For a complete description of the Timing Report View options, see Timing
Report View, on page 402 in the Reference Manual.
Using the Timing Report View Chapter 9: Analyzing Timing
March 2014 475
Viewing and Analyzing the Synthesis Timing Report
The following procedure describes how to use the synthesis timing report and
analyze the information in it. For information about comparing synthesis
timing information to place-and-route information, see Viewing and
Analyzing the P&R Timing and Correlation Report, on page 477.
1. Run synthesis. From an open implementation, display the Timing
Report View by selecting Analysis->Timing Report View or by clicking the
Timing Report view icon ( ) or by clicking the Timing Report View link
in the Project Status window.
By default, the view shows the synthesis timing summary on the
Synthesis Timing tab. The summary matches the critical paths shown in
the Clock Relationships section of the log file after synthesis.
2. Set reporting and display options.
For Xilinx devices, select the kind of timing report summary to
display by enabling the Logic Synthesis or Physical Plus Synthesis buttons.
For Altera designs you can only display a logic synthesis report.
To expand all paths for the clocks and instances, click Expand All.
To collapse all paths for the clocks and instances, click Collapse All.
LO
476 March 2014
To change the number of paths displayed per end point, select the
path and click Options. Set the number of paths to display in the
Synthesis Timing Options dialog box that opens.
3. To locate objects like clocks or instances, click Find and type in the text
to locate:
4. To view and analyze individual paths, use the following features in the
view:
To generate a filtered HDL Analyst schematic for a path, select the
path and click Synthesis Schematic.
To generate a timing report summary for a path, select the path and
click Synthesis Report.
March 2014 477
Viewing and Analyzing the P&R Timing and Correlation Report
The following procedure describes how to generate and analyze the informa-
tion in the P&R timing report, and compare it to the results from synthesis. If
you only want to view the synthesis timing results, use the procedure
described in Viewing and Analyzing the Synthesis Timing Report, on
page 475.
LO
478 March 2014
1. To generate the timing report, follow these steps:
Run synthesis and place-and-route. Make sure the P&R tool is
enabled.
Open the implementation you want.
Display the Timing Report View by selecting Analysis->Timing Report View
or by clicking the Timing Report view icon ( ).
Select the P&R Timing and Correlation tab.
2. Define the scope of the correlation results and run correlation.
For Xilinx devices, specify the synthesis results you want to compare
by enabling either Logic Synthesis or Physical Plus Synthesis at the top of
the window. The only choice for Altera designs is Logic Synthesis.
In the P&R Directory field, specify another implementation for the
comparison. Select Other to specify the location of a project outside
the current project.
To correlate all paths, click the All Paths button on the right.
To selectively correlate paths, click Selected Path and select the paths
you want.
The window displays the place-and-route timing information, correlated
to the synthesis information. For example, you can compare synthesis
timing results with P&R Static Timing Analysis (STA) results. The view
reports the status of end points, start points, and required periods.
Paths are reported against the end clock. The P&R path is shown first,
with the synthesis path to be correlated below.
A green check mark ( ) in the Correlated Status column indicates a
match between synthesis timing and P&R timing results for end points,
start points, and requested periods on that path. A red x ( ) indicates a
mismatch. Float over the mismatched cell for a tool tip that describes
the error. For a complete description of the Timing Report View options,
see Timing Report View, on page 402 in the Reference Manual.
March 2014 479
3. To compare synthesis and P&R clock names, click the Clock Mappings
button.
The clock correlation table links synthesis clock names to P&R clock
names. The synthesis clock is a clock alias name that appears in the
synthesis log file (srr) or timing report file (ta).
4. To view and analyze individual paths, use the following features in the
view:
To generate a filtered HDL Analyst schematic for a path, select the
path and click Synthesis Schematic.
To generate a timing report summary for a path, select the path and
click Synthesis Report.
To generate a P&R summary for a path, select the path and click P&R
Report.
LO
480 March 2014
5. Set other reporting and display options as needed.
Order the paths in ascending or descending order of slack values by
sorting on the Slack column.
Change P&R timing correlation options by clicking the Options button
and specifying the settings you want. For example, you can specify
the number of paths to report per end point. If you do not enable any
of the limiting options, the report includes paths for all these
constraints. Rerun correlation by clicking All Paths or Selected Paths to
view the updated results.
March 2014 481
To expand all paths for the clocks and instances, click Expand All.
To collapse all paths for the clocks and instances, click Collapse All.
To change the number of paths displayed per end point, select the
path and click Options. Set the number of paths to display in the
Synthesis Timing Options dialog box that opens.
To locate objects like clocks or instances, click Find and type in the
string to locate.
LO
Chapter 9: Analyzing Timing Analyzing Timing with Physical Analyst
482 March 2014
Analyzing Timing with Physical Analyst
You can use the Physical Analyst functionality to analyze timing. This section
describes how to view and use the critical path for further physical synthesis.
Viewing Critical Paths in Physical Analyst, on page 482
Tracing Critical Paths Forward in Physical Analyst, on page 485
Tracing Critical Paths Backward in Physical Analyst, on page 487
Viewing Critical Paths in Physical Analyst
The Physical Analyst tool makes it easy to find and examine critical paths
and the relevant logic in the HDL Analyst schematic view. Make sure the HDL
Analyst view is open, for example, by selecting HDL Analyst->Technology->
Flattened View or HDL Analyst->RTL->Flattened View. The following procedure
shows you how to filter and analyze a critical path.
1. To generate a view of the critical path with the Physical Analyst tool,
click the Show Critical Path icon (stopwatch icon ( ) or select the
command from the popup menu. To zoom in on the critical path, right-
click and select Zoom Selected from the popup menu.
2. Check the Technology view.
You can also cross probe the critical path from the flattened Technology
view to the Physical Analyst view by clicking on the Show Critical Path icon
( ). Then, right-click and select Select All Schematic->Instances. Make
sure the Physical Analyst view is open.
3. Check the Physical Analyst view. Critical path instances and nets
should be highlighted in this view.
Analyzing Timing with Physical Analyst Chapter 9: Analyzing Timing
March 2014 483
4. In the HDL Analyst view that is already open, click on the Filter Schematics
icon ( ). Only the instances and nets belonging to the critical timing
path are displayed, as shown below.
LO
484 March 2014
5. In the HDL Analyst view, right-click and select Expand Paths from the
popup menu. Then, you can drag-and-drop this logic into a region on
the device design plan (sfp) file for further physical synthesis.
March 2014 485
Tracing Critical Paths Forward in Physical Analyst
The following procedure shows you how to trace a critical path forwards
starting from the instance containing the critical start point.
1. Do one of the following in the Physical Analyst view:
Right-click and select Critical Path->Expand Path Forward from the popup
menu
Press F3.
The instance containing the critical path start point is displayed in green
and highlighted. Move the cursor over the instance to display a tool tip
that specifies its name and identifies this as the critical start point.
You can also use the Filter Search option of the Find command to locate
the Critical path start point.
2. Select Critical Path->Expand Path Forward or press F3 again.
The next instances on the critical path and input ports that feed into the
path are displayed and highlighted and shown connected to the critical
path start point.
LO
486 March 2014
3. Repeat the previous step to continue tracing the path to the next
instance in the path. Continue until you reach the end point.
(Critical End)
(Critical Start)
March 2014 487
The following figure shows you how the critical path is finally displayed.
Tracing Critical Paths Backward in Physical Analyst
The following procedure shows you how to trace a critical path backward. See
the figures in Tracing Critical Paths Forward in Physical Analyst, on page 485,
which also apply to this procedure.
1. Do one of the following in the Physical Analyst view:
Right-click and select Critical Path->Expand Path Backward from the
popup menu.
Press Shift+F3.
LO
488 March 2014
The instance containing the critical path end point is displayed and
highlighted. Move the cursor over the instance to display a tool tip that
specifies its name and identifies this as the critical end point.
You can also use the Filter Search option of the Find command to locate
the Critical path end point. The cell location of the critical path end point is
displayed in red in the Physical Analyst view.
2. Use one of the methods described in the previous step to continue to
trace the net to the next instance in its path.
The next instance containing the critical path and output ports that feed
into the path are displayed and highlighted and shown connected to the
critical path end point.
3. Repeat the previous step until you reach the start point. See the figure
in step 3 of Tracing Critical Paths Forward in Physical Analyst, on
page 485 for an example of how the critical path is displayed.
March 2014
CHAPTER 10
Inferring High-Level Objects
This chapter contains guidelines on how to structure your code or attach
attributes so that the synthesis tools can automatically infer high-level
objects like RAMs. See the following for more information:
Defining Black Boxes for Synthesis, on page 490
Defining State Machines for Synthesis, on page 500
Implementing High-Reliability Designs, on page 505
Automatic RAM Inference, on page 529
Initializing RAMs, on page 554
Using Implicit Initial Values, on page 558
Inferring Shift Registers, on page 559
Working with LPMs, on page 565
LO
Chapter 10: Inferring High-Level Objects Defining Black Boxes for Synthesis
490 March 2014
Defining Black Boxes for Synthesis
Black boxes are predefined components for which the interface is specified,
but whose internal architectural statements are ignored. They are used as
place holders for IP blocks, legacy designs, or a design under development.
This section discusses the following topics:
Instantiating Black Boxes and I/Os in Verilog, on page 490
Instantiating Black Boxes and I/Os in VHDL, on page 492
Adding Black Box Timing Constraints, on page 494
Adding Other Black Box Attributes, on page 498
For information about using black boxes with the Clock Conversion option, see
Working with Gated Clocks, on page 840.
Instantiating Black Boxes and I/Os in Verilog
Verilog black boxes for macros and I/Os come from two sources: commonly-
used or vendor-specific components that are predefined in Verilog macro
libraries, or black boxes that are defined in another input source like a
schematic. For information about instantiating black boxes in VHDL, see
Instantiating Black Boxes and I/Os in VHDL, on page 492. Additional infor-
mation about black boxes can be found in Working with Gated Clocks, on
page 840, Instantiating CoreGen Cores, on page 1040, and Instantiating
Virtex PCI Cores, on page 1041.
The following process shows you how to instantiate both types as black
boxes. Refer to the installDirectory/examples directory for examples of instantia-
tions of low-level resources.
1. To instantiate a predefined Verilog module as a black box:
Select the library file with the macro you need from the
installDirectory/lib/technology directory. Files are named technology.v.
Most vendor architectures provide macro libraries that predefine the
black boxes for primitives and macros.
Make sure the library macro file is the first file in the source file list
for your project.
Defining Black Boxes for Synthesis Chapter 10: Inferring High-Level Objects
March 2014 491
2. To instantiate a module that has been defined in another input source
as a black box:
Create an empty macro that only contains ports and port directions.
Put the syn_black_box synthesis directive just before the semicolon in
the module declaration.
module myram (out, in, addr, we) /* synthesis syn_black_box */;
output [15:0] out;
input [15:0] in;
input [4:0] addr;
input we;
endmodule
Make an instance of the stub in your design.
Compile the stub along with the module containing the instantiation
of the stub.
To simulate with a Verilog simulator, you must have a functional
description of the black box. To make sure the synthesis software
ignores the functional description and treats it as a black box, use
the translate_off and translate_on constructs. For example:
module adder8(cout, sum, a, b, cin);
// Code that you want to synthesize
/* synthesis translate_off */
// Functional description.
/* synthesis translate_on */
// Other code that you want to synthesize.
endmodule
3. To instantiate a vendor-specific (black box) I/O that has been defined in
another input source:
Create an empty macro that only contains ports and port directions.
Put the syn_black_box synthesis directive just before the semicolon in
the module declaration.
Specify the external pad pin with the black_box_pad_pin directive, as in
this example:
module BBDLHS(D,E,GIN,GOUT,PAD,Q)
/* synthesis syn_black_box black_box_pad_pin="PAD"
Make an instance of the stub in your design.
LO
492 March 2014
Compile the stub along with the module containing the instantiation
of the stub.
4. Add timing constraints and attributes as needed. See Adding Black Box
Timing Constraints, on page 494 and Adding Other Black Box Attributes,
on page 498.
5. After synthesis, merge the black box netlist and the synthesis results file
using the method specified by your vendor.
Instantiating Black Boxes and I/Os in VHDL
VHDL black boxes for macros and I/Os come from two sources: commonly-
used or vendor-specific components that are predefined in VHDL macro
libraries, or black boxes that are defined in another input source like a
schematic. For information about instantiating black boxes in VHDL, see
Instantiating Black Boxes and I/Os in Verilog, on page 490.
The following process shows you how to instantiate both types as black
boxes. Refer to the installDirectory/examples directory for examples of instantia-
tions of low-level resources.
1. To instantiate a predefined VHDL macro (for a component or an I/O),
Select the library file with the macro you need from the
installDirectory/lib/vendor directory. Files are named family.vhd. Most
vendor architectures provide macro libraries that predefine the black
boxes for primitives and macros.
Add the appropriate library and use clauses to the beginning of your
design units that instantiate the macros.
library family ;
use family.components.all;
2. To create a black box for a component from another input source:
Create a component declaration for the black box.
Declare the syn_black_box attribute as a boolean attribute.
Set the attribute to true.
March 2014 493
library synplify;
entity top is
port (clk, rst, en, data: in bit; q: out bit);
end top;
architecture structural of top is
component bbox
port(Q: out bit; D, C, CLR: in bit);
end component;
attribute syn_black_box of bbox: component is true;
...
Instantiate the black box and connect the ports.
begin
my_bbox: bbox port map (
Q => q,
D => data,
C => clk,
CLR => rst);
To simulate with a VHDL simulator, you must have the functional
description of a black box. To make sure the synthesis software
ignores the functional description and treats it as a black box, use
the translate_off and translate_on constructs. For example:
architecture behave of ram4 is
begin
-- synthesis translate_off
stimulus: process (clk, a, b)
-- Functional description
end process;
-- synthesis translate_on
-- Other source code you WANT synthesized
3. To create a vendor-specific (black box) I/O for an I/O defined in another
input source:
Create a component declaration for the I/O.
Declare the black_box_pad_pin attribute as a string attribute.
Set the attribute value on the component to be the external pin name
for the pad.
LO
494 March 2014
library synplify;
...
component mybuf
port(O: out bit; I: in bit);
end component;
attribute black_box_pad_pin of mybuf: component is "I";
Instantiate the pad and connect the signals.
begin
data_pad: mybuf port map (
O => data_core,
I => data);
4. Add timing constraints and attributes. See Adding Black Box Timing
Constraints, on page 494, Using Gated Clocks for Black Boxes, on
page 872, and Adding Other Black Box Attributes, on page 498.
Adding Black Box Timing Constraints
A black box does not provide the software with any information about
internal timing characteristics. You must characterize black box timing
accurately, because it can critically affect the overall timing of the design. To
do this, you add constraints in the source code or in the SCOPE interface.
You attach black box timing constraints to instances that have been defined
as black boxes. There are three black box timing constraints, syn_tpd, syn_tsu,
and syn_tco. There are additional attributes for black box pins and black
boxes with gated clocks; see Adding Other Black Box Attributes, on page 498
and Using Gated Clocks for Black Boxes, on page 872.
Black Box
D
syn_tpd
syn_tsu
syn_tco
Q
clk
March 2014 495
1. Define the instance as a black box, as described in Instantiating Black
Boxes and I/Os in Verilog, on page 490 or Instantiating Black Boxes and
I/Os in VHDL, on page 492.
2. Determine the kind of constraint for the information you want to specify:
3. In VHDL, use the following syntax for the constraints.
Use the predefined attributes package by adding this syntax
library synplify;
In VHDL, you must use the predefined attributes package. For each
directive, there are ten predeclared constraints in the attributes
package, from directive_name1 to directive_name10. If you need more
constraints, declare the additional constraints using integers greater
than 10. For example:
attribute syn_tco11 : string;
attribute syn_tco12 : string;
Define the constraints in either of these ways:
The following table shows the appropriate syntax for att_value. See the
Reference Manual for complete syntax information.
To define ... Use ...
Propagation delay through the black box syn_tpd
Setup delay (relative to the clock) for input pins syn_tsu
Clock-to-output delay through the black box syn_tco
VHDL
syntax
attribute attributeName<n> : "att_value"
Verilog-style
notation
attribute attributeName<n> of bbox_name :
component is "att_value"
LO
496 March 2014
The following is an example of black box attributes, using VHDL
signal notation:
architecture top of top is
component rcf16x4z port(
ad0, ad1, ad2, ad3 : in std_logic;
di0, di1, di2, di3 : in std_logic;
wren, wpe : in std_logic;
tri : in std_logic;
do0, do1, do2 do3 : out std_logic;
end component
attribute syn_tpd1 of rcf16x4z : component is
"ad0,ad1,ad2,ad3 -> do0,do1,do2,do3 = 2.1";
attribute syn_tpd2 of rcf16x4z : component is
"tri -> do0,do1,do2,do3 = 2.0";
attribute syn_tsu1 of rcf16x4z : component is
"ad0,ad1,ad2,ad3 -> ck = 1.2";
attribute syn_tsu2 of rcf16x4z : component is
"wren,wpe,do0,do1,do2,do3 -> ck = 0.0";
4. In Verilog, add the directives as comments, as shown in the following
example. For explanations about the syntax, see the table in the
previous step or the Reference Manual.
module ram32x4 (z, d, addr, we, clk)
/* synthesis syn_black_box
syn_tpd1="addr[3:0]->z[3:0]=8.0"
syn_tsu1="addr[3:0]->clk=2.0"
syn_tsu2="we->clk=3.0" */;
output [3:0[ z;
Attribute Value Syntax
syn_tsu<n> bundle -> [!]clock = value
syn_tco<n> [!]clock -> bundle = value
syn_tpd<n> bundle -> bundle = value
<n> is a numerical suffix.
bundle is a comma-separated list of buses and scalar signals, with no
intervening spaces. For example, A,B,C.
! indicates (optionally) a negative edge for a clock.
value is in ns.
March 2014 497
input [3:0] d;
input [3:0] addr;
input we;
input clk;
endmodule
5. To add black box attributes through the SCOPE interface, do the
following:
Open the SCOPE spreadsheet and select the Attributes panel.
In the Object column, select the name of the black-box module or
component declaration from the pull-down list. Manually prefix the
black box name with v: to apply the constraint to the view.
In the Attribute column, type the name of the timing attribute, followed
by the numerical suffix, as shown in the following table. You cannot
select timing attributes from the pull-down list.
In the Value column, type the appropriate value syntax, as shown in
the table in step 3.
Save the constraint file, and add it to the project.
The resulting constraint file contains syntax like this:
define_attribute v:{blackboxModule} attribute<n> {attributeValue}
6. Synthesize the design, and check black box timing.
LO
498 March 2014
Adding Other Black Box Attributes
Besides black box timing constraints, you can also add other attributes to
define pin types on the black box or define gated clocks. You cannot use the
attributes for all technologies. Check the Reference Manual for details about
which technologies are supported. For information about black boxes with
gated clocks, see Using Gated Clocks for Black Boxes, on page 872.
1. To specify that a clock pin on the black box has access to global clock
routing resources, use syn_isclock.
Depending on the technology, different clock resources are inserted. In
Xilinx, the software inserts BUFG and for Microsemi it inserts CLKBUF.
2. To specify that the software need not insert a pad for a black box pin,
use black_box_pad_pin. Use this for technologies that automatically insert
pad buffers for the I/Os.
3. To define a tristate pin so that you do not get a mixed driver error when
there is another tristate buffer driving the same net, use
black_box_tri_pins.
Pad
Clk
Clk buffer
syn_isclock
black_box_tri_pins
Black Box
black_box_pad_pin
March 2014 499
4. To ensure consistency between synthesized black box netlist names and
the names generated by third party tools or IP cores, use the following
attributes (Xilinx only):
syn_edif_bit_format
syn_edif_scalar_format
LO
Chapter 10: Inferring High-Level Objects Defining State Machines for Synthesis
500 March 2014
Defining State Machines for Synthesis
A finite state machine (FSM) is a piece of hardware that advances from state
to state at a clock edge. The synthesis software recognizes and extracts the
state machines from the HDL source code. For guidelines on setting up the
source code, see the following:
Defining State Machines in Verilog, on page 500
Defining State Machines in VHDL, on page 501
Specifying FSMs with Attributes and Directives, on page 502
For information about the attributes used to define state machines, see
Running the FSM Compiler, on page 606. For information about implementing
safe FSMs, see Specifying Safe FSMs, on page 519.
Defining State Machines in Verilog
The synthesis software recognizes and automatically extracts state machines
from the Verilog source code if you follow the coding guidelines listed below.
The software attaches the syn_state_machine attribute to each extracted FSM.
For alternative ways to define state machines, see Defining State Machines for
Follow these Verilog coding guidelines:
In Verilog, model the state machine with case, casex, or casez statements
in always blocks. Check the current state to advance to the next state
and then set output values. Do not use if statements.
Always use a default assignment as the last assignment in the case
statement, and set the state variable to bx. This is a dont care state-
ment and ensures that the software can remove unnecessary decoding
and gates.
Make sure the state machines have a synchronous or asynchronous
reset to set the hardware to a valid state after power-up, or to reset the
hardware when you are operating.
Defining State Machines for Synthesis Chapter 10: Inferring High-Level Objects
March 2014 501
Specify explicit state values for states with parameter or define state-
ments. This is an example of a parameter statement that sets the current
state to 2h2:
parameter state1 = 2h1, state2 = 2h2;
...
current_state = state2;
This example shows how to set the current state value with `define state-
ments:
define state1 2h1
define state2 2h2
...
current_state = state2;
Make state assignments using parameter with symbolic state names.Use
parameter over `define, because `define is applied globally while parameter
definitions are local. Local definitions make it easier to reuse common
state names in multiple FSM designs, like RESET, IDLE, READY, READ,
WRITE, ERROR, and DONE.
If you use `define to assign the names, you cannot reuse a state name
because it has already been used in the global name space. To reuse the
same names in this scenario, you have to use ùndef and `define state-
ments between modules to redefine the names. This method makes it
difficult to probe the internal values of FSM state buses from a
testbench and compare them to the state names.
Defining State Machines in VHDL
The synthesis software recognizes and automatically extracts state machines
from the VHDL source code if you follow the coding guidelines below. For
alternative ways to define state machines, see Defining State Machines for
The following are VHDL guidelines for coding. The software attaches the
syn_state_machine attribute to each extracted FSM.
Use case statements to check the current state at the clock edge,
advance to the next state, and set output values. You can also use if-then-
else statements, but case statements are preferable.
LO
502 March 2014
If you do not cover all possible cases explicitly, include a when others
assignment as the last assignment of the case statement, and set the
state vector to some valid state.
If you create implicit state machines with multiple WAIT statements, the
software does not recognize them as state machines.
Make sure the state machines have a synchronous or asynchronous
reset to set the hardware to a valid state after power-up, or to reset the
hardware when you are operating.
To choose an encoding style, attach the syn_encoding attribute to the
enumerated type. The software automatically encodes your state
machine with the style you specified.
Specifying FSMs with Attributes and Directives
If your design has state machines, the software can extract them automati-
cally with the FSM Compiler, or you can manually attach attributes to state
registers to define them as state machines. See Optimizing State Machines, on
page 605 for information about automatic FSM extraction, and Defining State
Machines for Synthesis, on page 500 for other ways to specify FSMs.
The following steps show you how to manually attach attributes to define
FSMs for extraction.
1. To determine how state machines are extracted, set attributes in the
source code as shown in the following table:
For information about how to add attributes, see Specifying Attributes
and Directives, on page 169.
To ... Attribute
Specify a state machine for extraction and
optimization
syn_state_machine=1
Prevent state machines from being extracted
and optimized
syn_state_machine=0
Prevent the state machine from being
optimized away
syn_preserve=1
Defining State Machines for Synthesis Chapter 10: Inferring High-Level Objects
March 2014 503
2. To determine the encoding style for the state machine, set the
syn_encoding attribute in the source code or in the SCOPE window. For
VHDL users there are alternative methods, described in the next step.
The FSM Compiler and the FSM Explorer honor the syn_encoding setting.
The different values for this attribute are briefly described here; refer to
the Attributes Reference manual for complete details.
3. If you are using VHDL, you have two choices for defining encoding:
Use syn_encoding as described above, and enable the FSM compiler.
Situation: If ... syn_encoding Value Explanation
Area is important sequential One of the smallest encoding
styles.
Speed is
important
onehot Usually the fastest style and
suited to most FPGA styles.
Recovery from an
invalid state is
important
safe, with another
style. For example:
/* synthesis
syn_encoding =
"safe, onehot" */
Forces the state machine to
reset in certain situations. For
example, if an alpha particle hit
in a hostile operating
environment causes a
spontaneous register change,
you can use safe to reset the
state machine. For further
information, see Specifying Safe
FSMs, on page 519.
There are
<5 states
sequential Default encoding.
A large output
decoder follows
the FSM
sequential | gray Could be faster than onehot,
even though the value must be
decoded to determine the state.
For sequential, more than one bit
can change at a time; for gray,
only one bit changes at a time,
but more than one bit can be
hot.
There are a large
number of flip-
flops
onehot Fastest style, because each state
variable has one bit set, and
only one bit of the state register
changes at a time.
LO
504 March 2014
Use syn_enum_encoding to define the states (sequential, onehot, gray, and
safe) and disable the FSM compiler. If you do not disable the FSM
compiler, the syn_enum_encoding values are not implemented. This is
because the FSM compiler, a mapper operation, overrides
syn_enum_encoding, which is a compiler directive. Use the
syn_enum_encoding method for user-defined FSM encoding. For
example:
attribute syn_enum_encoding of state_type : type is "001 010 101";
Implementing High-Reliability Designs Chapter 10: Inferring High-Level Objects
March 2014 505
Implementing High-Reliability Designs
As geometries shrink, the possibility of soft errors or radiation effects
increase. This affects industries like aerospace most immediately, but many
other applications increasingly require high reliability and built-in fault toler-
ance.
The synthesis software provides different ways to implement high reliability,
and the following describe methods to implement high reliability in your
designs:
Implementing Distributed TMR, on page 506
Implementing Duplication with Comparison (DWC), on page 510
Using TMR or ECC for RAMs, on page 516
Specifying Safe FSMs, on page 519
Error Monitoring for High Reliability Features, on page 522
For Microsemi designs, see Working with Radhard Designs, on page 1028 and
Specifying syn_radhardlevel in the Source Code, on page 1029 for information
about implementing high reliability features.
About Triple Modular Redundancy (TMR)
One of the ways to ensure high reliability is to use triple modular redundancy
or TMR. TMR is a method of ensuring fault tolerance by automatically adding
redundancy to provide immunity for single event transient (SET) and single
event upset (SEU) faults.
A SET fault is a temporary change in output of combinational logic
caused by ions or electro-magnetic radiation. This fault usually corrects
itself within several nanoseconds, but can become more problematic at
higher operating frequencies or if the fault propagates through the logic.
A SEU fault is a change of state caused by ions or electro-magnetic
radiation that affects sequential elements.
With TMR, three redundant systems execute a process and a voting system
produces a single output that reflects the majority vote from the three
systems. If any one system fails, the voter chooses the majority from the other
two systems, so that the system avoids failure due to SET and SEU faults.
The synthesis tools use attributes to implement TMR.
LO
Chapter 10: Inferring High-Level Objects Implementing High-Reliability Designs
506 March 2014
TMR can be local, distributed, or global, and the following table shows
support for the different kinds of TMR in the synthesis tools. The synthesis
tools also support Duplication with Comparison (DWC).
Implementing Distributed TMR
Distributed TMR protects against SETs in combinatorial logic. It triplicates
the sequential logic and the combinatorial logic, including the voters. It is
primarily aimed at commercial/military-aerospace implementations,
especially those that require detailed control over the area, speed, or
reliability of specific blocks.
The following procedure specifies how to implement distributed TMR.
1. Select a supported technology family in the Synplify Premier tool.
See Vendor Support for Distributed TMR and DWC, on page 511 for a list.
2. Enable the Enhanced Optimization option.
3. From the Attributes tab of the SCOPE editor, specify the syn_radhardlevel
attribute with a value of distributed_tmr for the modules you want to
triplicate.
For the syn_radhardlevel attribute syntax, see syn_radhardlevel, on
page 342 in the Reference Manual.
You must set the attribute on views or modules. You can specify hierar-
chical modules that require increased reliability to prevent SEU and SET
faults. If the specified module contains an FSM, TMR is also applied to
the FSM. In this case it could override a syn_fsm_correction directive speci-
fied for the FSM. Safe correcting FSMs are converted to safe detecting
Local TMR Microsemi
Altera/Xilinx
RAMs
Working with Radhard Designs, on page 1028
Specifying Local TMR for RAMs, on page 516
Distributed TMR Altera, Xilinx,
Lattice
Implementing Distributed TMR, on page 506
DWC Altera, Xilinx Implementing Duplication with Comparison
(DWC), on page 510
Global TMR Microsemi Specifying syn_radhardlevel in the Source
Code, on page 1029
March 2014 507
FSMs. For a list of restrictions to using this attribute, see Limitations, on
page 507.
The voter system to resolve the three systems can be implemented in
different ways. See Voter Insertion Examples, on page 508 for details.
4. Add redundancy for I/Os connected to distributed TMR modules.
See Using Redundancy for I/O Connectors, on page 513 for details.
Note: You can optionally add I/O redundancy to TMR modules and only
when it is required.
5. Provide error monitoring.
See Error Monitoring for High Reliability Features, on page 522 for details.
Note: You can optionally specify the error monitoring Tcl commands for
distributed TMR.
6. Run synthesis.
The entire module with the specified attribute is triplicated. In addition
to the inserted TMR elements in the netlist, you can view them in the
HDL Analyst tool.
Limitations
Distributed TMR support includes the following limitations:
Cross-boundary optimizations, such as retiming, packing, or constant
propagation are not allowed across a distributed TMR module boundary.
TMR is always applied to an FSM in the parent module when it is tagged
for distributed TMR. Safe correcting FSM is converted to safe detecting.
Distributed TMR does not support the following:
Module with tristates
Module that includes an instantiated module
Module that includes a BUFG for Xilinx devices
Top-level module
Conflicting syn_ramstyle values of ecc or tmr
LO
508 March 2014
Voter Insertion Examples
The tool implements voter logic as synchronous voters (in the case of loops)
and asynchronous or output voters (to resolve TMR logic). You can control
voter insertion for synchronous voters with the syn_vote_loops attribute. The
following examples illustrate different cases of voter insertion:
Example 1: Standard Distributed TMR, on page 508
Example 2: Distributed TMR with Cyclic Module, on page 508
Example 3: Distributed TMR with Multiple Modules, on page 509
Example 1: Standard Distributed TMR
This example has three separate instances created for the specified module.
The inputs to the original module are connected to all three instances. The
outputs are fed to a majority voter, which produces a single output connected
to the fanout of the original module.
Example 2: Distributed TMR with Cyclic Module
This example has a loop in the specified module. To restore the state after an
SEU fault, the loop in each of the three instances must insert a voter. Any of
the TMR module outputs can be the final output.
March 2014 509
If you used a mitigation mechanism to avoid the accumulation of faults in a
sequential feedback path and do not want the overhead of voter logic, you can
turn off voter insertion by setting the syn_vote_loops attribute to false. For
details, see syn_vote_loops, on page 495 in the Reference Manual.
Example 3: Distributed TMR with Multiple Modules
This example shows a case where multiple hierarchical modules have distrib-
uted TMR applied. The modules are triplicated in each path with three voters,
until the last module is reached. The last module converges the three paths
to one, and then drives the non-TMR module.
LO
510 March 2014
Implementing Duplication with Comparison (DWC)
Duplication with Comparison (DWC) is a mitigation methodology that
protects against SEU failures in a design. It duplicates modules and
compares the outputs of this circuit to determine if an error occurs. Signal
nets are also duplicated to be the same as the original connectivity. Since this
option limits the redundancy performed, it has less impact on area and QoR
than distributed TMR.
The following procedure specifies how to implement DWC.
3. From the Attributes tab of the SCOPE editor, specify the syn_radhardlevel
attribute with a value of duplicate_with_compare for the modules you want
to duplicate.
For the syn_radhardlevel attribute syntax, see syn_radhardlevel, on
You must set the attribute on views or modules. You can specify hierar-
chical modules that require increased reliability to prevent SEU and SET
March 2014 511
faults. You cannot apply this attribute on the top-level module or
globally.
4. Add redundancy for I/Os connected to distributed DWC modules.
See Using Redundancy for I/O Connectors, on page 513 for details.
Note: You can optionally add I/O redundancy to DWC modules and only
when it is required.
Note: You must specify the error monitoring Tcl commands for DWC.
Otherwise, the mapper generates an error message.
6. Run synthesis.
The modules with the specified attribute are duplicated. In addition to
the inserted DWC elements in the netlist, you can view them in the HDL
Analyst tool.
Vendor Support for Distributed TMR and DWC
The following technology families support the specification of distributed TMR
and DWC at the module level:
DWC Examples
The tool implements DWC with comparator logic (XOR/OR) that is connected
to the error monitor port. The following examples illustrate different cases of
DWC:
Example 1: DWC with Single Module, on page 512
Example 2: DWC with Multiple Modules, on page 512
Altera Arria V, Cyclone III, Cyclone IV, Cyclone V, Stratix III, Stratix IV,
Stratix V
Xilinx Artix-7, Kintex-7, and Virtex families
Lattice
(Distributed
TMR only)
Lattice ECP3, Lattice MachXO2
LO
512 March 2014
Example 1: DWC with Single Module
This example has two separate instances created for the specified module.
The outputs are fed to comparator logic that is connected to the error
monitoring port (ERROR_FLAG). Output from the redundant copy is
connected to the original output OUT.
Example 2: DWC with Multiple Modules
This example shows a case where multiple hierarchical modules have DWC
applied. The modules are duplicated and their outputs are fed to comparator
logic (XOR/OR) that connects to the corresponding error monitoring ports,
respectively (ERROR_FLAG_A and (ERROR_FLAG_B). Outputs for the redun-
dant copies of module A are connected to the corresponding inputs of the
redundant copies of module B. Output from the redundant copy of module B
is connected to the original output OUT.
March 2014 513
Using Redundancy for I/O Connectors
I/O connectors that interface to modules with distributed TMR or DWC allow
you to access the signals within its boundaries. The synthesis software imple-
ments connections to copies of modules that have been specified for distrib-
uted TMR or DWC and ensures that their inputs and outputs are not a
single-point of failure.
The following procedure specifies how to implement redundancy for I/O
connectors.
3. Instantiate the I/O connector modules in the RTL that are to be
connected to these I/O connectors.
4. From the Attributes tab of the SCOPE editor, specify the
syn_highrel_ioconnector attribute with a value of 1 along with connections
to I/Os on one side and the DTMR/DWC on the other side.
LO
514 March 2014
The following logic must be included in the module definition to qualify
as an I/O connector:
DWC ip connector: AND/OR logic
DWC op connector: feedthrough connection
DTMR ip connector: any majority voter logic
DTMR op connector: feedthrough connection
For the syn_highrel_ioconnector attribute syntax, see syn_highrel_ioconnector,
I/O Connector Redundancy Examples
Create redundant ports and instantiate connector objects with the attribute
syn_highrel_ioconnector for DWC or DTMR modules. The following examples
illustrate cases for I/O connector redundancy:
Example 1: I/O Connectors with DWC, on page 514
Example 2: I/O Connectors with DTMR, on page 515
Example 1: I/O Connectors with DWC
This example creates redundant ports and instantiates connector objects
with the syn_highrel_ioconnector attribute. The following are specified:
Valid input connector for 2 inputs and 1 output with AND/OR logic.
Valid output connector for 1 input and 2 outputs with feedthrough logic.
Use the "syn_radhardlevel=duplicate_with_compare" attribute with the module for
which DWC is applied and that is connected to error monitoring. Two copies
of the modules (A0, A1) with their outputs fed to comparator logic (XOR/OR)
are connected to the error monitoring port (ERROR_FLAG).
The inputs (IN0, IN1) and outputs (OUT0, OUT1) are connected to the corre-
sponding redundant copies (A0, A1) with their hierarchies dissolved.
March 2014 515
Example 2: I/O Connectors with DTMR
This example creates redundant ports and instantiates connector objects
with the syn_highrel_ioconnector attribute. The following are specified:
Valid input connector for 3 inputs and 1 output with voter logic.
Valid output connector for 1 input and 3 outputs with feedthrough logic.
Use the "syn_radhardlevel=distributed_tmr" attribute with the module for which
distributed TMR is applied. The inputs (IN0, IN1, IN2) are fed to the corre-
sponding redundant copies (A0, A1, A2) and their outputs are connected to
the outputs (OUT0, OUT1, OUT2) through individual voter logic.
LO
516 March 2014
Using TMR or ECC for RAMs
You can specify fault tolerance for Altera and Xilinx RAM architectures, using
local TMR or Error Correction Code (ECC). The details are described here:
Specifying Local TMR for RAMs
Specifying ECC for RAMs
Specifying Local TMR for RAMs
For some Altera and Xilinx architectures, you can specify local TMR for RAM
to increase fault tolerance. Local TMR protects sequential elements like RAMs
from SEUs by tripling and then voting on registers.
Do the following to implement local TMR for a RAM:
1. Select a supported device in the Synplify Premier tool.
See Vendor Support for Local TMR RAMs, on page 517 for a list.
3. Specify the syn_ramstyle attribute with the tmr value.
March 2014 517
You can specify the tmr value in combination with other syn_ramstyle
values, like block_ram. For the attribute syntax, see syn_ramstyle, on
local TMR RAM.
5. Run synthesis.
The software implements the inferred RAM primitive in triplicate for the
design.
6. Check the log file for the TMR RAM.
Vendor Support for Local TMR RAMs
The following technology families support local TMR for RAMs:
Specifying ECC for RAMs
Using Error Correction Code (ECC) RAM lets you detect and correct single-bit
errors on RAM. Some Altera and Xilinx architectures offer ECC memories
that automatically detect and correct single-bit errors. The synthesis software
can infer and connect these vendor-specific memories.
The following procedure shows you how to ensure high reliability by speci-
fying ECC RAMs. You can also combine the error-mitigating ECC RAMs with
TMR to prevent false data from being captured by the memory and propa-
gated to other parts of the circuitry.
1. Select a supported device in the Synplify Premier tool.
For a list of supported technologies, see Vendor Support for ECC for
RAMs, on page 518. Note that some Xilinx ECC primitives are not
supported.
Altera Arria V, Cyclone III, Cyclone IV, Cyclone V, Stratix III, Stratix IV, Stratix V
Xilinx Artix-7, Kintex-7, and Virtex families
LO
518 March 2014
3. Specify the syn_ramstyle attribute with a value of ecc.
If the ecc value is used in combination with other syn_ramstyle values like
select_ram, it has a higher priority. This means that if ecc and mlab are
both specified for an Altera device, mlab is ignored because ecc has
higher priority. For more about the attribute syntax, see syn_ramstyle,
4. For Altera RAM modes that do not support an ECC implementation,
either specify the syn_ramstyle attribute with the ecc and no_rw_check
values, or disable read-write check for the RAM with the set_option
-RWCheckOnRam 0 command.
ECC RAM.
6. Run synthesis.
The software infers the built-in ECC RAM primitive in the design. The
synthesis tool creates the ECC RAM block primitive and its associated
glue logic (for example, address decoders/encoders or comparators),
while keeping the RAM interface the same.
7. Check the log file for the ECC RAM.
Vendor Support for ECC for RAMs
The following technology families support the specification of TMR for RAMs:
Altera Stratix V
Xilinx Artix-7, Kintex-7, Virtex-5, Virtex-6, and Virtex-7
The following ECC technology primitives are not supported:
Byte-wide write enable RAM
RAM with synchronous set/reset signal
RAM with output register clock enable
Explicitly instantiated block RAM with parity pins for wider configuration
March 2014 519
Specifying Safe FSMs
Typically, unspecified or unreachable FSM states are optimized away during
synthesis, so if an SEU causes a bit to be inverted, the FSM can be put into
an undefined, invalid state, and lock up the circuit. An SEU fault is a change
of state caused by ions or electro-magnetic radiation that affects sequential
elements. The basic principle of a safe FSM is to prevent the state machine
from getting stuck in an unknown state because of an SEU.
Safe FSMs are primarily required by commercial or military-aerospace users,
especially those who want to ensure that their FSMs are tolerant of single
event upset (SEU) faults and continue to function correctly.
The following procedures describe ways to ensure high reliability and fault
tolerance for FSMs:
Implementing Safe Case FSMs, on page 519
Implementing FSMs with Hamming 3 Encoding, on page 521
Vendor Support for Safe FSMs
The following technology families support the specification of safe case and
Hamming Distance 3 for FSMs:
Implementing Safe Case FSMs
To implement safe case FSMs, follow this procedure:
1. Select a supported device in the Synplify Pro or Synplify Premier
synthesis tools.
See Vendor Support for Safe FSMs, on page 519 for a list.
Altera Cyclone V, Cyclone IV, Stratix V
Xilinx Virtex-7, Virtex-6, Virtex-5
Lattice ECP3, MachXO2
Microsemi SmartFusion/2, RT ProASIC3, ProASIC3/3E/3L, IGLOO/+/E/2,
54SX, 54SX-A, eX, 40MX, Axcelerator
LO
520 March 2014
2. To globally implement safe case FSMs, go to the Implementation Options->
High Reliability tab, and enable the Preserve and Decode Unreachable States
(FSM, Counters, Sequential Logic) option.
The high reliability safe case option turns off sequential optimizations
that would otherwise optimize away some FSM states.
3. To apply safe case on an individual module or architecture, set the
syn_safe_case directive on a module.
This is a Verilog example: module /* syn_safe_case =1*/
For details about this directive, see syn_safe_case, on page 405 in the
Reference Manual.
4. To choose an encoding style that can be implemented when building the
recovery logic for the FSM, use the syn_encoding attribute. The software
honors the values you specify for the encoding style. You can apply the
attribute globally on a module or architecture in the Verilog/VHDL
source code, as well as, the FDC constraint file. For example:
module /*synthesis syn_encoding="encodingStyles";*/
attribute syn_encoding of architecture : signal is
"encodingStyles";
You can also define a SCOPE collection in the constraint file, then apply
the attribute to the collection:
define_scope_collection sm {find -hier -inst * -filter
inst_of==statemachine}
define_attribute {$sm} {syn_encoding} {encodingStyles}
For details about this attribute, see syn_encoding, on page 159.
March 2014 521
You must enable the FSM Compiler option to ensure that the syn_encoding
attribute takes affect. This overrides the default FSM compiler encoding
for the state machine.
safe FSM.
Implementing FSMs with Hamming 3 Encoding
Synplify Premier
Generating fault-tolerant FSMs with Hamming-3 encoding is an effective
error mitigation technique. Hamming 3 encoding detects and corrects single-
bit errors in the FSM state registers with a Hamming distance of 3, and
ensures that the FSM continues to operate correctly after the error is
corrected.
Parity bits are added to the FSM state register to generate Hamming distance
3 encoding. Error correction logic is used to automatically detect and correct
an SEU in the register bits.
To provide immunity against single-bit errors and implement FSMs with
Hamming 3 encoding, do the following:
1. Select a supported device in the Synplify Premier tools.
See Vendor Support for Safe FSMs, on page 519 for a list of supported
devices.
2. To enable Hamming 3 encoding globally, go to the Implementation Options->
High Reliability tab, and enable the FSM Error Correction Using Hamming
Distance 3 option.
LO
522 March 2014
3. To apply Hamming 3 encoding to an individual FSM, use the
syn_fsm_correction directive.
For a description of this directive, see syn_fsm_correction, on page 190
When Hamming distance 3 is applied to an FSM that is inside a module to
which distributed TMR is applied, then TMR takes precedence and the FSM is
triplicated along with the rest of the module and the Hamming distance 3
specification ignored. This also generates a warning message in the log file.
Error Monitoring for High Reliability Features
The software can inform you when it detects that an error has occurred.
Based on the type of error, you may want to take corrective action (such as,
reset the design or enable/disable scrubbing). Error monitoring can occur for
the following:
Modules specified for distributed TMR
Modules specified for distributed DWC
RTL RAM specified for ECC; provide error status bit
Local RAM TMR
Finite state machines with unreachable states
I/O connectors with distributed TMR or DWC
Error Monitoring Procedure
Error monitoring requires that you do the following:
March 2014 523
1. As a prerequisite, a top-level port or user instantiated error monitoring
IP (EMIP) must be provided in the RTL. You must specify syn_keep on the
signal/wire feeding into the top-level port or EMIP port.
2. Specify the connectivity between the module/instance being monitored
for the error with the error monitoring IP port or top-level port for the
error monitoring module. You must define the control signals of the
source and elements for error monitoring with the following Tcl
commands:
syn_create_err_net
syn_connect
Add these commands in the constraint file. For a descriptions of the
syntax, see syn_connect, on page 154 and syn_create_err_net, on
page 155.
Here are some examples of specifying these commands:
# Unregistered error flag connected to top-level error port
syn_create_err_net {-name {error_flag} -inst {i:inst_A}}
syn_connect {-from {n:error_flag} -to {p:emp}}
# Error flag with 4 stage pipeline registers with asynchronous
reset connected to EMIP port
syn_create_err_net {-name {error_flag} -inst {i:inst_A}
-err_pipe_num {4} -err_clk {n:inst_A.clk} -err_reset
{n:inst_A.rst} -err_synch {false}}
syn_connect {-from {n:error_flag} -to {t:inst_emip.emp}}
The usage model for setting up the error monitoring varies slightly depending
on the type of high reliability feature you are implementing: DWC, DTMR, or
ECC.
Error Monitoring Examples
Error monitoring is applied to an instance. You can have a 1-bit error port for
each instance. To do this, use the following Tcl commands:
syn_create_err_net Creates logic (XOR/OR) that compares the outputs
for the selected module and connects it to the source of the new net that
you specified. You can also specify pipeline registers along with clock
LO
524 March 2014
and other control signals to improve timing through the comparator
circuitry.
syn_connect Connects the new net that you specified to an existing net,
top-level port, or input port of the instantiated Error Monitoring IP
(EMIP).
See the following examples:
Example 1: Error Monitoring with DWC, on page 524
Example 2: Error Monitoring with DTMR, on page 524
Example 3: Error Monitoring with ECC/TMR RAM, on page 525
Example 4: Error Monitoring with FSM, on page 527
Example 1: Error Monitoring with DWC
To set up the error monitoring for a DWC module, specify the following:
1. On the module:
define_attribute {v:A} syn_radhardlevel {duplicate_with_compare}
2. On the instance:
syn_create_err_net name {error_flag} inst {i:A_1}
-err_pipe_num {1}
-err_clk {n: hierarchical path to the input pin of clk}
-err_reset {n: hierarchical path to the input pin of reset}
-err_set {n: hierarchical path to the input pin of set}
-err_enable {n: hierarchical path to the input pin of enable}
-err_synch {false}
syn_connect -from {n:error_flag} -to {t:EMIP.err_port}
For an example, see Example 1: DWC with Single Module, on page 512.
Example 2: Error Monitoring with DTMR
To set up the error monitoring for a DTMR module and provide access to
error bits, specify the following:
1. On the module:
define_attribute {v:A} syn_radhardlevel {distributed_tmr}
March 2014 525
2. On the instance:
syn_create_err_net name {error_flag} inst {i:A_}
-err_pipe_num {1}
-err_synch {false}
In this example, module A is specified for distributed TMR and error
monitoring. Three copies of the module (A0, A1, A2) are created, for which
their outputs are fed through the majority voter logic. The outputs of A0, A1,
and A2 are connected to the comparator logic (XOR/OR) and the error flag is
connected to the EMP port.
Example 3: Error Monitoring with ECC/TMR RAM
To set up the error monitoring for a DTMR module and provide access to
error bits, specify the following:
1. On the instance:
LO
526 March 2014
define_attribute {i:RAM} syn_ramstyle {ecc|tmr}
2. On the instance:
syn_create_err_net name {error_flag} inst {i:RAM}
-err_pipe_num {1}
-err_synch {false}
In this example, the "syn_ramstyle=ecc" attribute is applied globally to the RAM,
for which error monitoring is implemented. The built-in ECC is inferred for
the block RAM. Error bits are ORed and the error flag is connected to the
EMP port. For
Altera ECCSTATUS
Xilinx SBITERR and DBITERR
March 2014 527
In this example, the "syn_ramstyle=tmr" attribute is applied globally to the RAM,
for which error monitoring is implemented. Three copies of the inferred block
RAM primitive are created with outputs voted through majority voter logic.
The outputs (TMR0, TMR1, TMR2) are compared with (XOR/OR) logic to the
error flag connected to the EMP port.
Example 4: Error Monitoring with FSM
To set up the error monitoring for an FSM and provide access to error bits,
specify the following:
1. Enable Preserve and Decode Unreachable States on the High Reliability tab of
the Implementation Options panel for the state machine.
2. On the instance:
syn_create_err_net {name {error_flag} inst {i:state[1:3]}}
syn_connect -from {{n:error_flag} -to {t:EMIP.err_port}}
In this example, the Preserve and Decode Unreachable States option is enabled on
the High Reliability tab of the Implementation Options panel for the compiler to
implement recovery logic by inferring the stateerrordetect IP. The Tcl commands
connect the output of this IP to the EMP port for error monitoring of the FSM
to occur.
LO
528 March 2014
Automatic RAM Inference Chapter 10: Inferring High-Level Objects
March 2014 529
Automatic RAM Inference
Instead of instantiating synchronous RAMs, you can let the synthesis tools
automatically infer them directly from the HDL source code and map them to
the appropriate technology-specific RAM resources on the FPGA. This
approach lets you maintain portability.
Here are some of the advantages offered by the inference approach:
The tool automatically infers the RAMs from the HDL code, which is
technology-independent. This means that the design is portable from
one technology to another without rework.
RAM inference is the best method for prototyping.
The tool automatically adds the extra glue logic needed to ensure that
the logic is correct.
The software automatically runs timing-driven synthesis for inferred
RAMs.
For further details about RAM inference, see:
Inferring Block RAM, on page 533
Inferring LUTRAMs, on page 538
Inferring RAM with Control Signals, on page 540
Distributed RAM Inference, on page 542
Inferring Asymmetric RAM, on page 546
Inferring Asymmetric RAM as a Black Box Model, on page 546
Inferring Byte-Enable RAM, on page 552
Inferring Byte-Wide Write Enable RAM, on page 553
Block RAM
The synthesis software can implement the block RAM it infers using different
types of block RAM and different block RAM modes.
LO
Chapter 10: Inferring High-Level Objects Automatic RAM Inference
530 March 2014
Types of Block RAM
The synthesis software can infer different kinds of block RAM, according to
how the code is set up. For details about block RAM inference, see Inferring
Block RAM, on page 533 and RAM Attributes, on page 531. For inference
examples, and see Block RAM Examples, on page 646.
The synthesis tool can infer the following kinds of block RAM:
Single-port RAM
Dual-port RAM
Based on how the read and write ports are used, dual-port RAM can be
further classified as follows:
Simple dual-port
Dual-port
True dual-port
Supported Block RAM Modes
Block RAM supports three operating modes, which determine the output of
the RAM when write enable is active. The synthesis tools infer the mode from
the RTL you provide. It is best to explicitly describe the RAM behavior in the
code, so as to correctly infer the operating mode you want. Refer to the
examples for recommended coding styles.
The block RAM operating modes are described in the following table:
Mode When write enable (WE) is active ...
WRITE_FIRST This is a transparent mode, and the input data is simultaneously
written into memory and stored in the RAM data output (DO). DO
uses the value of the RAM data input (DI). See WRITE_FIRST Mode
Example, on page 646 for an example.
READ_FIRST This mode is read before write. The data previously stored at the
write address appears at the RAM data output (DO) first, and then
the RAM input data is stored in memory. DO uses the value of the
memory content. See READ_FIRST Mode Example, on page 648 for
an example.
NO_CHANGE RAM data output (DO) remains the same during a write operation,
with DO containing the last read data. See NO_CHANGE Mode
Example, on page 649 for an example.
March 2014 531
RAM Attributes
In addition to the automatic inference by the tool, you can specify RAM infer-
ence with the syn_ramstyle and syn_rw_conflict_logic attributes. The syn_ramstyle
attribute explicitly specifies the kind of RAM you want, while the
syn_rw_conflict_logic attribute specifies that you want to infer a RAM, but leave
it to the synthesis tools to select the kind of RAM, as appropriate.
Attribute-Based Inference of Block RAM
For block RAM, the syn_ramstyle attribute has a number of valid values, all of
which are extensively described in the documentation. This section confines
itself to the following values, which are most relevant to the discussion:
If you specify the syn_rw_conflict_logic attribute, the synthesis tools can infer
block RAM, depending on the design. If the tool does infer block RAM, it does
not insert bypass logic around the block RAM to account for read-write
conflicts and prevent simulation mismatches. In this way its functionality is
the same as syn_ramstyle with no_rw_check, which does not insert bypass logic
either.
Specifying the Attributes
You set the attribute in the HDL source code, through the SCOPE interface or
in an FPGA constraint file.
syn_ramstyle Value Description
block_ram Enforces the inference and implementation of a technology-
specific RAM.
registers Prevents inference of a RAM, and maps the RAM to flip-flops
and logic.
no_rw_check Does not create overhead logic to account for read-write
conflicts.
LO
532 March 2014
HDL Source Code
Set the attribute on the Verilog register or VHDL signal that holds the output
values of the RAM. The following syntax shows how to specify the attribute in
Verilog and VHDL code:
SCOPE
For the syn_ramstyle attribute, set the attribute on the RAM register memory
signal, mem, as shown below. For the syn_rw_conflict_logic attribute, set it on
the instance or set it globally. The attributes are written out to a constraints
file using the syntax described in the next section.
Constraints File
In the fdc Tcl constraints file written out from the SCOPE interface, the
syn_ramstyle attribute is attached to the register mem signal of the RAM, and
the syn_rw_conflict_logic attribute is attached to the view, as shown below:
define_attribute {i:mem[7:0]} {syn_ramstyle} {block_ram}
define_attribute {v:mem[0:7]} syn_rw_conflict_logic {0}
For the syn_rw_conflict_logic attribute, you can also specify it globally, as well as
on individual modules and instances:
define_global_attribute syn_rw_conflict_logic {0}
Verilog reg [7:0] ram_dout [127:0]
/*synthesis syn_ramstyle = "block_ram"*/;
reg [d_width-1:0] mem [mem_depth-1:0]
/*synthesis syn_rw_conflict_logic = 0*/;
VHDL attribute syn_ramstyle of ram_dout : signal is "block_ram";
March 2014 533
Inferring Block RAM
Based on the design and how you code it, the tool can infer the following
kinds of block RAM: single-port, simple dual-port, dual-port, and true dual-
port. The details about RAM inference and setup guidelines are described
here:
Setting up the RTL and Inferring Block RAM, on page 533
Simple Dual-Port Block RAM Inference, on page 535
Dual-Port RAM Inference, on page 537
True Dual-Port RAM Inference, on page 537
Setting up the RTL and Inferring Block RAM
To ensure that the tool infers the kind of block RAM you want, do the
following:
1. Set up the RAM HDL code in accordance with the following guidelines:
The RAM must be synchronous. It must not have any asynchronous
control signals connected. The synthesis tools do not infer
asynchronous block RAM.
You must register either the read address or the output.
The RAMs must not be too small, as the tool does not infer block RAM
for small-sized RAMs. The size threshold varies with the target
technology.
2. Set up the clocks and read and write ports to infer the kind of RAM you
want. The following table summarizes how to set up the RAM in the RTL:
RAM Clock Read Ports Write Ports
Single-port Single clock One; same as write One; same as read
See Dual-Port RAM Inference, on page 537 and True Dual-Port RAM Inference,
on page 537 for additional information.
LO
534 March 2014
For illustrative code examples, see the single-port and dual-port
examples listed in Block RAM Examples, on page 646.
3. If needed, guide automatic inference with the syn_ramstyle attribute:
To force the inference of block RAM, specify syn_ramstyle=blockram.
To prevent a block RAM from being inferred or if your resources are
limited, use syn_ramstyle=registers.
If you know your design does not read and write to the same address
simultaneously, specify syn_ramstyle=no_rw_check to ensure that the
synthesis tool does not unnecessarily create bypass logic for resolving
conflicts.
The tool first compiles the design and infers the RAMs, which it repre-
sents as abstract technology-independent primitives like RAM1 and
RAM2. You can view these RAMs in the RTL view, which is a graphic,
technology-independent representation of your design after compilation:
Simple dual-
port
Single or dual
clock
One dedicated read One dedicated write
Dual-port Single or dual
clock
Two independent
reads
One dedicated write
True dual-port Single or dual
clock
Two independent
reads
Two independent
writes
RAM Clock Read Ports Write Ports
See Dual-Port RAM Inference, on page 537 and True Dual-Port RAM Inference,
March 2014 535
It is important that the compiler first infers the RAM, because the tool
only maps the inferred RAM primitives to technology-specific block RAM.
Any RAM that is not inferred is mapped to registers. You can view the
mapped RAMs in the Technology view, which is a graphic representation
of your design after synthesis, and shows the design mapped to
technology-specific resources.
Simple Dual-Port Block RAM Inference
Simple dual-port RAMs (SDP) are block RAMs with one port dedicated to read
operations and one port dedicated to write operations. SDP RAMs offer the
unique advantage of combining ports and using them to pack double the data
width and address width.
The synthesis tools map SDP RAMs to RAM primitives in the architecture. A
unique set of addresses, clocks, and enable signals are used for each port.
The synthesis tool might also set the RAM_MODE property on the RAM to
indicate the RAM mode.
The inference of simple dual-port RAM is dependent on the size of the
address and data. The RAM must follow the coding guidelines listed below to
be inferred.
The read and write addresses must be different
The read and write clocks can be different
The enable signals can be different
Here is an example where the tool infers SDP RAM:
module Read_First_RAM (
read_clk,
read_address,
data_in,
write_clk,
rd_en,
wr_en,
reg_en,
write_address,
data_out );
LO
536 March 2014
parameter address_width = 8;
parameter data_width = 32;
parameter depth = 256;
input read_clk, write_clk;
input rd_en;
input wr_en;
input reg_en;
input [address_width-1:0] read_address, write_address;
input [data_width-1:0] data_in;
output [data_width-1:0] data_out;
//wire [data_width-1:0] data_out;
reg [data_width-1:0] mem [depth -1 : 0]/* synthesis
syn_ramstyle="no_rw_check"
*/;
reg [data_width-1:0] data_out;
always @(posedge write_clk)
if(wr_en)
mem[write_address] <= data_in;
always @( posedge read_clk)
if(rd_en)
data_out <= mem[read_address];
endmodule
March 2014 537
Dual-Port RAM Inference
Dual-port RAM is configured to have read and/or write operations from both
ports of the RAM. One such configuration is a RAM with one port for both
read and write operations and another dedicated read-only port. A unique set
of addresses, clocks, and enable signals are used for each port. The synthesis
tool sets properties on the RAM to indicate the RAM mode.
To infer dual-port block RAM, the RAM must follow the coding rules
described below.
The read and write addresses must be different
The read and write clocks can be different
The enable signals can be different
True Dual-Port RAM Inference
True dual-port RAMs (TDP) are block RAMs with two write ports and two read
ports. The compiler extracts a RAM2 primitive for RAMs with two write ports
or two read ports and the tool maps this primitive to TDP RAM. The ports
operate independently, with different clocks, addresses and enables.
The synthesis tool also sets the RAM_MODE property on the RAM to indicate
the RAM mode.
The compiler infers TDP block RAM based on the write processes. The imple-
mentation depends on whether the write enables use one process or multiple
processes:
When all the writes are made in one process, there are no address
conflicts, and the compiler generates an nram that is later mapped to
either true dual-port block RAM. The following coding results in an nram
with two write ports, one with write address waddr0 and the other with
write address waddr1:
begin
if(we1) mem[waddr0] <= data1;
end
When the writes are made in multiple processes, the software does not
infer a multiport RAM unless you explicitly specify the syn_ramstyle attri-
bute with a value that indicates the kind of RAM to implement, or with
LO
538 March 2014
the no_rw_check value. If the attribute is not specified as such, the
software does not infer an nram, but infers a RAM with multiple write
ports. You get a warning about simulation mismatches when the two
addresses are the same.
In the following case, the compiler infers an nram with two write ports
because the syn_ramstyle attribute is specified. The writes associated with
waddr0 and waddr1 are we1 and we2, respectively.
reg [1:0] mem [7:0] /* synthesis syn_ramstyle="no_rw_check" */ ;
always @(posedge clk1)
begin
end
begin
end
Inferring LUTRAMs
Altera Technologies
The Altera technologies have LUTRAM memory components. MLAB (Memory
LAB) resources are configured as LUTRAM. MLABs can be configured as
single-port RAM or ROM, or simple dual-port RAM. LUTRAM writes occur on
the falling edge of the clock and can be configured to have synchronous or
asynchronous read.
The following procedure shows you how to set up the synthesis tool to map
memory to MLABs and LUTRAMs. Note that you cannot currently map to a
LUTRAM ROM, nor can you initialize asynchronous memory.
1. Start with a Stratix III design.
2. Enable the Clearbox flow option.
If this option is not enabled, the memories are mapped to ALTSYNCRAM
or ALTDPRAM instead of LUTRAM.
3. Set the syn_ramstyle attribute to MLAB.
March 2014 539
This automatically maps the RAM to MLAB resources, which can be
configured as LUTRAMs. If you do not want to infer LUTRAM, set
syn_ramstyle to registers.
For Verilog code examples that implement LUTRAM, see LUTRAM
Examples, on page 659 in the Reference Manual.
4. Synthesize your design.
The software maps asynchronous RAMs to LUTRAM, and reports
resource utilization in the log file, like this example:
Memory ALUTs: 10 (0% of 19000)
The following shows how the software maps an SDPRAM with registered
output and asynchronous read to a simple dual-port RAM in the RTL view:
LO
540 March 2014
The following shows how the same memory is mapped in the Technology view
to a stratixiii_mlab_cell LUTRAM component:
Inferring RAM with Control Signals
Altera Technologies
Altera RAM blocks provide built-in functionality for control signals with
enable pins. The synthesis tool extracts control signals for single-port and
simple dual-port RAMs with a single common clock, and maps the logic to
March 2014 541
dedicated RAM instead of registers. This avoids inferring extra logic, and
improves resource utilization and QOR. The control signals can be read
enables, write enables, and clock enables.
For prerequisites to extract RAM control signals of the design, see Guidelines
for Extracting RAMs with Control Signals, on page 541.
Guidelines for Extracting RAMs with Control Signals
These are guidelines the tool uses for extracting RAM with control signals:
The tool supports different clock modes as follows:
For clock enables with read enable and write enable, the design must
have a single clock.
For true dual-port RAM, the tool supports RAM with one write and two
read processes.
If a negative level-sensitive signal is combined with an enable, the
software might not extract a RAM.
Guidelines for WRITE_FIRST Mode
The tool does not support two clock enables with read enable and write
enable in WRITE_FIRST mode.
To extract read enable in WRITE_FIRST mode, register the read enable
signal. With READ_FIRST mode, the read enable is inferred normally.
If you do not register the read enable signal in WRITE_FIRST mode, the
tool maps it to one of the clock enable pins (ena0/ena1/ena2/ena3)
depending on the functionality, and ties the read enable to 1.
To use a clock enable in WRITE_FIRST mode, the read enable register
must use the clock enable as the enable for that register.
Single-port, simple dual-port, and true
dual-port RAM
Input or output clock mode
Simple dual-port RAM Read-write clock mode
True dual-port RAM Independent clock mode
LO
542 March 2014
Guidelines for READ_FIRST Mode
To implement the clock enable and read enable for the controlling read
operation in READ_FIRST mode, register the output of the RAM with two
stage registers. The read enable controls the first register output and the
clock enable controls the second register stage.
To implement the clock enable with read and write enables in
READ_FIRST mode, the output register must be enabled by both the
clock enable and read enable. In addition, the write enable for the RAM
should be fed by both the write enable pin and the clock enable.
For code examples of RAM with control signals, see RAM with Control Signals
Examples, on page 663.
Distributed RAM Inference
Xilinx Technologies
Distributed RAMs are inferred memories that the synthesis tools do not map
to the dedicated block RAM memory resources. Instead, the tools implement
them using regular lookup tables (LUTs) within a slice of the configurable
logic block (CLB). Typically, distributed RAMs are used for small embedded
memory blocks, like synchronous and asynchronous FIFOs, for example.
Distributed RAMs have a single clock. Reads can be asynchronous, but
writes are synchronous. The tool supports the following memory types for
distributed RAM:
Single-port distributed RAM
Dual-port distributed RAM
Multiport distributed RAM
Attribute-Based Inference of Distributed RAM
By default, the tool implements any memories with unregistered outputs or
read addresses as distributed RAM or logic. You can use the syn_ramstyle attri-
bute to specify the implementation you want.
March 2014 543
If you specify the syn_rw_conflict_logic attribute, the synthesis tools can infer
distributed RAM, depending on the design.
For information about setting up your design to infer distributed RAM, see
Inferring Distributed RAM, on page 543 and RAM Attributes, on page 531. For
examples of distributed RAM, see Distributed RAM Examples, on page 669.
Inferring Distributed RAM
Xilinx Technologies
Based on the design and how you code it, the tool can infer the following
kinds of distributed RAM: single-port, dual-port, and multiport. To ensure
that the tool infers the kind of RAM you want, do the following:
1. Set up the RAM HDL code in accordance with the following guidelines:
The RAM can be synchronous or asynchronous.
Do not register the read address or the output. If you add a register,
the software implements block RAM, not distributed RAM.
To be automatically inferred, make sure the RAM is above the
minimum size threshold.
You can also guide inference with the syn_ramstyle attribute, as described
in step 3.
2. Set up the clocks and read and write ports to infer the kind of RAM you
want. The following table summarizes how the RAM must be set up:
syn_ramstyle Value Description
select_ram Enforces the inference and implementation of a technology-
specific distributed RAM.
registers Prevents inference of a RAM, and maps the inferred RAM to
flip-flops and logic.
LO
544 March 2014
The inference of multiport distributed RAM depends on whether one or
multiple write processes are used. See True Dual-Port RAM Inference, on
3. If needed, guide automatic inference with the syn_ramstyle attribute:
To force the inference of distributed RAM, specify
syn_ramstyle=select_ram.
To prevent a distributed RAM from being inferred, use
syn_ramstyle=logic.
The tool first compiles the design and infers the RAMs, which it maps to
abstract technology-independent primitives. The following figure shows
an inferred RAM in the RTL view:
The tool then maps the inferred RAM primitives to technology-specific
distributed RAM. The following view shows the inferred RAM from the
RTL view mapped to technology-specific RAM resources in the
Technology view. The RAMs are highlighted in red:
Distributed RAM Read Ports Write Ports
Single Port One; same as write One; same as read
Dual Port One dedicated read One dedicated write
Multiport 3 or 4 independent read
ports
One shared write port
March 2014 545
Single-Port Distributed RAM Inference
For single-port RAM, the same address is used for reading and writing opera-
tions. The tool automatically infers single-port distributed RAM in the
following cases:
The block RAM resources have been exhausted
The RAM contains an asynchronous read port
The syn_ramstyle attribute is set to select_ram
The RTL view shows a RAM1 primitive inferred.
Dual-Port Distributed RAM Inference
For distributed RAM, dual-port inference is the same as for block RAM. See
Dual-Port RAM Inference, on page 537 for details.
LO
546 March 2014
Multiport Distributed RAM Inference
Newer Xilinx technologies, like Virtex-5 and later, have multiport distributed
RAM primitives, like RAM32M and RAM64M for example. These RAMs have
four ports, generally configured as one write and three read ports. The RAM
configurations follow the DRC rules provided by Xilinx.
When the compiler encounters more than two ports in the RTL, it infers an
nram primitive. The nrams are mapped to RAM32M or RAM64M primitives by
the mapper.
Inferring Asymmetric RAM
Altera and Xilinx Technologies
RAMs with different port widths for read and write operations are called
asymmetric RAMs. The synthesis tools support different port widths for read
and write ports within a single block RAM primitive. The read and write
widths vary by 2**n. The synthesis tools infer asymmetric RAM if it is coded
as a contiguous write operation.
For code examples of asymmetric RAM, see Asymmetric RAM Examples, on
page 671.
Inferring Asymmetric RAM as a Black Box Model
True dual-port asymmetric RAM can be instantiated as black box models and
inferred as synchronous RAM. To infer the asymmetric RAM, you must
instantiate the following black box syn_asym_tdp_ram_model into your design.
March 2014 547
Then, you can specify parameter values for your particular RAM design, as
shown in the table below.
Asymmetric RAM Parameter Descriptions
Parameter Type Valid Values Description
PORT_0_DEPTH Integer 2
ADDR_0_WIDTH
Port 0 RAM depth
ADDR_0_WIDTH Integer 32* Port 0 Address width
DIN_0_WIDTH Integer Up to 128** Port 0 Data width
PORT_1_DEPTH Integer 2
ADDR_1_WIDTH
Port 1 RAM depth
ADDR_1_WIDTH Integer 32 Port 1 Address width
DIN_1_WIDTH Integer Up to 128 Port 1 Data width
OUTPUT_REG Integer 0 | 1 Inserts output data registers
READ_ADDRESS_REG Integer 0 | 1 Inserts input read address
registers
LO
548 March 2014
Altera-specific RAM Mode Configuration Values
For Altera RAM, only WRITE_FIRST mode is supported. If a read-during-write
occurs, then the new data is read out. Either READ_ADDRESS_REG must be
set to 0 or WRITE_FIRST and OUTPUT_REG must both be set to 1. This
ensures that the RAM is inferred in WRITE_FIRST mode with synchronous
registers.
Xilinx-specific RAM Mode Configuration Values
For Xilinx RAM, both WRITE_FIRST and READ_FIRST modes are supported.
For WRITE_FIRST mode, if a read-during-write occurs, then the new
data is read out. In WRITE_FIRST mode, WRITE_FIRST and
OUTPUT_REG must both be set to 1 or READ_ADDRESS_REG must be
set to 1.
For READ_FIRST mode, if a read-during-write occurs, then the old data
is read out. In READ_FIRST mode, both READ_ADDRESS_REG and
WRITE_FIRST must be set to 0.
RESET_TYPE String None |
Synchronous |
Asynchronous
Indicates the reset port type
WRITE_FIRST Integer 0 | 1 Indicates the RAM mode.
See:
Altera-specific RAM Mode
Configuration Values, on
page 548
or
Xilinx-specific RAM Mode
Configuration Values, on
page 548
* - 12 bits. Currently, the maximum address width is limited by the depth of a single block RAM.
** - 36 bits. Currently, the maximum data width is limited by the width of the Xilinx block RAM.
Asymmetric RAM Parameter Descriptions
March 2014 549
This table shows how the RAM ports can be mapped for Ports 0 and 1.
Parameter Requirements
Here are the parameter requirements that must be met to infer asymmetric
RAM correctly:
By definition, the true dual-port asymmetric RAM must satisfy the
following equation:
Asymmetric RAM Port Descriptions
Port Direction Description
CLK_0 Input Port 0 Clock
WEN_0 Input Port 0 Write enable. (Optional port)
REN_0 Input Port 0 Read enable. (Optional port)
RESET_0 Input Port 0 Reset. RESET_TYPE parameter specifies
whether the reset is enabled and its type.
ADDR_0 Input Port 0 Address. Address width is set using the
ADDR_0_WIDTH parameter.
DIN_0 Input Port 0 Data in. Data width is set using the
DIN_0_WIDTH parameter.
DOUT_0 Output Port 0 Data out. Data width is set using the
CLK_1 Input Port 1 Clock
WEN_1 Input Port 1 Write enable. (Optional port)
REN_1 Input Port 1 Read enable. (Optional port)
RESET_1 Input Port 1 Reset. RESET_TYPE parameter specifies
whether the reset is enabled and its type.
ADDR_1 Input Port 1 Address. Address width is set using the
ADDR_1_WIDTH parameter.
DIN_1 Input Port 1 Data in. Data width is set using the
DOUT_1 Output Port 1 Data out. Data width is set using the
LO
550 March 2014
(PORT_0_DEPTH * DIN_0_WIDTH) = (PORT_1_DEPTH * DIN_1_WIDTH)
The port depths must be a power of 2.
Verilog Example: Asymmetric RAM Instantiation Model
This is a Verilog template that you can use to create an instantiation model
for the asymmetric RAM.
syn_asym_tdp_ram_model
#(
.PORT_0_DEPTH(PORT_0_DEPTH),
.ADDR_0_WIDTH(ADDR_0_WIDTH),
.DIN_0_WIDTH(DIN_0_WIDTH),
// Port 0
.PORT_1_DEPTH(PORT_1_DEPTH),
.ADDR_1_WIDTH(ADDR_1_WIDTH),
.DIN_1_WIDTH(DIN_1_WIDTH),
// RAM Control Signals
.OUTPUT_REG(OUTPUT_REG),
.READ_ADDRESS_REG(READ_ADDRESS_REG),
.RESET_TYPE(RESET_TYPE),
.WRITE_FIRST(WRITE_FIRST)
)
Model_inst (
.CLK_0(CLK_0),
.WEN_0(WEN_0),
.REN_0(REN_0),
.RESET_0(RESET_0),
.ADDR_0(ADDR_0),
.DIN_0(DIN_0),
.DOUT_0(DOUT_0),
// Port 1
.CLK_1(Clk_1),
.WEN_1(WEN_1),
.RESET_1(RESET_1),
.ADDR_1(ADDR_1),
.DIN_1(DIN_1),
.DOUT_1(DOUT_1)
);
March 2014 551
VHDL Example: Asymmetric RAM Instantiation Model
This is a VHDL template you can use to create an instantiation model for the
asymmetric RAM.
Model_inst : syn_asym_tdp_ram_model
generic map (
PORT_0_DEPTH => PORT_0_DEPTH,
ADDR_0_WIDTH => ADDR_0_WIDTH,
DIN_0_WIDTH => DIN_0_WIDTH,
-- Port 0
PORT_1_DEPTH => PORT_1_DEPTH,
ADDR_1_WIDTH => ADDR_1_WIDTH,
DIN_1_WIDTH =>DIN_1_WIDTH,
-- RAM Control Signals
OUTPUT_REG => OUTPUT_REG,
READ_ADDRESS_REG => READ_ADDRESS_REG,
RESET_TYPE => RESET_TYPE,
WRITE_FIRST => WRITE_FIRST
)
port map(
CLK_0 => CLK_0,
WEN_0 => WEN_0,
REN_0 => REN_0,
RESET_0 => RESET_0,
ADDR_0 => ADDR_0,
DIN_0 => DIN_0,
DOUT_0 => DOUT_0,
-- Port 1
CLK_1 => Clk_1,
WEN_1 => WEN_1,
REN_1 => REN_1,
RESET_1 => RESET_1,
ADDR_1 => ADDR_1,
DIN_1 => DIN_1,
DOUT_1 => DOUT_1
);
Instantiation of Parameters Example
This example shows how the Verilog or VHDL templates above can actually
specify parameters for the RAM. The following code snippet is an explicit
WRITE_FIRST style RAM with asynchronous reset:
LO
552 March 2014
PORT_0_DEPTH(16),
.ADDR_0_WIDTH(4),
.DIN_0_WIDTH(32),
// Port 0
.PORT_1_DEPTH(32),
.ADDR_1_WIDTH(5),
.DIN_1_WIDTH(16),
// RAM Control Signals
.OUTPUT_REG(1),
.READ_ADDRESS_REG(1),
.RESET_TYPE("Asynchronous"),
.WRITE_FIRST(1)
Altera-specific Limitations
Altera device limitations for the RAM include the following:
For Arria 10, Arria V, Cyclone V, and Stratix V devices, only
WRITE_FIREST mode is supported across the same ports.
For Altera devices, mixed port RAM mode is WRITE_FIRST. Glue logic is
generated around the blockram for all implementations.
Xilinx-specific Limitation
Xilinx device limitations for the RAM include the following:
Only Virtex-7 and Virtex-6 devices are supported.
The maximum depth for the RAM is 1K and maximum width is 36 bits.
For higher capacity devices, you must multiplex individual block RAMs.
Inferring Byte-Enable RAM
Xilinx Technologies
The synthesis tools infer byte-enable RAM.khkhak Instead of using a single
enable bit to write data serially to one location at a time, this feature uses
multiple enable signals to read or write data to multiple locations in a block
RAM simultaneously. Data can be processed in parallel, and this increases
the speed and overall efficiency of the FPGA.
For:
March 2014 553
Code examples of byte-enable RAM, see Byte-Enable RAM Examples, on
page 677.
More detailed information and examples, refer to SolvNet article 030578,
Byte-Enable RAM Support.
Inferring Byte-Wide Write Enable RAM
The synthesis tool can infer byte-wide write enable RAM for single-port and
simple dual-port RAM. The tool maps the byte-wide write enable RAM to
block RAM for improved performance by merging the RAM and reducing its
area.
True dual-port RAM with byte-wide write enable is not supported.
For code examples of byte-wide write enable RAM, see Byte-Wide Write
Enable RAM Examples, on page 680.
LO
Chapter 10: Inferring High-Level Objects Initializing RAMs
554 March 2014
Initializing RAMs
You can specify startup values for RAMs and pass them on to the place-and-
route tools. See the following topics for ways to set the initial values:
Initializing RAMs in Verilog, on page 554
Initializing RAMs in VHDL, on page 555
Initializing RAMs with $readmemb and $readmemh, on page 558
Initializing RAMs in Verilog
In Verilog, you specify startup values using initial statements, which are
procedural assign statements guaranteed by the language to be executed by
the simulator at the start of simulation. This means that any assignment to a
variable within the body of the initial statement is treated as if the variable
was initialized with the corresponding LHS value. You can initialize memories
using the built-in load memory system tasks $readmemb (binary) and
$readmemh (hex).
The following procedure is the recommended method for specifying initial
values:
1. Create a data file with an initial value for every address in the memory
array. This file can be a binary file or a hex file. See Initialization Data
File, on page 690in the Reference Manual for details of the formats for
these files.
2. Do the following in the Verilog file to define the module:
Include the appropriate task enable statement, $readmemb or
$readmemh, in the initial statement for the module:
$readmemb ("fileName", memoryName [, startAddress [, stopAddress]]);
$readmemh ("fileName", memoryName [, startAddress [, stopAddress]]);
Use $readmemb for a binary file and use $readmemh for a hex file. For
descriptions of the syntax, see Initial Values for RAMs, on page 689
Make sure the array declaration matches the order in the initial value
data file you specified. As the file is read, each number encountered is
assigned to a successive word element of the memory. The software
Initializing RAMs Chapter 10: Inferring High-Level Objects
March 2014 555
starts with the left-hand address in the memory declaration, and
loads consecutive words until the memory is full or the data file has
been completely read. The loading order is the order in the
declaration. For example, with the following memory definition, the
first line in the data file corresponds to address 0:
reg [7:0] mem_up [0:63]
With this next definition, the first line in the data file applies to
address 63:
reg [7:0] mem_down [63:0]
3. To forward-annotate initial values, use the $readmemb or $readmemh
statements, as described in Initializing RAMs with $readmemb and
$readmemh, on page 558.
See RAM Initialization Example, on page 690 in the Reference Manual
for an example of a Verilog single-port RAM.
Initializing RAMs in VHDL
There are two ways to initialize the RAM in the VHDL code: with signal decla-
rations or with variable declarations.
Initializing VHDL Rams with Signal Declarations
The following example shows a single-port RAM that is initialized with signal
initialization statements. For alternative methods, see Initializing VHDL Rams
with Variable Declarations, on page 557.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity w_r2048x28 is
port (
clk : in std_logic;
adr : in std_logic_vector(10 downto 0);
di : in std_logic_vector(26 downto 0);
we : in std_logic;
dout : out std_logic_vector(26 downto 0));
end;
LO
Chapter 10: Inferring High-Level Objects Initializing RAMs
556 March 2014
architecture arch of w_r2048x28 is
-- Signal Declaration --
type MEM is array(0 to 2047) of std_logic_vector (26 downto 0);
signal memory : MEM := (
"111111111111111000000000000"
,"111110011011101010011110001"
,"111001111000111100101100111"
,"110010110011101110011110001"
,"101001111000111111100110111"
,"100000000000001111111111111"
,"010110000111001111100110111"
,"001101001100011110011110001"
,"000110000111001100101100111"
,"000001100100011010011110001"
,"000000000000001000000000000"
,"000001100100010101100001110"
,"000110000111000011010011000"
,"001101001100010001100001110"
,"010110000111000000011001000"
,"011111111111110000000000000"
,"101001111000110000011001000"
,"110010110011100001100001110"
,"111001111000110011010011000"
,"111110011011100101100001110"
,"111111111111110111111111111"
,"111110011011101010011110001"
,"111001111000111100101100111"
,"110010110011101110011110001"
,"101001111000111111100110111"
,"100000000000001111111111111"
,others => (others => '0'));
begin
process(clk)
begin
if rising_edge(clk) then
if (we = '1') then
memory(conv_integer(adr)) <= di;
end if;
dout <= memory(conv_integer(adr));
end if;
end process;
end arch;
Initializing RAMs Chapter 10: Inferring High-Level Objects
March 2014 557
Initializing VHDL Rams with Variable Declarations
The following example shows a RAM that is initialized with variable declara-
tions. For alternative methods, see Initializing VHDL Rams with Signal Decla-
rations, on page 555 and Initializing RAMs with $readmemb and $readmemh,
on page 558.
library ieee;
use ieee.numeric_std.all;
entity one is
generic (data_width : integer := 6;
address_width :integer := 3
);
port ( data_a :in std_logic_vector(data_width-1 downto 0);
raddr1 :in unsigned(address_width-2 downto 0);
waddr1 :in unsigned(address_width-1 downto 0);
we1 :in std_logic;
clk :in std_logic;
out1 :out std_logic_vector(data_width-1 downto 0) );
end;
architecture rtl of one is
type mem_array is array(0 to 2**(address_width) -1) of
std_logic_vector(data_width-1 downto 0);
begin
WRITE1_RAM : process (clk)
variable mem : mem_array := (1 => "111101", others => (1=>'1',
others => '0'));
begin
out1 <= mem(to_integer(raddr1));
if (we1 = '1') then
mem(to_integer(waddr1)) := data_a;
end if;
end if;
end process WRITE1_RAM;
end rtl;
LO
Chapter 10: Inferring High-Level Objects Using Implicit Initial Values
558 March 2014
Initializing RAMs with $readmemb and $readmemh
1. Create a data file with an initial value for every address in the memory
array. This file can be a binary file or a hex file. See Initialization Data
File, on page 690 in the Reference Manual for details.
2. Include one of the task enable statements, $readmemb or $readmemh, in
the initial statement for the module:
$readmemb ("fileName", memoryName [, startAddress [, stopAddress]]) ;
$readmemh ("fileName", memoryName [, startAddress [, stopAddress]]) ;
Use $readmemb for a binary file and $readmemh for a hex file. For details
about the syntax, see Initial Values for RAMs, on page 689 in the Refer-
ence Manual.
Using Implicit Initial Values
Synplify Premier
Xilinx
Instead of using default initial values, you can load explicit initial values for
Xilinx technology primitives from the unisim library (unisim.v or unisim.vhd) and
apply them to the corresponding FD-type technology primitives. These
explicit initial values for the primitives are set through INIT properties
supported by the Xilinx mapper and used throughout optimization.
1. To use implicit initial values, use one of these methods:
Enable the Implicit Initial Value Support for Instantiated Primitives check box
on the Device panel of the Implementation Options dialog box.
Use this Tcl command:
set_option -support_implicit_init_netlist 1
2. Enable the Enhanced Optimization option on the Device panel.
You must enable Enhanced Optimization; if it is not enabled, a warning
message is issued and the tool enables the Enhanced Optimization option
automatically.
Inferring Shift Registers Chapter 10: Inferring High-Level Objects
March 2014 559
Inferring Shift Registers
Altera Stratix, Xilinx Virtex
The software infers shift registers for certain architectures. For Altera Stratix
designs, you can implement the shift register as an altshift_tap with tap points.
Use the following procedure.
1. Set up the HDL code for the sequential shift components. See Shift
Register Examples, on page 561 for examples.
Note the following:
2. Specify the implementation style with the syn_srlstyle attribute.
You can set the value globally or on individual registers. For example, if
you do not want the components automatically mapped to shift regis-
ters, set it globally to registers. You can then override this with specific
settings on individual registers as needed.
Altera The registers must be dff or dffe registers.
All registers must have the same type and use the same control
signals.
Xilinx The new component represents a set of three or more registers that
can be shifted left (from a low address to a higher address).
The contents of only one register can be seen at a time, based on
the read address.
For static components, the software only taps the output of the last
register. The read address of the inferred component is set to a
constant.
syn_srlstyle Value Implemented as ...
registers registers
select_srl Xilinx SRL16 primitives
no_extractff_srl Xilinx SRL16 primitives without output flip-flops
altshift_tap Altera Altshift_tap components
LO
Chapter 10: Inferring High-Level Objects Inferring Shift Registers
560 March 2014
3. For Altera shift registers, use attributes to control how the registers are
packed:
If you do not specify anything, registers are packed across hierarchy. In
all cases, the registers are not packed if doing so violates DRC restric-
tions.
4. Run synthesis.
After compilation, the software displays the components as seqShift
components in the RTL view. The following figure shows the components
in the RTL view.
In the technology view, the components are implemented as Xilinx
SRL16 or Altera altshift_tap primitives or registers, depending on the attri-
bute values you set.
To ... Attach ...
Prevent a register from being packed
into shift registers
syn_useioff or syn_noprune to the
register. You can also use syn_srlstyle
with a value of registers.
Prevent two registers from being
packed into the same shift registers
syn_keep between the two registers.
The algorithm slices the chain
vertically, and packs the two registers
into separate shift registers.
Specify that two registers be packed
in different shift registers
syn_srlstyle with different group names
for the registers you want to separate
(syn_srlstyle= altshift_tap, groupName)
March 2014 561
5. Check the results in the log file and the technology file.
The log file reports the shift registers and the number of registers packed
in them. The following is an Altera example, showing the number of
registers packed and taps inferred:
ShiftTap: 1 (10100 registers)
Shift Register Examples
Altera Shift Register (VHDL)
library ieee;
entity test is
port (
clk : in std_logic;
din : in std_logic_vector(31 downto 0);
dout : out std_logic_vector(31 downto 0);
tap7 : out std_logic_vector(31 downto 0);
tap1 : out std_logic_vector(31 downto 0)
);
end test;
architecture rtl of test is
type dataAryType is array(31 downto 0) of std_logic_vector(31
downto 0);
signal q : dataAryType;
begin
process (Clk)
begin
if (Clk'Event And Clk = '1') then
q <= (q(30 DOWNTO 0) & din);
end if;
end process;
LO
562 March 2014
dout <= q(31);
tap7 <= q(27);
tap6 <= q(23);
tap5 <= q(19);
tap4 <= q(15);
tap3 <= q(11);
tap2 <= q(7);
tap1 <= q(3);
end rtl;
Altera Shift Register (Verilog)
module
test(dout,tap7,tap6,tap5,tap4,tap3,tap2,tap1,din,shift,clk);
output [7:0] dout;
output [7:0] tap7;
output [7:0] tap6;
output [7:0] tap5;
output [7:0] tap4;
output [7:0] tap3;
output [7:0] tap2;
output [7:0] tap1;
input [7:0] din;
input shift, clk;
reg [7:0] q[63:0];
integer n;
assign dout = q[63];
assign tap7 = q[55];
assign tap1 = q[7];
if (shift)
begin
q[0] <= din;
for (n=0; n<63; n=n+1)
begin
March 2014 563
q[n+1] <= q[n];
end
end
endmodule
Xilinx Shift Register (VHDL)
This is a VHDL example of a shift register with no resets. It has four 8-bit
wide registers and a 2-bit wide read address. Registers shift when the write
enable is 1.
library IEEE;
use IEEE.std_logic_1164.all;
entity srltest is
port ( inData: std_logic_vector(7 downto 0);
clk, en : in std_logic;
outStage : in integer range 3 downto 0;
outData: out std_logic_vector(7 downto 0)
);
end srltest;
architecture rtl of srltest is
type dataAryType is array(3 downto 0) of std_logic_vector(7
downto 0);
signal regBank : dataAryType;
begin
outData <= regBank(outStage);
process(clk, inData)
begin
if (clk'event and clk = '1') then
if (en='1') then
regBank <= (regBank(2 downto 0) & inData);
end if;
end if;
end process;
end rtl;
LO
564 March 2014
Xilinx Shift Register (Verilog)
module test_srl(clk, enable, dataIn, result, addr);
input clk, enable;
input [3:0] dataIn;
input [3:0] addr;
output [3:0] result;
reg [3:0] regBank[15:0];
integer i;
always @(posedge clk) begin
if (enable == 1) begin
for (i=15; i>0; i=i-1) begin
regBank[i] <= regBank[i-1];
end
regBank[0] <= dataIn;
end
end
assign result = regBank[addr];
endmodule
Working with LPMs Chapter 10: Inferring High-Level Objects
March 2014 565
Working with LPMs
Altera
Some technologies support LPMs (Library of Parameterized Modules), which
are technology-independent logic functions that are parameterized for
scalability and adaptability. There are two ways to instantiate LPMs in your
source code: as black boxes, or by using prepared components.
The following table compares the methods for instantiating LPMs.
See the following for more information about instantiating LPMs:
Instantiating Altera LPMs as Black Boxes, on page 566
Instantiating Altera LPMs Using VHDL Prepared Components, on
page 570
Instantiating Altera LPMs Using a Verilog Library, on page 572
Black Box
Method
Verilog Library/VHDL
Prepared Component Method
Applies to any LPM Yes No
Synthesis LPM timing support No Yes
Synthesis procedure More coding Simple
LO
Chapter 10: Inferring High-Level Objects Working with LPMs
566 March 2014
Instantiating Altera LPMs as Black Boxes
The method described here uses either Verilog or VHDL LPMs in the Altera-
prescribed megafunction format. Alternatively, you can use the methods
described in Instantiating Altera LPMs Using a Verilog Library, on page 572 or
Instantiating Altera LPMs Using VHDL Prepared Components, on page 570.
For information about using Clearbox in Synplify Pro Stratix designs, see
Implementing Megafunctions with Clearbox Models, on page 738.
1. Generate the LPM using the Altera MegaWizard Plug-in Manager. If you
generate the file using another method, make sure to use the same
MegaWizard format, where ALTSYNCRAM is instantiated.
For examples of coding style, see LPM Megafunction Example (Verilog), on
page 566 and LPM Megafunction Example (VHDL), on page 568.
2. Manually edit the LPM file and add the syn_black_box attribute to make
the LPM a black box for synthesis.
See the examples in LPM Megafunction Example (Verilog), on page 566
and LPM Megafunction Example (VHDL), on page 568.
3. Instantiate the LPM in your design so that the LPM is not the top level.
Synthesize the design.
The synthesis software treats the LPM as a black box. After synthesis,
the software writes out a vqm file where the module is a black box.
4. Add the original LPM file to the results directory and use it along with
the vqm file to place and route your design.
The place-and-route software uses the synthesized design information
from the vqm file and adds in the ALTSYNCRAM parameter information
from the original megafunction file to place and route the LPM RAM
correctly.
LPM Megafunction Example (Verilog)
The following file shows the coding style the Altera MegaWizard uses to
generate a Verilog LPM file, with the syn_black_box attribute added for
synthesis.
March 2014 567
module mylpm (
data,
wren,
wraddress,
rdaddress,
clock,
q)/* synthesis syn_black_box */;
input [7:0] data;
input wren;
input [4:0] wraddress;
input [4:0] rdaddress;
input clock;
output [7:0] q;
wire [7:0] sub_wire0;
wire [7:0] q = sub_wire0[7:0];
altsyncram altsyncram_component (
.wren_a (wren),
.clock0 (clock),
.address_a (wraddress),
.address_b (rdaddress),
.data_a (data),
.q_b (sub_wire0));
defparam
altsyncram_component.operation_mode = "DUAL_PORT",
altsyncram_component.width_a = 8,
altsyncram_component.widthad_a = 5,
altsyncram_component.numwords_a = 32,
altsyncram_component.width_b = 8,
altsyncram_component.widthad_b = 5,
altsyncram_component.numwords_b = 32,
altsyncram_component.lpm_type = "altsyncram",
altsyncram_component.width_byteena_a = 1,
altsyncram_component.outdata_reg_b = "UNREGISTERED",
altsyncram_component.indata_aclr_a = "NONE",
altsyncram_component.wrcontrol_aclr_a = "NONE",
altsyncram_component.address_aclr_a = "NONE",
altsyncram_component.address_reg_b = "CLOCK0",
altsyncram_component.address_aclr_b = "NONE",
LO
568 March 2014
altsyncram_component.outdata_aclr_b = "NONE",
altsyncram_component.read_during_write_mode_mixed_ports
= "DONT_CARE",
altsyncram_component.ram_block_type = "AUTO",
altsyncram_component.intended_device_family = "Stratix";
endmodule
LPM Megafunction Example (VHDL)
Instantiate a file like this one at the top level, and include it in the project file,
as shown in the preceding figure.
ENTITY myram IS
PORT(
data : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
wren : IN STD_LOGIC := '1';
wraddress : IN STD_LOGIC_VECTOR (4 DOWNTO 0);
rdaddress : IN STD_LOGIC_VECTOR (4 DOWNTO 0);
clock : IN STD_LOGIC ;
q : OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
);
END myram;
ARCHITECTURE SYN OF mylpram IS
SIGNAL sub_wire0 : STD_LOGIC_VECTOR (7 DOWNTO 0);
COMPONENT altsyncram
GENERIC (
operation_mode : STRING;
width_a : NATURAL;
widthad_a : NATURAL;
numwords_a : NATURAL;
width_b : NATURAL;
widthad_b : NATURAL;
numwords_b : NATURAL;
lpm_type : STRING;
width_byteena_a : NATURAL;
outdata_reg_b : STRING;
indata_aclr_a : STRING;
wrcontrol_aclr_a : STRING;
address_aclr_a : STRING;
address_reg_b : STRING;
address_aclr_b : STRING;
March 2014 569
outdata_aclr_b : STRING;
read_during_write_mode_mixed_ports : STRING;
ram_block_type : STRING;
intended_device_family : STRING
);
PORT (
wren_a : IN STD_LOGIC ;
clock0 : IN STD_LOGIC ;
address_a : IN STD_LOGIC_VECTOR (4 DOWNTO 0);
address_b : IN STD_LOGIC_VECTOR (4 DOWNTO 0);
q_b : OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_a : IN STD_LOGIC_VECTOR (7 DOWNTO 0)
);
END COMPONENT;
BEGIN
<= sub_wire0(7 DOWNTO 0);
altsyncram_component : altsyncram
GENERIC MAP (
operation_mode => "DUAL_PORT",
width_a => 8,
widthad_a => 5,
numwords_a => 32,
width_b => 8,
widthad_b => 5,
numwords_b => 32,
lpm_type => "altsyncram",
width_byteena_a => 1,
outdata_reg_b => "CLOCK0",
indata_aclr_a => "NONE",
wrcontrol_aclr_a => "NONE",
address_aclr_a => "NONE",
address_reg_b => "CLOCK0",
address_aclr_b => "NONE",
outdata_aclr_b => "NONE",
read_during_write_mode_mixed_ports => "DONT_CARE",
ram_block_type => "AUTO",
intended_device_family => "Stratix"
)
LO
570 March 2014
PORT MAP (
wren_a => wren,
clock0 => clock,
address_a => wraddress,
address_b => rdaddress,
data_a => data,
q_b => sub_wire0
);
END SYN;
Instantiating Altera LPMs Using VHDL Prepared Components
Prepared LPM components, available as component declarations in
LPM_COMPONENTS, use generics instead of attributes to specify different
design parameters. After you specify library and use clauses, instantiate the
components and assign (map) the ports and the values for the generics. Refer
to the Quartus II documentation for ports and generics that require mapping.
See Prepared LPM Components Provided by Synopsys (VHDL), on page 862 in
the Reference Manual for a list of available LPM components.
The prepared components method is the simplest to use, but it does not cover
all available LPMs. For other methods, see Instantiating Altera LPMs as Black
Boxes, on page 566), or Instantiating Altera LPMs Using a Verilog Library, on
page 572 (Altera only). The prepared components method uses generics
instead of attributes to specify design parameters. You specify the library,
instantiate the components, and assign (map) the ports and the values for the
generics.
1. In the higher-level entity, specify the appropriate library and use
clauses.
library lpm;
use lpm.components.all;
The prepared components are in the installDirectory\lib\vhd directory. The
Altera LPM prepared components are in lpm.
2. Instantiate the prepared component.
3. Assign the ports and values for the generics. These assignments override
the generic values in the library. Refer to the vendor documentation for
details about ports and values for generics.
March 2014 571
This is an example of an LPM instantiated at a higher level:
library ieee, lpm;
use lpm.components.all;
entity test is
port(data : in std_logic_vector (5 downto 0);
distance : in std_logic_vector (7 downto 0);
result : out std_logic_vector (5 downto 0);
end test;
architecture arch1 of test is
begin
u1 : lpm_clshift
generic map (LPM_WIDTH=>6, LPM_WIDTHDIST =>8)
port map (data=>data, distance=>distance, result=>result);
end arch1;
Prepared Components LPM Example (Altera)
This example shows the instantiation of the prepared component lpm_ram_dq:
library lpm;
use lpm.lpm_components.all;
library ieee;
entity lpm_inst is
port (clock, we: in std_logic;
data : in std_logic_vector(3 downto 0);
address : in std_logic_vector(3 downto 0);
q : out std_logic_vector (3 downto 0));
end lpm_inst;
architecture arch1 of lpm_inst is
begin
I0 : lpm_ram_dq
generic map (LPM_WIDTH => 4,
LPM_WIDTHAD => 4,
LPM_TYPE => "LPM_RAM_DQ")
port map (data => data,
address => address,
we => we,
inclock => clock,
outclock => clock,
q => q);
end arch1;
LO
572 March 2014
Instantiating Altera LPMs Using a Verilog Library
For Altera LPMs, you can also instantiate LPMs from a Verilog library. For
other methods of instantiating LPMs, see Instantiating Altera LPMs as Black
Boxes, on page 566 and Instantiating Altera LPMs Using VHDL Prepared
Components, on page 570.
1. Add the Verilog library file installDirectory/lib/altera/altera_lpm.v to your
project. The following shows the code for lpm_ram_dp.
module lpm_ram_dp (q, data, wraddress, rdaddress, rdclock,
wrclock,
rdclken, wrclken, rden, wren) /*synthesis syn_black_box*/;
parameter lpm_type = "lpm_ram_dp";
parameter lpm_width = 1;
parameter lpm_widthad = 1;
parameter numwords = 1<<lpm_widthad;
parameter lpm_indata = "REGISTERED";
parameter lpm_outdata = "REGISTERED";
parameter lpm_rdaddress_control = "REGISTERED";
parameter lpm_wraddress_control = "REGISTERED";
parameter lpm_file = "UNUSED";
parameter lpm_hint = "UNUSED";
input [lpm_width-1:0] data;
input [lpm_widthad-1:0] rdaddress, wraddress;
input rdclock, wrclock, rdclken, wrclken, wren, rden;
output [lpm_width-1:0] q;
endmodule //lpm_ram_dp
2. Instantiate the LPM in the higher-level module. For example:
module top(d, q1, wclk, rclk, wraddr, raddr, wren, rden,
wrclken, rdclken) ;
parameter AWIDTH = 4;
parameter DWIDTH = 8;
parameter WDEPTH = 1<<AWIDTH;
input [AWIDTH-1:0] wraddr, rdaddr;
input [DWIDTH-1:0] d;
input wclk, rclk, wren, rden;
input wrclken, rdclken;
output [DWIDTH-1:0] q1;
March 2014 573
lpm_ram_dp u1(.data(d), .wrclock(wclk), .rdclock(rclk), .q(q1),
.wraddress(wraddr), .rdaddress(rdaddr), .wren(wren),
.rden(rden), .wrclken(wrclken), .rdclken(rdclken));
defparam u1.lpm_width = DWIDTH;
defparam u1.lpm_widthad = AWIDTH;
defparam u1.lpm_indata = "REGISTERED";
defparam u1.lpm_outdata = "REGISTERED";
defparam u1.lpm_wraddress_control = "REGISTERED";
defparam u1.lpm_rdaddress_control = "REGISTERED";
endmodule
For information about using the LPMs in Altera simulation flows, see
Using LPMs in Simulation Flows, on page 1005.
LO
574 March 2014
March 2014 575
CHAPTER 11
Specifying Design-Level Optimizations
This chapter covers techniques for optimizing your design using built-in tools
or attributes. For vendor-specific optimizations, see Chapter 20, Optimizing
for Specific Targets. It describes the following:
Tips for Optimization, on page 576
Pipelining, on page 580
Retiming, on page 584
Preserving Objects from Being Optimized Away, on page 592
Optimizing Fanout, on page 598
Sharing Resources, on page 602
Inserting I/Os, on page 603
Optimizing State Machines, on page 605
Inserting Probes, on page 613
LO
Chapter 11: Specifying Design-Level Optimizations Tips for Optimization
576 March 2014
Tips for Optimization
The software automatically makes efficient trade-offs to achieve the best
results. However, you can optimize your results by using the appropriate
control parameters. This section describes general design guidelines for
optimization. The topics have been categorized as follows:
General Optimization Tips, on page 576
Optimizing for Area, on page 577
Optimizing for Timing, on page 578
General Optimization Tips
This section contains general optimization tips that are not directly area or
timing-related. For area optimization tips, see Optimizing for Area, on
page 577. For timing optimization, see Optimizing for Timing, on page 578.
In your source code, remove any unnecessary priority structures in
timing-critical designs. For example, use CASE statements instead of
nested IF-THEN-ELSE statements for priority-independent logic.
If your design includes safe state machines, use the syn_encoding attri-
bute with a value of safe. This ensures that the synthesized state
machines never lock in an illegal state.
For FSMs coded in VHDL using enumerated types, use the same
encoding style (syn_enum_encoding attribute value) on both the state
machine enumerated type and the state signal. This ensures that there
are no discrepancies in the type of encoding to negatively affect the final
circuit.
Make sure that the source code supports inferencing or instantiation by
using architecture-specific resources like memory blocks.
Some designs benefit from hierarchical optimization techniques. To
enable hierarchical optimization on your design, set the syn_hier attri-
bute to firm.
For accurate results with timing-driven synthesis, explicitly define clock
frequencies with a constraint, instead of using a global clock frequency.
Tips for Optimization Chapter 11: Specifying Design-Level Optimizations
March 2014 577
Optimizing for Area
This section contains information on optimizing to reduce area. Optimizing
for area often means larger delays, and you will have to weigh your perfor-
mance needs against your area needs to determine what works best for your
design. For tips on optimizing for performance, see Optimizing for Timing, on
page 578. General optimization tips are in General Optimization Tips, on
page 576.
Increase the fanout limit when you set the implementation options. A
higher limit means less replicated logic and fewer buffers inserted
during synthesis, and a consequently smaller area. In addition, as P&R
tools typically buffer high fanout nets, there is no need for excessive
buffering during synthesis. See Setting Fanout Limits, on page 598 for
more information.
Enable the Resource Sharing option when you set implementation options.
With this option checked, the software shares hardware resources like
adders, multipliers, and counters wherever possible, and minimizes
area. This is a global setting, but you can also specify resource sharing
on an individual basis for lower-level modules. See Sharing Resources,
on page 602 for details.
For designs with large FSMs, use the gray or sequential encoding styles,
because they typically use the least area. For details, see Specifying
FSMs with Attributes and Directives, on page 502.
If you are mapping into a CPLD and do not meet area requirements, set
the default encoding style for FSMs to sequential instead of onehot. For
details, see Specifying FSMs with Attributes and Directives, on page 502.
For small CPLD designs (less than 20K gates), you might improve area
by using the syn_hier attribute with a value of flatten. When specified, the
software optimizes across hierarchical boundaries and creates smaller
designs.
LO
Chapter 11: Specifying Design-Level Optimizations Tips for Optimization
578 March 2014
Optimizing for Timing
This section contains information on optimizing to meet timing requirements.
Optimizing for timing is often at the expense of area, and you will have to
balance the two to determine what works best for your design. For tips on
optimizing for area, see Optimizing for Area, on page 577. General optimiza-
tion tips are in General Optimization Tips, on page 576.
Use realistic design constraints, about 10 to 15 percent of the real goal.
Over-constraining your design can be counter-productive because you
can get poor implementations. Typically, you set timing constraints like
clock frequency, clock-to-clock delay paths, I/O delays, register I/O
delays and other miscellaneous path delays. Use clock, false path, and
multi-cycle path constraints to make the constraints realistic.
Enable the Retiming option. This optimization moves registers into I/O
buffers if this is permitted by the technology and the design. However, it
may add extra registers when clouds of logic are balanced across more
than one register-to-register timing path. Extra registers are only added
in parallel within the timing path and only if no extra latency is added by
the additional registers. For example, if registers are moved across a 2x1
multiplexer, the tool adds two new registers to accommodate the select
and data paths.
You can set this option globally or on specific registers. When it is
enabled, it automatically enables pipelining as well. See Retiming, on
Enable the Pipelining option. With this optimization enabled, the tool
moves existing registers into a ROM or multiplier. Unlike retiming, it
does not add any new logic. Pipelining reduces routing and delay and
the extra instance delay of the external register by moving it into the
ROM or multiplier and making it a built-in register.
Select a balanced fanout constraint. A large constraint creates nets with
large fanouts, and a low fanout constraint results in replicated logic. See
Setting Fanout Limits, on page 598 for information about setting limits
and using the syn_maxfan attribute. You can use this in conjunction with
the syn_replicate attribute that controls register duplication and buffering.
Control register duplication and buffering criteria with the syn_replicate
attribute. The tool automatically replicates registers during optimization,
and you can use this attribute globally or locally on a specific register to
turn off register duplication. See Controlling Buffering and Replication,
Tips for Optimization Chapter 11: Specifying Design-Level Optimizations
March 2014 579
on page 600 for a description. Use syn_replicate in conjunction with the
syn_maxfan attribute that controls fanout.
If the critical path goes through arithmetic components, try disabling
Resource Sharing. You can get faster times at the expense of increased
area, but use this technique carefully. Adding too many resources can
cause longer delays and defeat your purpose.
If the P&R and synthesis tools report different critical paths, use a
timing constraint with the -route option. With this option, the software
adds route delay to its calculations when trying to meet the clock
frequency goal. Use realistic values for the constraints.
For FSMs, use the onehot encoding style, because it is often the fastest
implementation. If a large output decoder follows an FSM, gray or
sequential encoding could be faster.
For designs with black boxes, characterize the timing models accurately,
using the syn_tpd, syn_tco, and syn_tso directives.
If you see warnings about feedback muxes being created for signals
when you compile your source code, make sure to assign set/resets for
the signals. This improves performance by eliminating the extra mux
delay on the input of the register.
Make sure that you pass your timing constraints to the place-and-route
tools, so that they can use the constraints to optimize timing.
If you are working in the Synplify Premier tool and performance and
quality of results (QoR) are not essential to the application (as with early
prototyping and what if scenarios), use the Fast Synthesis option. For
details, refer to Chapter 12, Fast Synthesis.
The Fast Synthesis option reduces the amount and number of mapper
optimizations performed so that you get faster synthesis runtimes. Once
the design has been evaluated with fast synthesis, the mapper optimiza-
tion effort can be returned to its normal, default level for optimum
performance/QoR evaluations. This option is only available with the
Synplify Premier tool for devices from the Xilinx Virtex and Spartan
families or the Altera Stratix families.
LO
Chapter 11: Specifying Design-Level Optimizations Pipelining
580 March 2014
Pipelining
Pipelining is the process of splitting logic into stages so that the first stage
can begin processing new inputs while the last stage is finishing the previous
inputs. This ensures better throughput and faster circuit performance. If you
are using selected technologies which use pipelining, you can also use the
related technique of retiming to improve performance. See Retiming, on
For pipelining, the software splits the logic by moving registers into the multi-
plier or ROM:
This section discusses the following pipelining topics:
Prerequisites for Pipelining, on page 580
Pipelining the Design, on page 581
Prerequisites for Pipelining
Pipelining is only supported for certain Altera, Lattice, Microsemi, and
Xilinx technologies.
In Xilinx Virtex device families, you can pipeline ROMs and multipliers.
In Altera designs, you can pipeline multipliers, but not ROMs.
For Xilinx Virtex device families, you can only pipeline multipliers if the
adjacent register has a synchronous reset.
ROMs to be pipelined must be at least 512 words. Anything below this
limit is too small.
For Xilinx Virtex device families, you can push any kind of flip-flop into
the module, as long as all the flip-flops in the pipeline have the same
clock, the same set/reset signal or lack of it, and the same enable
control or lack of it. For Altera designs, you must have asynchronous
set/resets if you want to do pipelining.
Pipelining Chapter 11: Specifying Design-Level Optimizations
March 2014 581
Pipelining the Design
The following procedure shows you techniques for pipelining.
1. Make sure the design meets the criteria described in Prerequisites for
Pipelining, on page 580.
2. To enable pipelining for the whole design, check the Pipelining check box.
from the button panel in the Project window, or with the Project-
>Implementation Options command (Options tab). The option is only available
in the appropriate technologies.
Use this approach as a first pass to get a feel for which modules you can
pipeline. If you know exactly which registers you want to pipeline, add
the attribute to the registers in the source code or interactively using the
SCOPE interface.
3. To check whether individual registers are suitable for pipelining, do the
following:
Open the RTL view of the design.
Select the register and press F12 to filter the schematic view.
LO
Chapter 11: Specifying Design-Level Optimizations Pipelining
582 March 2014
In the new schematic view, select the output and type e (or select
Expand from the popup menu. Check that the register is suitable for
pipelining.
4. To enable pipelining on selected registers, use either of the following
techniques:
Check the Pipelining checkbox and attach the syn_pipeline attribute with
a value of 0 or false to any registers you do not want the software to
move. This attribute specifies that the register cannot be moved for
pipelining.
Do not check the Pipelining checkbox. Attach the syn_pipeline attribute
with a value of 1 or true to any registers you want the software to
consider for retiming. This attribute marks the register as one that
can be moved during retiming, but does not necessarily force it to be
moved during retiming.
The following are examples of the attribute:
SCOPE Interface:
Verilog Example:
reg [lefta:0] a_aux;
reg [leftb:0] b_aux;
reg [lefta+leftb+1:0] res /* synthesis syn_pipeline=1 */;
reg [lefta+leftb+1:0] res1;
VHDL Example:
Pipelining Chapter 11: Specifying Design-Level Optimizations
March 2014 583
architecture beh of onereg is
signal temp1, temp2, temp3,
std_logic_vector(31 downto 0);
attribute syn_pipeline : boolean;
attribute syn_pipeline of temp1 : signal is true;
5. Click Run.
The software looks for registers where all the flip-flops of the same row
have the same clock, no control signal, or the same unique control
signal, and pushes them inside the module. It attaches the syn_pipeline
attribute to all these registers. If there already is a syn_pipeline attribute
on a register, the software implements it.
6. Check the log file (*.srr). You can use the Find command for
occurrences of the word pipelining to find out which modules got
pipelined.
The log file entries look like this:
@N:|Pipelining module res_out1
@N:|res_i is level 1 of the pipelined module res_out1
@N:|r is level 2 of the pipelined module res_out1
LO
Chapter 11: Specifying Design-Level Optimizations Retiming
584 March 2014
Retiming
Some Altera, Lattice, Microsemi, and Xilinx technologies
Retiming improves the timing performance of sequential circuits without
modifying the source code. It automatically moves registers (register
balancing) across combinatorial gates or LUTs to improve timing while
maintaining the original behavior as seen from the primary inputs and
outputs of the design. Retiming moves registers across gates or LUTs, but
does not change the number of registers in a cycle or path from a primary
input to a primary output. However, it can change the total number of regis-
ters in a design.
The retiming algorithm retimes only edge-triggered registers. It does not
retime level-sensitive latches. Note that registers associated with RAMS,
DSPs, and the mapping for generated clocks may be moved, regardless of the
Retiming option setting. The Retiming option is not available if it does not apply
to the family you are using.
These sections contain details about using retiming.
Controlling Retiming, on page 584
Retiming Example, on page 586
Retiming Report, on page 587
How Retiming Works, on page 588
Controlling Retiming
The following procedure shows you how to use retiming.
1. To enable retiming for the whole design, check the Retiming check box.
You can set the Retiming option from the button panel in the Project
window, or with the Project->Implementation Options command (Options tab).
The option is only available in certain technologies.
Retiming Chapter 11: Specifying Design-Level Optimizations
March 2014 585
For Altera, Lattice, and Xilinx designs, retiming is a superset of
pipelining, so when you select Retiming, you automatically select
Pipelining. See Pipelining, on page 580 for more information. For
Microsemi designs, retiming does not include pipelining.
Retiming works globally on the design, and moves edge-triggered regis-
ters as needed to balance timing.
2. To enable retiming on selected registers, use either of the following
techniques:
Check the Retiming checkbox and attach the syn_allow_retiming attribute
with a value of 0 or false to any registers you do not want the software
to move. This attribute specifies that the register cannot be moved for
retiming. Refer to How Retiming Works, on page 588 for a list of the
components the retiming algorithm will move.
Do not check the Retiming checkbox. Attach the syn_allow_retiming
attribute with a value of 1 or true to any registers you want the
software to consider for retiming. You can do this in the SCOPE
interface or in the source code. This attribute marks the register as
one that can be moved during retiming, but does not necessarily force
it to be moved during retiming. If you apply the attribute to an FSM,
RAM or SRL that is decomposed into flip-flops and logic, the software
applies the attribute to all the resulting flip-flops
Set the retiming option in either place.
LO
586 March 2014
Retiming is a superset of pipelining; therefore adding syn_allow_retiming=1
on any registers implies that syn_pipeline =1.
3. You can also fine-tune retiming using attributes:
To preserve the power-on state of flip-flops without sets or resets (FD
or FDE) during retiming, set syn_preserve=1 or syn_allow_retiming=0 on
these flip-flops.
To force flip-flops to be packed in I/O pads, set syn_useioff=1 as a
global attribute. This will prevent the flip-flops from being moved
during retiming.
4. Set other options for the run. Retiming might affect some constraints
and attributes. See How Retiming Works, on page 588 for details.
5. Click Run to start synthesis.
After the LUTs are mapped, the software moves registers to optimize
timing. See Retiming Example, on page 586 for an example. The software
honors other attributes you set, like syn_preserve, syn_useioff, and
syn_ramstyle. See How Retiming Works, on page 588 for details.
Note that the tool might retime registers associated with RAMs, DSPs,
and generated clocks, regardless of whether the Retiming option is on or
off.
The log file includes a retiming report that you can analyze to under-
stand the retiming changes. It contains a list of all the registers added or
removed because of retiming. Retimed registers have a _ret suffix added
to their names. See Retiming Report, on page 587 for more information
about the report.
Retiming Example
The following example shows a design with retiming disabled and enabled.
March 2014 587
The top figure shows two levels of logic between the registers and the output,
and no levels of logic between the inputs and the registers.
The bottom figure shows the results of retiming the three registers at the
input of the OR gate. The levels of logic from the register to the output are
reduced from two to one. The retimed circuit has better performance than the
original circuit. Timing is improved by transferring one level of logic from the
critical part of the path (register to output) to the non-critical part (input to
register).
Retiming Report
The retiming report is part of the log file, and includes the following:
The number of registers added, removed, or untouched by retiming.
Names of the original registers that were moved by retiming and which
no longer exist in the Technology view.
Names of the registers created as a result of retiming, and which did not
exist in the RTL view. The added registers have a _ret suffix.
LO
588 March 2014
How Retiming Works
This section describes how retiming works when it moves sequential compo-
nents (flip-flops). Registers associated with RAMs, DSPs, and the mapping for
fixing generated clocks might be moved, whether Retiming is enabled or not.
Here are some implications and results of retiming:
Flip-flops with no control signals (resets, presets, and clock enables) are
moved. Flip-flops with minimal control logic can also be retimed.
Multiple flip-flops with reset, set or enable signals that need to be
retimed together are only retimed if they have exactly the same control
logic.
The software does not retime the following combinatorial sequential
elements: flip-flops with both set and reset, flip-flops with attributes like
syn_preserve, flip-flops packed in I/O pads, level-sensitive latches, regis-
ters that are instantiated in the code, SRLs, and RAMs. If a RAM with
combinatorial logic has syn_ramstyle set to registers, the registers can be
retimed into the combinatorial logic.
Retimed flip-flops are only moved through combinatorial logic. The
software does not move flip-flops across the following objects: black
boxes, sequential components, tristates, I/O pads, instantiated compo-
nents, carry and cascade chains, and keepbufs. For Altera designs,
registers that are in counter modes are not retimed to preserve the
performance benefit of the counter mode.
You might not be able to crossprobe retimed registers between the RTL
and the Technology view, because there may not be a one-to-one corre-
spondence between the registers in these two views after retiming. A
single register in the RTL view might now correspond to multiple regis-
ters in the Technology view.
Retiming affects or is affected by, these attributes and constraints:
March 2014 589
Attribute/Constraint Effect
False path constraint Does not retime flip-flops with different false path
constraints. Retimed registers affect timing
constraints.
Multicycle constraint Does not retime flip-flops with different multicycle
constraints. Retimed registers affect timing
constraints.
Register constraint Does not maintain define_reg_input_delay and
define_reg_output_delay constraints. Retimed
registers affect timing constraints.
from/to timing
exceptions
If you set a timing constraint using a from/to
specification on a register, it is not retimed. The
exception is when using a max_delay constraint. In
this case, retiming is performed but the constraint is
not forward annotated. (The max_delay value would
no longer be valid.)
syn_hier=macro Does not retime registers in a macro with this
attribute.
syn_keep Does not retime across keepbufs generated because
of this attribute.
syn_hier=macro Does not retime registers in a macro with this
attribute.
syn_pipeline Automatically enabled if retiming is enabled.
syn_preserve Does not retime flip-flops with this attribute set.
syn_probe Does not retime net drivers with this attribute. If the
net driver is a LUT or gate, no flip-flops are retimed
across it.
syn_reference_clock On a critical path, does not retime registers with
different syn_reference_clock values together,
because the path effectively has two different clock
domains.
syn_useioff Does not override attribute-specified packing of
registers in I/O pads. If the attribute value is false,
the registers can be retimed. If the attribute is not
specified, the timing engine determines whether the
register is packed into the I/O block.
syn_allow_retiming Registers are not retimed if the value is 0.
LO
590 March 2014
Retiming does not change the simulation behavior (as observed from
primary inputs and outputs) of your design, However if you are
monitoring (probing) values on individual registers inside the design,
you might need to modify your test bench if the probe registers are
retimed.
Beginning with the C-2009.09-SP1 release, the behavior for retiming
unconstrained I/O pads has changed. If retiming is enabled, registers
connected to unconstrained I/O pins are not retimed by default. If you
want to revert back to how retiming I/O paths was previously imple-
mented, you can:
Globally turn on the Use clock period for unconstrained IO switch from the
Constraints tab of the Implementation Options panel.
Add constraints to all input/output ports.
Separately constrain each I/O pin as required.
March 2014 591
How Retiming Works With Synplify Premier Regions
The following conditions can occur after a register has been retimed:
If the retimed register and its driver and load remain in a Synplify
Premier-specific region, then the register will remain in the region.
If the retimed register is moved outside of a Synplify Premier-specific
region but its load remains in the region, then the register will remain in
the region.
If the retimed register and its driver and load are moved outside a
Synplify Premier-specific region, then the register will be moved outside
the region.
If the retimed register is moved to the boundary of a Synplify Premier-
specific region, then tunneling can occur.
Retiming may move a register across a Synplify Premier-specific region
but not across combinatorial logic.
LO
Chapter 11: Specifying Design-Level Optimizations Preserving Objects from Being Optimized Away
592 March 2014
Preserving Objects from Being Optimized Away
Synthesis can collapse or remove nets during optimization. If you want to
retain a net for simulation, probing, or for a different synthesis implementa-
tion, you must specify this with an attribute. Similarly, the software removes
duplicate registers or instances with unused output. If you want to preserve
this logic for simulation or analysis, you must use an attribute. The following
table lists the attributes to use in each situation. For details about the attri-
butes and their syntax, see the Attributes Reference Manual.
To Preserve
...
Use ... Result
Nets syn_keep on wire or reg (Verilog),
or signal (VHDL).
For Microsemi designs (except
500K and PA), use alspreserve
as well as syn_keep.
Keeps net for simulation, a
different synthesis
implementation, or for passing to
the place-and-route tool.
Nets for
probing
syn_probe on wire or reg
(Verilog), or signal (VHDL)
Preserves internal net for
probing.
Shared
registers
syn_keep on input wire or signal
of shared registers
Preserves duplicate driver cells,
prevents sharing. See Using
syn_keep for Preservation or
Replication, on page 593 for
details on the effects of applying
syn_keep to different objects.
Sequential
components
syn_preserve on reg or module
(Verilog), signal or architecture
(VHDL)
Preserves logic of constant-
driven registers, keeps registers
for simulation, prevents sharing
FSMs syn_preserve on reg or module
(Verilog), signal (VHDL)
Prevents the output port or
internal signal that holds the
value of the state register from
being optimized
Instantiated
components
syn_noprune on module or
component (Verilog),
architecture or instance (VHDL)
Keeps instance for analysis,
preserves instances with unused
outputs
Preserving Objects from Being Optimized Away Chapter 11: Specifying Design-Level Optimizations
March 2014 593
See the following for more information:
Using syn_keep for Preservation or Replication, on page 593
Controlling Hierarchy Flattening, on page 596
Preserving Hierarchy, on page 596
Using syn_keep for Preservation or Replication
By default the tool considers replicated logic redundant, and optimizes it
away. If you want to maintain the redundant logic, use syn_keep to preserve
the logic that would otherwise be optimized away.
The following Verilog code specifies a replicated AND gate:
module redundant1(ina,inb,out1);
input ina,inb;
output out1,out2;
wire out1;
wire out2;
assign out1 = ina & inb;
assign out2 = ina & inb;;
endmodule
The compiler implements the AND function by replicating the outputs out1
and out2, but optimizes away the second AND gate because it is redundant.
LO
594 March 2014
To replicate the AND gate in the previous example, apply syn_keep to the input
wires, as shown below:
module redundant1d(ina,inb,out1,out2);
input ina,inb;
output out1,out2;
wire out1;
wire out2;
wire in1a /*synthesis syn_keep = 1*/;
wire in1b /*synthesis syn_keep = 1*/;
wire in2a /*synthesis syn_keep = 1*/;
wire in2b /*synthesis syn_keep = 1 */;
assign in1a = ina;
assign in1b = inb;
assign in2a = ina;
assign in2b = inb;
assign out1 = in1a & in1b;
assign out2 = in2a & in2b;
endmodule
Setting syn_keep on the input wires ensures that the second AND gate is
preserved:
March 2014 595
You must set syn_keep on the input wires of an instance if you want to
preserve the logic, as in the replication of this AND gate. If you set it on the
outputs, the instance is not replicated, because syn_keep preserves the nets
but not the function driving the net. If you set syn_keep on the outputs in the
example, you get only one AND gate, as shown in the next figure.
LO
596 March 2014
Controlling Hierarchy Flattening
Optimization flattens hierarchy. To control the flattening, use the syn_hier
attribute as described here. You can also use the attribute to prevent
flattening, as described in Preserving Hierarchy, on page 596.
1. Attach the syn_hier attribute with the value you want to the module or
architecture you want to preserve.
You can also add the attribute in SCOPE instead of the HDL code. If you
use SCOPE to enter the attribute, make sure to use the v: syntax. For
details, see syn_hier, on page 205 in the Reference Manual.
The software flattens the design as directed. If there is a lower-level
syn_hier attribute, it takes precedence over a higher-level one.
2. If you want to flatten the entire design, use the syn_netlist_hierarchy
attribute set to false, instead of the syn_hier attribute.
This flattens the entire netlist and does not preserve any hierarchical
boundaries. See syn_netlist_hierarchy, on page 281 in the Reference
Manual for the syntax.
Preserving Hierarchy
The synthesis process includes cross-boundary optimizations that can flatten
hierarchy. To override these optimizations, use the syn_hier attribute as
described here. You can also use this attribute to direct the flattening process
as described in Controlling Hierarchy Flattening, on page 596.
1. Attach the syn_hier attribute to the module or architecture you want to
preserve. You can also add the attribute in SCOPE. If you use SCOPE to
enter the attribute, make sure to use the v: syntax.
To ... Value ...
Flatten all levels below, but not the current level flatten
Remove the current level of hierarchy without affecting
the lower levels
remove
Remove the current level of hierarchy and the lower levels flatten, remove
Flatten the current level (if needed for optimization) soft
March 2014 597
2. Set the attribute value:
The software flattens the design as directed. If there is a lower-level
syn_hier attribute, it takes precedence over a higher-level one.
To ... Value ...
Preserve the interface but allow cell packing across the
boundary
firm
Preserve the interface with no exceptions (Altera, Microsemi,
and Xilinx only)
hard
Preserve the interface and contents with no exceptions
(Microsemi (except PA, 500K, and ProASIC3 families), Altera
and Lattice only)
macro
Flatten lower levels but preserve the interface of the specified
design unit
flatten, firm
LO
Chapter 11: Specifying Design-Level Optimizations Optimizing Fanout
598 March 2014
Optimizing Fanout
You can optimize your results with attributes and directives, some of which
are specific to the technology you are using. Similarly, you can use specify
objects or hierarchy that you want to preserve during synthesis. For a
complete list of all the directives and attributes, see the Reference Manual.
This section describes the following:
Setting Fanout Limits, on page 598
Controlling Buffering and Replication, on page 600
Setting Fanout Limits
Optimization affects net fanout. If your design has critical nets with high
fanout, you can set fanout limits. You can only do this in certain technolo-
gies. For details specific to individual technologies, see the Reference Manual.
1. To set a global fanout limit for the whole design, do either of the
following:
Select Project-> Implementation Options->Device and type a value for the
Fanout Guide option.
Apply the syn_maxfan attribute to the top-level view or module.
The value sets the number of fanouts for a given driver, and affects all
the nets in the design. The defaults vary, depending on the technology.
Select a balanced fanout value. A large constraint creates nets with large
fanouts, and a low fanout constraint results in replicated or buffered
logic. Both extremes affect routing and design performance. The right
value depends on your design. The same value of 32 might result in
fanouts of 11 or 12 and large delays on the critical path in one design or
in excessive replication in another design.
The software uses the value as a soft limit, or a guide. It traverses the
inverters and buffers to identify the fanout, and tries to ensure that all
fanouts are under the limit by replicating or buffering where needed (see
Controlling Buffering and Replication, on page 600 for details). However,
the synthesis tool does not respect the fanout limit absolutely; it ignores
the limit if the limit imposes constraints that interfere with optimization.
Optimizing Fanout Chapter 11: Specifying Design-Level Optimizations
March 2014 599
2. For certain Microsemi technologies, you can set a global hard fanout
limit by doing the following:
Select Project-> Implementation Options->Device and type a value for the
Fanout Guide option, as described in the previous step.
On the same tab, check the Hard Fanout Limit option.
This makes the specified value a global hard fanout limit for the design.
3. To override the global fanout guideline and set a soft fanout limit at a
lower level, set the syn_maxfan attribute on modules, views, or non-
primitive instances.
These limits override the more global limits for that object (including a
global hard limit in Microsemi technologies). However, these limits still
function as soft limits, and are replicated or buffered, as described in
Controlling Buffering and Replication, on page 600.
4. To set a hard or absolute limit, set the syn_maxfan attribute on a port,
net, register, or primitive instance.
Fanouts that exceed the hard limit are buffered or replicated, as
described in Controlling Buffering and Replication, on page 600.
5. To preserve net drivers from being optimized, attach the syn_keep or
syn_preserve attributes.
For example, the software does not traverse a syn_keep buffer (inserted
as a result of the attribute), and does not optimize it. However, the
software can optimize implicit buffers created as a result of other opera-
tions; for example, it does not respect an implicit buffer created as a
result of syn_direct_enable.
Attribute specified on ... Effect
Module or view Soft limit for the module; overrides the global setting.
Non-primitive instance Soft limit; overrides global and module settings
Clock nets or
asynchronous control nets
Soft limit.
LO
Chapter 11: Specifying Design-Level Optimizations Optimizing Fanout
600 March 2014
6. Check the results of buffering and replication in the following:
The log file (click View Log). The log file reports the number of buffered
and replicated objects and the number of segments created for the
net.
The HDL Analyst views. The software might not follow DRC rules
when buffering or replicating objects, or when obeying hard fanout
limits.
Controlling Buffering and Replication
To honor fanout limits (see Setting Fanout Limits, on page 598) and reduce
fanout, the software either replicates components or adds buffers. The tool
uses buffering to reduce fanout on input ports, and uses replication to reduce
fanout on nets driven by registers or combinatorial logic. The software first
tries replication, replicating the net driver and splitting the net into segments.
This increases the number of register bits in the design. When replication is
not possible, the software buffers the signals. Buffering is more expensive in
terms of intrinsic delay and resource consumption. The following table
summarizes the behavior.
Replicates When ... Creates Buffers When ...
syn_maxfan is set on a
register output
syn_maxfan is set on input ports in Microsemi
ProASIC (500K), ProASIC PLUS (PA) and ProASIC3
families.
syn_replicate is 1 syn_replicate is 0.
Note that the syn_replicate attribute must be used in
conjunction with the syn_maxfan attribute for
Microsemi families. The syn_replicate attribute is
used only to turn off the replication.
syn_maxfan is set on a port/net that is driven by a
port or I/O pad
The net driver has a syn_keep or syn_preserve
attribute
The net driver is not a primitive gate or register
Optimizing Fanout Chapter 11: Specifying Design-Level Optimizations
March 2014 601
You can control whether high fanout nets are buffered or replicated, using
the techniques described here:
To use buffering instead of replication, set syn_replicate with a value of 0
globally, or on modules or registers. The syn_replicate attribute prevents
replication, so that the software uses buffering to satisfy the fanout
limit. For example, you can prevent replication between clock bound-
aries for a register that is clocked by clk1 but whose fanin cone is driven
by clk2, even though clk2 is an unrelated clock in another clock group.
To specify that high-fanout clock ports should not be buffered, set
syn_noclockbuf globally, or on individual input ports. Use this if you want
to save clock buffer resources for nets with lower fanouts but tighter
constraints.
Inverters merged with fanout loads increase fanout on the driver during
placement and routing. A distinction is made between a keep buffer
created as the result of the syn_keep attribute being applied by the user
(explicit keep buffer) and a keep buffer that exists as the result of
another attribute (implicit keep buffer). For example, the syn_direct_enable
attribute inserts a keep buffer. When a syn_maxfan attribute is applied to
the output of an explicit keep buffer, the signal is buffered (the keep
buffer is not traversed so that the driver is not replicated). When the
syn_maxfan attribute is applied to the output of an implicit keep buffer,
the keep buffer is traversed and the driver is replicated.
In Xilinx designs, you can handle extremely large clock fanout nets by
inserting a global buffer (BUFG) in your design. A global buffer reduces
delay for a large fanout net and can free up routing resources for other
signals.
Turn off buffering and replication entirely, by setting syn_maxfan to a very
high number, like 1000.
LO
Chapter 11: Specifying Design-Level Optimizations Sharing Resources
602 March 2014
Sharing Resources
One of the ways to optimize area is to use resource sharing in the compiler.
With resource sharing, the software uses the same arithmetic operators for
mutually exclusive statements; for example, with the branches of a case
statement. Conversely, you can improve timing by disabling resource
sharing, but at the expense of increased area.
Compiler resource sharing is on by default. You can set it globally and then
override the global setting on individual modules
1. To disable resource sharing globally for the whole design, use one of the
methods below.
Leave the default setting to improve area; disable the option to improve
timing.
Select Project->Implementation Options->Options, disable Resource Sharing.
Alternatively, disable the Resource Sharing button on the left side of the
Project view.
Apply the syn_sharing directive to the top-level module or architecture
in the source code. See syn_sharing, on page 406 of the Reference
Manual for syntax and examples.
Edit your project file and include the following command: set_option
-resource_sharing 0
When you save the project file, it includes the Tcl set_option
-resource_sharing command.
You cannot specify syn_sharing from the SCOPE interface, because it is a
compiler directive, and works during the compilation stage of synthesis.
The resource sharing setting does not affect the mapper, so even if
resource sharing is disabled, the tool can share resources during the
mapping phase to optimize the design and improve results.
Verilog module top(out, in, clk_in) /* synthesis syn_sharing = "off" */;
VHDL architecture rtl of top is
attribute syn_sharing : string;
attribute syn_sharing of rtl : architecture is "false";
Inserting I/Os Chapter 11: Specifying Design-Level Optimizations
March 2014 603
2. To specify resource sharing on an individual basis or override the global
setting, specify the syn_sharing attribute for the lower-level
module/architecture.
Inserting I/Os
You can control I/O insertion globally, or on a port-by-port basis.
1. To control the insertion of I/O pads at the top level of the design, use the
Disable I/O Insertion option as follows:
Select Project->Implementation Options and click the Device panel.
Enable the option (checkbox on) if you want to do a preliminary run
and check the area taken up by logic blocks, before synthesizing the
entire design.
Do this if you want to check the area your blocks of logic take up,
before you synthesize an entire FPGA. If you disable automatic I/O
insertion, you do not get any I/O pads in your design, unless you
manually instantiate them.
Leave the Disable I/O Insertion checkbox empty (disabled) if you want to
automatically insert I/O pads for all the inputs, outputs and
bidirectionals.
When this option is set, the software inserts I/O pads for inputs,
outputs, and bidirectionals in the output netlist. Once inserted, you
can override the I/O pad inserted by directly instantiating another
I/O pad.
For the most control, enable the option and then manually
instantiate the I/O pads for specific pins, as needed.
For more information about using the Disable I/O Insertion option with
Lattice and Xilinx devices, see syn_insert_pad, on page 233.
2. For Lattice designs, you can force I/O pads to be inserted for input ports
that do not drive logic with the syn_force_pads attribute:
To force I/O pad insertion at the module level, set the syn_force_pads
attribute on the module. Set the attribute value to 1. To disable I/O
pad insertion at the module level, set the syn_force_pads attribute for
the module to 0.
LO
Chapter 11: Specifying Design-Level Optimizations Inserting I/Os
604 March 2014
To force I/O pad insertion on an individual port, set the
syn_force_pads attribute on the port with a value to 1. To disable I/O
insertion for a port, set the attribute on the port with a value of 0.
Enable this attribute to preserve user-instantiated pads, insert pads on
unconnected ports, insert bi-directional pads on bi-directional ports
instead of converting them to input ports, or insert output pads on
unconnected outputs.
If you do not set the syn_force_pads attribute, the synthesis design
optimizes any unconnected I/O buffers away.
Optimizing State Machines Chapter 11: Specifying Design-Level Optimizations
March 2014 605
Optimizing State Machines
You can optimize state machines with the symbolic FSM Compiler and the
FSM Explorer tools.
The Symbolic FSM Compiler
An advanced state machine optimizer, it automatically recognizes state
machines in your design and optimizes them. Unlike other synthesis
tools that treat state machines as regular logic, the FSM Compiler
extracts the state machines as symbolic graphs, and then optimizes
them by re-encoding the state representations and generating a better
logic optimization starting point for the state machines.
The FSM Explorer
A specialized state machine optimizer that explores different encoding
styles before selecting the best style. It uses the FSM Compiler to extract
state machines, and runs the FSM Compiler automatically if it has not
been run.
For more information, see the following:
Deciding when to Optimize State Machines, on page 605
Running the FSM Compiler, on page 606
Running the FSM Explorer, on page 610
Deciding when to Optimize State Machines
The FSM Explorer and the FSM Compiler are automatic tools for encoding
state machines, but you can also specify FSMs manually with attributes. For
more information about using attributes, see Specifying FSMs with Attributes
and Directives, on page 502.
Here are the main reasons to use the FSM Compiler:
To generate better results for your state machines
The software uses optimization techniques that are specifically tuned for
FSMs, like reachability analysis for example. The FSM Compiler also lets
you convert an encoded state machine to another encoding style (to
improve speed and area utilization) without changing the source. For
example, you can use a onehot style to improve results.
LO
Chapter 11: Specifying Design-Level Optimizations Optimizing State Machines
606 March 2014
To debug the state machines
State machine description errors result in unreachable states, so if you
have errors, you will have fewer states. You can check whether your
source code describes your state machines correctly. You can also use
the FSM Viewer to see a high-level bubble diagram and crossprobe from
there. For information about the FSM Viewer, see Using the FSM Viewer,
on page 446.
To run the FSM Explorer
The FSM Explorer is a tool that examines all the encoding styles before
selecting the best option, based on the state machine extraction done by
the FSM Compiler. If the FSM Compiler has not been run previously, the
Explorer automatically runs it. For more information about using the
FSM Explorer, see Running the FSM Explorer, on page 610.
If you are trying to decide whether to use the FSM Compiler or the FSM
Explorer to optimize your state machines, remember these points:
The FSM Explorer runs the FSM Compiler if it has not already been run,
because it picks encoding styles based on the state machines that the
FSM Compiler extracts.
Like the FSM Compiler, you use the FSM Explorer to generate better
results for your state machines. Unlike the FSM Compiler, which picks
an encoding style based on the number of states, the FSM Explorer tries
out different encoding styles and picks the best style for the state
machine based on overall design constraints.
The trade-off is that the FSM Explorer takes longer to run than the FSM
Compiler.
Running the FSM Compiler
You can run the FSM Compiler tool on the whole design or on individual
FSMs. See the following:
Running the FSM Compiler on the Whole Design, on page 607
Running the FSM Compiler on Individual FSMs, on page 608
March 2014 607
Running the FSM Compiler on the Whole Design
1. Enable the compiler by checking the Symbolic FSM Compiler box in one of
these places:
The main panel on the left side of the project window
The Options tab of the dialog box that comes up when you click the
Add Implementation/New Impl or Implementation Options buttons
2. To set a specific encoding style for a state machine, define the style with
the syn_encoding attribute, as described in Specifying FSMs with
Attributes and Directives, on page 502.
If you do not specify a style, the FSM Compiler picks an encoding style
based on the number of states.
3. Click Run to run synthesis.
The software automatically recognizes and extracts the state machines
in your design, and instantiates a state machine primitive in the netlist
for each FSM it extracts. It then optimizes all the state machines in the
design, using techniques like reachability analysis, next state logic
optimization, state machine re-encoding and proprietary optimization
algorithms. Unless you specified an encoding style, the tool automati-
cally selects the encoding style. If you did specify a style, the tool uses
that style.
In the log file, the FSM Compiler writes a report that includes a descrip-
tion of each state machine extracted and the set of reachable states for
each state machine.
4. Select View->View Log File and check the log file for descriptions of the
state machines and the set of reachable states for each one. You see text
like the following:
Extracted state machine for register cur_state
State machine has 7 reachable states with original encodings of:
0000001
0000010
0000100
0001000
0010000
0100000
1000000
....
original code -> new code
LO
608 March 2014
0000001 -> 0000001
0000010 -> 0000010
0000100 -> 0000100
0001000 -> 0001000
0010000 -> 0010000
0100000 -> 0100000
1000000 -> 1000000
5. Check the state machine implementation in the RTL and Technology
views and in the FSM viewer.
In the RTL view you see the FSM primitive with one output for each
state.
In the Technology view, you see a level of hierarchy that contains the
FSM, with the registers and logic that implement the final encoding.
In the FSM viewer you see a bubble diagram and mapping
information. For information about the FSM viewer, see Using the
FSM Viewer, on page 446.
In the statemachine.info text file, you see the state transition
information.
Running the FSM Compiler on Individual FSMs
If you have state machines that you do not want automatically optimized by
the FSM Compiler, you can use one of these techniques, depending on the
number of FSMs to be optimized. You might want to exclude state machines
from automatic optimization because you want them implemented with a
specific encoding or because you do not want them extracted as state
machines. The following procedure shows you how to work with both cases.
1. If you have just a few state machines you do not want to optimize, do the
following:
Enable the FSM Compiler by checking the box in the button panel of
the Project window.
If you do not want to optimize the state machine, add the
syn_state_machine directive to the registers in the Verilog or VHDL
code. Set the value to 0. When synthesized, these registers are not
extracted as state machines.
March 2014 609
If you want to specify a particular encoding style for a state machine,
use the syn_encoding attribute, as described in Specifying FSMs with
Attributes and Directives, on page 502. When synthesized, these
registers have the specified encoding style.
Run synthesis.
The software automatically recognizes and extracts all the state
machines, except the ones you marked. It optimizes the FSMs it
extracted from the design, honoring the syn_encoding attribute. It writes
out a log file that contains a description of each state machine extracted,
and the set of reachable states for each FSM.
2. If you have many state machines you do not want optimized, do this:
Disable the compiler by disabling the Symbolic FSM Compiler box in one
of these places: the main panel on the left side of the project window
or the Options tab of the dialog box that comes up when you click the
Add Implementation or Implementation Options buttons. This disables the
compiler from optimizing any state machine in the design. You can
now selectively turn on the FSM compiler for individual FSMs.
For state machines you want the FSM Compiler to optimize
automatically, add the syn_state_machine directive to the individual
state registers in the VHDL or Verilog code. Set the value to 1. When
synthesized, the FSM Compiler extracts these registers with the
default encoding styles according to the number of states.
For state machines with specific encoding styles, set the encoding
style with the syn_encoding attribute, as described in Specifying FSMs
Verilog reg [3:0] curstate /* synthesis syn_state_machine=0 */;
VHDL signal curstate : state_type;
attribute syn_state_machine : boolean;
attribute syn_state_machine of curstate : signal is
false;v
Verilog reg [3:0] curstate /* synthesis syn_state_machine=1 */;
attribute syn_state_machine of curstate : signal is true;
LO
610 March 2014
with Attributes and Directives, on page 502. When synthesized, these
registers have the specified encoding style.
Run synthesis.
The software automatically recognizes and extracts only the state
machines you marked. It automatically assigns encoding styles to the
state machines with the syn_state_machine attribute, and honors the
encoding styles set with the syn_encoding attribute. It writes out a log file
that contains a description of each state machine extracted, and the set
of reachable states for each state machine.
3. Check the state machine in the log file, the RTL and technology views,
and the FSM viewer, which is not available to Synplify users. For
information about the FSM viewer, see Using the FSM Viewer, on
page 446.
Running the FSM Explorer
1. If you need to customize the extraction process, set attributes.
Use syn_state_machine=0 to specify state machines you do not want to
extract and optimize.
Use syn_encoding if you want to set a specific encoding style.
The FSM Compiler honors the syn_state_machine attribute when it
extracts state machines, and the FSM Explorer honors the syn_encoding
attribute when it sets encoding styles. See Specifying FSMs with Attri-
butes and Directives, on page 502 for details.
Verilog reg [3:0] curstate /* synthesis state_machine */;
attribute syn_state_machine of curstate : signal is true;
Verilog reg [3:0] curstate /* synthesis syn_encoding="gray"*/;
attribute syn_encoding : string;
attribute syn_encoding of curstate : signal is "gray";
March 2014 611
2. Enable the FSM Explorer by checking the FSM Explorer box in one of
these places:
The main panel on the left side of the project window
The Options tab of the dialog box that comes up when you click the
Add Implementation or Implementation Options buttons.
If you have not checked the FSM Compiler option, checking the FSM
Explorer option automatically selects the FSM Compiler option.
3. Click Run to run synthesis.
The FSM Explorer uses the state machines extracted by the FSM
Compiler. If you have not run the FSM Compiler, the FSM Explorer
invokes the compiler automatically to extract the state machines,
instantiate state machine primitives, and optimize them. Then, the FSM
Explorer runs through each encoding style for each state machine that
does not have a syn_encoding attribute and picks the best style. If you
have defined an encoding style with syn_encoding, it uses that style.
The FSM Compiler writes a description of each state machine extracted
and the set of reachable states for each state machine in the log file. The
FSM Explorer adds the selected encoding styles. The FSM Explorer also
generates a <design>_fsm.sdc file that contains the encodings and
which is used for mapping.
4. Select View->View Log File and check the log file for the descriptions. The
following extract shows the state machine and the reachable states as
well as the encoding style, gray, set by FSM Explorer.
Extracted state machine for register cur_state
State machine has 7 reachable states with original encodings of:
0000001
0000010
0000100
0001000
0010000
0100000
1000000
....
Adding property syn_encoding, value "gray", to instance
cur_state[6:0]
List of partitions to map:
view:work.Control(verilog)
LO
612 March 2014
Encoding state machine work.Control(verilog)-
cur_state_h.cur_state[6:0]
original code -> new code
0000001 -> 000
0000010 -> 001
0000100 -> 011
0001000 -> 010
0010000 -> 110
0100000 -> 111
1000000 -> 101
5. Check the state machine implementation in the RTL and Technology
views and in the FSM viewer.
For information about the FSM viewer, see Using the FSM Viewer, on
page 446.
Inserting Probes Chapter 11: Specifying Design-Level Optimizations
March 2014 613
Inserting Probes
Probes are extra wires that you insert into the design for debugging. When
you insert a probe, the signal is represented as an output port at the top
level. You can specify probes in the source code or by interactively attaching
an attribute.
Specifying Probes in the Source Code
To specify probes in the source code, you must add the syn_probe attribute to
the net. You can also add probes interactively, using the procedure described
in Adding Probe Attributes Interactively, on page 614.
1. Open the source code file.
2. For Verilog source code, attach the syn_probe attribute as a comment on
any internal signal declaration:
module alu(out, opcode, a, b, sel);
output [7:0] out;
input [2:0] opcode;
input [7:0 a, b;
input sel;
reg [7:0] alu_tmp /* synthesis syn_probe=1 */;
reg [7:0] out;
//Other code
The value 1 indicates that probe insertion is turned on. For detailed
information about Verilog attributes and examples of the files, see the
Reference Manual.
To define probes for part of a bus, specify where you want to attach the
probes; for example, if you specify reg [1:0] in the previous code, the
software only inserts two probes.
3. For VHDL source code, add the syn_probe attribute as follows:
architecture rtl of alu is
signal alu_tmp : std_logic_vector(7 downto 0);
attribute syn_probe : boolean;
attribute syn_probe of alu_tmp : signal is true;
--other code;
LO
Chapter 11: Specifying Design-Level Optimizations Inserting Probes
614 March 2014
For detailed information about VHDL attributes and sample files, see the
Reference Manual.
4. Run synthesis.
The software looks for nets with the syn_probe attribute and creates
probes and I/O pads for them.
5. Check the probes in the log file (*.srr) and the Technology view.
This figure shows some probes and probe entries in the log file.
Adding Probe Attributes Interactively
The following procedure shows you how to insert probes by adding the
syn_probe attribute through the SCOPE interface. Alternatively, you can add
the attribute in the source code, as described in Specifying Probes in the
Source Code, on page 613.
1. Open the SCOPE window and click Attributes.
2. Push down as necessary in an RTL view, and select the net for which
you want to insert a probe point.
Do not insert probes for output or bidirectional signals. If you do, you
see warning messages in the log file.
3. Do the following to add the attribute:
Drag the net into a SCOPE cell.
Adding property syn_probe, value 1, to net pc[0]
....
@N|Added probe pc_keep_probe_1[0] on pc_keep[0] in
eight_bit_uc
@N|Also padding probe pc_keep_probe_1[0]
eight_bit_uc
eight_bit_uc
Inserting Probes Chapter 11: Specifying Design-Level Optimizations
March 2014 615
Add the prefix n: to the net name in the SCOPE window. If you are
adding a probe to a lower-level module, the name is created by
concatenating the names of the hierarchical instances.
If you want to attach probes to part but not all of a bus, make the
change in the Object column. For example, if you enter
n:UC_ALU.longq[4:0] instead of n:UC_ALU.longq[8:0], the software only
inserts probes where specified.
Select syn_probe in the Attribute column, and type 1 in the Value
column.
Add the constraint file to the project list.
4. Rerun synthesis.
5. Open a Technology view and check the probe wires that have been
inserted. You can use the Ports tab of the Find form to locate the probes.
The software adds I/O pads for the probes. The following figure shows
some of the pads in the Technology view and the log file entries.
....
eight_bit_uc
eight_bit_uc
eight_bit_uc
LO
Chapter 11: Specifying Design-Level Optimizations Inserting Probes
616 March 2014
March 2014 617
CHAPTER 12
Fast Synthesis
The following describe how to use the Fast Synthesis feature in the Synplify
Premier software:
About Fast Synthesis, on page 618
Using Fast Synthesis, on page 619
LO
Chapter 12: Fast Synthesis About Fast Synthesis
618 March 2014
About Fast Synthesis
Fast synthesis is a feature available in the Synplify Premier software. It is a
logic synthesis design flow that is specific to the Synplify Premier tool, like
enhanced optimization.
What fast synthesis does is to significantly reduce synthesis runtimes by a
factor of 2 or 3. It accomplishes this by reducing the number of optimizations
performed, so there is a trade-off in performance.
You can use fast synthesis with designs targeting Altera Stratix and Xilinx
Virtex and Spartan device families.
When to Use Fast Synthesis
Fast synthesis is best used in situations where quality of results (QoR) is not
crucial, or quick turnaround times are more important. Do not use this flow if
performance is critical. The following list some situations where fast
synthesis is effective:
In the initial design development phase, when you need to quickly
evaluate a design or get a baseline result, and performance is secondary.
When exploring "what if" scenarios when you have different implementa-
tions in mind for your design. In such a case, fast synthesis could save
you time working through different runs.
When you need a quick preliminary synthesis result to help get post-
synthesis feedback.
When prototyping a design (Altera Stratix and Xilinx Virtex and Spartan
families only). This can speed up the process for ASIC prototype
designers who are developing initial board-level implementations to
verify the design.
When you need to have quick RTL-to-board turnaround times for debug
iterations.
Using Fast Synthesis Chapter 12: Fast Synthesis
March 2014 619
Using Fast Synthesis
This section describes how to run Synplify Premier fast synthesis.
The Fast Synthesis Design Flow
The following figure summarizes the steps in the fast synthesis design flow.
The steps are described in Running Logic Synthesis with Fast Synthesis, on
page 619.
Running Logic Synthesis with Fast Synthesis
Use the following procedure for quick evaluations or where a faster runtime is
more important than the quality of results.
1. Create a Synplify Premier project.
Add Source Files
Set Constraints
Set Logic Mode
Create Project
Rerun synthesis
Set Options
Analyze Results
Run the Software
Goals Met?
Yes
No
LO
Chapter 12: Fast Synthesis Using Fast Synthesis
620 March 2014
In general, timing attributes are not honored in Fast Synthesis mode.
4. Set options.
Set any options that you want in the Implementation Options dialog box.
Make sure that the Auto Constrain option is disabled.
5. Specify logic synthesis with fast synthesis.
Disable the Physical Synthesis option, either in the Project window or in
the Implementation Options dialog box. This ensures that you are only
running logic synthesis. You cannot run fast synthesis if the Physical
Synthesis option is enabled.
In the Device panel of the Implementation Options dialog box, set Target to
one of the supported Altera or Xilinx families.
Enable Fast Synthesis either in the Project view or the Options panel of
the Implementation Options dialog box. This option is off by default, and
you must explicitly enable it.
The tool reduces the amount and number of logic synthesis
optimizations performed which results in faster runtimes. If you have
both Fast Synthesis and Enhanced Optimization enabled (see Logic
Synthesis with Enhanced Optimization, on page 42), the software
ignores the Enhanced Optimization setting and runs fast synthesis.
Click OK.
7. Analyze the results, using the log file, the HDL Analyst schematic views,
the Message window and the Watch Window.
After you have analyzed the results of this preliminary run, you can do
another fast synthesis run, or disable the Fast Synthesis option and repeat
synthesis with a full-scale logic or physical synthesis run.
Implementation Options->Options Project View
Using Fast Synthesis Chapter 12: Fast Synthesis
March 2014 621
If Fast Synthesis is intended for quick synthesis results and not for a fast
board implementation, it is recommended that you do not run P&R on
the resulting netlist, as you might get sub-optimal QOR and longer P&R
runtimes.
Attributes Limitation
The Fast Synthesis flow does not support the following attributes:
syn_allow_retiming
syn_maxfan
syn_pipeline
syn_replicate
LO
Chapter 12: Fast Synthesis Fast Synthesis and Other Synthesis Options
622 March 2014
Fast Synthesis and Other Synthesis
Options
When you run fast synthesis, other optimizations can be affected.
Option Usage with Fast Synthesis
Auto Constrain Do not use this option with fast synthesis.
Enhanced Optimization Do not set this option with fast synthesis, as it will be
ignored.
FSM Explorer You can use this option with fast synthesis.
Physical synthesis You cannot run fast synthesis with physical synthesis
enabled. Fast synthesis only operates in logic synthesis
mode in the Synplify Premier tool. Fast synthesis does not
generate any placement information.
Pipelining You can use this option with fast synthesis.
Resource Sharing You can use this option with fast synthesis.
Retiming If you enable Fast Synthesis, the tool does not do any
retiming optimizations.
Timing constraints You can set any design constraints as you would normally
do. However, if your goal is to shorten runtimes for a fast
board implementation for example, it is recommended
that you either use loose timing constraints or set the
global clock to 1 Mhz.
March 2014 623
CHAPTER 13
Working with Compile Points
The following sections describe compile points and how to use them in logic
synthesis iterative flows:
Compile Point Basics, on page 624
Compile Point Synthesis Basics, on page 634
Synthesizing Compile Points, on page 644
Using Compile Points with Other Features, on page 659
Resynthesizing Incrementally, on page 661
LO
Chapter 13: Working with Compile Points Compile Point Basics
624 March 2014
Compile Point Basics
Compile points are RTL partitions of the design that you define before synthe-
sizing the design. Compile points can be defined manually, or the tool can
generate them automatically. The software treats each compile point as a
block, and can synthesize, optimize, place, and route the compile points
independently. Compile points can be nested.
See the following topics for some details about compile points:
Advantages of Compile Point Design, on page 624
Automatic and Manual Compile Points, on page 626
Nested Compile Points, on page 627
Compile Point Types, on page 628
Advantages of Compile Point Design
Designing with compile points makes it more efficient to work with the
increasingly larger designs of today and the corresponding team approach to
design. They offer several advantages, which are described here:
Compile Points and Design Flows, next
Runtime Savings, on page 625
Design Preservation, on page 625
Compile Points and Design Flows
Compile points improve the efficacy of both top-down and bottom-up design
flows:
In a traditional bottom-up design flow, compile points make it possible
to easily divide up the design effort between designers or design teams.
The compile points can be worked on separately and individually. The
compile point synthesis flow eliminates the need to maintain the
complex error-prone scripts for stitching, modeling, and ordering
required by the traditional bottom-up design flow.
From a top-down design flow perspective, compile points make it easier
to work on the top-level design. You can mark compile points that are
still being developed as black boxes, and synthesize the top level with
Compile Point Basics Chapter 13: Working with Compile Points
March 2014 625
what you have. You can also customize the compile point type settings
for individual compile points to take advantage of cross-boundary
optimizations.
You can also synthesize incrementally, because the tool does not resyn-
thesize compile points that are unchanged when you resynthesize the
design. This saves runtime and also preserves parts of the design that
are done while the rest of the design is completed.
See Compile Point Synthesis, on page 640 for a description of the synthesis
process with compile points.
Runtime Savings
Compile points are the required foundation for multiprocessing and incre-
mental synthesis, both of which translate directly to runtime savings:
Multiprocessing runs synthesis as multiple parallel processes, using the
compile points as the partitions that are synthesized in parallel on
different processors. See Combining Compile Points with Multipro-
cessing, on page 660.
Incremental synthesis uses compile points to determine which portions
of the design to resynthesize, only resynthesizing the compile points that
have been modified. See Resynthesizing Compile Points Incrementally,
on page 661.
In addition, you can combine all of them with the Synplify Premier Fast
Synthesis mode for even more savings.
Design Preservation
Using compile points addresses the need to maintain the overall stability of a
design while portions of the design evolve. When you use compile points to
partition the design, you can isolate one part from another. This lets you
preserve some compile points, and only resynthesize those that need to be
rerun. These scenarios describe some design situations where compile points
can be used to isolate parts of the design and run incremental synthesis:
During the initial design phase, design modules are still being designed.
Use compile points to preserve unchanged design modules and evaluate
the effects of modifications to parts of the design that are still changing.
LO
626 March 2014
During design integration, use compile points to preserve the main
design modules and only allow the glue logic to be remapped.
If your design contains IP, synthesize the IP, and use compile points to
preserve them while you run incremental synthesis on the rest of the
design.
In the final stages of the design, use compile points to preserve design
modules that do not need to be updated while you work through minor
RTL changes in some other part of the design.
Automatic and Manual Compile Points
Compile points can be generated automatically by the tool or you can create
them manually. A design can contain a mixture of automatic and manual
compile points.
Automatic compile points are simple to use and do not require any setup.
Manual compile points require more setup, but provide more control because
they let you define the partition boundaries and constraints instead of the
tool.
Automatic compile points (ACP)
Automatic compile points offer the simplest way to set up compile points
and are also the most automated way to leverage multiprocessing. The
tool makes the decisions and automatically creates compile points based
on various parameters, like the size of the design, the sizes of hierar-
chical modules, their boundary logic, the number of ports driven by
constants, and so on. For details about this process, see Automatic
Compile Point Generation, on page 647. You do not need to define
boundary constraints for automatic compile points.
The tool automatically sets automatic compile points as hard compile
points. See Compile Point Types, on page 628 for a description. The
down side to using automatic compile points is that they might increase
area if the partition boundaries prevent many cross-boundary optimiza-
tions.
Manual compile points (MCP)
Manual compile points provide more control. You can specify boundary
constraints for each compile point individually. You can separate
completed parts of the design from parts that are still being designed, or
March 2014 627
fine-tune the compile points to take advantage of as many cross-
boundary optimizations as possible. For example, you can ensure that a
critical path does not cross a compile point boundary, thus ensuring
synthesis results with optimal performance.
Guidelines for Using Automatic and Manual Compile Points
Determine the kind of compile point to use based on what the design
requires. The table lists some guidelines:
Nested Compile Points
A design can have any number of compile points, and compile points can be
nested inside other compile points. In the following figure, compile point CP6
is nested inside compile point CP5, which is nested inside compile point CP4.
To simplify things, the term child is used to refer to a compile point that is
contained inside another compile point; the term parent is used to refer to a
container compile point that contains a child. These terms are not used in
their strict sense of direct, immediate containment: If a compile point A is
nested in B, which is nested in C, then A and B are both considered children
of C, and C is a parent of both A and B. The top level is considered the parent
Use Automatic Compile Points ... Use Manual Compile Points ...
When runtime and quick results
are more important than the best
QoR
When you know the design in detail.
Create manual compile points to get better
QoR. Good candidates for manual compile
points include the following:
Completed modules with registered
interfaces, where you want to preserve the
design
Modules created to include an entire critical
path, so as to get the best performance.
Modules that are less likely to be affected by
cross boundary optimizations like constant
propagation and register absorption.
When you expect many updates or
cross-boundary optimization
changes.
When you do not want further optimizations to
a completed compile point.
When you want more control to determine
cross-boundary optimizations on an individual
basis.
LO
628 March 2014
of all compile points. In the figure above, both CP5 and CP6 are children of
CP4; both CP4 and CP5 are parents of CP6; CP5 is an immediate child of CP4
and an immediate parent of CP6.
Compile Point Types
Compile point designs do not have as good QoR as designs without them
because the boundaries limit optimizations. Cross-boundary optimizations
typically improve area and timing, at the expense of runtime. The compile
point type determines whether boundary optimizations are allowed. The tool
marks automatic compile points as hard by default. For manual compile
points, you define the type. See Defining the Compile Point Type, on page 653
for details.
These are descriptions of the soft, hard, locked, locked,partition, and black_box
compile types:
Soft
Compile point boundaries can be reoptimized during top-level mapping.
Timing optimizations like sizing, buffering, and DRC logic optimizations
can modify boundary instances of the compile point and combine them
with functions from the next higher level of the design. The compile
point interface can also be modified. Multiple instances are uniquified.
CP1
CP2
CP3
CP5 is nested inside CP4.
CP5 is an immediate child of CP4.
CP4 is the immediate parent of CP5.
CP4 is also the parent of CP6 and CP7.
The top level is a parent of all compile points.
It is an immediate parent of CP1, CP2, CP3,
and CP4, and parent to all other compile points.
CP6 & CP7 are nested inside CP5.
CP5 is the immediate parent of CP6 & CP7.
CP6 & CP7 are immediate children of CP5.
CP6 & CP7 are children of both CP4 & CP5.
CP4 & CP5 are parents of CP6 & CP7.
Top Level
CP6
CP4
CP5
CP7
March 2014 629
Any optimization changes can propagate both ways: into the compile
point and from the compile point to its parent.
Using soft mode usually yields the best quality of results, because the
software can utilize boundary optimizations. On the other hand, soft
compile points can take a longer time to run than the same design with
hard or locked compile points.
The following figure shows the soft compile point with a dotted boundary
to show that logic can be moved in or out of the compile point.
Hard
For hard compile points, the compile point boundary can be reoptimized
during top-level mapping and instances on both sides of the boundary
can be modified by timing and DRC optimizations using top-level
constraints. However, the boundary is not modified. Any changes can
propagate in either direction while the compile point boundary
(port/interface) remains unchanged. Multiple instances are uniquified.
For performance improvements, constant propagation and removal of
unused logic optimizations are performed across hard compile points.
In the following figure, the solid boundary on the hard compile point
indicates that no logic can be moved in or out of the compile point.
Optimization of entire logic cone across boundary
TOP
compile_point = soft
LO
630 March 2014
The hard compile point type allows for optimizations on both sides of the
boundary without changing the boundary. There is a trade-off in quality
of results to keep the boundaries. Using hard also allows for hierarchical
equivalence checking for the compile point module.
Note: For automatic compile points, the default compile point is hard.
The hard compile point, for automatic compile points, also has the
functionality of the locked and locked, partition compile points. See
Locked, on page 630 and Locked, partition, on page 632.
Locked
This is the default compile point type for manual compile points. With a
locked compile point, the tool does not make any interface changes or
reoptimize the compile point during top-level mapping. An interface logic
model (ILM) of the compile point is created (see Interface Logic Models,
on page 636) and included for the top-level mapping. The ILM remains
unchanged during top-level mapping.
The locked value indicates that all instances of the same compile point
are identical and unaffected by top-level constraints or critical paths. As
a result, multiple instances of the compile point module remain identical
even though the compile point is uniquified. The Technology view (srm
file) shows unique names for the multiple instances, but in the final
Verilog netlist (vma file) the original module names for the multiple
instances are restored.
Timing optimization can only modify instances outside the compile
point. Although the compile point is used to time the top-level netlist,
TOP
compile_point = hard
Optimization on both sides
March 2014 631
changes do not propagate into or out of a locked compile point. The
following figure shows a solid boundary for the locked compile point to
indicate that no logic is moved in or out of the compile point during top-
level mapping.
This mode has the largest trade-off in terms of QoR, because there are
no boundary optimizations. So, it is very important to provide accurate
constraints for locked compile points. The following table lists some
advantages and limitations with the locked compile point:
Advantages Limitations
Consumes smallest amount of memory.
Used for large designs because of this
memory advantage.
Interface timing
Provides most runtime advantage
compared to other compile point types.
Constant propagation
Allows for obtaining stable results for a
completed part of the design.
BUFG insertion
Allows for hierarchical place and route with
multiple output netlists for each compile
point and the top-level output netlist.
GSR hookup
Allows for hierarchical simulation. IO pads, like IBUFs and OBUFs,
should not be instantiated
within compile points
TOP
compile_point = locked
No optimization inside compile point
LO
632 March 2014
functionality of the locked compile point.
Locked, partition
You can also specify a compile point type to be locked, partition. With this
setting and depending on the technology specified, the tool creates the
following:
Altera A designName.tcl file for the compile points that are defined.
Each compile point generates a vqm netlist file that includes a
timestamp used by Quartus II for incremental place and route.
Microsemi A designName_partition.tcl file that contains timestamps
for each compile point. The contents of this file is used in the
incremental synthesis flow.
Xilinx An xpartition.sxml file for the compile points that are defined
and includes timestamps for each compile point. The contents of this
file is used by Xilinx incremental place and route.
This mode offers place-and-route runtime advantages and lets you
converge on stable results for a completed design. However, this mode
has the largest trade-off of quality of results because boundary optimiza-
tions are not allowed.
functionality of the locked, partition compile point.
Black Box
The tool treats black_box compile points as black boxes. It ignores the
contents of the compile point and only uses its ports for synthesis. Black
box compile point modules only write port definitions to the netlist files.
The contents are not written to any of the netlist files (srm, edf, vqm, edn,
vm, or vhm). This compile point type supports all black box directives.
You can change the type of a compile point to black_box at any time
during synthesis. The previous compile point results are retained from
intermediate mapping srd files, but the parent compile point might be
March 2014 633
remapped. This table shows the results when the RTL is unchanged and
a compile point (CP) is changed to black_box for the second synthesis run:
Compile Point Type Summary
The following table summarizes how the tool handles different compile points
during synthesis:
Original CP Effect of changing to black_box
soft The top level is resynthesized because of cross-boundary
optimizations between the top-level and compile point A
during the previous synthesis run. For the second run,
since A is a black box, no logic from the top-level can be
moved into A.
hard Same as soft.
locked Synthesis ignores its contents. When mapping other
hierarchical compile points, the tool uses only the black box
port information. It only writes port definitions to the output
netlist files for these black box compile points.
Features Compile Point Type
Soft Hard Locked Black Box
Boundary optimizations Yes Limited No No
Uniquification of multiple
instance modules
Yes Yes Limited No
Compile point interface (port
definitions)
Modified Not modified Not modified Not modified
Hierarchical simulation No Yes Yes Yes*
Hierarchical equivalence
checking
No Yes Yes Yes*
Interface Logic Model
(created/used)
No Yes Yes No
* If you replace the black box with the original RTL, you can run hierarchical simulation or hierarchical
equivalence checking on the rest of the design.
LO
Chapter 13: Working with Compile Points Compile Point Synthesis Basics
634 March 2014
Compile Point Synthesis Basics
This section describes the compile point constraint files and timing models,
and describes the steps the tool goes through to synthesize compile points.
Compile Point Constraint Files, on page 634
Interface Logic Models, on page 636
Interface Timing for Compile Points, on page 637
Compile Point Synthesis, on page 640
Incremental Compile Point Synthesis, on page 642
Forward-annotation of Compile Point Timing Constraints, on page 643
For step-by-step information about how to use compile points, see Synthe-
sizing Compile Points, on page 644.
Compile Point Constraint Files
A compile point design can contain two levels of constraint files, as described
below:
The constraint file at the top level
This is a required file, and contains constraints that apply to the entire
design. This file also contains the definitions of the compile points in the
design. The define_compile_point command is automatically written to the
top-level constraint file for each compile point you define.
The following figure shows that this design has one locked compile
point, pgrm_cntr. It uses the following syntax to define the compile point:
define_compile_point {v:work.prgm_cntr} -type {locked}
Compile Point Synthesis Basics Chapter 13: Working with Compile Points
March 2014 635
Constraints files at the compile point level
These constraint files are optional, and are used for better control over
manual compile points. If your design consists of automatic compile
points only, you do not need any compile point-level files, and the tool
uses interface timing to synthesize the individual compile points.
The compile point constraints are specific to the compile point and only
apply within it. If your design has manual compile points, you can
define corresponding compile point constraint files for them. See Setting
Constraints at the Compile Point Level, on page 654 for a step-by-step
procedure. Automatic compile points do not require compile point
constraint files, because their constraints come from the top level.
When compile point constraints are defined, the tool uses them to
synthesize the compile point, not automatic interface timing. Note that
depending on the compile point type, the tool might further optimize the
compile points during top-down synthesis of the top level to improve
timing performance and overall design results, but the compile point
itself is synthesized with the defined compile point constraints.
LO
636 March 2014
The first command in a compile point constraint file is
define_current_design, and it specifies the compile point module for the
contained constraints. This command sets the context for the constraint
file. The remainder of the file is similar to the top-level constraint file.
For example:
define_current_design {work.pgrm_cntr}
If your design has some compile points with their own constraint files and
others without them, the tool uses the defined compile point constraints
when it synthesizes those compile points. For the other compile points
without defined constraints, it uses automatic interface timing, as described
in Interface Timing for Compile Points, on page 637.
Interface Logic Models
The interface logic model (ILM) of a locked or hard compile point is a timing
model that contains only the interface logic necessary for accurate timing. An
ILM is a partial gate-level netlist that represents the original design
March 2014 637
accurately while requiring less memory during mapping. Using ILMs
improves the runtime for static timing analysis without compromising timing
accuracy.
The tool does not do any timing optimizations on an ILM. The interface logic
is preserved with no modifications. All logic required to recreate timing at the
top level is included in the ILM. ILM logic includes any paths from an
input/inout port to an internal register, an internal register to an
output/inout port, and an input/inout port to an output/inout port.
The tool removes internal register-to-register paths, as shown in this
example. In this design, and_a is not included in the ILM because the timing
path that goes through and_a is an internal register-to-register path.
Interface Timing for Compile Points
By default, the synthesis tool automatically infers timing constraints for all
compile points from the top-level constraints. However, if a compile point has
its own constraint file, the tool applies those compile point-specific
constraints to synthesize the compile point.
For automatic interface timing, the tool derives constraints from the top
level and uses them to synthesize the compile point. The top level is
synthesized at the same time as the other compile points.
When there are compile point constraint files, the tool first synthesizes
the compile point using the constraints in the compile point constraints
file and then synthesizes the top level using the top-level constraints.
Gates included in ILM
Gate not included
in ILM
and_a and_b
and_c or_a
CP 1
LO
638 March 2014
When it synthesizes a compile point, the tool considers all other compile
points as black boxes and only uses their interface timing information. In the
following figure, when the tool is synthesizing compile point A, it applies
relevant timing information to the boundary registers of B and C, because it
treats them as black boxes.
March 2014 639
Interface Timing Example
The design below shows how the interface timing works on compile points.
Interface Timing Off
Interface timing is off for a compile point when you define constraints for it in
a compile point constraints file. In this example, the following frequencies are
defined for the level1 compile point shown above:
When interface timing is off, the compile point log file (srr) reports the clock
period for the compile point as 20 ns, which is the compile point period.
Clock Period Constraints File
Top-level clock 10 ns Top-level constraint file
Compile point-level clock 20 ns Compile point constraint file
Contents of level1 Module
LO
640 March 2014
Interface Timing On
For automatic interface timing to run on a compile point (interface timing on),
there must not be a compile-point level constraints file. When interface
timing is on, the compile point log file (srr) reports the clock period for the
top-level design, which is 10 ns:
Compile Point Synthesis
During synthesis, the tool first synthesizes the compile points and then maps
the top level. In the case of automatic compile points, the compile points and
the top level are mapped simultaneously. The rest of this section describes
the process that the tool goes through to synthesize compile points; for step-
by-step information about what you need to do to use compile points, see
Synthesizing Compile Points, on page 644.
March 2014 641
Automatic Compile Point Synthesis
The tool synthesizes all compile points individually. The top level is also
treated as a compile point.
A compile point stands on its own, and is optimized separately from its parent
environment (the compile point container or the top level). This means that
critical paths from a higher level do not propagate downwards, and they are
unaffected by them.
Automatic compile points have constraints automatically assigned from the
top level, and you do not need to add any constraints at the compile point
level.
By default, synthesis stops if the tool encounters an error while synthesizing
a compile point. You can specify that the tool ignore the error and continue
synthesizing other compile points. See Using Continue on Error for Compile
Point Synthesis, on page 373.
After synthesis for all the automatic compile points are done, the software
reloads all the automatic compile point results and writes out a single output
netlist and one constraint file for the entire design. See Forward-annotation
of Compile Point Timing Constraints, on page 643 for a description of the
constraints that are forward-annotated.
Manual Compile Point Synthesis
The following headings describe the process of manual compile point
synthesis:
Stage 1: Bottom-up Compile Point Synthesis
The tool synthesizes compile points individually from the bottom up. If you
have enabled multiprocessing, it synthesizes the compile points in parallel
using multiple processing jobs. For nested compile points, it starts with the
compile point at the lowest level of hierarchy and works up the hierarchy.
A compile point stands on its own, and is optimized separately from its parent
environment (the compile point container or the top level). This means that
critical paths from a higher level do not propagate downwards, and they are
unaffected by them.
LO
642 March 2014
If you have specified compile point-level constraints, the tool uses them to
synthesize the compile point; if not, it uses automatic interface timing propa-
gated from the top level. For compile point synthesis, the tool assumes that
all other compile points are black boxes, and only uses the interface informa-
tion.
When defined, compile point constraints apply within the compile point.
Automatic compile points have constraints automatically assigned from the
top level, and you do not need to add any constraints at the compile point
level. For manual compile points, it is recommended that you set constraints
on locked compile points, but setting constraints is optional for soft and hard
compile points.
By default, synthesis stops if the tool encounters an error while synthesizing
a compile point. You can specify that the tool ignore the error and continue
synthesizing other compile points with the Continue on Error option. See Using
Continue on Error for Compile Point Synthesis, on page 373 for details.
Stage 2: Top-Level Synthesis
Once all the compile points have been synthesized, the tool synthesizes the
entire design from the top down, using the model information generated for
each compile point and constraints defined in the top-level constraints file.
You do not need to duplicate compile point constraints at a higher level,
because the tool takes the compile point timing models into account when it
synthesizes a higher level. Note that if you run standalone timing analysis on
a compile point, the timing report reflects the top-level constraints and not
the compile point constraints, although the tool used compile point level
constraints to synthesize the compile point.
The software writes out a single output netlist and one constraint file for the
entire design. See Forward-annotation of Compile Point Timing Constraints,
on page 643 for a description of the constraints that are forward-annotated.
Incremental Compile Point Synthesis
The tool treats compile points as blocks for incremental synthesis. On subse-
quent synthesis runs, the tool runs incrementally and only resynthesizes
those compile points that have changed, and the top level. The synthesis tool
automatically detects design changes and resynthesizes compile points only if
March 2014 643
necessary. For example, it does not resynthesize a compile point if you only
add or change a source code comment, because this change does not really
affect the design functionality.
The tool resynthesizes a compile point that has already been synthesized, in
any of these cases:
The HDL source code defining the compile point is changed in such a
way that the design logic is changed.
The constraints applied to the compile point are changed.
Any of the options on the Device panel of the Implementation Options dialog
box, except Update Compile Point Timing Data, are changed. In this case the
entire design is resynthesized, including all compile points.
You intentionally force the resynthesis of your entire design, including
all compile points, with the Run -> Resynthesize All command.
The Update Compile Point Timing Data device mapping option is enabled and
at least one child of the compile point (at any level) has been remapped.
The option requires that the parent compile point be resynthesized using
the updated timing model of the child. This includes the possibility that
the child was remapped earlier, while the option was disabled. The
newly enabled option requires that the updated timing model of the
child be taken into account, by resynthesizing the parent.
For each compile point, the software creates a subdirectory named for the
compile point, in which it stores intermediate files that contain hierarchical
interface timing and resource information that is used to synthesize the next
level. Once generated, the model file is not updated unless there is an inter-
face design change or you explicitly specify it. If you happen to delete these
files, the associated compile point will be resynthesized and the files regener-
ated.
Forward-annotation of Compile Point Timing Constraints
In addition to a top-level constraint file, each compile point can have its own
constraint file. Constraints are forward-annotated to placement and routing
from the top-level as well as the compile point-level files. However, not all
compile point constraints are forward-annotated, as explained below. For
example, constraints on top-level ports are always forward annotated, but
compile point port constraints are not forward annotated.
Top-level constraints are forward-annotated.
LO
Chapter 13: Working with Compile Points Synthesizing Compile Points
644 March 2014
Constraints applied to the interface (ports and bit ports) of the compile
point are not forward-annotated.
These include input_delays, output_delays, and clock definitions on the
ports. Such constraints are only used to map the compile point itself,
not its parents. They are not used in the final timing report, and they are
not forward-annotated.
Constraints applied to instances inside the compile point are forward-
annotated
Constraints like timing exceptions and internal clocks are used to map
the compile point and its parents. They are used in the final timing
report, and they are forward-annotated.
Synthesizing Compile Points
This section describes the synthesis process with automatic compile points,
manual compile points, or a combination of both in your design:
The Automatic Compile Point Flow, next
The Manual Compile Point Flow, on page 648
Creating a Top-Level Constraints File for Compile Points, on page 651
Defining Manual Compile Points, on page 652
Setting Constraints at the Compile Point Level, on page 654
Analyzing Compile Point Results, on page 656
Using Automatic and Manual Compile Points Together, on page 658
The Automatic Compile Point Flow
The following figure shows how to set up and use automatic compile points
(ACP) in a synthesis flow. The compile point setup section also shows how to
use automatic compile points in a design that includes manual compile
points (MCP).
Synthesizing Compile Points Chapter 13: Working with Compile Points
March 2014 645
1. Create a project and set implementation options as usual.
2. Set constraints.
3. Create a top-level constraints file and set compile point constraints, as
described in Creating a Top-Level Constraints File for Compile Points, on
page 651.
If your design is to include both manual and automatic compile points,
you can define manual compile points at this stage and set constraints
for them. Alternatively, you can generate the automatic compile points
first and then specify manual compile points.
4. Specify that you want to generate compile points automatically.
Enable the Auto Compile Point option in the Project window, or set it on
the Options tab of the Implementation Options dialog box. You can also set
LO
646 March 2014
it with the set_option -automatic_compile_point 1 command in the project
file.
If you do not want a module to be made into an automatic compile
point, set the syn_no_compile_point attribute on that design module in
the top-level constraint file. An automatic compile point is hard and
does not allow for many optimizations, so set this attribute if you
want the tool to optimize a particular module. If the compile point is a
nested compile point, apply the attribute to each level of hierarchy to
prevent the tool from creating a compile point from a sub-module.
See Automatic Compile Point Generation, on page 647 for a description
of the process the tool goes through to generate automatic compile
points.
5. To improve runtime further, use multiprocessing. In the Synplify
Premier tool, you can additionally specify Fast Synthesis.
The tool uses automatic interface timing to determine the constraints for
the compile points. It first synthesizes individual compile points using
interface timing propagated from the top level, and assumes that other
compile points are black boxes. It then synthesizes the top level, as
described in Compile Point Synthesis, on page 640.
For automatic compile points, the top level is treated as another compile
point and is synthesized along with them.
7. Analyze the design.
March 2014 647
For details, see Analyzing Compile Point Results, on page 656. If you
resynthesize the design, the tool uses incremental synthesis. See Resyn-
thesizing Compile Points Incrementally, on page 661 for details.
At this point, you can choose to create additional manual compile points
as needed, by defining them in the top-level constraints file.
If you want to apply constraints to an automatically identified compile
point, first define that compile point as a manual compile point and then
apply constraints to it.
Automatic Compile Point Generation
The automatic compile point process does not generate new hierarchy. It
honors existing hierarchy, so if you have RAMs, ROMs or DSPs that cross
hierarchies, it does not disturb them. The automatic compile point process
does not generate automatic compile points for IP modules like NGCs and
EDIFs.
In a typical design, the tool goes through these stages to generate automatic
compile points and their constraints.
It first identifies compile points based on factors like the size of hierar-
chical modules, their boundary logic, and the number of hierarchical
ports driven by constants.
It then extracts compile point constraints from the top-level timing
constraints, and propagates this interface timing automatically to the
automatic compile points.
If the design has manual compile points that do not have a constraint
file at the top level, the tool derives constraints for them from the top
level, just as with automatic compile points. If the design has manual
compile points with constraints, the tool honors these defined
constraints for the manual compile points.
For black box compile point modules, the tool only writes port defini-
tions to the netlist files. It does not write the contents of the module to
any of the netlist files like srm, edf, vqm, edn, vm, or vhm.
LO
648 March 2014
The Manual Compile Point Flow
Using manual compile points is most advantageous in the following situa-
tions, where you
Have to work with a large design
Experience long runtimes, or need to reduce synthesis runtime
Require the maximum QoR from logic synthesis
Can adjust design methodology to get the best results from the tools
The following figure summarizes the process for using manual compile points
in your design.
This procedure describes the steps in more detail:
1. Set up the project.
March 2014 649
Create the project and add RTL and IP files to the project, as usual.
Target a device and technology for which compile points are
supported. This includes most of the newer Achronix, Altera, Lattice,
Microsemi, and Xilinx device families.
If you are using the Synplify Premier tool, go to the GCC & Prototyping
Tools tab of the Implementation Options dialog box, and enable the
Feedthrough Optimization, Constant Propagation, Create Always/Process Level
Hierarchy, and Optimize Netlist netlist prototype options. For certain
Altera devices, you can also enable Create MAC Hierarchy.
Set other options as usual.
2. Compile the design (F7) to initialize the constraints file.
3. Do the following in the top-level constraint file:
Define compile points in the top-level constraint file. See Creating a
Top-Level Constraints File for Compile Points, on page 651. Note that
by default, the tool automatically calculates the interface timing for
all compile points.
Set timing constraints and attributes in the top-level constraint file:
4. Set compile point-specific constraints as needed in a separate, compile
point-level constraint file.
Constraint Apply to ... Example
Clock All clocks in the design. create_clock {p:clk} -name clk -period
100 -clockgroup cg1
I/O
constraints
All top-level port constraints.
Register the compile point I/O
boundaries to improve timing.
set_input_delay {p:a} {1} -clock {clk:r}
Timing
exceptions
All timing exceptions that are
outside the compile point
module, or that might be
partially in the compile point
modules.
set_false_path -from {i:reg1} -to
{i:reg2}
Attributes All attributes that are
applicable to the rest of the
design, not within the compile
points.
define_attribute {i:statemachine_1}
syn_encoding {sequential}
LO
650 March 2014
See Setting Constraints at the Compile Point Level, on page 654 for a
step-by-step procedure. After setting the compile point constraints, add
the compile point constraint file to the project.
5. If you do not want to interrupt synthesis for compiler errors, select
Options->Configure Compile Point Process and enable the Continue on Error
option.
With this option enabled, the tool black boxes any compile points that
have mapper errors and continues to synthesize the rest of the design.
See Combining Compile Points with Multiprocessing, on page 660 for
more information about this mode.
The tool synthesizes the compile points separately and then synthesizes
the top level. See Compile Point Synthesis, on page 640 for details about
the process.
The first time it runs synthesis, the tool maps the entire design.
For subsequent synthesis runs, the tool only maps compile points
that were modified since the last run. It preserves unchanged compile
points.
You can also run synthesis on individual compile points, without
synthesizing the whole design.
7. Analyze the synthesis results using the top-level srr log file.
See Analyzing Compile Point Results, on page 656 for details.
8. If you do not meet your design goals, make necessary changes to the
RTL, constraints, or synthesis controls, and re-synthesize the design.
The tool runs incremental synthesis on the modified parts of the design,
as described in Incremental Compile Point Synthesis, on page 642. See
Resynthesizing Compile Points Incrementally, on page 661 for a detailed
procedure.
March 2014 651
Creating a Top-Level Constraints File for Compile Points
All compile points require a top-level constraints file. If you have manual
compile points, define them in this file. The top-level file also contains design-
level constraints. The following procedure describes how to create a top-level
constraints file for a compile point design.
1. Create the top-level constraints file.
To define compile points in an existing top-level constraint file, open a
SCOPE window by double-clicking the file in the Project view.
To define compile points in a new top-level constraint file, click the
SCOPE icon. Click on the FPGA Constraints (SCOPE) button.
The SCOPE window opens. It includes a Current Design field, where you
can specify constraints for the top-level design from the drop-down
menu and define manual compile points.
2. Set top-level constraints like input/output delays, clock frequencies or
multicycle paths.
You do not have to redefine compile point constraints at the top level as
the tool uses them to synthesize the compile points.
3. Define manual compile points if needed.
See Defining Manual Compile Points, on page 652 for details.
4. Save the top-level constraints file and add it to the project.
LO
652 March 2014
Defining Manual Compile Points
Compile points and constraints are both saved in a constraint file, so this
step can be combined with the setting of constraints, as convenient. This
procedure only describes how to define compile points. You define compile
points in a top-level constraint file. You can add the compile point definitions
to an existing top-level constraint file or create a new file.
1. From the Current Design field, select the module for which you want to
create the compile point.
2. Click the Compile Points tab in the top-level constraints file.
See Creating a Top-Level Constraints File for Compile Points, on
page 651 if you need information about creating this file.
3. Set the module you want as a compile point.
Do this by either selecting a module from the drop-down list in the View
column, or dragging the instance from the HDL Analyst RTL view to the
View column. The equivalent Tcl command is define_compile_point, as
shown in this example:
define_compile_point {v:work.m3} -type {black_box}
You can get a list of all the modules from which you can select and
designate compile points with the Tcl find command, as shown here:
c_print [find -hier -view {*} -filter ((!@is_black_box) && (@is_verilog == 1 ||
@is_vhdl == 1))] -file view.txt
March 2014 653
4. Set the Type to locked, locked,partition, hard, soft, or black_box, according to
your design goals. See Defining the Compile Point Type, on page 653 for
details.
This tags the module as a compile point. The following figure shows the
prgm_cntr module set as a locked compile point:
5. Save the top-level constraint file.
You can now open the compile point constraint file and define constraints for
the compile point, as needed for manual compile points. See Setting
Constraints at the Compile Point Level, on page 654 for details.
Defining the Compile Point Type
The compile point type you select depends on your design goals. For descrip-
tions of the various compile point types, see Compile Point Types, on
page 628. This procedure shows you how to set the compile point type in the
top-level constraint file when you define the compile points:
1. When runtime is the main objective and QoR is not a primary concern,
set the compile point type as follows on the SCOPE Compile Points tab:
Situation Compile Point Type
RTL is almost ready locked
RTL is still being built
but the module interface
is ready
black_box
If you define black box compile points, you must
update the value and rerun synthesis after you
have completed the RTL for the compile point.
LO
654 March 2014
The following example shows the Tcl command and the equivalent
version in the in the SCOPE GUI:
define_compile_point {v:work.user_top} -type {locked}
2. When runtime and QoR are both important, do the following to ensure
the best performance while still saving runtime:
Register the I/O boundaries for the compile points.
As far as possible, put the entire critical path into the same compile
point.
Set each compile point type individually, using these compile point
types:
3. If your goal is design preservation, set the compile point you want to
preserve to locked.
Setting Constraints at the Compile Point Level
You can specify constraints for each compile point in individual constraint
files. (See Compile Point Constraint Files, on page 634 for a description of the
files.) It is recommended that you specify constraints for each locked manual
compile point, but you do not need to set them for soft and hard compile
points. You do not need to set constraints for automatic compile points.
When you specify compile point constraints, the tool synthesizes the compile
point using the compile point timing models instead of automatic interface
timing from the top level. This procedure explains how to create a (compile
point constraint file, and set constraints for the compile point:
1. In an open project, click the SCOPE icon ( ). Click on the FPGA
Constraints (SCOPE) button. The New Constraints File dialog box opens.
Situation Compile Point Type
Need boundary optimizations soft
Do not need boundary optimizations locked
March 2014 655
2. From the Current Design field, select the module for which you want to
create the compile point.
3. Check that you are in the right file.
A default name for the compile point file appears in the banner of the
SCOPE window. Unlike the top-level constraint file, the Compile Point tab
in the SCOPE UI is greyed out when the constraint file is for a compile
point.
4. Set constraints for the compile point. In particular, do the following:
Define clocks for the compile point.
Specify I/O delay constraints for non-registered I/O paths that may
be critical or near critical.
Set port constraints for the compile point that are needed for top-level
mapping.
The tool uses the compile point constraints you define to synthesize the
compile point. Compile point port constraints are not used at the parent
level, because compile point ports do not exist at that level.
LO
656 March 2014
You can specify SCOPE attributes for the compile point as usual. See
Using Attributes with Compile Points, on page 656 for some exceptions.
5. Save the file and add it to the project. When prompted, click Yes to add
the constraint file to the top-level design project.
Otherwise, use Save As to write a file such as, moduleName.fdc to the
current directory. The hierarchical paths for compile point modules in
the constraint file are specified at the compile point level; not the top-
level design.
Using Attributes with Compile Points
You can use attributes as usual when you set constraints for compile points.
The following sections describe some caveats and exceptions:
syn_hier
When you use syn_hier on a compile point, the only valid value is flatten.
All other values of this attribute are ignored for compile points. The
syn_hier attribute behaves normally for all other module boundaries that
are not defined as compile points.
syn_allowed_resources
Apply the syn_allowed_resources attribute globally or to a compile point to
specify its allowed resources. When a compile point is synthesized, the
resources of its siblings and parents cannot be taken into account
because it stands alone as an independent synthesis unit. This attribute
limits dedicated resources such as block RAMs or DSPs that the compile
point can use, so that there are adequate resources available during the
top-down flow.
Analyzing Compile Point Results
The software writes all timing and area results to a single log file in the imple-
mentation directory. You can check this file and the RTL and Technology
views to determine if your design has met the goals for area and performance.
You can also view and isolate the critical paths, search for and highlight
design objects and crossprobe between the schematics and source files.
1. Check that the design meets the target frequency for the design. Use the
Watch window or check the log file.
March 2014 657
2. Open the log file and check the following:
Check top-level and compile point boundary timing. You can also
check this visually using the RTL and Technology view schematics. If
you find negative slack, check the critical path. If the critical path
crosses the compile point boundary, you might need to improve the
compile point constraints.
If the design was resynthesized, check the Summary of Compile Points
section to see if compile points were preserved or remapped.
Note that this section reports black box compile points as Not Mapped,
and lists the reason as Black Box.
Review all warnings and determine which should be addressed and
which can be ignored.
Review the area report in the log file and determine if the cell usage is
acceptable for your design.
Check all DRC information.
3. Check other files:
Check the individual compile point module log files. The tool creates a
separate directory for each compile point module under the
implementation directory. Check the compile point log file in this
directory for synthesis information about the compile point synthesis
run.
Check the compile point timing report. This report is located in the
compile point results directory of the implementation directory for
each compile point.
4. Check the RTL and Technology view schematics for a graphic view of the
design logic. Even though instantiations of compile points do not have
unique names in the output netlist, they have unique names in the
Technology view. This is to facilitate timing analysis and the viewing of
critical paths.
LO
658 March 2014
Note: Compile points of type {hard} and {locked, partition} are easily located
in the Technology view with the color green.
5. Fix any errors.
Remember that the mapper reports an error if synthesis at a parent level
requires that interface changes be made to a locked compile point. The
software does not change the compile point interface, even if changes
are required to fix DRC violations.
Using Automatic and Manual Compile Points Together
There are two ways to use automatic and manual compile points together in
the same design:
Have the tool generate automatic compile points and then define one or
more of them as manual compile points. Add constraint files for the
manual compile points to the project if needed.
Start with some manual compile points defined. Then enable the
automatic compile points option in the synthesis tool, and let the tool
generate automatic compile points in addition to the manual ones that
have already been defined.
Using Compile Points with Other Features Chapter 13: Working with Compile Points
March 2014 659
Using Compile Points with Other Features
You can effectively combine compile points with other synthesis features for
better runtime. The following sections describe how you can use compile
points with fast synthesis and multiprocessing:
Combining Compile Points with Fast Synthesis, on page 659
Combining Compile Points with Multiprocessing, on page 660
For information about using compile points with Continue on Error, see Using
Continue on Error for Compile Point Synthesis, on page 373.
Combining Compile Points with Fast Synthesis
You can use the Synplify Premier Fast Synthesis mode in a compile point
design to improve runtime.
Do the following to use compile points with fast synthesis:
1. Set up the project with compile points.
Automatic compile points are faster to set up than manual compile
points.
2. Specify fast synthesis, in one of these ways. Disable the Physical Synthesis
option.
Globally Enable Fast Synthesis from the Project window.
On individual compile
points
Open the top-level constraints file, and apply the
syn_cp_use_fast_synthesis attribute to the compile
point module, as shown in this example:
LO
Chapter 13: Working with Compile Points Using Compile Points with Other Features
660 March 2014
3. Specify other features. This is a list of combinations that improve
runtime, with the fastest runtime results first:
Fast synthesis, multiprocessing, and automatic compile points
Fast synthesis and automatic compile points
Fast synthesis and manual compile points
Combining Compile Points with Multiprocessing
To use compile points with multiprocessing, do the following.
1. Set up the project with compile points.
2. Specify the number of parallel jobs to run with the Options->Configure
Compile Point Process command.
Alternatively, you can set this with the set_option -max_parallel_jobs
Tcl command, or in the ini file.
3. Run synthesis.
The software synthesizes the compile points as separate processor jobs.
Parallel processing reduces runtime. If you are using the Synplify
Premier tool, you can use Fast Synthesis mode to further reduce runtime.
Resynthesizing Incrementally Chapter 13: Working with Compile Points
March 2014 661
Resynthesizing Incrementally
Incremental synthesis can significantly reduce runtime on subsequent runs.
It can also help with design stabilization and preservation. The following
describe the incremental synthesis process, and how compile points are used
in incremental synthesis within the tool and with other tools:
Incremental Compile Point Synthesis, on page 642
Resynthesizing Compile Points Incrementally, on page 661
Synthesizing Incrementally with Other Tools, on page 664
Resynthesizing Compile Points Incrementally
The following figure illustrates how compile points (CP) are used in incre-
mental synthesis.
LO
Chapter 13: Working with Compile Points Resynthesizing Incrementally
662 March 2014
1. To synthesize a design incrementally, make the changes you need to fix
errors or improve your design.
Define new compile point constraints or modify existing constraints
in the existing constraint file or in a new constraint file for the
compile point. Save the file.
If necessary, reset implementation options. Click Implementation Options
and modify the settings (operating conditions, optimization switches,
and global frequency).
To obtain the best results, define any required constraints and set the
proper implementation options for the compile point before resynthe-
sizing.
2. Click Run to resynthesize the design.
When a design is resynthesized, compile points are not resynthesized
unless source code logic, implementation options, or constraints have
been modified. If there are no compile point interface changes, the
software synthesizes the immediate parent using the previously gener-
ated model file for the compile point. See Incremental Compile Point
Synthesis, on page 642 for details.
3. Check the log file for changes.
The following figure illustrates incremental synthesis by comparing
compile point summaries. After the first run, a syntax change was made
in the mult module, and a logic change in the comb_logic module. The
figure shows that incremental synthesis resynthesizes comb_logic (logic
change), but does not resynthesize mult because the logic did not change
even though there was a syntax change. Incremental synthesis re-uses
the mapped file generated from the previous run to incrementally
synthesize the top level.
Resynthesizing Incrementally Chapter 13: Working with Compile Points
March 2014 663
4. To force the software to generate a new model file for the compile point,
click Implementation Options on the Device tab and enable Update Compile
Point Timing Data. Click Run.
The software regenerates the model file for each compile point when it
synthesizes the compile points. The new model file is used to synthesize
the parent. The option remains in effect until you disable it.
5. To override incremental synthesis and force the software to resynthesize
all compile points whether or not there have been changes made, use
the Run->Resynthesize All command.
You might want to force resynthesis to propagate changes from a locked
compile point to its environment, or resynthesize compile points one last
time before tape out. When you use this option, incremental synthesis is
disabled for the current run only. The Resynthesize All command does not
regenerate model files for the compile points unless there are interface
changes. If you enable Update Compile Point Timing Data and select Resynthe-
size All, you can resynthesize the entire design and regenerate the
compile point model files, but synthesis will take longer than an incre-
mental synthesis run.
Incremental Run Log Summary
First Run Log Summary
Syntax changes only; not resynthesized
Logic changes; compile
point resynthesized
LO
Chapter 13: Working with Compile Points Resynthesizing Incrementally
664 March 2014
Synthesizing Incrementally with Other Tools
Just as with incremental synthesis, other downstream tools can also take
advantage of the RTL compile points to run incrementally and speed up
runtime through their processes. The Xilinx and Altera place-and-route tools
can leverage the compile points and use them to run incrementally. Similarly,
the Identify tool can run incremental instrumentation if it starts with a
synthesis design with compile points.
For details about how these tools use compile points to run incrementally,
see the following:
Running Altera Quartus II Incrementally, on page 1108
Running Xilinx ISE Incrementally, on page 1131
Working with the Identify Tools, on page 1142
March 2014 665
CHAPTER 14
Working with IP Input
This chapter describes how to work with IP from different sources. It
describes the following:
Generating IP with SYNCore, on page 666
The Synopsys FPGA IP Encryption Flow, on page 702
Working with Encrypted IP, on page 707
Using DesignWare IP, on page 724
Working with Synenc-encrypted IP, on page 728
Using Hyper Source, on page 729
Working with Altera IP, on page 734
Working with SOPC Builder Components, on page 765
Importing Projects from Quartus, on page 769
Working with Lattice IP, on page 778
Incorporating Vivado IP, on page 779
Working with Xilinx IP Cores, on page 795
Converting Xilinx Projects with ise2syn, on page 800
LO
Chapter 14: Working with IP Input Generating IP with SYNCore
666 March 2014
Generating IP with SYNCore
You can use the SYNCore IP wizard to generate FIFO, RAM, ROM,
adder/subtractor, and counter implementations. See the following for more
information.
Specifying FIFOs with SYNCore, on page 666
Specifying RAMs with SYNCore, on page 671
Specifying Byte-Enable RAMs with SYNCore, on page 678
Specifying ROMs with SYNCore, on page 684
Specifying Adder/Subtractors with SYNCore, on page 689
Specifying Counters with SYNCore, on page 696
Specifying FIFOs with SYNCore
The SYNCore IP Wizard helps you generate Verilog code for your FIFO imple-
mentations. The following procedure shows you how to generate Verilog code
for a FIFO using the SYNCore IP wizard.
Note: The SYNCore FIFO model uses Verilog 2001. When adding a FIFO
model to a Verilog-95 design, be sure to enable the Verilog 2001 check
box on the Verilog tab of the Implementation Options dialog box or include
a set_option -vlog_std v2001 statement in your project file to prevent a
syntax error.
1. Start the wizard.
From the synthesis tool GUI, select Run->Launch SYNCore or click the
Launch SYNCore icon to start the SYNCore IP wizard.
Generating IP with SYNCore Chapter 14: Working with IP Input
March 2014 667
In the window that opens, select sfifo_model and click Ok. This opens
the first screen of the wizard.
2. Specify the parameters you need in the five pages of the wizard. For
details, refer to Specifying SYNCore FIFO Parameters, on page 669.
The FIFO symbol on the left reflects the parameters you set.
3. After you have specified all the parameters you need, click the Generate
button (lower left).
The tool displays a confirmation message (TCL execution successful!) and
writes the required files to the directory you specified in the parameters.
The HDL code is in Verilog.
LO
668 March 2014
The FIFO generated is a synchronous FIFO with symmetric ports and
with the same clock controlling both the read and write operations. Data
is written or read on the rising edge of the clock. All resets are synchro-
nous with the clock. All edges (clock, enable, and reset) are considered
positive.
SYNCore also generates a testbench for the FIFO that you can use for
simulation. The testbench covers a limited set of vectors for testing.
You can now close the SYNCore wizard.
4. Add the FIFO you generated to your design.
Use the Add File command to add the Verilog design file that was
generated and the syncore_sfifo.v file to your project. These files are in
the directory for output files that you specified on page 1 of the
wizard.
Use a text editor to open the instantiation_file.vin template file, which is
located in the same directory. Copy the lines that define the memory,
and paste them into your top-level module. The following shows a
template file (in red text) inserted into a top-level module.
module top (
input Clk,
input [15:0] DataIn,
input WrEn,
);
fifo_a32 <instanceName>(
.Clock(Clock)
,.Din(Din)
,.Write_enable(Write_enable)
,.Dout(Dout)
endmodule
template ,.Read_enable(Read_enable)
input RdEn,
,.Full(Full)
,.Empty(Empty)
)
output Full,
output Empty,
output [15:0] DataOut
March 2014 669
Edit the template port connections so that they agree with the port
definitions in the top-level module as shown in the example below.
You can also assign a unique name to each instantiation.
Note that currently the FIFO models will not be implemented with the
dedicated FIFO blocks available in certain technologies.
Specifying SYNCore FIFO Parameters
The following elaborates on the parameter settings for SYNCore FIFOs. The
status, handshaking, and programmable flags are optional. For descriptions
of the parameters, see SYNCore FIFO Wizard, on page 362 in the Reference
Manual. For timing diagrams, see SYNCore FIFO Compiler, on page 704in the
Reference Manual.
1. Start the SYNCore wizard, as described in Specifying FIFOs with
SYNCore, on page 666.
2. Do the following on page 1 of the FIFO wizard:
In Component Name, specify a name for the FIFO. Do not use spaces.
fifo_a32 busfifo(
.Clock(Clk)
,.Din(DataIn)
,.Write_enable(WrEn)
,.Dout(DataOut)
endmodule
module top (
input Clk,
input [15:0] DataIn,
input WrEn,
);
input RdEn,
,.Read_enable(RdEn)
,.Full(Full)
,.Empty(Empty)
)
output Full,
output Empty,
LO
670 March 2014
In Directory, specify a directory where you want the output files to be
written. Do not use spaces.
In Filename, specify a name for the Verilog output file with the FIFO
specifications. Do not use spaces.
Click Next. The wizard opens another page where you can set
parameters.
3. For a FIFO with no status, handshaking, or programmable flags, use the
default settings. You can generate the FIFO, as described in Specifying
FIFOs with SYNCore, on page 666.
4. To set an almost full status flag, do the following on page 2 of the FIFO
wizard:
Enable Almost Full.
Set associated handshaking flags for the signal as desired, with the
Overflow Flag and Write Acknowledge options.
Click Next when you are done.
5. To set an almost empty status flag, do the following on page 3:
Enable Almost Empty.
Set associated handshaking flags for the signal as desired, with the
Underflow Flag and Read Acknowledge options.
6. To set a programmable full flag, do the following:
Make sure you have enabled Full on page 2 of the wizard and set any
handshaking flags you require.
Go to page 4 and enable Programmable Full.
Select one of the four mutually exclusive configurations for
Programmable Full on page 4. See Programmable Full, on page 715
in the Reference Manual for details.
7. To set a programmable empty flag, do the following:
Make sure you have enabled Empty on page 3 of the wizard and set
any handshaking flags you require.
Go to page 5 and enable Programmable Empty.
March 2014 671
Select one of the four mutually exclusive configurations for
Programmable Empty on page 5. See Programmable Empty, on
page 718 in the Reference Manual for details.
You can now generate the FIFO and add it to the design, as described in
Specifying FIFOs with SYNCore, on page 666.
Specifying RAMs with SYNCore
The SYNCore IP wizard helps you generate Verilog code for your RAM imple-
mentation requirements. The following procedure shows you how to generate
Verilog code for a RAM using the SYNCore IP wizard.
Note: The SYNCore RAM model uses Verilog 2001. When adding a RAM
syntax error.
From the synthesis tool GUI, select Run->Launch SYNCore or click the
Launch SYNCore icon to start the SYNCore IP wizard.
In the window that opens, select ram_model and click Ok. This opens
the first screen of the wizard.
LO
672 March 2014
2. Specify the parameters you need in the wizard.
For details about the parameters for a single-port RAM, see
Specifying Parameters for Single-Port RAM, on page 674.
For details about the parameters for a dual-port RAM, see Specifying
Parameters for Dual-Port RAM, on page 675. Note that dual-port
implementations are only supported for some technologies.
The RAM symbol on the left reflects the parameters you set.
The default settings for the tool implement a block RAM with synchro-
nous resets, and where all edges (clock, enable, and reset) are considered
positive.
button in the lower left corner.
The tool displays a confirmation message is displayed (TCL execution
successful!) and writes the required files to the directory you specified in
the parameters. The HDL code is in Verilog.
SYNCore also generates a testbench for the RAM. The testbench covers a
limited set of vectors.
March 2014 673
You can now close the SYNCore Memory Compiler.
4. Edit the RAM files if necessary.
The default RAM has a no_rw_check attribute enabled. If you do not
want this, edit syncore_ram.v and comment out the `define
SYN_MULTI_PORT_RAM statement, or use ùndef
SYN_MULTI_PORT_RAM.
If you want to use the synchronous RAMs available in the target
technology, make sure to register either the read address or the
outputs.
5. Add the RAM you generated to your design.
generated and the syncore_ram.v file to your project. These files are in
wizard.
Use a text editor to open the instantiation_file.vin template file, which is
located in the same directory. Copy the lines that define the memory,
and paste them into your top-level module. The following figure
shows a template file (in red text) inserted into a top-level module.
module top (
input ClkA,
input [7:0] AddrA,
input [15:0] DataInA,
input WrEnA,
output [15:0] DataOutA
);
myram2 <InstanceName> (
.PortAClk(PortAClk)
, .PortAAddr(PortAAddr)
, .PortADataIn(PortADataIn)
, .PortAWriteEnable(PortAWriteEnable)
, .PortADataOut(PortADataOut)
);
endmodule
template
LO
674 March 2014
Specifying Parameters for Single-Port RAM
To create a single-port RAM with the SYNCore Memory Compiler, you need to
specify a single read/write address (single port) and a single clock. You only
need to configure Port A. The following procedure lists what you need to
specify. For descriptions of each parameter, refer to SYNCore RAM Wizard, on
1. Start the SYNCore RAM wizard, as described in Specifying RAMs with
2. Do the following on page 1 of the RAM wizard:
In Component Name, specify a name for the memory. Do not use
spaces.
module top (
input ClkA,
input [7:0] AddrA,
input [15:0] DataInA,
input WrEnA,
output [15:0] DataOutA
);
myram2 decoderram(
.PortAClk(ClkA)
, .PortAAddr(AddrA)
, .PortADataIn(DataInA)
, .PortAWriteEnable(WrEnA)
, .PortADataOut(DataOutA)
);
endmodule
March 2014 675
In Filename, specify a name for the Verilog file that will be generated
with the RAM specifications. Do not use spaces.
Enter data and address widths.
Enable Single Port, to specify that you want to generate a single-port
RAM. This automatically enables Single Clock.
parameters for Port A.
The RAM symbol dynamically updates to reflect the parameters you set.
Set Use Write Enable to the setting you want.
Set Register Read Address to the setting you want.
Set Synchronous Reset to the setting you want. Register Outputs is
always enabled
Specify the read access you require for the RAM.
You can now generate the RAM by clicking Generate, as described in
Specifying RAMs with SYNCore, on page 671. You do not need to specify
any parameters on page 3, as this is a single-port RAM and you do not
need to specify Port B. All output files are in the directory you specified
on the first page of the wizard.
For details about setting dual-port RAM parameters, see Specifying
Parameters for Dual-Port RAM, on page 675. For read/write timing
diagrams, see Read/Write Timing Sequences, on page 728 of the Refer-
ence Manual.
Specifying Parameters for Dual-Port RAM
The following procedure shows you how to set parameters for dual-port
memory in the SYNCore wizard. Dual-port RAMs are only supported for some
technologies. For information about generating single-port RAMs, see Speci-
fying Parameters for Single-Port RAM, on page 674. It shows you how to
generate these common RAM configurations:
One read access and one write access
Two read accesses and one write access
Two read accesses and two write accesses
LO
676 March 2014
For the corresponding read/write timing diagrams, see Read/Write Timing
Sequences, on page 728 of the Reference Manual.
1. Start the SYNCore RAM wizard, as described in Generating IP with
spaces.
with the RAM specifications. Do not use spaces.
Enter data and address widths.
Enable Dual Port, to specify that you want to generate a dual-port
RAM.
Specify the clocks.
parameters for Port A.
3. Do the following on page 2 of the RAM wizard to specify settings for Port
A:
Set parameters according to the kind of memory you want to
generate:
Specify a setting for Register Read Address.
For a single clock ... Enable Single Clock.
For separate clocks for
each of the ports ...
Enable Separate Clocks For Each Port.
One read & one write Enable Read Only Access.
Two reads & one write Enable Read and Write Access.
Specify a setting for Use Write Enable.
Two reads & two writes Enable Read and Write Access.
Specify a read access option for Port A.
March 2014 677
Set Synchronous Reset to the setting you want. Register Outputs is
always enabled.
parameters for Port B. The page and the parameters are identical to
the previous page, except that the settings are for Port B instead of
Port A.
4. Specify the settings for Port B on page 3 of the wizard according to the
kind of memory you want to generate:
The RAM symbol on the left reflects the parameters you set. All output
files are written to the directory you specified on the first page of the
wizard.
You can now generate the RAM by clicking Generate, as described in
Generating IP with SYNCore, on page 666, and add it to your design.
One read & one write Enable Write Only Access.
Set Use Write Enable to the setting you want.
Two reads & one write Enable Read Only Access.
Two reads & two writes Enable Read and Write Access.
Set Synchronous Reset to the setting you want.
Note that Register Outputs is always enabled.
Select a read access option for Port B.
LO
678 March 2014
Specifying Byte-Enable RAMs with SYNCore
The SYNCore IP wizard helps you generate SystemVerilog code for your byte-
enable RAM implementation requirements. The following procedure shows
you how to generate SystemVerilog code for a byte-enable RAM using the
SYNCore IP wizard.
Note: The SYNCore byte-enable RAM model uses SystemVerilog. When
adding a byte-enable RAM to your design, be sure to enable the
System Verilog check box on the Verilog tab of the Implementation Options
dialog box or include a set_option -vlog_std sysv statement in your
project file to prevent a syntax error.
From the FPGA synthesis tool GUI, select Run->Launch SYNCore or
click the Launch SYNCore icon to start the SYNCore IP wizard.
In the window that opens, select byte_en_ram_model and click Ok to
open the first page (page1) of the wizard.
March 2014 679
2. Specify the parameters you need in the wizard. For details about the
parameters, see Specifying Byte-Enable RAM Parameters, on page 682.
The BYTE ENABLE RAM symbol on the left reflects any parameters you
set.
button in the lower left corner. The tool displays a confirmation message
(TCL execution successful!) and writes the required files to the directory you
specified on page 1 of the wizard. The HDL code is in SystemVerilog.
SYNCore also generates a test bench for the byte-enable RAM compo-
nent. The test bench covers a limited set of vectors. You can now close
the SYNCore byte-enable RAM compiler.
4. Edit the generated files for the byte-enable RAM component if necessary.
5. Add the byte-enable RAM that you generated to your design.
On the Verilog tab of the Implementation Options dialog box, make
sure that SystemVerilog is enabled.
generated (the filename entered on page 1 of the wizard) and the
LO
680 March 2014
syncore_*.v file to your project. These files are in the directory for
output files that you specified on page 1 of the wizard.
Use a text editor to open the instantiation_file.vin template file. This file is
located in the same output files directory. Copy the lines that define
the byte-enable RAM and paste them into your top-level module.
definitions in the top-level module; also change the instantiation
name to agree with the component name entered on page 1. The
following figure shows a template file inserted into a top-level module
with the updated component name and port connections in red.
module top
(input ClockA,
input [3:0] AddA
input [31:0] DataIn
input WrEnA,
input Reset
)
INST_TAG
SP_RAM #
(.ADD_WIDTH(4),
.WE_WIDTH(2),
.RADDR_LTNCY_A(1), // 0 - No Latency , 1 - 1 Cycle Latency
.RDATA_LTNCY_A(1), // 0 - No Latency , 1 - 1 Cycle Latency
.RST_TYPE_A(1), // 0 - No Reset , 1 synchronous
.RST_RDATA_A({32{1b1}}),
.DATA_WIDTH(32)
)
4x32spram
(// Output Ports
.RdDataA(DataIn),
// Input Ports
.WrDataA(DataOut),
.WenA(WeEnA),
.AddrA(AddA),
.ResetA(Reset),
.ClkA(ClockA)
);
March 2014 681
Port List
Port A interface signals are applicable for both single-port and dual-port
configurations; Port B signals are applicable for dual-port configuration only.
Name Type Description
ClkA Input Clock input for Port A
WenA Input Write enable for Port A; present when Port
A is in write mode
AddrA Input Memory access address for Port A
ResetA Input Reset for memory and all registers in core;
present with registered read data when
Reset is enabled; active low (cannot be
changed)
WrDataA Input Write data to memory for Port A; present
when Port A is in write mode
RdDataA Output Read data output for Port A; present when
Port A is in read or read/write mode
ClkB Input Clock input for Port B; present in dual-
port mode
WenB Input Write enable for Port B; present in dual-
port mode when Port B is in write mode
AddrB Input Memory access address for Port B; present
in dual-port mode
ResetB Input Reset for memory and all registers in core;
present in dual-port mode when read data
is registered and Reset is enabled; active
low (cannot be changed)
WrDataB Input Write data to memory for Port B; present
in dual-port mode when Port B is in write
mode
RdDataB Output Read data output for Port B; present in
dual-port mode when Port B is in read or
read/write mode
LO
682 March 2014
Specifying Byte-Enable RAM Parameters
When creating a single-port, byte-enable RAM with the SYNCore IP wizard,
you must specify a single read address and a single clock; you only need to
configure the Port A parameters on page 2 of the wizard.
When creating a dual-port, byte-enable RAM, you must additionally configure
the Port B parameters on page 3 of the wizard.
The following procedure lists the parameters you need to specify. For descrip-
tions of each parameter, refer to Parameter List, on page 735 in the reference
manual.
1. Start the SYNCore byte-enable RAM wizard as described in Specifying
Byte-Enable RAMs with SYNCore, on page 678.
2. Do the following on page 1 of the byte-enable RAM wizard:
Specify a name for the memory in the Component Name field; do not
use spaces.
Specify a directory name in the Directory field where you want the
output files to be written; do not use spaces.
Specify a name in the File Name field for the SystemVerilog file to be
generated with the byte-enable RAM specifications; do not use
spaces.
Enter a value for the address width of the byte-enable RAM; the
maximum depth of memory is limited to 2^256.
Enter a value for the data width for the byte-enable RAM; data width
values range from 2 to 256.
Enter a value for the write enable width; write-enable width values
range from 1 to 4.
Select Single Port to generate a single-port, byte-enable RAM or select
Dual Port to generate a dual-port, byte-enable RAM.
Click Next to open page 2 of the wizard.
The Byte Enable RAM symbol dynamically updates to reflect the param-
eters that you set.
March 2014 683
3. Do the following on page 2 (configuring Port A) of the wizard:
Select the Port A configuration. Only Read and Write Access mode is
valid for single-port configurations; this mode is selected by default.
Set Pipelining Address Bus and Output Data according to your
application. By default, read data is registered; you can register both
the address and data registers.
Set the Configure Reset Options. Enabling the checkbox enables the
synchronous reset for read data. This option is enabled only when the
read data is registered. Reset is active low and cannot be changed.
Configure output reset data value options under Specify output data
on reset; reset data can be set to default value of all '1' s or to a user-
defined decimal value. Reset data value options are disabled when
the reset is not enabled for Port A.
Set Write Enable for Port A value; default for the write-enable level is
active high.
4. If you are generating a dual-port, byte-enable RAM, set the Port B
parameters on page 3 (note that the Port B parameters are only enabled
when Dual Port is selected on page 1).
The Port B parameters are identical to the Port A parameters on page 2.
When using the dual-port configuration, when one port is configured for
read access, the other port can only be configured for read/write access
or write access.
5. Generate the byte-enable RAM by clicking Generate. Add the file to your
project and edit the template file as described in Specifying Byte-Enable
RAMs with SYNCore, on page 678. For read/write timing diagrams, see
Read/Write Timing Sequences, on page 732 of the reference manual.
LO
684 March 2014
Specifying ROMs with SYNCore
The SYNCore IP wizard helps you generate Verilog code for your ROM imple-
mentation requirements. The following procedure shows you how to generate
Verilog code for a ROM using the SYNCore IP wizard.
Note: The SYNCore ROM model uses Verilog 2001. When adding a ROM
syntax error.
In the window that opens, select rom_model and click Ok to open page
1 of the wizard.
March 2014 685
parameters, see Specifying ROM Parameters, on page 688. The ROM
symbol on the left reflects any parameters you set.
button in the lower left corner. The tool displays a confirmation message
(TCL execution successful!) and writes the required files to the directory you
specified on page 1 of the wizard. The HDL code is in Verilog.
SYNCore also generates a testbench for the ROM. The testbench covers
a limited set of vectors.
You can now close the SYNCore ROM Compiler.
4. Edit the ROM files if necessary. If you want to use the synchronous
ROMs available in the target technology, make sure to register either the
read address or the outputs.
5. Add the ROM you generated to your design.
generated and the syncore_rom.v file to your project. These files are in
LO
686 March 2014
wizard.
Use a text editor to open the instantiation_file.vin template file. This file
is located in the same output files directory. Copy the lines that
define the ROM, and paste them into your top-level module. The
following figure shows a template file (in red text) inserted into a top-
level module.
module test_rom_style(z,a,clk,en,rst);
input clk,en,rst;
output reg [3:0] z;
input [6:0] a;
my1stROM <InstanceName> (
// Output Ports
.DataA(DataA),
// Input Ports
.ClkA(ClkA),
.EnA(EnA),
.ResetA(ResetA),
.AddrA(AddrA)
);
template
March 2014 687
Port List
PortA interface signals are applicable for both single-port and dual-port
configurations; PortB signals are applicable for dual-port configuration only.
Name Type Description
ClkA Input Clock input for Port A
EnA Input Enable input for Port A
AddrA Input Read address for Port A
ResetA Input Reset or interface disable pin for Port A
DataA Output Read data output for Port A
ClkB Input Clock input for Port B
EnB Input Enable input for Port B
AddrB Input Read address for Port B
ResetB Input Reset or interface disable pin for Port B
DataB Output Read data output for Port B
module test_rom_style(z,a,clk,en,rst);
input clk,en,rst;
output reg [3:0] z;
input [6:0] a;
my1stROM decode_rom(
// Output Ports
.DataA(z),
// Input Ports
.ClkA(clk),
.EnA(en),
.ResetA(rst),
.AddrA(a)
);
LO
688 March 2014
Specifying ROM Parameters
If you are creating a single-port ROM with the SYNCore IP wizard, you need to
specify a single read address and a single clock, and you only need to
configure the Port A parameters on page 2. If you are creating a dual-port
ROM, you must additionally configure the Port B parameters on page 3. The
following procedure lists what you need to specify. For descriptions of each
parameter, refer to SYNCore RAM Wizard, on page 372 in the Reference
Manual.
1. Start the SYNCore ROM wizard, as described in Specifying ROMs with
2. Do the following on page 1 of the ROM wizard:
spaces.
with the ROM specifications. Do not use spaces.
Enter values for Read Data width and ROM address width (minimum depth
value is 2; maximum depth of the memory is limited to 2^256).
Select Single Port Rom to indicate that you want to generate a single-
port ROM or select Dual Port Rom to generate a dual-port ROM.
Click Next. The wizard opens page 2 where you set parameters for Port
A.
The ROM symbol dynamically updates to reflect any parameters you set.
3. Do the following on page 2 (Configuring Port A) of the RAM wizard:
For synchronous ROMs, select Register address bus AddrA and/or
Register output data bus DataA to register the read address and/or the
outputs. Selecting either checkbox enables the Enable for Port A
checkbox which is used to select the Enable level.
Set the Configure Reset Options. Enabling the checkbox enables the type
of reset (asynchronous or synchronous) and allows an output data
pattern (all 1s or a specified pattern) to be defined on page 4.
4. If you are generating a dual-port ROM, set the port B parameters on
page 3 (the page 3 parameters are only enabled when Dual Port Rom is
selected on page 1).
March 2014 689
5. On page 4, specify the location of the ROM initialization file and the data
format (Hexadecimal or Binary). ROM initialization is supported using
memory-coefficient files. The data format is either binary or hexadecimal
with each data entry on a new line in the memory-coefficient file
(specified by parameter INIT_FILE). Supported file types are txt, mem, dat,
and init (recommended).
6. Generate the ROM by clicking Generate, as described in Specifying ROMs
with SYNCore, on page 684 and add it to your design. All output files are
in the directory you specified on page 1 of the wizard.
For read/write timing diagrams, see Read/Write Timing Sequences, on
Specifying Adder/Subtractors with SYNCore
The SYNCore IP wizard helps you generate Verilog code for your
adder/subtractor implementation requirements. The following procedure
shows you how to generate Verilog code for an adder/subtractor using the
SYNCore IP wizard.
Note: The SYNCore adder/subtractor models use Verilog 2001. When
adding an adder/subtractor model to a Verilog-95 design, be sure to
enable the Verilog 2001 check box on the Verilog tab of the Implementation
Options dialog box or include a set_option -vlog_std v2001 statement in
your project file to prevent a syntax error.
LO
690 March 2014
n the window that opens, select addnsub_model and click Ok to open
page1 of the wizard.
March 2014 691
parameters, see Specifying Adder/Subtractor Parameters, on page 694.
The ADDnSUB symbol on the left reflects any parameters you set.
The tool displays a confirmation message (TCL execution successful!)
and writes the required files to the directory you specified on page 1 of
the wizard. The HDL code is in Verilog.
The SYNCore wizard also generates a testbench for your
adder/subtractor. The testbench covers a limited set of vectors. You can
now close the wizard.
4. Add the adder/subtractor you generated to your design.
Edit the adder/subtractor files if necessary.
generated and the syncore_addnsub.v file to your project. These files are
in the directory for output files that you specified on page 1 of the
wizard.
Use a text editor to open the instantiation_file.v template file. This file is
the adder/subtractor and paste them into your top-level module. The
following figure shows a template file (in red text) inserted into a top-
level module.
LO
692 March 2014
module top (
output [15 : 0] Out,
input Clk,
input [15 : 0] A,
input CEA,
input RSTA,
input [15 : 0] B,
input CEB,
template
March 2014 693
input RSTB,
input CEOut,
input RSTOut,
input ADDnSUB,
input CarryIn);
My_ADDnSUB ADDnSUB_inst (
// Output Ports
.PortOut(Out),
// Input Ports
.PortClk(Clk),
.PortA(A),
.PortCEA(CEA),
.PortRSTA(RSTA),
.PortB(B),
.PortCEB(CEB),
.PortRSTB(RSTB),
.PortCEOut(CEOut),
.PortRSTOut(RSTOut),
.PortADDnSUB(ADDnSUB),
.PortCarryIn(CarryIn));
endmodule
Port List
The following table lists the port assignments for all possible configurations;
the third column specifies the conditions under which the port is available.
Port Name Description Required/Optional
PortA Data input for
adder/subtractor
Parameterized width and
pipeline stages
Always present
PortB Data input for
adder/subtractor
Parameterized width and
pipeline stages
Not present if
adder/subtractor is
configured as a constant
adder/subtractor
PortClk Primary clock input; clocks all
registers in the unit
Always present
PortRstA Reset input for port A pipeline
registers (active high)
Not present if pipeline stage
for port A is 0
LO
694 March 2014
Specifying Adder/Subtractor Parameters
The SYNCore adder/subtractor can be configured as any of the following:
Adder
Subtractor
Dynamic Adder/Subtractor
If you are creating a constant input adder, subtractor, or a dynamic
adder/subtractor with the SYNCore IP wizard, you must select Constant Value
Input and specify a value for port B in the Constant Value/Port B Width field on
page 2 of the parameters. The following procedure lists the parameters you
need to define when generating an adder/subtractor. For descriptions of each
parameter, see SYNCore Adder/Subtractor Wizard, on page 383 in the Refer-
ence Manual.
PortRstB Reset input for port B pipeline
registers (active high)
for port B is 0 or for constant
adder/subtractor
PortADDnSUB Selection port for dynamic
operation
Not present if
adder/subtractor configured
as standalone adder or
subtractor
PortRstOut Reset input for output register
(active high)
Not present if output pipeline
stage is 0
PortCEA Clock enable for port A
pipeline registers (active high)
for port A is 0
PortCEB Clock enable for port B
pipeline registers (active high)
for port B is 0 or for constant
adder/subtractor
PortCarryIn Carry input for
adder/subtractor
Always present
PortCEOut Clock enable for output
register (active high)
Not present if output pipeline
stage is 0
PortOut Data output Always present
March 2014 695
1. Start the SYNCore adder/subtractor wizard as described in Specifying
Adder/Subtractors with SYNCore, on page 689.
2. Enter the following on page 1 of the wizard:
n the Component Name field, specify a name for your
adder/subtractor. Do not use spaces.
In the Directory field, specify a directory where you want the output
files to be written. Do not use spaces.
n the Filename field, specify a name for the Verilog file that will be
generated with the adder/subtractor definitions. Do not use spaces.
Select the appropriate configuration in Configure the Mode of Operation.
3. Click Next. The wizard opens page 2 where you set parameters for port A
and port B.
4. Configure Port A and B.
In the Configure Port A section, enter a value in the Port A Width field.
If you are defining a synchronous adder/subtractor, check Register
Input A and then check Clock Enable for Register A and/or Reset for Register
A.
To configure port B as a constant port, go to the Configure Port B
section and check Constant Value Input. Enter the constant value in the
Constant Value/Port B Width field.
To configure port B as a dynamic port, go to the Configure Port B
section and check Enable Port B and enter the port width in the
Constant Value/Port B Width field.
To define a synchronous adder/subtractor, check Register Input B and
then check Clock Enable for Register B and/or Reset for Register B.
5. In the Configure Output Port section:
Enter a value in the Output port Width field.
If you are registering the output port, check Register output Port.
If you are defining a synchronous adder/subtractor check Clock Enable
for Register PortOut and/or Reset for Register PortOut.
6. In the Configure Reset type for all Reset Signal section, click Synchronous Reset
or Asynchronous Reset as appropriate.
LO
696 March 2014
As you enter the page 2 parameters, the ADDnSUB symbol dynamically
updates to reflect the parameters you set.
7. Generate the adder/subtractor by clicking the Generate button as
described in Specifying Adder/Subtractors with SYNCore, on page 689
and add it to your design. All output files are in the directory you
specified on page 1 of the wizard.
Specifying Counters with SYNCore
The SYNCore IP wizard helps you generate Verilog code for your counter
implementation requirements. The following procedure shows you how to
generate Verilog code for a counter using the SYNCore IP wizard.
Note: The SYNCore counter model uses Verilog 2001. When adding a
counter model to a Verilog-95 design, be sure to enable the Verilog
2001 check box on the Verilog tab of the Implementation Options dialog box
or include a set_option -vlog_std v2001 statement in your project file to
prevent a syntax error.
n the window that opens, select counter_model and click Ok to open
page1 of the wizard.
March 2014 697
parameters, see Specifying Counter Parameters, on page 700. The
COUNTER symbol on the left reflects any parameters you set.
The tool displays a confirmation message (TCL execution successful!)
and writes the required files to the directory you specified on page 1 of
the wizard. The HDL code is in Verilog.
The SYNCore wizard also generates a testbench for your counter. The
testbench covers a limited set of vectors. You can now close the wizard.
4. Add the counter you generated to your design.
Edit the counter files if necessary.
generated and the syncore_addnsub.v file to your project. These files are
in the directory for output files that you specified on page 1 of the
wizard.
LO
698 March 2014
Use a text editor to open the instantiation_file.v template file. This file is
the counter and paste them into your top-level module. The following
figure shows a template file (in red text) inserted into a top-level
module.
template
March 2014 699
module counter #(
parameter COUNT_WIDTH = 5,
parameter STEP = 2,
parameter RESET_TYPE = 0,
parameter LOAD = 2,
parameter MODE = "Dynamic" )
(
// Output Ports
output wire [WIDTH-1:0] Count,
// Input Ports
input wire Clock,
input wire Reset,
input wire Up_Down,
input wire Load,
input wire [WIDTH-1:0] LoadValue,
input wire Enable);
SynCoreCounter #(
.COUNT_WIDTH(COUNT_WIDTH),
.STEP(STEP),
.RESET_TYPE(RESET_TYPE),
.LOAD(LOAD),
.MODE(MODE))
SynCoreCounter_ins1 (
.PortCount(PortCount),
.PortClk(Clock),
.PortRST(Reset),
.PortUp_nDown(Up_Down),
.PortLoad(Load),
.PortLoadValue(LoadValue),
.PortCE(Enable));
endmodule
Port List
The following table lists the port assignments for all possible configurations;
the third column specifies the conditions under which the port is available.
LO
700 March 2014
Specifying Counter Parameters
The SYNCore counter can be configured for any of the following functions:
Up Counter
Down Counter
Dynamic Up/Down Counter
The counter core can have a constant or variable input load or no load value.
If you are creating a constant-load counter, you will need to select Enable Load
and Load Constant Value on page 2 of the wizard. If you are creating a variable-
load counter, you will need to select Enable Load and Use Variable Port Load on
page 2. The following procedure lists the parameters you need to define when
generating a counter. For descriptions of each parameter, see SYNCore
Counter Wizard, on page 387 of the Reference Manual.
1. Start the SYNCore counter wizard, as described in Specifying Counters
with SYNCore, on page 696.
2. Enter the following on page 1 of the wizard:
PortCE Count Enable input pin with
size one (active high)
Always present
PortClk Primary clock input Always present
PortLoad Load Enable input which
loads the counter (active high).
Not present for parameter
LOAD=0
PortLoadValue Load value primary input
(active high)
Not present for parameter
LOAD=0 and LOAD=1
PortRST Reset input which resets the
counter (active high)
Always present
PortUp_nDown Primary input which
determines the counter mode.
0 = Up counter
1 = Down counter
Present only for
MODE=Dynamic
PortCount Counter primary output Always present
March 2014 701
n the Component Name field, specify a name for your counter. Do not
use spaces.
In the Directory field, specify a directory where you want the output
files to be written. Do not use spaces.
n the Filename field, specify a name for the Verilog file that will be
generated with the counter definitions. Do not use spaces.
Enter the width and depth of the counter in the Configure the Counter
Parameters section.
Select the appropriate configuration in the Configure the Mode of Counter
section.
3. Click Next. The wizard opens page 2 where you set parameters for
PortLoad and PortLoadValue.
Select Enable Load option and the required load option in Configure Load
Value section.
Select the required reset type in the Configure Reset type section.
The COUNTER symbol dynamically updates to reflect the parameters you
set.
4. Generate the counter core by clicking Generate button. All output files
are written to the directory you specified on page1 of the wizard.
LO
Chapter 14: Working with IP Input The Synopsys FPGA IP Encryption Flow
702 March 2014
The Synopsys FPGA IP Encryption Flow
The Synopsys FPGA IP encryption flow is a design flow that encourages
interoperability while protecting IP implementations using encryp-
tion/decryption technologies. This flow offers the following advantages:
interoperability, protection of IP, reuse of IP, and a standard flow for IP
encryption. Currently, Synopsys FPGA synthesis products support the
following encryption technologies:
P1735 with key-block (Version 1)
OpenIP
Overview of the Synopsys FPGA IP Flow
The complete flow for protecting IP requires a partnership between the IP
vendor, Synopsys, and the silicon vendor as illustrated in the following figure.
However, depending on the level of agreement between Synopsys and the
silicon vendor downstream, the re-encryption of IP following synthesis can
vary from the ideal flow shown in the figure.
The Synopsys FPGA IP Encryption Flow Chapter 14: Working with IP Input
March 2014 703
For further details of the hand-offs between vendors and how encryption and
decryption are handled, see Encryption and Decryption, on page 703.
Encryption and Decryption
There are two major classes of encryption/decryption algorithms: symmetric,
and asymmetric (see Encryption and Decryption Methodologies, on page 759
in the Reference Manual for details). Each has its own advantages and disad-
vantages. The approach for the Synopsys FPGA IP flow is a hybrid scheme
that uses both asymmetric and symmetric encryption to leverage the
strengths of each scheme. The methodology described here can also be used
for other design hand-offs. For example, for a handoff from synthesis to
place-and-route, the synthesis tool would be in the upstream position
occupied by the IP vendor in this flow, and the FPGA vendor would be in the
downstream position occupied by the synthesis tool.
LO
704 March 2014
The following figure illustrates the steps in this encryption/decryption
methodology, showing the handoff from an IP vendor to a Synopsys FPGA
synthesis tool.
The following describes each of the phases shown in the figure. Note that
Synopsys provides the following scripts to simplify and automate the process
of encrypting data for the IP vendor.
P1735
OpenIP
4.
3.
5.
Unencrypted
source data
Encrypt with IP vendors
symmetric data key
Encrypt data key with
Synopsys public key
Bundle data block and
key block in one file
Symmetrically
encrypted
data block
Asymmetrically
encrypted key
block
Decode data key with
Synopsys private key
Decode data block with
decrypted data key
1.
2.
Bundled file
with data block
and key block
Unencrypted
source data
Symmetrically
encrypted
data block
IP VENDOR
Synopsys FPGA
Private
Public
S
S
The Synopsys FPGA IP Encryption Flow Chapter 14: Working with IP Input
March 2014 705
Data Encryption - Step 1
The IP vendor encrypts the IP data using their own symmetric key. This key is
called the data key. The result of encoding is a data block. Using symmetric
encryption offers two advantages to the IP vendor: fast data encryption
because it is symmetric encryption, and freedom to use any symmetric
scheme they choose.
Data Key Encryption - Step 2
Next, the IP vendor encrypts the data key used to encode the IP block, and
generates a key block. For this operation, the vendor uses RSA asymmetric
encryption and the public key provided by Synopsys.
Asymmetric encryption offers the following advantages:
Although asymmetric encryption is compute-intensive, the data key
itself is small, so this is not time-intensive.
The IP vendor can use public keys from different vendors to encrypt the
same block for different EDA vendors. This capability ensures that IP
consistency is maintained, because there is no need for multiple copies.
Only the public key from the downstream vendor needs to be passed to
the IP vendor.
Source data Encrypted data
Symmetric Encryption/Decryption with One Key
Source data Encrypted data
Public key
Private key
Asymmetric Encryption/Decryption with Public and Private Keys
LO
706 March 2014
Bundling of Encrypted Data Block and Data Key - Step 3
The IP vendor bundles the encrypted data block with the key block into one
file for handoff to the EDA vendor. Note that this methodology allows the IP
vendor to create just one version of the IP which includes the key blocks for
all the downstream vendors it supports; for example, a synthesis tool and a
simulation tool. Also, this approach eliminates the need to securely transmit
the symmetric key, because this is included in the file. Security is maintained
because both the key and the data are encrypted.
In the figure, this is the point at which the IP vendor hands off the IP to the
synthesis tool.
Data Key Decryption - Step 4
Decryption is a two-stage process. The first step is to decrypt the symmetric
data key from the IP vendor, which was encrypted using the asymmetric
public key provided. To decode this key, use the private key counterpart to
the public key and extract the data key.
Data Decryption - Step 5
The second step is to use the extracted data key to access the IP data. As the
data key is the original symmetric key used to encode the IP, the process is
quick. The synthesis tools can now synthesize the unencrypted IP.
After synthesis, the IP can be re-encrypted if the vendor has adopted one of
the Synopsys methodologies. See Output Methods for encryptIP, on page 54 in
the Reference Manual for a description of the choices available.
Re-Encryption in the Synopsys FPGA IP Flow
Re-encryption of the synthesized IP for FPGA vendors downstream requires
that the FPGA vendor supply Synopsys with a public key. When the input file
includes a downstream key block, the re-encrypted data is accessible to the
downstream tool. If such an agreement is not in place, the IP is treated as a
black box. Accordingly, you can have an IP flow that outputs black boxes in
the netlists, plaintext netlists, or encrypted netlists.
Working with Encrypted IP Chapter 14: Working with IP Input
March 2014 707
Working with Encrypted IP
The Synopsys FPGA IP encryption schemes available include:
P1735
OpenIP
With either of these approaches, the IP vendor can encrypt and control distri-
bution of the IP from their own website. The synthesis user will have access
from the synthesis tool to the IP that the vendor makes available for
download and evaluation within a synthesis design.
The following sections describe how to encrypt and package your IP for evalu-
ation if you are an IP vendor, and how to access and evaluate available IP, if
you are an end-user.
Encrypting Your IP, on page 707
Preparing the IP Package, on page 717
Encrypting Your IP
IP vendors can use either of the supported Synopsys FPGA IP schemes to
provide IP for synthesis users to evaluate and use. Both schemes uses a two-
stage encryption process:
First, encrypt your IP files using a symmetric encryption algorithm and
your own session or data key to create an encrypted data block.
Next, encrypt the session key for the encrypted data block using an
asymmetric algorithm and the Synopsys public key. All of the Synopsys
encryption methodologies support RSA encryption.
Synopsys provides scripts to simplify this process. See the following proce-
dures for details on script usage.
Preparing and Encrypting Your IP
To prepare and encrypt your IP, do the following:
1. Gather your RTL files.
LO
Chapter 14: Working with IP Input Working with Encrypted IP
708 March 2014
You only encrypt the RTL. You can encrypt any number of Verilog and
VHDL (or mixed) RTL files to form your encrypted IP, and each file can
be encrypted in its entirety.
2. Determine your file setup for each IP.
Create a single set of files for the IP (for use with all supported FPGAs)
if your IP has no vendor-specific or vendor-optimized content and if
the output method is supported by all intended consumers (blackbox
or plaintext).
Create multiple versions of your protected IP if you have specific
FPGA vendors or specific FPGA vendor families, if you are using FPGA
device-family specific RTL like architecture-specific instantiations, or
if you optimized your RTL or constraints for use with a specific FPGA
vendor device family or FPGA vendor.
Encrypt the files with the appropriate encryption script as described
in one of the following subsections:Encrypting IP with the
encryptP1735.pl Script, on page 708
Encrypting IP with the encryptIP Script, on page 714.
3. Package your IP, as described in Preparing the IP Package, on page 717.
4. Verify that your IP works with the synthesis tools by going through the
procedure that the user would use.
Start the synthesis tool and load the IP with the Import IP->Import IP
Package command. You can load your IP into an existing Synplify
project.
For system-level IP, run it through the System Designer tool and
ensure bus-model compatibility between your IP and any other IP to
which it interfaces. See the System Designer documentation for
details on using this tool.
Run synthesis.
Encrypting IP with the encryptP1735.pl Script
The encryptP1735.pl script supports the P1735 proposed standard with limited
interoperability. The encryptP1735.pl script accepts inputs from three sources:
command line arguments, the RTL input file, and a file containing the public
keys. The RTL input file, depending on the use model, may contain encryp-
tion attributes.
March 2014 709
A keys.txt file, which contains the public key for consumption by Synopsys
FPGA tools, is included with the script. Add other public keys to this file
when the IP is to be consumed by additional EDA tools.
The following procedure shows you how to encrypt your data with the
encryptP1735.pl script. This script automates the two-stage encryption process
described in the Synopsys FPGA IP scheme (The Synopsys FPGA IP Encryp-
tion Flow, on page 702). The encryptP1735.pl script:
First encrypts your IP files using a symmetric encryption algorithm and
your own session or data key to create an encrypted data block.
Next encrypts the session key for the encrypted data block using an
asymmetric algorithm and the Synopsys public key. The Synplify tool
currently supports RSA encryption.
The encryptP1735.pl script is located in the installDir/lib directory and requires
the installation of Perl on your machine. The following examples show typical
script applications. For more information on the script and the command line
arguments, see encryptP1735, on page 57 in the Command Reference
Manual. The encryptP1735 encryption script supports the following three use
models for encrypting RTL files:
Full-File Use Model
Partial File with All Pragmas Use Model
Partial File with Minimal Pragmas Use Model
Full-File Use Model
With a full-file use model, the RTL contains no encryption-related pragmas,
and the entire RTL file is encrypted by encryptP1735.pl to create the decryption
envelope. This use model is intended to be used with complete RTL files that
do not require the addition of encryption attributes; the encryptP1735.pl
script automatically adds these attributes to create the decryption envelope.
To illustrate the full-file use model, consider a single, Verilog file (tb_encrypt.v)
to be encrypted without pragmas. This file contains a single module named
secret.
module secret (a, b, clk);
input a, clk;
output b;
reg b=0;
LO
710 March 2014
b = a;
end
endmodule
With no encryption-related pragmas in the RTL file, a decryption envelope is
created with the command:
perl encryptP1735.pl -list mylist -log encryptP1735.log
In the above command, the list file (mylist) contains the single Verilog file
tb_encrypt.v. The command uses the default keys.txt file from the directory
installLocation/lib as the public keys file to create the decryption envelope file
tb_encrypt.vp. The resulting messages are written in the encryptP1735.log file.
Partial File with All Pragmas Use Model
With the partial file with all pragmas use model, the RTL contains all of the
encryption-related pragmas which are used by the encryptP1735.pl script with
the default keys.txt file to create the decryption envelope.
When there are overlapping pragmas in the RTL and the keys.txt file, the RTL
pragma takes precedence over the corresponding pragma in the keys.txt file.
For example, if the data_method pragma contains des-cbc in the RTL and
aes128-cbc in the keys.txt file, the following pragma is copied to the decryption
envelope:
data_method="des-cbc"
Verilog Example
To illustrate the partial file with all pragmas use model, consider a single,
Verilog file (tb_encrypt.v) to be encrypted. This file contains a module named
secret and all the encryption-related pragmas with the exception of the
key_public_key in the RTL itself.
input a, clk;
output b;
`pragma protect version=1
`pragma protect encoding=(enctype="base64")
`pragma protect author="author-a", author_info="author-a-details"
`pragma protect encrypt_agent="encryptP1735.pl", encrypt_agent_info="Synplify encryption scripts"
`pragma protect key_keyowner="Synopsys",key_keyname="SYNP05_001", key_method="rsa", key_block
`pragma protect data_keyowner="ip-vendor-a",data_keyname="fpga-ip", data_method="des-cbc"
`pragma protect begin
reg b=0;
March 2014 711
b = a;
end
`pragma protect end
endmodule
With the encryption-related pragmas in the RTL file, a decryption envelope is
perl encryptP1735.pl -list mylist
tb_encrypt.vp. Any messages from the run are not output to a log file.
VHDL Example
To encrypt a partial VHDL file with an all pragmas use model, consider the
single, VHDL file (tb_encrypt.vhd). The file contains a single entity/architecture
pair named secret with all the encryption-related pragmas with the exception
of the key_public_key in the RTL itself.
Note: VHDL formatted pragmas do not include a pragma string
preceding the keyword protect.
library IEEE;
entity secret is
port (clk : in std_logic;
a : in std_logic;
b : out std_logic );
end entity;
architecture rtl of secret is
`protect version=1
`protect author="author-a", author_info="author-a-details"
`protect encrypt_agent="encryptP1735.pl", encrypt_agent_info="Synplify encryption scripts"
`protect encoding=(enctype="base64")
`protect key_keyowner="Synopsys", key_keyname="SYNP05_001", key_method="rsa", key_block
`protect data_keyowner="ip-vendor-a", data_keyname="fpga-ip", data_method="des-cbc"
`protect begin
signal b_reg: std_logic;
begin
process (clk) is
begin
b_reg <= a;
end if;
end process;
b <= b_reg;
`protect end
LO
712 March 2014
end architecture;
With the encryption-related pragmas in the RTL file, a decryption envelope is
In the above command, the list file (mylist) contains the single VHDL file
tb_encrypt.vhd. The command uses the default keys.txt file from the directory
tb_encrypt.vhdp. Any messages from the run are not output to a log file.
Partial File with Minimal Pragmas Use Model
With the partial file with minimal pragmas use model, the RTL contains only
the begin and end encryption-related pragmas to indicate the start and end
points of the encryption. This use model is helpful when automatic insertion
is used to reduce the amount of manually inserted pragmas. After defining
the start- and end-point pragmas, the encryptP1735.pl script, using the default
keys.txt file, creates the decryption envelope. To illustrate this use model,
consider a single, Verilog file (tb_encrypt.v) to be encrypted with only begin and
end pragmas. This file contains a single module named secret.
input a, clk;
output b;
`pragma protect begin
reg b=0;
b = a;
end
`pragma protect end
endmodule
With the start and end pragmas in the RTL file, a decryption envelope is
tb_encrypt.vp. The absence of a specified log file (-log option) results in no
messages being written to the log file.
March 2014 713
Encrypting Multiple RTL Files
The examples in the previous sections included a single Verilog or VHDL file.
Multiple files can be similarly encrypted by adding their file names to the
specified list file. Running the script produces encryption envelopes for each
listed file. To create a list file for multiple files, add the name of each file to be
encrypted on a separate line.
Public Keys Repository File
The encryptP1735.pl encryption script requires public keys from the file speci-
fied by the -public_keys (or -pk) option. This file includes public keys for each of
the tools that require a key block in the encrypted file.
// Use verilog pragma syntax in this file
`pragma protect version=1
`pragma protect author="default"
`pragma protect author_info="default"
`pragma protect key_keyowner="Synopsys", key_keyname="SYNP05_001", key_method="rsa"
`pragma protect key_public_key
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAybsQaMidiCHZyh14wbXn
UpP8lK+jJY5oLpGqDfSW5PMXBVp0WFd1d32onXEpRkwxEJLlK4RgS43d0FG2ZQ1l
irdimRKNnUtPxsrJzbMr74MQkwmG/X7SEe/lEqwK9Uk77cMEncLycI5yX4f/K9Q9
WS5nLD+Nh6BL7kwR0vSevfePC1fkOa1uC7b7Mwb1mcqCLBBRP9/eF0wUIoxVRzjA
+pJvORwhYtZEhnwvTblBJsnyneT1LfDi/D5WZoikTP/0KBiP87QHMSuVBydMA7J7
g6sxKB92hx2Dpv1ojds1Y5ywjxFxOAA93nFjmLsJq3i/P0lv5TmtnCYX3Wkryw4B
eQIDAQAB
// Add additional public keys below this line
// Add additional public keys above this line
`pragma protect data_keyowner="default-ip-vendor"
`pragma protect data_keyname="default-ip-key"
`pragma protect data_method="aes128-cbc"
// End of file
For the partial file with all pragmas use model, the following pragma attribute
values must match the corresponding values in the key-block section of the
encryption envelope:
`pragma protect key_keyowner="Synopsys", key_keyname="SYNP05_001", key_method="rsa"
Note: This encryptP1735.pl script is compatible only with versions
I-2013.09 and later of the Synopsys FPGA synthesis tool.
For information on the pragmas supported by the encryptP1735.pl script, see
Pragmas Used in the encryptIP Script, on page 766 of the Reference Manual.
LO
714 March 2014
Encrypting IP with the encryptIP Script
The following procedure shows you how to encrypt your data with the
encryptIP (OpenIP) script. The encryptIP script automates the two-stage encryp-
tion process proposed in the Synopsys FPGA IP scheme (The Synopsys FPGA
IP Encryption Flow, on page 702).
First, it encrypts your IP files using a symmetric encryption algorithm
and your own session or data key. This creates an encrypted data block.
Next, it encrypts the session key for the encrypted data block using an
asymmetric algorithm and the Synopsys public key. The Synplify tool
currently supports RSA encryption.
1. Install the encryptIP Perl script.
You can download the encryptIP Perl script from SolvNet. See the
article published at:
https://solvnet.synopsys.com/retrieve/032343.html
Install Perl on your machine. You cannot run the script if you do not
have Perl installed.
2. Make sure that the encryptIP script specifies the decryption key and the
matching key length:
Specify the symmetric data decryption key with the -k option.
Optionally, you can also specify a symmetric encryption key in
hexadecimal format with the -kx option.
Make sure you specify the right key length for the encryption
algorithm with the -c option. For example, TEST1234 becomes a 64-bit
key, so you specify the des-cbc algorithm.
See Syntax, on page 52 in the Reference Manual for full details of the
encryptip syntax.
3. Make sure you specify the appropriate output method (-om) when you
run the script.
This is important because the output method (-om) determines what is
encrypted to the user. When the example above is synthesized, the user
can view the output netlist because the output method specified is plain-
text, which means that the synthesis output netlist includes the IP
netlist in an unencrypted and readable form. See Specifying the Script
Output Method, on page 715 for more information.
March 2014 715
The script encrypts the IP with the standard symmetric encryption
algorithm you specified, and produces a data_block. The data key used for
encrypting the HDL is then encrypted with an asymmetric algorithm and
the Synopsys public key, and produces a key_block. The data_block and
the key_block are combined with the appropriate pragmas for the flow
being used, and the script creates an encrypted HDL file. For a detailed
figure, see Encryption and Decryption, on page 703.
All other output files from synthesis, including srm, srd, and srs files,
are encrypted using the same encryption method specified for the input
to synthesis. Output constraints are not encrypted.
4. Run the encryptIP script on each RTL file you want to encrypt.
The following example encrypts the Verilog plain_ip.v file into an
encrypted file called protected_ip.v, using AES128-cbc encryption. The
session key is MY_AES_SAMPLEKEY. See Syntax, on page 52 in the Refer-
ence Manual for details about the syntax and required parameters.
perl encryptIP -in plain_ip.v -out protected_ip.v -c aes128-cbc
-k MY_AES_SAMPLEKEY bd 16OCT2007 -om plaintext -v
5. Check the encrypted RTL file to make sure that there is only one key
block present.
Specifying the Script Output Method
You can control access to the IP by setting the appropriate output method.
You specify the output method using the -om parameter, as described in
Syntax, on page 52 or Syntax, on page 58 in the Reference Manual.
The output method mainly affects the output netlist. The following are guide-
lines for setting the output method for the encryptIP script, and detail the
effects of different settings:
1. When using the encrypyIP script, set -om to persistent_key in the following
cases:
If you are working with a Lattice non-CPLD technology
If you have an agreement in place with Synopsys and want the output
netlist to be encrypted
2. Set -om to plaintext in the following cases:
LO
716 March 2014
If you want to allow the IP to be incorporated in a physical synthesis
or logic synthesis design
For physical synthesis, the Synplify Premier tool runs global
placement and logic synthesis simultaneously. To place the IP and its
contents, the tool must be allowed to access and optimize it. Setting
the output method to plaintext allows the tool to synthesize, run gate-
level simulations, place and route, and implement an FPGA (that
includes the IP) on a board.
If you want the IP to be freely optimized by the synthesis tools
Although IP cores are already optimized, the synthesis tools can effect
additional optimizations based on the design context in which it will
be used. When the synthesis tool is allowed to optimize the IP, it can
prune away IP logic that is unused or unnecessary in the current
design context. Or take the case where the output of an instantiated
IP core is timing-critical because it drives hundreds of user loads. If
the synthesis tool can freely optimize, it can replicate sources within
the core and fix the problem.
3. To let the IP be incorporated in a logic synthesis design, set -om to
plaintext or blackbox.
Setting the output method to plaintext allows the tool to synthesize, run
gate-level simulations, place and route, and implement an FPGA (that
includes the IP) on a board. Setting the output method to blackbox does
not allow the tool to run gate-level simulations or place and route the IP,
because it only uses the port and connectivity information.
4. If you have set -om to plaintext and you want to specify individual cores as
white boxes, set the syn_macro directive to 1 on the view for the IP.
Note that you must set this on the view, not the instance. When this is
set, the tool treats the IP as a white box and only uses the timing and
connection information from the IP. The synthesis tool maintains the IP
boundary and only trims unused logic inside the IP.
5. During synthesis, the IP contents appear as a black box in the RTL and
Physical Analyst views, irrespective of the output method selected. When
the output method is set to plaintext, you can push down into the IP from
the Technology view.
6. After synthesis, the output method affects the results in the following
ways:
March 2014 717
Output constraints for an IP are in the standard Synopsys format and
are not encrypted.
The output method affects the contents of the output netlist and its
format. This table summarizes the encryptIP or encryptP1735 behavior
with different output methods.
Preparing the IP Package
Do the following to package your IP and make it accessible from the synthesis
tools:
1. Collect the files for the package.
Encrypt the files you need, as described in Encrypting Your IP, on
page 707.
Make sure your package includes the files listed in IP Package File
List, on page 719.
Structure the files as described in Suggested Directory Structure, on
page 720.
2. For IP-XACT models for use with System Designer (see Providing System-
Level Models for the IP, on page 721), make sure of the following:
At a minimum, include a top-level xml file that specifies the complete
component, vendor, library, name, and component version (VLNV).
This file references library components that are described in other
files in the directory tree using relative paths.
Method (-om) Output Netlist After Synthesis
blackbox The output netlist contains the IP interface only, and no IP
contents. It only includes IP ports and connections. The IPs are
treated as black boxes, and there are no nets or instances shown
inside the IP. This applies to all the netlist formats generated for
different vendors, whether it is HDL (vm or vhm), EDIF (edf or
edn), or vqm.
plaintext The output netlist contains your unencrypted synthesized IP,
which is completely readable (nothing is encrypted).
persistent_key
(encryptIP only)
The output netlist includes encrypted versions of the IP. For
Lattice designs, the tool generates one output netlist (EDIF or
HDL) that includes the encrypted IP blocks. The netlist is
readable, except for the IP block sections, which are encrypted.
LO
718 March 2014
If you want to allow System Designer to generate HDL files for the IP
for later synthesis, include the Verilog/VHDL files for the IP in the
package. This allows the core to be evaluated using a synthesis flow.
If you do not want to allow System Designer to generate HDL files for
synthesis, do not include the Verilog/VHDL files in the package. The
System Designer tool creates a top-level netlist and corresponding
wrappers and generates an error message for the missing files. This
method allows the core to be tested for compatibility with the rest of
the system, but it will not be an evaluation with complete synthesis.
The IP-XACT models consist of a library of your system-level compo-
nents, including bus definitions. When System Designer reads this
library, the various components like specific timers, buses, and CPUs,
appear in the library window for the user to drag and drop and instan-
tiate, as they assemble a design from the components. See the System
Designer documentation for details.
3. If your IP package is intended for synthesis only, without subsystem
assembly, create a compressed package for download, using one of these
methods:
Create a compressed tarball (.tar.gz), which is a tar archive
compressed with the gzip utility, using one of these commands:
tar cf -fileList | gzip -c > compressed-tarball
gtar -cf compressed-tarball fileList
Preserve the directory structure when you run gzip.
Create a zip file (zip) by running WinZip. WinZip archives and
preserves your directory hierarchy.
4. If your IP package is intended to be a subsystem that will be assembled
by System Designer, create a compressed tarball (.tar.gz) using one of
these commands:
tar cf -fileList | gzip -c > compressed-tarball
gtar -cf compressed-tarball fileList
Preserve the directory structure when you run gzip.
5. Post the packaged IP on your website for downloading.
March 2014 719
The user generally untars or unzips the IP package into a top-level direc-
tory after downloading it. The synthesis tools can then read the contents
of the directory.
6. Supply Synopsys with the following:
The URL for the download package.
Vendor and advertising information you wish to display on the
Synopsys website. See Supplying Vendor Information, on page 722 for
details.
IP Package File List
Your IP package should contain the following files:
Files Description
ipinfo.txt Text file that lists the name of the IP, the version, restrictions
for use, support contact information, and an email alias to
request a licence for the full RTL for your IP.
Documentation,
preferably a PDF
Documents the IP, and includes detailed information about
usage restrictions like vendor, device family, etc.
Readme An optional text file that contains instructions on use of the IP
for assembly and/or synthesis, and hints on how to use it
correctly.
Encrypted HDL or
EDIF
Protected RTL for the IP, created using the Synopsys encryptIP
script. See the documentation for details.
SDC constraints Unencrypted design constraints for the IP. You need only
maintain a single file for both the Synopsys synthesis tools, as
the Synplify Pro software ignores any constraints that are
specific to the Synplify Premier software.
SPIRIT IP-XACT
v1.4 models
System-level models for your IP. This allows the synthesis
tools to include your IP in a system-level design by stitching
the IP together using bus architectures.
LO
720 March 2014
Suggested Directory Structure
Follow these recommendations when you structure the IP package:
If you include a Synopsys prj project file or an xml file for use in System
Designer, make sure to use relative paths from the prj or xml directory
to refer to other files like the Verilog or VHDL files.
Always use relative paths to reference a file.
Always preserve directory structure when you run gzip.
You can place IP-XACT xml files in the top-level directory or in a common
subdirectory. You can have multiple files or a single file for the same
component or variants of a component. However, it is preferred that you
keep all IP-XACT components that are in one library at the same direc-
tory level, even if it is many levels deep in the directory hierarchy.
For packaging, System Designer treats IP-XACT bus definitions just like
IP core components. So, place each bus definition in its own separate
sub-hierarchy, parallel to the sub-hierarchies of your other system-level
components. This makes it easy for the user to see if the component
library includes the necessary bus definitions, and to load just the bus
definition files into System Designer.
The following example shows the structure of a Leon2 processor, which is
included with the System Designer installation. Note that although compo-
nents are placed deep in the hierarchy, they are all at the same depth.
Common files are in the common subdirectory, at the same level as the compo-
nents. Bus definitions are at the same depth, in a parallel directory.
March 2014 721
Providing System-Level Models for the IP
If you have system-level IP like microprocessors and peripherals, you can
additionally provide system-level models for your protected IP. This allows
users to assemble your IP as part of a subsystem, using the Synplify Pro and
Synplify Premier system-level assembly tool, System Designer.
This tool reads IP-XACT models (an XML schema) as defined by the SPIRIT
Consortium (www.spiritconsortium.org). The current release of System Designer
is Spirit v1.4 compliant.
LO
722 March 2014
Supplying Vendor Information
To make your IP accessible for downloads and evaluation from the Synopsys
synthesis tools, you must supply Synopsys with some vendor information as
well as information for each of the cores or IPs to be used.
1. Supply Synopsys with the following general information to advertise
your company and IP on the Synopsys website:
2. Supply Synopsys with the following information about each core or IP to
be used:
IP vendor name and logo Your vendor name and logo for display.
Optional IP description Short paragraph describing the IP and key
features.
Email alias Synopsys sends leads to this alias when evaluation
cores are requested on the Synopsys IP website.
Website URL Unique URL for accessing IP. After the user has
filled out lead information on the website, the
Synopsys tool directs the user to this URL to
download the IP. The lead form on your website can
be pre-filled by prior arrangement with Synopsys
Marketing.
IP name Name of the IP.
IP short
description
Sentence describing the IP, which is displayed in the
summary view on the Synopsys website.
IP paragraph
description
More detailed description of the IP, covering functional
description and compatibility with other cores or
peripherals.
Notes about usage Any other information, like licensing requirements
March 2014 723
Core datasheet
(HTML or PDF)
Information about the characteristics, features,
functions, and interfaces.
Supported FPGA
vendors and
devices
List of the targeted vendors and devices that the core
supports.
IP-XACT
compatibility
information
List of the IP-XACT version number supported, the IP-
XACT VLNV, and the IP-XACT VLNVs of all the bus
definitions required for the core, along with a link to
download each of these bus definitions.
LO
Chapter 14: Working with IP Input Using DesignWare IP
724 March 2014
Using DesignWare IP
Synplify Premier
You can implement DesignWare IP in FPGA designs from the Synopsys
DesignWare foundation library building blocks. The Synopsys foundation
library is licensed separately. See the following sections for details:
Using DesignWare Building Blocks, on page 724
DW_Foundation_Arith Package, on page 726
Using DesignWare Building Blocks
Synplify Premier
This section describes how to use the building blocks from the DesignWare
foundation library with the Synplify Premier tools. For a list of the available
building blocks, see http://www.synopsys.com/dw/buildingblock.php.
1. Install the Synopsys DesignWare foundation library included in the
Synopsys Design Compiler download; a separate license is required.
2. Set the path to the DesignWare foundation library by doing either of the
following:
Specify the path to the library using the dc_root installPath Tcl
command.
Select the Implementation Options dialog box and use either the Verilog or
VHDL tab to enter the path to the library in the Design Compiler
Installation Location [$SYNOPSYS=]: field
To access the DesignWare foundation library from a Windows machine,
use the map network drive utility to mount the library on an available
Windows drive.
Using DesignWare IP Chapter 14: Working with IP Input
March 2014 725
3. Enable the use of the DesignWare foundation library from the GUI or
command line:
Check the Use DesignWare Foundation Library checkbox on either the
Verilog or VHDL tab
Enter one of the these Tcl commands:
set_option -dw_foundation 1
set_option -dw_library {dw_foundation}
4. To use low-power building blocks in place of standard DesignWare
building blocks, enable the DesignWare minPower library from the GUI
or command line:
Check the Use DesignWare MinPower Library on either the Verilog or VHDL
tab. Checking the Use DesignWare MinPower Library automatically
enables the DesignWare foundation library if it was not previously
enabled.
Entering either of these Tcl commands:
set_option -dw_minpower 1
set_option -dw_library {dw_minpower}
These commands do not automatically enable the DesignWare
foundation library; the foundation library must be explicitly enabled
to use the minPower library.
5. Specify the response to being unable to locate a DesignWare foundation
library license according to your design criteria.
Check Stop Synthesis if no DesignWare license found
Enter the following Tcl command: set_option dw_stop_on_nolic 1
This stops design synthesis when a DesignWare building block is
encountered and a DesignWare foundation library feature license is not
found. Conversely, not enabling the checkbox or setting the option to 0
(the default) allows synthesis to continue by black boxing each building
block in the RTL.
6. Optionally, set the number of licenses for multiprocessing, open the
Options->Configure Compile Point Options dialog box and set the Maximum
number of parallel synthesis jobs value to the desired number of licenses.
The DesignWare feature license can use multiprocessing when multiple
processor cores are available. The normal ratio of license use is one
DesignWare license for every two synthesis licenses.
LO
Chapter 14: Working with IP Input Using DesignWare IP
726 March 2014
DW_Foundation_Arith Package
Synplify Premier
You can implement DesignWare function inferencing using the
DW_Foundation_Arith package from the dware library.
1. To use these arithmetic functions in your VHDL code, add the
DW_Foundation_Arith package from the dware library using the VHDL use
clause as shown below:
library dware;
use dware.DW_Foundation_arith.all;
2. To enable this feature, check Use DesignWare Foundation Library on the
VHDL tab of the Implementation Options dialog box.
Example
library ieee,dware;
use ieee.std_logic_arith.all;
use dware.DW_foundation_arith.all;
entity ew_002_sus is
port (a : in signed(3 downto 0);
b : in unsigned(3 downto 0);
c : out signed(3 downto 0));
end entity;
architecture behv of ew_002_sus is
begin
c <= a / b;
end architecture;
Supported Functions
The supported DesignWare functions in the DW_Foundation_Arith package
are listed in the following table.
Using DesignWare IP Chapter 14: Working with IP Input
March 2014 727
Division Functions
function "/" (A : signed; B : unsigned) return signed;
function "/" (A : unsigned; B : signed) return signed;
function "/" (A : unsigned; B : unsigned) return std_logic_vector;
function "/" (A : signed; B : signed) return std_logic_vector;
function "/" (A : signed; B : unsigned) return std_logic_vector;
function "/" (A : unsigned; B : signed) return std_logic_vector;
Remainder Functions
function "rem" (A : signed; B : unsigned) return signed;
function "rem" (A : unsigned; B : signed) return signed;
function "rem" (A : unsigned; B : unsigned) return std_logic_vector;
function "rem" (A : signed; B : signed) return std_logic_vector;
function "rem" (A : signed; B : unsigned) return std_logic_vector;
function "rem" (A : unsigned; B : signed) return std_logic_vector;
Modulo Functions
function "mod" (A : signed; B : unsigned) return signed;
function "mod" (A : unsigned; B : signed) return signed;
function "mod" (A : unsigned; B : unsigned) return std_logic_vector;
function "mod" (A : signed; B : signed) return std_logic_vector;
function "mod" (A : signed; B : unsigned) return std_logic_vector;
function "mod" (A : unsigned; B : signed) return std_logic_vector;
Binary Encoder Functions
function DW_binenc(A: SIGNED; ADDR_width: NATURAL) return SIGNED;
function DW_binenc(A: UNSIGNED; ADDR_width: NATURAL) return UNSIGNED;
function DW_binenc(A: std_logic_vector; ADDR_width: NATURAL) return std_logic_vector;
Decoder Functions
function DW_decode(A: SIGNED) return SIGNED;
function DW_decode(A: UNSIGNED) return UNSIGNED;
function DW_decode(A: std_logic_vector) return std_logic_vector;
Priority Encoder Functions
function DW_prienc(A: SIGNED; INDEX_width: NATURAL) return SIGNED;
function DW_prienc(A: UNSIGNED; INDEX_width: NATURAL) return UNSIGNED;
function DW_prienc(A: std_logic_vector; INDEX_width: NATURAL) return std_logic_vector;
LO
Chapter 14: Working with IP Input Working with Synenc-encrypted IP
728 March 2014
Working with Synenc-encrypted IP
Synplify Premier
When running on Linux, the software can read Synenc-encrypted IP as input.
Synenc-encrypted IP refers to Synopsys-encrypted RTL cores, which are
configured and generated using the Synopsys coreTools. You can read them
in and synthesized them in the FPGA synthesis tool. The synenc-encrypted
data cannot include any licensed components, but the tool can accept as
input DesignWare library macrocells and proprietary RTL cores encrypted
using Synopsys coreTools.
The following steps describe how to use these encrypted cores:
1. For cores created with coreConsultant, follow these steps:
Create a synthesis project file in coreConsultant. This file includes
the synenc-encrypted DesignWare core files in the correct order.
Add this project file to the synthesis project as a subproject, using the
project -insert command.
2. For existing synenc-encoded source files where you cannot go back to
coreConsultant and create a project file, add the core files manually to
the synthesis project.
File order is critical, because incorrect order causes the compiler to error
out with a message about unknown macros. Ensure correct file order by
doing one of the following:
Use the original lst file from coreConsultant to set up your project.
The lst file gives the proper order of files. This is the typical path to
the lst file:
ip_core_name/src/ip_core_name.lst
If the lst file is unavailable, make sure that the params and constants
files for each core are listed first, and make sure that the undef file for
the core is listed last.
Using Hyper Source Chapter 14: Working with IP Input
March 2014 729
Using Hyper Source
Hyper source is a useful feature that lets you prototype ASIC designs that use
one or more FPGAs. You can also use it to validate and debug the RTL for IP
designs. See the following for details:
Using Hyper Source for Prototyping, on page 729
Using Hyper Source for IP Designs, on page 729
Threading Signals Through the Design Hierarchy of an IP, on page 730
Using Hyper Source for Prototyping
For prototyping, use Hyper Source to efficiently thread nets across multiple
modules to the top-level design to support Time Domain Multiplexing (TDM).
You can also use it to easily replace an ASIC RAM with an FPGA RAM. Follow
these guidelines to replace an ASIC RAM with an FPGA RAM:
1. Change the RTL for the RAM instantiation.
2. Add an extra clock signal to all the module interfaces.
Hyper source reduces the number of modified RTL modules to two, one
for the RAM and one for the top level.
Using Hyper Source for IP Designs
For IP designs, Hyper Source is useful for validating and debugging the RTL
without directly modifying it. After the RTL has been fully tested with
complete QoR results, use Hyper Source to debug, as described in the
following cases:
Add some instrumentation logic that is not part of the original design,
such as a cache profiler that counts cache misses or bus monitor that
might count statistics about bus contention. The cache or bus might be
buried deep inside the RTL; accessing the cache or the bus means ports
might need to be added through several levels of hierarchy in the RTL.
The instrumentation logic can be included anywhere in the design, so
you can use hyper source and hyper connect to easily thread the neces-
sary connections during synthesis.
LO
Chapter 14: Working with IP Input Using Hyper Source
730 March 2014
Insert other hyper sourcing inside the IP to probe, monitor, and verify
correct operation of known signals within the IP.
Threading Signals Through the Design Hierarchy of an IP
Use this mechanism to thread a signal through the design hierarchy of a user
IP. This signal can be threaded to a top-level port or signal. This works even if
the Verilog or VHDL is compiled separately. The tool automatically adds ports
and signals between the source and the connection. Otherwise, these connec-
tions must be manually added to the RTL code.
However, if you use hyper source to thread signals through an EDIF, you
must use the Synplify Premier tool. You can run the software with or without
Physical Synthesis, but turn on the Enhanced Optimization switch.
The following procedure describes a method for using hyper source, using the
example HDL shown in Hyper Source Example, on page 731.
1. Define how to connect to the signal source. The following apply to this
example:
Signal syn_hyper_source (in1) module defines the source, with a width of
1.
The tag name "tag_name" is the global name for the hyper source.
2. Define how to access the hyper source which drives the local signal or
port. The following apply to this example:
Signal syn_hyper_connect (out1) module defines the connection. The
signal width of 1 matches the source.
Tag name can be the global name or the instance path to the hyper
source.
3. In this hierarchical design, note the following about hyper source:
Applies to the module lower_module.
Signal syn_hyper_source my_source(din) module is defined for the source
with a width of 8.
The tag name of "probe_sig" must match the name used in the hyper
connect block to thread the signal properly.
4. In this hierarchical design, note the following about the hyper connect:
Applies to the top-level module top, but can be any level of hierarchy.
March 2014 731
Signal syn_hyper_connect connect_block (probe) module is defined for the
connection with a width of 8.
Tag name of "probe_sig" must match the name used in the hyper
source block to thread the signal properly.
5. After you run synthesis, the following message appears in the log file:
Hyper Source Example
/* Connect to a signal you want to export example : in1*/
module syn_hyper_source(in1) /*synthesis syn_black_box=1 syn_noprune=1 */;
parameter w = 1;
parameter tag = "tag_name"; /* global name of hyper_source */
input [w-1:0] in1;
endmodule
/* Use to access hyper_source and drive a local signal or port example
:out1 */
module syn_hyper_connect(out1) /* synthesis syn_black_box=1 syn_noprune=1
*/;
parameter w = 1; /* width must match source */
parameter tag = "tag_name"; /* global name or instance path to hyper_source
*/
parameter dflt = 0;
parameter mustconnect = 1'b1;
output [w-1:0] out1;
endmodule
/* Example hierarchical design which uses hyper_source */
module lower_module (clk, dout, din1, din2, we);
output reg [7:0] dout;
input clk, we;
input [7:0] din1, din2;
wire [7:0] din;
syn_hyper_source my_source(din);
defparam my_source.tag = "probe_sig"; /* to thread the signal this
tag_name must match to name used in the hyper connect block */
LO
Chapter 14: Working with IP Input Using Hyper Source
732 March 2014
defparam my_source.w = 8;
if (we)
dout <= din;
assign din = din1 & din2;
endmodule
module sub1_module (clk, dout, din1, din2, we);
output[7:0] dout;
input clk, we;
lower_module lower_module (clk, dout, din1, din2, we);
endmodule
module sub2_module (clk, dout, din1, din2, we);
output [7:0] dout;
input clk, we;
sub1_module sub1_module (clk, dout, din1, din2, we);
endmodule
module top (clk, dout, din1, din2, we, probe);
output[7:0] dout;
output [7:0] probe;
input clk, we;
syn_hyper_connect connect_block(probe);
defparam connect_block.tag = "probe_sig"; /* to thread the signal this
tag_name must match to name used in the hyper connect block */
defparam connect_block.w = 8;
sub2_module sub2_module (clk, dout, din1, din2, we);
endmodule
March 2014 733
The following figures show how the hyper source signal automatically gets
connected through the hierarchy of the IP in the HDL Analyst views.
RTL View
Technology View
LO
Chapter 14: Working with IP Input Working with Altera IP
734 March 2014
Working with Altera IP
You can incorporate and synthesize different kinds of Altera IP in your
synthesis design. See the following for details:
Using Altera LPMs or Megafunctions in Synthesis, on page 734
Implementing Megafunctions with Clearbox Models, on page 738
Implementing Megafunctions with Grey Box Models, on page 748
Including Altera Processor Cores Generated in SOPC Builder, on
page 759
Working with SOPC Builder Components, on page 765
For information about working with Megacore IPs in imported Quartus
designs, see Importing Quartus Designs with Megacore IPs, on page 774.
Using Altera LPMs or Megafunctions in Synthesis
You can include Altera LPMs or Megafunctions in your design in the following
ways:
Generate structural Verilog/VHDL for the IP and include it in your
design, as described in Recommended Method for Including Altera LPMs,
on page 735.
For newer Altera technologies, the synthesis tool can infer the Clearbox
or greybox megafunctions as described in Automatically Inferring
Megafunctions with Clearbox Information, on page 739 and Using
Clearbox Information for Instantiated Megafunctions, on page 743
For older Altera technologies, if you have a Clearbox netlist generated by
the Quartus tool for the IP, include the Clearbox netlist in the project,
and synthesize the design. See Instantiating Clearbox Netlists for
Megafunctions, on page 746.
Infer Altera LPMs or megafunctions included in the installDirec-
tory/lib/altera directory. This lets the tools access supported LPMs and
Megafunctions as required. Note that if you are using a VHDL compo-
nent from a non-default Quartus library, you must set the Quartus
Working with Altera IP Chapter 14: Working with IP Input
March 2014 735
version and add the library file you want to use to the prj file with an -
add file command.
Currently, physical synthesis only supports LPMs and Megafunctions for
Stratix II, Stratix II GX, and Stratix III devices. Note, at this time the Synplify
Premier software cannot handle the megafunction alt_pll component. This
megafunction is treated as a black box.
Recommended Method for Including Altera LPMs
The following is the recommended methodology for incorporating the LPM or
megafunction, where you generate structural Verilog or VHDL files for the
megafunction.
1. Use the Altera MegaWizard Plug-in Manager to generate structural
Verilog or VHDL files for the LPMs or megafunctions. See LPM /
Megafunction Example, on page 737 for an example.
2. Add the structural Verilog or VHDL files in the project. For the example,
you would add my_ram.v file to the project.
3. Instantiate the LPMs or megafunctions with a wrapper in your top-level
HDL source code.
For the example in LPM / Megafunction Example, on page 737, instan-
tiate the megafunction wrapper, my_ram, in the top-level HDL source
code.
module top (
...
);
my_ram my_ram_instantiation (
.address(),
.clock(),
.data(),
.wren(),
.q()
);
endmodule // top
4. Select the correct Quartus version.
LO
736 March 2014
This ensures that the synthesis tool accesses the appropriate port and
parameter definitions for these LPMs or megafunctions. If you need to,
ensure that existing megafunction wrappers comply with the latest
applicable version of the Quartus II place-and-route tool, by updating
the wrappers with this Quartus command:
qmegawiz -silent
When the physical synthesis tool encounters an ALTSYNCRAM
megafunction, it automatically executes a Quartus function which
determines how to implement the component type and defparams, and
how to write out the contents in the final netlist (vqm).
For this example, the Synplify Premier software writes out a
stratixii_ram_block primitive for this component in the final vqm netlist.
stratixii_ram_block altsyncram_component_ram_block1a_0_0_0_Z (
.portadatain({data_c[0]}),
.portaaddr({address_c[7], address_c[6], address_c[5], address_c[4],
address_c[3], address_c[2], address_c[1], address_c[0]}),
.portawe(wren_c),
.clk0(clock_c),
.portadataout({q_c[0]})
);
defparam altsyncram_component_ram_block1a_0_0_0_Z.connectivity_checking = "OFF";
defparam altsyncram_component_ram_block1a_0_0_0_Z.init_file =
"C:/public/qinghong/ram_init/rev_1/init_values.mif";
defparam altsyncram_component_ram_block1a_0_0_0_Z.init_file_layout = "port_a";
defparam altsyncram_component_ram_block1a_0_0_0_Z.logical_ram_name = "ALTSYNCRAM";
defparam altsyncram_component_ram_block1a_0_0_0_Z.operation_mode = "single_port";
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_address_width = 8;
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_data_out_clear = "none";
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_data_out_clock =
"clock0";
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_data_width = 1;
defparam
altsyncram_component_ram_block1a_0_0_0_Z.port_a_disable_ce_on_input_registers =
"on";
defparam
altsyncram_component_ram_block1a_0_0_0_Z.port_a_disable_ce_on_output_registers
= "on";
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_first_address = 0;
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_first_bit_number = 0;
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_last_address = 255;
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_logical_ram_depth
= 256;
defparam altsyncram_component_ram_block1a_0_0_0_Z.port_a_logical_ram_width = 4;
defparam altsyncram_component_ram_block1a_0_0_0_Z.power_up_uninitialized =
"false";
defparam altsyncram_component_ram_block1a_0_0_0_Z.ram_block_type = "M512";
defparam altsyncram_component_ram_block1a_0_0_0_Z.lpm_type
= "stratixii_ram_block";
March 2014 737
LPM / Megafunction Example
The following example shows the megafunction wrapper and the associated
defparams generated by the Altera MegaWizard Plug-in Manager for a single-
port RAM megafunction, ALTSYNCRAM.
/ megafunction wizard: %RAM: 1-PORT%
// GENERATION: STANDARD
// VERSION: WM1.0
// MODULE: altsyncram
// ============================================================
// File Name: my_ram.v
// Megafunction Name(s):
// altsyncram
//
// Simulation Library Files(s):
// altera_mf
// ============================================================
// ************************************************************
// THIS IS A WIZARD-GENERATED FILE. DO NOT EDIT THIS FILE!
//
// 7.0 Build 33 02/05/2007 SJ Full Version
// ************************************************************
//Copyright (C) 1991-2007 Altera Corporation
//Your use of Altera Corporation's design tools, logic functions
//and other software and tools, and its AMPP partner logic
//functions, and any output files from any of the foregoing
//(including device programming or simulation files), and any
//associated documentation or information are expressly subject
//to the terms and conditions of the Altera Program License
//Subscription Agreement, Altera MegaCore Function License
//Agreement, or other applicable license agreement, including,
//without limitation, that your use is for the sole purpose of
//programming logic devices manufactured by Altera and sold by
//Altera or its authorized distributors. Please refer to the
//applicable agreement for further details.
// synopsys translate_off
`timescale 1 ps / 1 ps
// synopsys translate_on
module my_ram (
address,
clock,
data,
wren,
q);
input[7:0] address;
input clock;
input[3:0] data;
input wren;
output[3:0] q;
wire [3:0] sub_wire0;
wire [3:0] q = sub_wire0[3:0];
altsyncram altsyncram_component (
.wren_a (wren),
LO
738 March 2014
.clock0 (clock),
.address_a (address),
.data_a (data),
.q_a (sub_wire0),
.aclr0 (1'b0),
.aclr1 (1'b0),
.address_b (1'b1),
.addressstall_a (1'b0),
.addressstall_b (1'b0),
.byteena_a (1'b1),
.byteena_b (1'b1),
.clock1 (1'b1),
.clocken0 (1'b1),
.clocken1 (1'b1),
.clocken2 (1'b1),
.clocken3 (1'b1),
.data_b (1'b1),
.eccstatus (),
.q_b (),
.rden_a (1'b1),
.rden_b (1'b1),
.wren_b (1'b0) );
defparam
altsyncram_component.clock_enable_input_a = "BYPASS",
altsyncram_component.clock_enable_output_a = "BYPASS",
altsyncram_component.init_file = "init_values.mif",
altsyncram_component.intended_device_family = "Stratix II",
altsyncram_component.lpm_type = "altsyncram",
altsyncram_component.numwords_a = 256,
altsyncram_component.operation_mode = "SINGLE_PORT",
altsyncram_component.outdata_aclr_a = "NONE",
altsyncram_component.outdata_reg_a = "CLOCK0",
altsyncram_component.power_up_uninitialized = "FALSE",
altsyncram_component.ram_block_type = "M512",
altsyncram_component.widthad_a = 8,
altsyncram_component.width_a = 4,
altsyncram_component.width_byteena_a = 1;
endmodule
Implementing Megafunctions with Clearbox Models
Generally, user-instantiated Quartus megafunctions do not have timing
information and are treated as black boxes, so the synthesis tool cannot
optimize timing at the megafunction boundary. For example, the tool does
not move the registers of a pipelined LPM_MULT to improve FMAX. Instead of
black boxes, you can implement the megafunctions as grey boxes (see Imple-
menting Megafunctions with Grey Box Models, on page 748) or clear boxes, as
described here.
Altera Clearbox netlists provide structural information for modules
containing the following primitives lcell, mac_mult, mac_out, and ram_block. The
Clearbox netlist is a fully synthesizeable Altera megafunction. When you
March 2014 739
synthesize with a clear box model, you get better timing and resource utiliza-
tion estimates, because the synthesis tool knows the architectural details
used in the Quartus II software. For details, see the following:
Automatically Inferring Megafunctions with Clearbox Information, on
page 739
Using Clearbox Information for Instantiated Megafunctions, on page 743
Instantiating Clearbox Netlists for Megafunctions, on page 746
Automatically Inferring Megafunctions with Clearbox Information
Use this method with the newer Altera families. With this method, you do not
have to explicitly do anything with the Clearbox megafunction, as the
synthesis tool automatically infers the megafunction and calls Quartus for
the supporting Clearbox details.
1. Structure the RTL so that the synthesis tool can infer the megafunctions
from the code.
The following table lists some tips for controlling inference:
Multipliers in DSP blocks Use syn_multstyle to control inference.
VQM
Synthesis
Timing optimization and resource
utilization use Clearbox information.
VQM includes Clearbox
internals if option was set
VQM does not include
Clearbox primitives.
VQM
Inferred
Megafunction
Instantiated
Megafunction
Instantiated Megafunction
with Clearbox Netlist
Synthesis
Clearbox netlist used for timing
analysis. No optimization.
LO
740 March 2014
See the Reference Manual for details about the attributes.
2. Set up the synthesis tool to use the clearbox information.
Make sure the QUARTUS_ROOTDIR environment variable is set and
pointing to the same Quartus version as the library.
In the synthesis tool, open the Implementation Options dialog box to the
Device tab, and set the synthesis tool to a supported family:
ROMs The address line must be at least two bits wide.
The ROM must be at least half full.
A CASE or IF statement must make 16 or more
assignments using constant values of the same
width.
Shift registers Use syn_srlstyle to control inference.
RAMs The address line must be at least two bits wide.
Do not have resets on the memory.
Check whether read and write ports must be
synchronous for your target family.
Avoid blocking statements when modeling the
RAM, because not all Verilog HDL blocking
assignments are mapped to RAM blocks.
Use syn_ramstyle to control inference.
Use $readmemb or $readmemh to initialize RAMs.
Synplify Pro Stratix II, Stratix III, Stratix IV, and Stratix V
Arria GX, Arria II, and Arria V
Cyclone V
Synplify Premier
(placement)
Stratix II, Stratix III, and Stratix IV
March 2014 741
Set the Altera Models device option.
Click OK.
3. Set any other options you want, and click Run to synthesize the design.
The synthesis tool infers the megafunction from the RTL code. For
example, it infers a RAM from this code:
module ram(q, a, d, we, clk);
output[7:0] q;
input [7:0] d;
input [3:0] a;
input we, clk;
reg [7:0] q ;
reg [3:0] read_add;
reg [7:0] mem [0:15];
q = mem[read_add];
end
if(we)
mem[a] <= d;
read_add <= a;
end
endmodule
It then calls the Clearbox executable which returns a netlist containing
the Clearbox internals for the inferred megafunction (based on the Altera
Models setting). The synthesis tool uses this information to optimize
timing and allocate resources. The RTL view shows the generic memory
inferred, but the Technology view shows some of the stratixii_ram_block
Clearbox primitives that were implemented after calling the Clearbox
executable.
To generate vqm that contains ... Set it to ...
The Altera primitives associated with the inferred or
instantiated Megafunction
on
The Altera primitives associated with the inferred
Megafunction only
clearbox_only
The instantiated Megafunction only off
LO
742 March 2014
The tool writes out the Clearbox information in the vqm netlist, according
to the Altera Models setting. In addition, for the alt2gxb_reconfig,
altasmi_parallel, altpll_reconfig, and altremote_update megafunctions, the
synthesis tool writes out the vqm exactly as generated by the Altera
MegaWizard. The Altera tool defines the lower levels of content for these
megafunctions ("clearbox=2" setting) with the parameters set for the
megafunction, and that is how they are written to the vqm.
4. Use this vqm file to place and route in Quartus II.
RTL View
Technology View
March 2014 743
Using Clearbox Information for Instantiated Megafunctions
There are two ways of instantiating megafunctions and using Clearbox infor-
mation in your synthesis design. The following is the recommended method
for instantiation in the newer Altera technologies, where you instantiate just
the megafunction, and the tool automatically infers the corresponding
Clearbox details. For older technologies, instantiate the Clearbox netlist for
the megafunction, as described in Instantiating Clearbox Netlists for
Megafunctions, on page 746.
1. Generate the Verilog or VHDL megafunction using the Altera
Megafunction wizard.
This is just the megafunction file, not a Clearbox primitive netlist.
2. Set up the megafunction for synthesis.
Instantiate the megafunction in your synthesis design.
Add the megafunction wrapper file to your project file.
3. Set up the synthesis tool to use the Clearbox information automatically.
Device tab, and set the synthesis tool target to a supported family:
Set the Altera Models device option.
Click OK.
Synplify Pro Stratix II, Stratix III, Stratix IV, Stratix V, Arria II,
Arria GX
Synplify Premier
(placement)
Stratix II, Stratix III, Stratix IV
To generate vqm that contains ... Set it to ...
The contents of the megafunction as well as grey box
netlists for any grey boxes in the design
on
The contents of the megafunction clearbox_only
The megafunction without its contents off
LO
744 March 2014
The tool instantiates the megafunction and calls the Clearbox execut-
able, which returns a netlist containing the Clearbox internals for the
megafunction (based on the Altera Models setting). The synthesis tool uses
this information to optimize timing and allocate resources.
The RTL view below shows an instantiated megafunction, ALTSYNCRAM.
The corresponding Technology view shows the stratixii_ram_block Clearbox
primitives. The tool generated the Clearbox information for the instanti-
ated megafunction by calling Quartus.
March 2014 745
The tool writes out the Clearbox information in the vqm netlist, according
to the Altera Models setting. In addition, for the alt2gxb_reconfig,
altasmi_parallel, altpll_reconfig, and altremote_update megafunctions, the
synthesis tool writes out the vqm exactly as generated by the Altera
MegaWizard. The Altera tool defines the lower levels of content for these
megafunctions ("clearbox=2" setting) with the parameters set for the
megafunction, and that is how they are written to the vqm.
5. Use the vqm file to place and route in Quartus II.
RTL View
Technology View
LO
746 March 2014
Instantiating Clearbox Netlists for Megafunctions
For older Altera technologies which do not supported the automatic inference
of Clearbox information (see Automatically Inferring Megafunctions with
Clearbox Information, on page 739 and Using Clearbox Information for Instan-
tiated Megafunctions, on page 743), you can read in a Clearbox netlist. You
only need to use the netlist method described here for older Altera target
families that do not support the other flows.
1. Generate the megafunction files with a Clearbox netlist.
Use the Altera Megafunction wizard to generate structural VHDL or
Verilog files for the megafunctions in your design. Make sure the
Synthesized Timing Netlist option is disabled. The Clearbox netlist has the
full content of the megafunction either in VHDL or Verilog. The
synthesis software uses this timing and resource information for the
megafunctions, but does not synthesize the internals of the
megafunctions.
If you are using VHDL, comment out the LIBRARY and USE clauses in
the file generated by the Altera MegaWizard tool. This is because the
Altera MegaWizard file declares the Clearbox components before
instantiating them, so you do not need references to the vhd files that
contain the component declarations. The following shows a Stratix
example of the lines to be commented out; for other technologies,
comment out the corresponding lines:
LIBRARY stratix;
USE stratix.all;
Make sure the Clearbox components match the Quartus version.
Because of ongoing modifications in Quartus, the component
declarations may not match. The component declarations are
packaged with the software in the lib/altera/quartus_IInn subdirectory.
Use the file from the subdirectory that corresponds to the Quartus
version that you are using. For example, the stratix.vhd and stratix.v files
for use with Quartus 8.1 are in the quartus_II81 subdirectory.
If you change from one version of Quartus to another or if you change
the target device, regenerate the Clearbox files using the Altera
Megafunction wizard before proceeding. Failure to regenerate these
files can result in a parameter-mismatch error.
2. Instantiate the megafunction in your design.
March 2014 747
3. Add the megafunction file (which includes the Clearbox components) to
your project.
Add the Clearbox Verilog/VHDL file to your project. It contains the
port and parameter definitions for the Clearbox primitives.
If you are using Verilog, the software does not automatically include
the definitions because Verilog does not support library statements.
4. Set implementation options for the megafunction.
Click Implementation Options, and set the target technology on the Device
tab.
On the Implementation Results tab, select the appropriate Quartus
version. This is important, because the version determines the format
of the output vqm file, which varies with different Quartus versions. If
you are using Verilog, the software automatically adds the Verilog
component declaration files for the selected target technology to your
project from the lib/altera/quartus_IInn subdirectory. Failing to specify
the version can result in a parameter mismatch error.
Click OK.
5. Optionally, set up the files so that you can run Quartus from the
synthesis tool by doing either of the following:
Select the Clearbox file from the project file list, right-click and select
File Options. Set File Type to Clearbox Verilog or Clearbox VHDL and click
OK.
Use the Tcl command appropriate to your file type:
add_file -clearbox_verilog "dsp/my_dsp_syn.v"
add_file -clearbox_vhdl "dsp/my_dsp_syn.vhd"
When you run Quartus from the synthesis UI, the Clearbox files must be
in the implementation/par_1 directory, which is only created after the
synthesis run. Specifying the Clearbox files ensures that they are copied
to the directory after it is created. You can now synthesize the design, as
described in the previous step.
6. Set any other options and synthesize the design.
The software uses the Clearbox timing and resource information from
the structural files to calculate paths more accurately. It implements the
megafunctions as hierarchical instances, not black boxes. The RTL and
LO
748 March 2014
Technology views both show the lowest-level primitives. The following
figure for example, shows stratixii_ram_blocks.
The vqm file generated for Quartus after synthesis only contains a
wrapper; it does not include the Clearbox primitives. The description of
the primitives is in the Clearbox netlist generated in step 1 and used as
input to synthesis.
7. Before you run Quartus, put all these files in the same result directory:
The structural Verilog/VHDL Clearbox netlist generated by Quartus
and used as input to synthesis. This file contains timing and resource
usage definitions for the primitives.
The vqm file generated after synthesis, which contains the wrapper.
The Quartus project file.
Placing these files in the same directory ensures that the Quartus
software can find all the information it needs in the vqm file and the
original structural Verilog/VHDL files.
Implementing Megafunctions with Grey Box Models
Altera provides the capability of implementing various MegaCore
IP cores
generated with the Altera MegaWizard tool. These cores use proprietary RTL
code for parameterization, generation, and instantiation in your design.
RTL View
Technology View
March 2014 749
Generally, user-instantiated Quartus megafunctions do not come with any
timing information and are treated as black boxes, so the synthesis tool
cannot optimize timing at the megafunction boundary. Instead of using black
boxes, you can implement the megafunctions using Clearbox primitives (see
Implementing Megafunctions with Clearbox Models, on page 738) or as grey
boxes, as described here. Use the grey box methodology when logic is
encrypted or when there are no Clearbox models for the megafunction.
There are three ways to use grey boxes:
The following procedures show you how to implement an Altera megafunc-
tion.
Automatically Using Grey Box Information for Megafunctions, on
page 750
Using Grey Box Information for Instantiated Megafunctions, on
page 751
Instantiating Megafunctions Using Grey Box Netlists, on page 752
VQM
Synthesis
Calls Altera for grey box timing and
resource information.
VQM does not include grey box internals
Inferred
Megafunction
Instantiated
Megafunction
Instantiated Megafunction
with Grey Box Netlist
Synthesis
Uses netlist for timing and resource
information.
LO
750 March 2014
Automatically Using Grey Box Information for Megafunctions
1. Structure the RTL so that the synthesis tool can infer the megafunctions
from the code.
2. Set up the synthesis tool to use the clearbox information.
Device tab, and set the synthesis tool to a supported family:
To use grey box timing information, set Altera Models device option to
on.
Click OK.
The synthesis tool infers the megafunction from the RTL code. It then
calls the Altera grey box executable which returns a netlist containing
the timing and resource information for the inferred megafunction. The
synthesis tool uses this information to optimize timing and allocate
resources. The RTL view shows the generic memory inferred, but the
Technology view shows the primitives that were implemented after
calling the grey box executable.
The tool does not include the grey box information in the output vqm
netlist. (
4. To place and route in Quartus II, use the following files:
The synthesis vqm output netlist
The encrypted file for the megafunction
Synplify Pro Stratix II and later, Arria II, Arria GX, Arria GZ
Synplify Premier
(placement)
Stratix II and later
March 2014 751
Using Grey Box Information for Instantiated Megafunctions
There are two ways of instantiating grey box megafunctions in your synthesis
design. The following procedure shows you how to instantiate a grey box
megafunction without a grey box netlist; to instantiate one with a grey box
netlist, refer to the procedure in Instantiating Megafunctions Using Grey Box
Netlists, on page 752.
1. Generate the Verilog or VHDL megafunction using the Altera
Megafunction wizard.
This is just the megafunction wrapper file, and does not include a grey
box netlist.
2. Set up the megafunction for synthesis.
Instantiate the megafunction in your synthesis design.
Add the megafunction wrapper file to your project file.
3. Set up the synthesis tool to use the grey box information.
Device tab, and set the synthesis tool target to a supported family:
To use grey box timing information, set Altera Models device option to
on.
Click OK.
The tool instantiates the megafunction and calls the grey box execut-
able, which returns a netlist containing the grey box timing for the
instantiated megafunction. The RTL view shows the instantiated
megafunction. The corresponding Technology view shows the primitives.
The tool instantiates the megafunction in the output vqm netlist, but
does not include the grey box timing information.
Synplify Pro Stratix II and later, Arria II,
Arria GX, Arria GZ
Synplify Premier
(placement)
Stratix II and later
LO
752 March 2014
5. To place and route in Quartus II, use the following files:
The synthesis vqm output netlist, which includes an empty
instantiation of the megafunction.
The encrypted file for the megafunction.
Instantiating Megafunctions Using Grey Box Netlists
The following procedure shows you how to use a greybox netlist to incorpo-
rate cores in a Synplify Pro or Synplify Premier design. The greybox netlist file
is only used for synthesis.
1. Make sure you are using Quartus II 10.0 or later.
2. Use the Altera MegaWizard tool to generate the files for the IP core and a
grey box netlist. The following example shows the files needed for a
project:
To generate the grey box netlist, enable the Generate netlist option in
the MegaWizard tool when you set up simulation. This is usually
under the EDA tab or in the Set Up Simulation section. The grey box
netlist provides the logic connectivity of specific mapped instances,
but does not represent the true functionality of the MegaCore IP.
top.v Top level design file. See top.v, on page 755.
my_ip_core.v Variation file (top-level wrapper) generated by the
MegaWizard tool, which instantiates the encrypted module
encrypted_ip.v. See my_ip_core.v, on page 755.
Do not add this file to the project.
encrypted_ip.v Encrypted IP core that is not readable.
Do not add this file to the project.
my_ip_core_syn.v A timing and resource estimation netlist (grey box file) for
use in synthesis.
Add this file to the project.
my_ip_core.qip A file that contains links to IP-related files. You must have
the referenced files to complete place and route. This file
must reside in the same directory as all other files
generated by the MegaWizard tool.
Add a reference to this file in altera_par.tcl.
March 2014 753
Parameterize the IP core and generate the IP files. The tool outputs a
grey box file (_syn.v) along with the other synthesis files.
3. Set up your design.
Instantiate the my_ip_core component in your HDL code.
In the synthesis tool, add the grey box netlist file, my_ip_core_syn.v to
your synthesis project.
4. Set up a reference to the my_ip_core.qip file by doing the following:
Create a file called altera_par.tcl and add a reference to the qip file.
Make sure that the path is relative to your PAR directory. The
following example shows a path if your qip file is at the same level as
the project file:
set_global_assignment -name QIP_FILE ../../my_ip_core.qip
Add altera_par.tcl to your project.
Right-click the file in the Project view and select File Options. Set File
Type to Altera P&R Options and click OK.
LO
754 March 2014
Add a new implementation.
Click Implementation Options. In the Implementation Options dialog box,
click P&R Options and enable the altera.par.tcl file.
5. Set other implementation options.
Set the target technology on the Device tab.
Go to the Implementation Results tab and specify the correct version for
the place-and-route tool. This is important because the version
determines the format for the vqm output file, which varies with
different versions.
Set any other options or constraints you want.
The synthesis tool uses the grey box netlist file for synthesis and timing
analysis. The RTL and Technology views show the internals of the core
March 2014 755
IP, because the grey box netlist file contains mapped instances. The log
file reports any critical paths found within the core, and the Technology
view displays timing numbers and critical paths.
After synthesis, the vqm netlist does not contain the mapped instances
found in the grey box netlist. It only contains a top-level instantiation of
my_ip_core, not its contents. If you synthesized with the Synplify Premier
tool, the placement locations of instances in the grey box netlist are not
forward-annotated to the P&R tool.
7. Place and route the design in Quartus.
When you run integrated Place & Route, the qip file is referenced in the
Quartus settings file (qsf). This informs Quartus of the location of the
IP-related files needed to complete PAR.
Examples of MegaCore IP Files for Synthesis
top.v
The following is a simple example of a top-level MegaCore IP file (top.v) that is
included in a synthesis project.
module top (in1, in2, out1, out2)
input in1, in2;
output out1, out2;
my_ip_core (in1, in2, out1, out2);
endmodule;
my_ip_core.v
The following is a simple example of a top-level MegaCore wrapper file that is
included in a synthesis project.
module my_ip_core (in1, in2, out1, out2)
input in1, in2;
output out1, out2;
encrypted_ip (in1, in2, out1, out2);
endmodule;
LO
756 March 2014
Including Altera MegaCore IP Using an IP Package
You can include MegaCore
IP cores generated with the Altera MegaWizard

tool using the method described below, but it is preferred that you use a
greybox netlist instead (Instantiating Megafunctions Using Grey Box Netlists,
on page 752).
For information about including cores generated with SOPC Builder, see
Including Altera Processor Cores Generated in SOPC Builder, on page 759.
1. Make sure you have installed Quartus II 7.2 or later.
2. Use the Altera MegaWizard tool to generate the files for the IP core. The
following is an example of the files needed for the project:
3. Copy the MegaCore IP and associated library files into a single directory.
You can find the library files associated with the IP core in the
MegaWizard output directory and in the IP library files in the Quartus
installation directory (for example, altera/72/pc_compiler.lib).
4. Import the core into the synthesis design.
Start the synthesis tool, and make sure the technology you are
targeting is either Stratix II, Stratix II-GX, Stratix III, or Stratix IV.
In the synthesis UI, select Import IP->Import IP Package.
top.v Top level design file. See top.v, on page 755.
my_ip_core.v Top-level wrapper generated by the MegaWizard tool, which
instantiates the encrypted module encrypted_ip.v. See
my_ip_core.v, on page 755.
my_ip_core_enc.v Encrypted IP core that is not readable.
March 2014 757
In the IP Directory field, enter the path to the directory with the
consolidated files.
In the Package Name field, enter the name of the top-level module. In
our example, this is my_ip_core.
Click OK.
The tool imports the file and creates a directory called System IP. This
includes a sub-directory with the package name (pci_core in our
example), which contains all the IP-related files.
5. Tag the IP component files so that they are not compiled for synthesis.
They are used for P&R, but not for synthesis.
LO
758 March 2014
Right-click a file and select File Options.
Enable Use for Place and Route Only in the dialog box and click OK.
Do this for every IP component file instantiated in the top-level IP
wrapper.
6. Instantiate the NIOS core in the top-level file for your synthesis design.
The tool automatically generates a greybox netlist for the IP core, and
uses it for timing. It does not use the internals of the core. The RTL view
only displays the top-level of the core, but you can view the internals
when you push down into the core in the Technology view.
March 2014 759
The log file reports any critical paths found within the core, and the
Technology view displays timing numbers and critical paths.
After synthesis, the vqm netlist that is written out does not contain the
mapped instances found in the greybox netlist. It only contains a top-
level instantiation of my_ip_core, not its contents.
If you synthesized with the Synplify Premier tool, the placement
locations of instances in the greybox netlist are not forward-annotated to
the P&R tool.
Including Altera Processor Cores Generated in SOPC Builder
Altera provides the capability of implementing configurable processor cores.
NIOS
II cores are created using the Altera SOPC Builder tool, which uses
proprietary RTL code to parameterize, generate, and instantiate NIOS II cores
in your design. The following procedure shows you how to use the greybox
flow to incorporate these cores in a Synplify Pro or Synplify Premier design
RTL View
Technology View
LO
760 March 2014
targeting certain Altera technologies. For information about including
MegaCore cores, see Instantiating Megafunctions Using Grey Box Netlists, on
page 752.
1. Make sure the following requirements are in place:
Install Quartus II 7.2 or later.
Install the MegaCore
IP library.
2. Generate the NIOS II core files as follows:
In Altera SOPC Builder, generate Verilog or VHDL output for the
NIOS II core files. Note that this flow does not support a block symbol
file (bsf); you must generate RTL code for the cores. The files may or
may not be encrypted.
Create a top-level wrapper for the core. In most cases, this wrapper
instantiates the components used to create the embedded system.
For example, if the embedded system consists of a NIOS II processor
that uses a PCI bus to interfaces to internal memory, the wrapper
would contain instantiations for the processor, memory and the PCI
bus.
Copy all generated IP core output files and the corresponding library
files into a single directory. Typically you must include the generated
HDL files, as well as any MegaCore IP cores in your design.
Depending on your design, the MegaCore IP files can be in the
MegaWizard IP tool output directory and in the IP library files in the
Quartus install directory (altera/72/ip/pci_compiler/lib).
The following example shows the list of files for a design that contains
a NIOS II core processor with internal memory that drives an LCD
display. This example does not have any MegaCore IP.
File Description
top.v User-defined top level of the design
first_nios2_system_bb.v User-defined module definition
first_nios2_system.v Top-level wrapper for SOPC system (SOPC Builder)
cpu.v Module instantiated in top-level wrapper (SOPC Builder)
cpu_jtag_debug_module.v Module instantiated in top-level wrapper (SOPC Builder)
cpu_jtag_debug_module_
wrapper.v
Module instantiated in top-level wrapper (SOPC Builder)
March 2014 761
3. Import the core into the synthesis design.
Start the synthesis tool, and make sure the technology you are
targeting is either Stratix II, Stratix II-GX, Stratix III, or Stratix IV.
In the synthesis UI, select Import IP->Import IP Package.
In the IP Directory field, enter the path to the directory with the
consolidated files.
In the Package Name field, enter the name of the top-level module. In
our example, this is first_nios2_system.
Click OK.
The tool imports the file and creates a directory called System IP. This
includes a sub-directory with the package name (first_nios2_system in our
example), which contains all the IP-related files.
cpu_mult_cell.v Module instantiated in top-level wrapper (SOPC Builder)
cpu_test_bench.v Module instantiated in top-level wrapper (SOPC Builder)
first_nios2_system.v Module instantiated in top-level wrapper (SOPC Builder)
jtag_uart.v Module instantiated in top-level wrapper (SOPC Builder)
led_pio.v Module instantiated in top-level wrapper (SOPC Builder)
onchip_mem.v Module instantiated in top-level wrapper (SOPC Builder)
sys_clk_timer.v Module instantiated in top-level wrapper (SOPC Builder)
sysid.v Module instantiated in top-level wrapper (SOPC Builder)
File Description
LO
762 March 2014
4. Tag the IP component files so that they are not compiled for synthesis.
They are used for P&R, but not for synthesis.
Right-click a file and select File Options.
Enable Use for Place and Route Only in the dialog box and click OK.
Do this for every IP component file instantiated in the top-level IP
wrapper.
5. Instantiate the NIOS core in the top-level file for your synthesis design.
March 2014 763
The tool automatically generates a greybox netlist for the IP core, and
uses it for timing. It does not use the internals of the core. The RTL view
only displays the top-level of the core, but you can view the internals
when you push down into the core in the Technology view.
The log file reports any critical paths found within the NIOS II core:
RTL View
Technology View
LO
764 March 2014
Worst Path Information
***********************
- Setup time: 0.187
+ Clock latency at ending point: 0.000
= Required time: 3.813
- Clock latency at starting point: 0.000
= Slack (critical): -3.043
Starting point:
first_nios2_system_ins.gbmodule_the_cpu_M_alu_result[0] / regout
Ending point:
first_nios2_system_ins.gbmodule_the_cpu_M_status_reg_pie / datain
The start point is clocked by clk [rising] on pin clk
The end point is clocked by clk [rising] on pin clk
After synthesis, the vqm netlist that is written out does not contain the
mapped instances found in the greybox netlist. It only contains a top-
level instantiation of first_nios2_system, not its contents.
If you synthesized with the Synplify Premier tool, the placement
locations of instances in the greybox netlist are not forward-annotated to
the P&R tool.
Working with SOPC Builder Components Chapter 14: Working with IP Input
March 2014 765
Working with SOPC Builder Components
You can incorporate Altera SOPC cores into your FPGA design. The following
figure summarizes the process.
See the following for step-by-step details:
The Synplify-SOPC Builder Design Flow, on page 765
Setting up the SOPC Builder Synthesis Project, on page 766
Defining SOPC Components as Black Boxes and White Boxes, on
page 767
The Synplify-SOPC Builder Design Flow
The following procedure describes the Synplify-SOPC Builder design flow step
by step. The previous figure provides a graphic overview of the flow.
1. Create your embedded design, using the Altera SOPC Builder- Quartus
Hardware Development flow. See the Altera documentation for details.
2. Import the SOPC Builder project into the Synplify Pro or Premier tool.
See Setting up the SOPC Builder Synthesis Project, on page 766 for
details.
4. Import the bitmap file back into the Quartus environment.
Generate cores with
SOPC Builder
Place and route with
Quartus
Read bitmap file into
Quartus
Read into synthesis
project
Synthesize and
optimize
Synplify Pro/Premier
Altera
LO
Chapter 14: Working with IP Input Working with SOPC Builder Components
766 March 2014
Close the open project in Quartus.
In the Quartus tool, select File ->Open Project. Browse to the synthesis
PAR directory (par_1) and select the qpf file:
synplify/rev_1/par_1/system.qpf.
Select Processing -> Start Compilation and compile the project.
If you have a Nios II license, the tool generates a programming file
called small_eval_board_time_limited.sof in the par_1 directory. You can
now download the file into the FPGA.
Setting up the SOPC Builder Synthesis Project
The following procedure provides the details on setting up an SOPC Builder
project for synthesis.
1. Start the Synplify Pro or Synplify Premier software, and select Import IP-
>Import Altera SOPC Project.
The Import Altera Design dialog box opens.
2. Do the following to import the SOPC project you created with the Altera
tools.
Specify the Altera ptf file you want to import in the PTF File option.
Specify a location for the synthesis project to be created in Project
Location, and a name for the project in Project Name.
Set the options you want in the Import Options section. Define the black
boxes and white boxes in your design with the Clear Box and Force
White Box Cores options (see Defining SOPC Components as Black
Boxes and White Boxes, on page 767 for details).
The tool will not complete synthesis if it finds inadequately defined
components, and you will have to iterate through synthesis again.
Click OK.
For descriptions of the import options, see Import Altera SOPC Project
Command, on page 343 of the Reference Manual. The software uses the
underlying sopc2syn functionality (see sopc2syn, on page 147 in the
Reference Manual) to read the Altera files and include the information
from them into the synthesis project.
Working with SOPC Builder Components Chapter 14: Working with IP Input
March 2014 767

3. To include an SOPC component as a subsystem in a larger design,
create the subsystem as described in the previous steps and instantiate
the subsystem in the top-level HDL.
Defining SOPC Components as Black Boxes and White Boxes
Accurately defining SOPC components as black boxes and white boxes is very
important, because the synthesis run fails if the design is not correctly speci-
fied, and you will have to iterate through another run.
LO
Chapter 14: Working with IP Input Working with SOPC Builder Components
768 March 2014
The following table lists definitions for black boxes and white boxes:
This procedure describes how to define black boxes and white boxes:
1. In the tool, select Import IP->Import Altera Project. This opens the Import Altera
Design dialog box.
2. To define a component as a black box, do the following:
List the core in Force White Box Cores.
Disable the Clear Box option.
Black box A component that does not have any definitions.
White box A component that has a core definition in vqm netlist format.
Importing Projects from Quartus Chapter 14: Working with IP Input
March 2014 769
With these settings, the tool copies the core wrapper file to the Synplify
folder and edits it to add the black box attribute. The component is
treated as a black box during synthesis. If the tool does not find the
named component, it issues a warning message.
3. To define a core as a white box, do the following:
List the core in Force White Box Cores.
Enable the Clear Box option.
With these settings, the tool goes through the Clearbox flow, and treats
the core as a white box during synthesis. It generates a definition vqm file
and adds this file to the Synplify project. If it does not find the specified
core in the ptf file, or the Clearbox file for the core, it issues a warning
message.
Importing Projects from Quartus
You can take a Quartus project and automatically translate it into a
synthesis project. If you have a SOPC Builder project, use the procedure
described in Working with SOPC Builder Components, on page 765. To import
projects from Quartus, see the following:
Importing Quartus Projects, on page 769
Importing Quartus Designs with Megacore IPs, on page 774
Importing Quartus Designs with Megafunctions/LPMs, on page 775
Troubleshooting Imported Quartus Designs, on page 776
Importing Quartus Projects
This procedure shows you how to translate a Quartus project into a project
that you can synthesize in the FPGA synthesis tools. It takes the Quartus
project settings and constraints from the qsf and sdc files and uses the
underlying qsf2syn utility to generate a synthesis project. See qsf2syn, on
page 95 in the Reference Manual for the syntax for the utility.
1. Set up your Quartus design and run Quartus.
LO
Chapter 14: Working with IP Input Importing Projects from Quartus
770 March 2014
Check that the Quartus version used matches the one specified in the
QUARTUS_ROOTDIR environment variable for synthesis. It is
recommended that you use the newer versions of Quartus.
Run Quartus and successfully complete a Quartus run on the design.
Read through Troubleshooting Imported Quartus Designs, on
page 776 and make sure you are following the tips listed there.
If your design contains Altera Megacore IP files, also read through
Importing Quartus Designs with Megacore IPs, on page 774 for
additional information on incorporating the IP.
If you have a SOPC Builder project, use the sopc2syn utility described
in Working with SOPC Builder Components, on page 765.
2. In the synthesis tool UI, select Import->Import Altera QSF Project.
The Import Altera QSF Project dialog box opens.

March 2014 771
3. Do the following in this dialog box:
In QSF File, specify the qsf file of the Quartus project you want to
import.
In the Synplify Project Location section, specify the name and location of
Synplify project file to create.
Click the Import button at the bottom.
This runs the qsf2syn utility, which does the following:
Creates a synthesis project file (prj) from the referenced source files,
synthesis settings, and timing constraints in the Quartus qsf and sdc
files.
Saves the project file to the specified location.
Writes the attributes and timing constraints to an sdc file.
You can run synthesis using the generated project.
See Synthesis Files Generated After Importing the Quartus Project, on
page 772 for a description of the files generated after the Quartus project
is successfully imported. For a list of the Quartus settings that are
translated, see Imported Quartus Project Settings and Timing Constraints,
on page 773.
4. To debug problems that might occur when you first import a Quartus
project, especially one with multiple source files, do the following:
Check the qsf2syn.log file in the project directory to get details about
the errors in the conversion run.
If possible, correct the error in the currently loaded project.
Check the timing_unapplied.sdc file for improperly translated timing
constraints.
See Troubleshooting Imported Quartus Designs, on page 776 for tips on
dealing with improperly translated constraints.
5. To resume the import process after you have fixed the errors that caused
translation to fail, select Import->Import Altera QSF Project in the synthesis
UI, and enable the Continue Previous Translation option.
This allows you to continue with the translation after you have fixed the
compilation errors.
LO
772 March 2014
Synthesis Files Generated After Importing the Quartus Project
Once the tool finishes importing the Quartus project, it automatically loads
the new synthesis project. The project view contains the following:
Folder Contains ...
VHDL/Verilog HDL source files referenced in the Quartus qsf file
Constraint Translated constraints referenced in the Quartus qsf and sdc
files. See Imported Quartus Project Settings and Timing
Constraints, on page 773 for a list of constraints.
attr_applied.sdc
Contains translated attributes from the Quartus qsf file
attr_unapplied.sdc
Contains translated attributes from the Quartus qsf file which
are unsupported or failed to match an object in the HDL source.
timing_applied.sdc
Contains translated timing constraints from the Quartus qsf or
sdc files.
timing_unapplied.sdc
Contains translated timing constraints from the Quartus qsf or
sdc files that failed to match objects in the HDL source. As
constraints can be applied at various points throughout the
Quartus flow, it may be difficult to match up the original HDL
object names during translation. Object names that cannot be
traced back to the HDL source name are written to this file.
These sdc files are physically located in the projectName_sdc
directory. To see the full path, right-click a file and select File
options.
Altera P&R
Options
The projectName_par_options.tcl file, which contains Quartus project
settings that were not translated for the synthesis project. This file
is sourced and its contents are written to the Quartus qsf file when
you run P&R.For IPs, it references the variation (top-level IP
wrapper file) and qip files.
March 2014 773
Imported Quartus Project Settings and Timing Constraints
The following table lists how the synthesis tools handle the import of Quartus
constraints and project settings:
Project Settings
(Translated in synthesis project file)
FAMILY
DEVICE
TOP_LEVEL_ENTITY
VERILOG_FILE
VHDL_FILE
SYSTEMVERILOG_FILE
SDC_FILE
USE_TIMEQUEST_TIMING_ANALYZER
EXTRACT_VERILOG_STATE_MACHINES
EXTRACT_VHDL_STATE_MACHINES
SYNTH_GATED_CLOCK_CONVERSION
SOURCE qsf_fileName
USER_LIBRARIES
SEARCH_PATH
Constraint Settings
(Translated in attr_applied.sdc file)
IO_STANDARD
PIN_<xx>
MAX_FANOUT
FAST_INPUT_REGISTER
FAST_OUTPUT_REGISTER
PRESERVE_REGISTER
STATE_MACHINE_PROCESSING
SAFE_STATE_MACHINE
LO
774 March 2014
Importing Quartus Designs with Megacore IPs
If your design contains Megacore IPs, use the following procedure:
1. When you generate the Megacore IP in the Altera MegaWizard tool, do
the following:
Generate each IP in a separate directory.
Generate a timing and resource netlist (_syn.v) for each IP.
It is strongly recommended that you generate this file during IP creation,
by going to the EDA tab and enabling the Timing and Resource Netlist option.
Although the translation process will open the MegaWizard and prompt
you to generate the file if you have not already done so, it is recom-
mended that the file be generated during IP creation instead of later.
Ensure that this netlist file is in the same directory as the corresponding
qip file for the IP.
2. Set up the Quartus project so that it follows the IP flow recommended by
Altera.
When Quartus prompts you, allow the tool to automatically add the
associated qip file for the IP to the Quartus project. This file contains
pointers to all related IP files. Do this for each IP in the design.
Do not add the IP-related files directly to the Quartus project. If you
do have IP-related files in the Quartus project along with the qip file,
TimeQuest Supported Constraints create_clock
create_generated_clock
set_clock_groups
set_input_delay
set_output_delay
set_false_path
set_multicycle_path
set_max_delay
Untranslated settings are written to the par_options.tcl file and passed to Quartus.
March 2014 775
the qsf2syn utility attempts to omit the IP-related files when it creates
the synthesis project.
Note that the software automatically translates older Quartus projects
that do not follow Alteras current flow (where IP-related files are added
to the Quartus project and there are no qip files) when you import the
design as described in step 4.
3. Check the following:
Verify that you have a _syn.v timing and resource netlist for each IP.
Verify that every IP has an associated qip file listed in the qsf file. If
you are using an older Quartus project, you will not have this file.
Verify that the IP-generated files listed in the qip file are not
referenced in the qsf file. If you are working with an older Quartus
project, these files may be in the qsf (Quartus settings) file.
4. Import the design with the Import Altera QSF command, as described in
Importing Quartus Projects, on page 769.
The process creates a new synthesis project and loads it in the project
view.
Importing Quartus Designs with Megafunctions/LPMs
If your design contains megafunctions or LPMs, use the following procedure
to create a synthesizable project from the Quartus project:
1. When you generate the megafunction/LPM in the Altera MegaWizard
tool, do the following.
Generate each megafunction or LPM in a separate directory.
Generate IP. You do not need to generate a timing and resource
netlist (_syn.v) file.
2. Set up the Quartus project so that it includes the top-level variation file
of the megafunction/LPM.
If you prefer to use the qip file instead of the top-level variation file
generated by the MegaWizard tool, the qsf2syn utility automatically looks
for the top-level variation file in the same directory as the qip file. It then
automatically adds this file to the synthesis project it creates.
LO
776 March 2014
3. Import the design with the Import Altera QSF command, as described in
Importing Quartus Projects, on page 769.
Troubleshooting Imported Quartus Designs
The following table lists some problems and their solutions:
Problem Solution
Qsf2Syn does not translate SOPC
Builder projects
Use the procedure described in Working with
SOPC Builder Components, on page 765 to
translate these projects.
Timing constraints on RTL objects
that infer RAMs are not applied
properly
Find the constraints in the timing_unapplied.sdc
file. Use the RTL viewer to find proper object
names and manually correct the names on
these constraints.
Constraints applied to RTL objects
in generate statements are not
applied properly
The tool does not translate constraints applied
on generate statements. Check the
constraints in timing_unapplied.sdc and
manually correct the object referenced by the
constraint.
Constraints applied on 2-D array
objects are not translated
Manually create the constraints, using the
RTL viewer to find the proper object names.
Constraints embedded in HDL
source code are not translated
correctly
Manually add the corresponding constraints
found in timing_unapplied.sdc. Use the RTL
viewer to find the correct object names.
You get an error message about an
undefined macro
Add `define macroName to the HDL.
You see this message if the HDL contains
`macroName without the `define macroName
statement. Although Quartus does not require
the define statement, the translation process
requires it.
State machine contains blocking
and non-blocking assignments in
the same variable
Modify the source code so that blocking and
non-blocking assignments are not combined
in the same variable.
You get a compiler error message
about undeclared VHDL libraries
Declare the library in a VHDL use clause.
Although Quartus does not require the library
to be declared, the FPGA synthesis compiler
requires this declaration.
March 2014 777
The get_keepers qualifier is
translated without a qualifier
Currently, this is the expected behavior. The
tool attempts to match an object using all
qualifiers. If it finds an object, it puts the
translated constraint in _applied.sdc.
The qip file generated by Altera
MegaWizard tags the top-level IP
wrapper file as MISC_FILE instead
of VERILOG_FILE or VHDL_FILE
Until Quartus fixes this issue, you must
manually modify the qip file and change the
tag to VERILOG_FILE or VHDL_FILE.
Clock constraints like
create_generated_clock, that are
applied to ALTPLL instantiations in
IP megafunctions, are translated to
timing_unapplied.sdc
You must modify these constraints with the
proper clock object names. You can find the
correct names in the constraints checker
results or in the srr logfile.
Quartus projects with Megacore
IPs have IP-related files added
directly to the project
Do not add the IP files directly to the Quartus
project. Use the flow recommended by Altera
and set up the project to include a qip file that
contains the pointers to the IP files.
Quartus designs with Megacore IPs
do not have a timing and resource
estimation netlist
When you create the IP with the MegaWizard
tool, generate the timing and resource
estimation netlist. The option to generate the
netlist on the EDA tab of the MegaWizard.
VHDL file order might cause
compiler errors
You might see compiler errors if the
architectures file is compiled before the
entities, If this happens, edit the Altera qsf file
to ensure that the VHDL entities are compiled
before the architecture files.
VHDL compiler fails because of
missing qsf file
Edit the Altera qsf file and ensure that all
library statements are included in this file.
Problem Solution
LO
Chapter 14: Working with IP Input Working with Lattice IP
778 March 2014
Working with Lattice IP
The Lattice IP encryption scheme uses the flow described in Encryption and
Decryption, on page 703. The following procedure details how to incorporate
Lattice encrypted IP in your design.
1. Create a synthesis project.
2. Obtain the IP from Lattice, and add the encrypted file to your project.
The Lattice IP is encrypted using the persistent_key method described in
Specifying the Script Output Method, on page 715.
3. Synthesize your design.
The tool automatically decrypts the protected IP and synthesizes it with
the other unencrypted files in the design. During synthesis, the IP is
treated as a black box and you cannot view its contents in HDL Analyst
views.
After synthesis, the tool generates one output netlist. The IP is re-
encrypted and included in this netlist. The rest of the netlist is not
encrypted and can be read. The IP is not included in any simulation
netlists that are written out; it is treated as a black box.
See Encryption and Decryption, on page 703 for a flow diagram of this
process.
Incorporating Vivado IP Chapter 14: Working with IP Input
March 2014 779
Incorporating Vivado IP
Xilinx
You can automatically import Vivado IP into your FPGA synthesis project
without having to manually add the IP files and translate constraints. There
are three ways to import IP RTL or netlists.
IP RTL
For IP that synthesizes well in the Synopsys synthesis tools, like MIG IP
for example, import the RTL directly.
IP netlist, previously synthesized with Vivado in standalone mode
You can import a previously generated netlist that was separately
synthesized in Vivado. Use this method when you have already gener-
ated the netlist and constraint files with Vivado.
IP netlist, automatically synthesized with Vivado on import
You can automatically run Vivado synthesis from the FPGA synthesis
tool and generate the IP netlist. Use this method for any IP.
The following figure illustrates the three methods:
For details, see the following:
LO
Chapter 14: Working with IP Input Incorporating Vivado IP
780 March 2014
Generating Vivado IP, on page 780
Including Vivado IP RTL in the FPGA Synthesis Design, on page 782
Including IP Netlists that Were Synthesized Standalone, on page 785
Automatically Synthesizing and Including IP Netlists, on page 789
Debugging XDC Constraint Conversion Messages, on page 793
Constraint translation is now an integral part of the import process, and you
do not need to run it separately.
Generating Vivado IP
Generate Vivado IP with the Vivado IP Catalog tool. You can invoke this tool
independently or start it from within the FPGA synthesis tool. The following
procedure describes both methods and covers the Launch VivadoIP Catalog and
Generate IP steps shown in Incorporating Vivado IP, on page 779.
1. To run Vivado IP Catalog independently, start the Vivado tool.
2. Open the tool from the FPGA synthesis GUI or command line.
To open it from the GUI, select Import->Launch Vivado IP Catalog.
Specify the Vivado project file and make sure that the XILINX_VIVADO
variable points to the Vivado installation. Click Launch to open the
Vivado GUI.
March 2014 781
Use these commands to launch Vivado with a Tcl command, or run it
in batch mode with a Tcl script:
launch_vivado -project ipDir/prjName.xpr -device deviceName
lauch_vivado -batch -tcl TclScript
You can also use the launch_vivado command with the -gui option to
bring up the Vivado GUI. See launch_vivado, on page 72 in the
Command Reference Manual for the complete syntax for this
command.
3. Once in the Vivado GUI, generate the IP by doing the following:
Click the IP Catalog button in the left column.
Select your IP in IP Catalog and double-click to start configuration. The
configuration wizard opens.
Work through this wizard to configure your IP.
Click Generate when you are done.
The tool generates the IP. The files include the IP RTL files, one or more
xdc constraint files and an xml metadata file. The tool writes the IP RTL
files to the ipcores directory.
You can now import the IP into your FPGA synthesis design, using the
procedures described in Including Vivado IP RTL in the FPGA Synthesis
LO
782 March 2014
Design, on page 782 and Including IP Netlists that Were Synthesized
Standalone, on page 785.
Including Vivado IP RTL in the FPGA Synthesis Design
The most direct way to add Vivado IP RTL to an FPGA design is to include the
RTL for the IP as described below. This method is best suited for IP like MIG
IP, that synthesizes well. For other IP that does not synthesize well, import
the netlist instead, using one of the other methods listed in Incorporating
Vivado IP, on page 779.
The following figure summarizes the steps for including RTL for Vivado IP.
With this method, the RTL is not encrypted and place-and-route timing is
verified through the Synopsys synthesis flow.
March 2014 783
This procedure describes how to add the RTL to an FPGA design:
1. Generate the RTL for the IP as described in Generating Vivado IP, on
page 780.
There are two ways to add the RTL: from the GUI or the command line,
as described in the next two steps.
2. Follow these steps to add the IP RTL using the GUI:
Select Import->Add Vivado IP and specify the IP XML file and the name of
the IP on the first page of the wizard that opens.
Set IP Source to RTL. Click Next.
On this page, set optional arguments for the synthesis run. You can
specify that the IP be included directly or as a subproject, and
whether you want to run place-and-route after synthesis.
LO
784 March 2014
Click Import.
3. Alternatively you can specify a Tcl command instead of using the GUI:
add_vivado_ip -xml ipDirPath/ipName.xml -rtl
The example shows the basic settings to add IP RTL with the
add_vivado_ip command. The command extracts all RTL and constraint
files (-rtl) from the generated XML file identified by the -xml option
(ipName.xml). It also translates any XDC constraints to FDC constraints
as part of the process; constraint translation is no longer a separate
manual step. It adds the RTL and constraints as a subproject in the top-
level synthesis project, and also adds the original XDC files to the place-
and-route options file. The command writes a default log file in the
project directory.
4. You can also specify advanced options, either on the second page of the
GUI import wizard, or from the command line.
From the command line, you can also specify the -sub_project, -nopar, and
-log options, which do the following respectively: include the RTL as a
subproject, prevent the XDC files from being added to the par directory,
and write out a specific log file. For the complete syntax for this
command, refer to add_vivado_ip, on page 27 in the Command Refer-
ence Manual.
March 2014 785
5. To prevent unnecessary boundary optimizations, set syn_hier = fixed on
the instantiated IP. The following line shows the syntax for the attribute:
define_attribute {v:ipModuleName} syn_hier {fixed}
6. Synthesize the design using the IP files created by the previous steps. If
you created a separate subproject for the IP, you can either synthesize
the subproject independently or run synthesis on the entire design.
The tool creates the following files for synthesizing the IP at the top level
of the synthesis project:
IP XML file
IP RTL files
IP FDC constraints, automatically translated from IP XDC constraints
Original IP XDC, for use during place and route
7. Run place and route.
Including IP Netlists that Were Synthesized Standalone
This is a two-step manual import process, where the IP was previously
synthesized separately in Vivado, and is now imported into the FPGA
synthesis tool. Use this method when you already have a netlist and
constraints generated for the IP.
LO
786 March 2014
Follow these steps:
1. From the FPGA synthesis tool, launch Vivado with the Import->Launch
Vivado command (launch_vivado), and generate a synthesized netlist as
described in Generating Vivado IP, on page 780.
The netlist for the IP must be in EDIF format.
You must generate a Verilog wrapper file that contains all the I/O
definitions that link the IP to the rest of the design.
To generate these files, open the IP in Vivado and run the commands
shown below. See the tool documentation for details.
write_verilog -mode port ipName.vm
write_edif ipName.edf
You can now add the synthesized netlist to the synthesis project, either
from the GUI or the comamnd line, as the next steps describe.
March 2014 787
2. To include the synthesized netlist using the GUI, follow these steps:
Select Import->Add Vivado IP and specify the Xilinx XML file and the
name of the IP on the first page of the dialog box.
Click Synthesized Netlist and select the netlist files for the IP using the
plus and minus buttons. Make sure to select both the EDIF netlist
and the wrapper file. Click Next.
On the last page, set optional arguments for the synthesis run. You
can specify that the IP be included directly or as a subproject, and
Click Import.
The command extracts all netlist and constraint files and translates any
XDC constraints to FDC constraints. It adds the netlist and its
constraints as a subproject in the top-level synthesis project and also
adds the original XDC files to the place-and-route options file. The
command writes out a default log file in the project directory.
LO
788 March 2014
3. To add the IP from the command line, use the add_vivado_ip command:
add_vivado_ip -xml mig_7series_0.xml -netlist -edif
mig_7series_0.edf -verilog mig_7series_0_wrapper.vm
The command shown has the basic -xml, -netlist, -edif, and -verilog options
specified. It runs as described in the previous step.
4. Optionally, you can specify other advanced options from the command
line or in the GUI.
One useful option is -subproject, which lets you include the RTL as a
subproject. The advantages to using this option is reduced runtime, and
all the IP files are in a separate subproject directory. For the complete
command syntax and examples, refer to add_vivado_ip, on page 27 or
Add Vivado IP Command, on page 335 in the Command Reference
Manual.
5. Synthesize the design, using the IP files.
The top-level project file now includes the following files for the IP:
IP XML file
March 2014 789
Synthesized IP netlist (synthesized in Vivado previously)
I/O wrapper file
The synthesis tool optimizes the design, including the IP subproject. It
uses the timing information from the IP.
6. Place and route the design using the post-synthesis netlist and the
original XDC constraints.
Automatically Synthesizing and Including IP Netlists
This method integrates and automates the synthesis and import of Vivado IP
netlists into a single step, which is driven by the FPGA synthesis tool. The
tool launches Vivado, configures the IP, and runs Vivado synthesis before
generating the synthesized IP netlist in Vivado. It then imports the netlist into
the FPGA synthesis tool and optimizes it.
This netlist method is suited to any IP that does not synthesize well in the
Synopsys FPGA synthesis tools, like encrypted IP or IP with RTL syntax that
you prefer synthesizing automatically in Vivado.
LO
790 March 2014
1. From the FPGA synthesis tool, launch Vivado and generate a netlist as
described in Generating Vivado IP, on page 780.
You can now add the netlist to the FPGA design from either the GUI or
the command line, as described in the next two steps.
2. To include the netlist using the GUI, follow these steps:
Select Import->Add Vivado IP and specify the Xilinx project file and the
name of the IP on the first page of the dialog box.
March 2014 791
Click Vivado Synthesized IP (Automatic Synthesis). This option
automatically runs Vivado synthesis and generates a synthesized
netlist.
Click Next.
On the last page, set optional arguments for the synthesis run. You
can specify that the IP be included directly or as a subproject, and
Click Import.
This command first runs Vivado synthesis on the top-level IP module
and translates any XDC constraints to FDC constraints before gener-
ating a Verilog netlist. It then adds the Verilog netlist and constraints as
a subproject in the top-level synthesis project and adds the original XDC
files to the place-and-route options file. The command writes the results
to the default log file in the project directory.
3. To use the command line, specify the add_vivado_ip command with the
-xml, -netlist, and -synthesize options:
add_vivado_ip -xml ipPath/ipName.xml -netlist -synthesize
The command executes as described in the previous step.
LO
792 March 2014
4. Optionally, specify advanced options.
You can specify additional options like -sub_project, -nopar, and -log, or
their GUI equivalents. For the complete syntax and examples, refer to
add_vivado_ip, on page 27 or Add Vivado IP Command, on page 335 in
the Command Reference Manual.
5. Handle any XDC constraints that were not translated by fixing the
errors or by translating them manually.
See Debugging XDC Constraint Conversion Messages, on page 793 for
information about how to handle some constraint conversion issues.
6. Synthesize the design, which includes the IP files.
The top-level project file includes the following files for the IP:
IP XML file
Synthesized IP netlist, automatically synthesized by Vivado
The synthesis tool optimizes the design, including the IP subproject. It
uses the timing information from the IP.
7. Place and route the design using the post-synthesis netlist and the
original XDC constraints.
March 2014 793
Debugging XDC Constraint Conversion Messages
The synthesis tool automatically converts XDC constraints when you import
Vivado IP using the methods described in Incorporating Vivado IP, on
page 779. You do not need to convert constraints manually for each IP. The
tool reports any xdc constraints it fails to translate. Some of these situations
are described here:
Inability to translate a constraint
If the tool does not translate every constraint from the input XDC file,
the untranslated constraints are flagged by messages like the one shown
below. Manually modify any untranslated constraints.
Untranslated constraint at line 124 of XDC file.
Possible errors in using original xdc file for place and route
If you use the converted fdc file for synthesis, but the original xdc file for
place-and-route, be aware that the synthesis tool might rename a
constrained element during synthesis. The translation process accounts
for this in the fdc file, but the original xdc file remains untouched. Make
sure you manually edit the element in the original xdc file to match the
post-synthesis results.
The command generates a warning like the following when it detects this
issue:
Warning: The following constraint has an element with a _reg suffix in its name.
Synthesis may rename this element, and this can cause the constraint not to work if you
use the original Xilinx XDC file for P&R. It is suggested that you edit the XDC file and
remove _reg from the element name to avoid this problem.
Incorrect translations
Manually modify the incorrectly translated constraints in the fdc file.
Informational messages about missing or removed files:
A message like the one shown below is generated when the software
tries to remove an existing FDC file that matches the translated FDC,
before a new file is added to the project. This only happens when you
use the -project option. You can safely ignore this message.
No files found matching:
C:\Projects\project_mig\project_mig.srcs\sources_1\ip\mig_7series_v1_8_a_0\
synplify_project\FDC_constraints\rev_1\mig_7series_v1_8_a_0_xdc_translated.fdc
LO
794 March 2014
Messages like the one shown below are generated if the XDC file is
removed from the project first, and then added back for use with
place and route. You can safely ignore this message.
Removed file:
C:\Projects\project_mig\project_mig.srcs\sources_1\ip\mig_7series_v1_8_a_0\
mig_7series_v1_8_a_0\user_design\constraints\mig_7series_v1_8_a_0.xdc
Working with Xilinx IP Cores Chapter 14: Working with IP Input
March 2014 795
Working with Xilinx IP Cores
You can incorporate Xilinx IP cores into your design in different ways,
depending on the format of the IP. For further information about secure and
non-secure edn, ngc, and, ngo files, see the following:
Xilinx Cores, on page 795
Secure and Non-secure Cores, on page 796
For information about including EDK cores or IP produced with encryptIP, see
Converting Xilinx Projects with ise2syn, on page 800.
Xilinx Cores
The following table describes how the tool handles different types of Xilinx IP
cores:
EDN The tool can read the contents of an EDN core. This means that it can
absorb and optimize the contents. It can also place the contents along
with the rest of the design. The tool includes the core contents in the
synthesized EDIF, and forward-annotates any placement constraints
in the accompanying ncf file.
NGO The tool can read the contents of the NGO core. This means that it
can absorb and optimize the contents. It can place the contents along
with the rest of the design. The tool includes the core contents in the
synthesized EDIF, and forward-annotates any placement constraints
in the accompanying ncf file.
NGC, non-
secured
The tool can read the core contents. For the Synplify Premier tool,
limited optimizations can be performed on the core, like constant
propagation. It can place the contents along with the rest of the
design. The tool annotates the core contents to the synthesized EDIF,
and forward-annotates any placement constraints in the
accompanying ncf file.
NGC,
secured
The tool can read the contents of secure NGC cores. For the Synplify
Premier tool, limited optimizations can be performed on the core, like
constant propagation. It can place the contents along with the rest of
the design. The tool writes a separate encrypted EDIF netlist for each
core.
LO
Chapter 14: Working with IP Input Working with Xilinx IP Cores
796 March 2014
The following table broadly summarizes how the synthesis tool treats various
kinds of IP:
Secure and Non-secure Cores
This section describes secure and non-secure IP cores and how the tools
handle them during synthesis.
Add the edn, ngo, and/or ngc core files to your project. The synthesis tools
can read these formats and incorporate the cores into the design.
IP Format Synthesis Input Synthesis Output Format
EDN, Non-secure NGC,
NGO
Add file Plain text
Secure NGC Add file Encrypted EDIF
Encrypted EDK Add IP with Import IP->Import
Xilinx EDK/ISE Project
White boxes
Encrypted RTL from
encryptIP
Download with Import IP->
Download IP from Synopsys,
unzip, and add file
Black box or plain text, as
determined by IP owner
IP Core File IP Visibility Effect of Synthesis Optimizations
EDN
NGO
NGC, non-secured
Core contents
visible to the
synthesis tool
For the Synplify Premier tool, some
optimizations can occur on the core, like
constant propagation. The contents can be
written to the output netlist along with the
rest of design.
NGC, secured Core contents
visible to the
synthesis tool
The tool cannot optimize or place cores or
absorb them into the netlist. During
synthesis, the secure core is treated as a
white box (a model that includes the port
interface and timing information only), and all
optimizations are based on this.
March 2014 797
After you synthesize the design, the synthesis process treats the cores as
follows:
After synthesis, the tool generates core output files for P&R:
Non-secure core with
no black box attributes
attached
For the Synplify Premier tool, limited optimizations
like constant propagation can be performed as
needed.
You can view the internals of the core in the RTL and
Technology views.
Non-secure core
marked as a white box
The synthesis tool does not modify the core or write
out the internals of the core in the synthesized netlist.
Secure cores For the Synplify Premier tool, limited optimizations
like constant propagation can be performed.
You can view the internals of the core in the
Technology view.
EDN
NGC, non-secured
NGO
The tool generates one main output netlist that includes
all the unencrypted cores. The log file resource usage
report includes the resources used by the cores.
All timing constraints are forward-annotated in the
synplicity.ucf file. This file includes imported UCF
constraints (see Converting and Using Xilinx UCF
Constraints, on page 325) as well as user-specified
timing constraints.
Placement constraints are forward-annotated in the
design.ncf file.
NGC, secured The tool writes out a top-level EDIF file which references
individual EDIFs for each instantiation of a secure core.
These files are not included in the main netlist.The tool
suffixes the original core name with _syn when it names
the lower-level files. The log file report of resource usage
includes the resources used by the cores.
The synthesis tool puts all timing constraints into one
synplicity.ucf file for the P&R tool. This file includes
imported UCF constraints (see Converting and Using
Xilinx UCF Constraints, on page 325) as well as user-
specified timing constraints.
Placement constraints, excluding constraints for secure
cores, are forward-annotated in a design.ncf file.
For each secure core, the tool generates an individual
ncf file with the constraints for that core.
LO
Chapter 14: Working with IP Input Working with Xilinx IP Cores
798 March 2014
Limitations
Module names can be changed in the final netlist that is output from
logic/physical synthesis, so names may differ from the module names used
in your UCF for place and route; this produces an error in the place-and-
route tool.
As a workaround, manually update the module names in the UCF.
Open the technology view (srm file).
Select the module and hit Ctrl-c to copy the module name as it appears in
the netlist.
In the UCF, paste the module name (replace the old module name with the
updated module name).
Including Xilinx Cores for Synthesis
Xilinx
The following procedure shows you how to include Xilinx secure and non-
secure cores in your project for logic synthesis or graph-based physical
synthesis.
The procedure itself is the same for both secure and non-secure cores, but
the implementation details are different, because the two kinds of cores are
treated differently.
1. Set up your design:
Set the XILINX environment variable to point to ISEpath/ISE.
Instantiate the Xilinx core in your top-level RTL.
Target a technology that supports this design flow.
2. Add the edn, ngo, and/or ngc core files directly to your project. The
synthesis tools can read these formats and incorporate the cores into
the design. For more information about theses cores, see Secure and
Non-secure Cores, on page 796.
3. Set the syn_macro attribute to determine how you want the cores to be
treated during synthesis. For details about this attribute, see
syn_macro, on page 255.
March 2014 799
Optionally, set the option to automatically run P&R from the
synthesis tool interface after synthesis is complete. If you chose to
run P&R from the synthesis tool, the output netlist and constraint
files are automatically copied to the P&R directory.
Set any other options.
Click the Run button to run synthesis.
The synthesis tools read the timing and resource usage information
from the core files. The tool runs synthesis and places the design at the
same time. For more information about how synthesis treats these cores
and the output core files generated for P&R, see Secure and Non-secure
Cores, on page 796.
LO
Chapter 14: Working with IP Input Converting Xilinx Projects with ise2syn
800 March 2014
Converting Xilinx Projects with ise2syn
The ise2syn utility (Import->Import ISE/EDK Project) takes a Xilinx project and
converts it to a synthesizable project which you can run in the Synplify Pro or
Synplify Premier tools. The ise2syn utility converts constraints when it trans-
lates the Xilinx project.
The following describe the ise2syn utility and its use in more detail:
Converting Designs with the ise2syn Utility, on page 800
The ise2syn Conversion Process, on page 806
Specifying EDK Cores as White Boxes, on page 809
Converting Designs with the ise2syn Utility
You can use the ise2syn utility to automatically generate a synthesis project
from a Xilinx project. You can use this utility to convert the following Xilinx
projects:
ISE *.ise, *.xise, and *.xmp projects. See Converting ISE Designs with the
ise2syn Utility, on page 801.
EDK standalone projects (*.xmp) or sub-projects used in an ISE project,
including EDK white box cores. See Converting EDK Designs with the
ise2syn Utility, on page 803.
Core generator modules that are sub-blocks in an ISE project
The utility translates constraints from ucf and ncf files. The utility applies to
ISE projects created with ISE 11.1 or later.
Converting Xilinx Projects with ise2syn Chapter 14: Working with IP Input
March 2014 801
The following figure summarizes the design flow for converting ISE projects.
See Converting ISE Designs with the ise2syn Utility, on page 801 and
Converting EDK Designs with the ise2syn Utility, on page 803 for detailed
procedures.
Converting ISE Designs with the ise2syn Utility
The following procedure describes how to convert ISE designs with the ise2syn
utility.
1. Make sure the ISE project was created with ISE 11.1 or later. If you used
an earlier version of ISE, update it version 11.1 or later before
proceeding.
2. Set the XILINX environment variable to the ISE installation used for
running the ISE project.
LO
802 March 2014
For example: XILINX=\\myServer\pctools\Xilinx\ise112\ISE
3. Check that you have write permission to the synthesis project directory
for conversion.
4. Import the ISE project into the Synplify Pro or Synplify Premier tool.
The following describes how to use the GUI to import the project. For the
syntax of the equivalent Tcl command, see ise2syn, on page 70 in the
Reference Manual.
Select the Import-> Import Xilinx ISE/EDK Project command. The Import
Xilinx Project dialog box opens. You can import .ise, .xise, or .xmp
projects.
Set other options to import the project, and click Import.
March 2014 803
After it successfully completes, the ise2syn utility generates the following
files. See Conversion Process, on page 806 for details of the process.
5. Use the converted prj and sdc files to run synthesis.
6. If you have an _unapplied.ucf file with unconverted constraints, check this
file and manually convert these constraints for input to P&R.
7. Run ISE P&R using the files generated after synthesis.
Converting EDK Designs with the ise2syn Utility
The following procedure describes how to convert EDK designs with the
ise2syn utility. For additional information about working with EDK cores, see
Specifying EDK Cores as White Boxes, on page 809.
1. Make sure the ISE project was created with ISE 11.1 or later. If you used
an earlier version of ISE, update it version 11.1 or later before
proceeding.
2. Set the following environment variables:
design.prj Synplify Pro or Synplify Premier project file
for FPGA synthesis
design_sdc/filename_conv.sdc Converted ucf, ncf, or xcf constraints for
synthesis
design_sdc/filename_unapplied.ucf File that contains unconverted constraints.
See Constraint Translation, on page 808
for details.
XILINX Set to the ISE installation used for running the ISE
project For example:
XILINX=\\myServer\pctools\Xilinx\ise112\ISE
XILINX_EDK Set to the EDK installation used for running the EDK
project. For example:
XILINX_EDK=\\myServer\pctools\Xilinx\ise112\EDK
XIL_MYPERIPHERALS If required, set to the location of user-specific cores. For
example:
XIL_MYPERIPHERALS=e\my_edk_cores
LO
804 March 2014
3. Check that you have write permission to the synthesis project directory
for conversion.
4. For an EDK project, first synthesize the project using the ISE tool.
When you use ISE to run XST synthesis, the tool generates ngc files for
the EDK cores. The FPGA synthesis tools use these ngc files instead of
the HDL files for the EDK projects. The tool also uses the ngc for
encrypted cores, because the ise2syn translator does not read encrypted
cores.
5. Import the ISE project into the Synplify Pro or Synplify Premier tool. The
following describes how to use the GUI to import the project. For the
syntax of the equivalent Tcl command, see ise2syn, on page 70 in the
Reference Manual.
Select Import-> Import Xilinx ISE/EDK Project. The Import Xilinx Project dialog
box opens. You can import .ise, .xise, or .xmp projects.
March 2014 805
If you have an encrypted core or a core that uses non-standard HDL,
enable the Force White Box Cores option and specify the names of the
cores. See Force White Box Cores Option (EDK), on page 342 in the
Reference Manual for details of its use.
If you do not do so, the tool errors out because it cannot read the
encrypted core or non-standard HDL. If the synthesis compiler does
error out while translating the project, enable the Force White Box Cores
option and specify the core names. When you enable this option, the
LO
806 March 2014
synthesis tool uses ngc files instead of the standard HDL files for the
specified cores.
Set other options to import the project, and click Import.
After it successfully completes, the ise2syn utility generates the following
files. See Conversion Process, on page 806 for details.
6. Use the converted prj and sdc files to run synthesis.
7. If you have an _unapplied.ucf file with unconverted constraints, check this
file and manually convert these constraints for input to P&R.
8. Run ISE P&R using the files generated after synthesis.
The ise2syn Conversion Process
The following describe the ise2syn conversion process:
Conversion Process, on page 806
Troubleshooting ise2syn Conversion Issues, on page 807
Constraint Translation, on page 808
Conversion Process
The ise2syn utility goes through the following phases when it converts the ISE
or EDK project to a Synplify Pro or Synplify Premier project ready for
synthesis.
design.prj Project file for FPGA synthesis
design_sdc/filename_conv.sdc Converted ucf, ncf, or xcf constraints for
synthesis
design_sdc/filename_unapplied.ucf Unconverted constraints file. See
Constraint Translation, on page 808 for
details.
March 2014 807
The utility translates ISE project options and EDK or Coregen sub-
projects, and generates a Synplify Pro or Synplify Premier project file
(prj).
It compiles the project to get a netlist (srs) file.
For EDK projects, it then updates the memory block names to use the
full hierarchical path names.
It translates the ucf, ncf, or xcf constraints from the Xilinx project to
the sdc format. It writes all untranslated constraints to the *_unapplied.ucf
file.
It then updates the project file.
Troubleshooting ise2syn Conversion Issues
The following table lists possible reasons for errors that occur at different
stages of the translation flow.
Error Occurs When ... Possible Causes
Importing the ISE
project
The XILINX/XILINX_EDK environment variable does not
point to a valid ISE/EDK installation.
The XILINX_EDK environment variable points to an EDK
version that is not the same as the one with which the
imported project was created
You do not have write permission to the specified Synplify
project directory.
Compiling the imported
project
For EDK projects with cores that use non-standard HDL,
specify those cores as white boxes when you import the
project.
Converting bmm files No errors are expected. If you see an error at this stage,
report it.
LO
808 March 2014
Constraint Translation
The ise2syn utility translates constraints; this has some limitations when it
translates Xilinx constraints.
The synthesis tools do not currently translate the following UCF
constraints. All untranslated Xilinx constraints are written to the
*_unapplied.ucf file.
OPEN/CLOSED in AREAGROUP constraints
OFFSET constraints that use the VALID keyword
OFFSET constraints that use the HIGH/LOW clock edges
If the generated names of objects like nets and instances do not exactly
match the XST-generated names, the tool does not convert the
constraints associated with these objects. It puts these untranslated
constraints in the _unapplied.ucf file. Make sure to check this file and
manually edit constraints as needed.
The tools do not translate constraints applied on inferred objects in an
XST-generated netlist.
Support for constraints applied on a core that uses ncf files is not
tested.
Translating constraints Currently, there is limited support for translating
constraints, as detailed in Constraint Translation, on
page 808. All unsupported constraints are written to the
*_unapplied.ucf file. Check this file and convert the
constraints manually for P&R.
No errors are expected at this stage. If you see an error,
report it.
Synthesizing the
converted project
No errors are expected. If you see an error at this stage,
report it.
Running P&R on the
converted project
This could be caused by untranslated constraints. Check
the *_unapplied.ucf file and convert the constraints
manually.
Error Occurs When ... Possible Causes
March 2014 809
Specifying EDK Cores as White Boxes
It is very important that you accurately define EDK cores as white boxes
because the synthesis run will fail if the design is not correctly specified, and
you will have to iterate through another run. For the ise2syn flow, a white box
is one that has a core definition in either edn or ngc format.
1. In the Synplify Pro or Synplify Premier software, and select Import IP-
>Import Xilinx ISE/EDK Project. This opens the Import Xilinx EDK dialog box.
2. If you want to treat a core as a white box during synthesis, specify the
core name in the Force White Box option. For details about settings for this
option, refer to Force White Box Cores Option (EDK), on page 342 in the
Reference Manual.
The software searches for the core in the mhs file, and for a definition file
named implementation/core.ngc. It adds this file to the project. The core is
treated as a white box during synthesis. If it does not find the named
core or the ngc file, it issues a warning message.
LO
810 March 2014
March 2014 811
CHAPTER 15
Optimizing Processes for Productivity
This chapter covers topics that can help the advanced user improve produc-
tivity and inter operability with other tools. It includes the following:
Using Batch Mode, on page 812
Working with Tcl Scripts and Commands, on page 819
Automating Flows with synhooks.tcl, on page 826
Using Revision Control Tools, on page 829
LO
Chapter 15: Optimizing Processes for Productivity Using Batch Mode
812 March 2014
Using Batch Mode
Batch mode is a command-line mode in which you run scripts from the
command line. You might want to set up multiple synthesis runs with a
batch script. You can run in batch mode if you have a floating license, but
not with a node-locked license.
Batch scripts are in Tcl format. For more information about Tcl syntax and
commands, see Working with Tcl Scripts and Commands, on page 819.
This section describes the following operations:
Running Batch Mode on a Project File, on page 812
Running Batch Mode with a Tcl Script, on page 813
Queuing Licenses, on page 815
Running Batch Mode on a Project File
Use this procedure to run batch mode if you already have a project file set up.
You can also run batch mode from a Tcl script, as described in Running Batch
Mode with a Tcl Script, on page 813.
1. Make sure you have a project file (prj) set up with the implementation
options. For more information about creating this Tcl file, see Creating a
Tcl Synthesis Script, on page 821.
2. From a command prompt, go to the directory where the project files are
located, and type one of the following, depending on which product you
are using:
synplify -batch project_file_name.prj
synplify_pro -batch project_file_name.prj
synplify_premier -batch project_file_name.prj
synplify_premier_dp -batch project_file_name.prj
The software runs synthesis in batch mode. Use absolute path names or
a variable instead of a relative path name.
If the -tclcmd switch is used, synthesis will not automatically run. To
make synthesis run, project -run must be added:
synplify_pro -batch myproj.prj -tclcmd "project -run"
Using Batch Mode Chapter 15: Optimizing Processes for Productivity
March 2014 813
The -tclcmd switch specifies the tcl commands to be executed before the
synthesis starts. To run a constraint check before synthesis:
synplify_pro -batch myproj.prj -tclcmd "project -run
constraint_check"
The -tclcmd switch also allows the synthesis results path to be changed.
synplify_pro -batch "D:/tests/myproj.prj" -tclcmd "set_option -
result_file \"./impl1/test.edf\" ; project -run"
The software returns the following codes after the batch run:
0 - OK
2 - logical error
3 - startup failure
4 - licensing failure
5 - batch not available
6 - duplicate-user error
7 - project-load error
8 - command-line error
9 - Tcl-script error
20 - graphic-resource error
21 - Tcl-initialization error
22 - job-configuration error
23 - parts error
24 - product-configuration error
25 - multiple top levels
3. If there are errors in the source files, check the standard output for
messages. On Linux systems, this is generally the monitor; on Windows
systems, it is the stdout.log file.
4. After synthesis, check the resultFile.srr log file for error messages about
the run.
Running Batch Mode with a Tcl Script
The following procedure shows you how to create a Tcl batch script for
running synthesis. If you already have a project file set up, use the procedure
described in Running Batch Mode on a Project File, on page 812.
1. Create a Tcl batch script. See Creating a Tcl Synthesis Script, on
LO
814 March 2014
2. Save the file with a tcl extension to the directory that contains your
source files and other project files.
3. From a command prompt, go to the directory with the files and type one
of the following as appropriate:
synplify -batch Tcl_script.tcl
synplify_pro -batch Tcl_script.tcl
synplify_premier -batch Tcl_script.tcl
synplify_premier_dp -batch Tcl_script.prj
The software runs synthesis in batch mode. The synthesis (compilation
and mapping) status results and errors are written to the log file result-
File.srr for each implementation. The synthesis tool also reports success
and failure return codes.
4. Check for errors.
For source file or Tcl script errors, check the standard output for
messages. On Linux systems, this is generally the monitor in addition
to the stdout.log file; on Windows systems, it is the stdout.log file.
For synthesis run errors, check the resultFile.srr log file. The software
uses the following error codes:
0 - OK
2 - logical error
3 - startup failure
4 - licensing failure
5 - batch not available
6 - duplicate-user error
7 - project-load error
8 - command-line error
9 - Tcl-script error
20 - graphic-resource error
21 - Tcl-initialization error
22 - job-configuration error
23 - parts error
24 - product-configuration error
25 - multiple top levels
March 2014 815
Queuing Licenses
A common problem when running in batch mode is that the run fails because
all of the available licenses are in use. License queuing allows a batch run to
wait for the next available license when a license is on the server but not
immediately available.
You can specify either blocking or non-blocking queuing. With blocking-style
queuing, the tool waits until a license becomes available; with non-blocking-
style queuing, the tool waits the specified length of time for a license to
become available.
You can also queue DesignWare IP licenses, so that they can be used as they
become available.
Queuing Considerations, on page 815
Queuing Licenses, on page 815
Queuing Synopsys DesignWare IP Licenses, on page 817
Queuing Considerations
Consider these points when using queuing:
A blocking-style queuing is used; license checkout does not exit until a
license becomes available.
There is no maximum wait time; once initiated, the tool can wait indefi-
nitely for a license.
If the server shuts down while the tool is waiting, a checkout failure is
reported.
When two licenses are required, queuing waits only until the first license
becomes available (and not the second) to avoid holding a license unnec-
essarily.
Queuing Licenses
The following procedure describes how to specify blocking-style or non-
blocking style queuing for synthesis licenses. You can specify the licensed
features for queuing in an environment variable or directly in batch mode.
LO
816 March 2014
1. Specify the list of licensed features you want to queue, using either of
the following methods:
Set the toolName_LICENSE_TYPE environment variable to the features
you want. For example:
SYNPLIFYPRO_LICENSE_TYPE=synplifypro:synplifypro_altera
Specify a list of features to wait for using the -batch, -licensetype and -
license_wait options. For example:
synplify_pro -batch -license_wait -licensetype
synplifypro:synplifypro_altera myProject.prj
See synplify, synplify_pro, synplify_premier, synplify_premier_dp, on
page 156 in the Command Reference for syntax details.
2. To enable blocking-style queuing, do one of the following:
Set environment variable toolName_LICENSE_WAIT=1 (toolName is the
name of the FPGA synthesis tool).
In batch mode, include a -license_wait command-line argument, as
shown in the following examples:
synplify_pro -batch -license_wait Tcl_script.tcl
synplify_premier -batch -license_wait projectFilename.prj
With blocking-style queuing enabled, the tool waits until the requested
license becomes available. It generates the following message in the
stdout.log or the Tcl window:
Waiting for license: toolName
3. To enable non-blocking-style queuing, do either of the following:
Set environment variable toolName_LICENSE_WAIT=waitTime
(toolName is the name of the FPGA synthesis tool and waitTime is the
maximum wait time in seconds). For example:
SYNPLIFYPRO_LICENSE_WAIT=180
SYNPLIFYPREMIER_LICENSE_WAIT=300
The waitTime value determines the maximum wait time, in seconds:
March 2014 817
Include a -license_wait waitTime command-line argument when
launching batch mode as shown in the following examples:
synplify_pro -batch -license_wait waitTime Tcl_script.tcl
synplify_premier -batch -license_wait waitTime projectFilename.prj
When non-blocking-style queuing is enabled, the tool waits up to the
maximum time limit specified for the license to become available. The
tool generates the following message in stdout.log or the Tcl window:
Waiting up to n seconds for license: toolName
Queuing Synopsys DesignWare IP Licenses
In batch mode, the synthesis tool waits for an available IP license. When no
license is available, the synthesis tool waits for either a specified time period
or indefinitely. You can queue DesignWare IP licenses with a command line
parameter to the tool invocation command.
There are some points to consider when queuing DesignWare licenses:
The queuing mechanism has no precedence over other Synopsys
products such as Design Compiler, and operates independently from
their license queues.
Requested Synopsys DesignWare IP licenses are queued when the
license is not immediately available.
The procedure to queue DesignWare licenses is described below; refer to
synplify, synplify_pro, synplify_premier, synplify_premier_dp, on page 156 in
the Command Reference for syntax details.
1. To enable IP license queuing in batch mode, use the following command-
line parameter along with -batch parameter:
-ip_license_wait waitTime
WaitTime Value Queuing Behavior
Undefined or 0 Queuing off
1 Queuing on; wait indefinitely
>1 Queuing on; wait up to the specified number of seconds
LO
818 March 2014
waitTime is the number of seconds to wait for a license. If you specify 1,
the synthesis tool waits indefinitely for the requested IP licenses.
The following examples illustrate command usage:
synplify_pro -batch -ip_license_wait waitTime Tcl_script.tcl
synplify_premier -batch -ip_license_wait waitTime
projectFilename.prj
If the wait time elapses and an IP license is still not available, the
synthesis tool continues processing using any available license.
An IP block without a requested license is processed as either an error or
a black box according to the project settings.
Working with Tcl Scripts and Commands Chapter 15: Optimizing Processes for Productivity
March 2014 819
Working with Tcl Scripts and Commands
The software uses extensions to the popular Tcl (Tool Command Language)
scripting language to control synthesis and for constraint files. See the
following for more information:
Using Tcl Commands and Scripts, next
Generating a Job Script, on page 820
Setting Number of Parallel Jobs, on page 820
Creating a Tcl Synthesis Script, on page 821
Using Tcl Variables to Try Different Clock Frequencies, on page 823
Using Tcl Variables to Try Several Target Technologies, on page 824
Running Bottom-up Synthesis with a Script, on page 825
You can also use synhooks Tcl scripts, as described in Automating Flows with
synhooks.tcl, on page 826.
Using Tcl Commands and Scripts
1. To get help on Tcl syntax, do any of the following:
Refer to the online help (Help->Tcl Help) for general information about
Tcl syntax.
Refer to the Reference Manual for information about the synthesis
commands.
Enter help * in the Tcl window for a list of all the Tcl synthesis
commands.
Enter help commandName in the Tcl window to see the syntax for an
individual command.
2. To run a Tcl script, do the following:
Create a Tcl script. Refer to Generating a Job Script, on page 820 and
Creating a Tcl Synthesis Script, on page 821.
Run the Tcl script by either entering source Tcl_scriptfile in the Tcl
script window, or by selecting File->Run Tcl Script, selecting the Tcl file,
and clicking Open.
LO
Chapter 15: Optimizing Processes for Productivity Working with Tcl Scripts and Commands
820 March 2014
The software runs the selected script by executing each command in
sequence. For more information about Tcl scripts, refer to the following
sections.
Generating a Job Script
You can record Tcl commands from the interface and use it to generate job
scripts.
1. In the Tcl script window, enter recording -file logfile to write out a Tcl log
file.
2. Work through a synthesis session.
The software saves the commands from this session into a Tcl file that
you can use as a job script or as a starting point for creating other
Tcl files.
For the command syntax, see recording, on page 96 in the Reference manual.
Setting Number of Parallel Jobs
You can set the maximum number of parallel jobs by setting a variable in the
ini file, by defining a Tcl variable, or specifying the maximum number in the
GUI.
1. To set the maximum number of parallel jobs in the ini file, do the
following:
Open the ini file for the synthesis tool. For example,
synplify_premier_dp.ini.
Add the MaxParallelJobs variable to the ini file, as follows:
[JobSetting]
MaxParallelJobs=<n>
The tool uses the MaxParallelJobs value from the ini file as the default for
both the UI (Project->Options) and batch mode. This value remains in
effect until you reset it in the ini file or from the GUI, as described in the
next step. To locate this configuration and initialization file (ini), see
Input Files, on page 292.
March 2014 821
2. To set or change the maximum number of parallel jobs from the GUI, do
the following:
Select Project->Options->Configure Compile Point Process.
Set the value you want in the Maximum number of parallel synthesis jobs
field, and click OK. This field shows the current ini value, but you
can reset it, and it will remain in effect until you change it again. The
value you set is saved to the ini file.
3. To set a Tcl variable for the maximum number of parallel jobs, do the
following:
Determine where you are going to define the variable. You can do this
in the project file, or a Tcl file, or you can type it in the Tcl window. If
you specify it in a Tcl file, you must source the file. If you specify it in
the Tcl window, the tool does not save the value, and it will be lost
when you end the current session.
Specify the max_parallel_jobs variable with the set_option Tcl command:
set_option -max_parallel_jobs value
The tool applies the max_parallel_jobs value specified to all project files
and their respective implementations. This is a global option. The
maximum number of parallel jobs remains in effect until you specify a
new value. This new value takes effect immediately, going forward.
However, when you set this option from the Tcl command window, the
max_parallel_jobs value is not saved and will be lost when you exit the
application.
Creating a Tcl Synthesis Script
Tcl scripts are text files with a tcl extension. You can use the graphic user
interface to help you create a Tcl script. Interactive commands that you use
actually execute Tcl commands, which are displayed in the Tcl window as
they are run. You can copy the command text and paste it into a text file that
you build to run as a Tcl script. For example:
add_file prep2.v
set_option -technology STRATIX
set_option -part EP1SGX40D
set_option -package FC1020
project -run
LO
822 March 2014
The following procedure covers general guidelines for creating a synthesis
script.
1. Use a text file editor or select File->New, click the Tcl Script option, and type
a name for your Tcl script.
2. Start the script by specifying the project with the project -new command.
For an existing project, use project -load project.prj.
3. Add files using the add_file command. The files are added to their
appropriate directories based on their file name extensions (see add_file,
on page 22 in the Reference Manual). Make sure the top-level file is last
in the file list:
add_file statemach.vhd
add_file rotate.vhd
add_file memory.vhd
add_file top_level.vhd
add_file design.fdc
For information on constraints and vendor-specific attributes, see Using
a Text Editor for Constraint Files (Legacy), on page 130 for details about
constraint files.
4. Set the design synthesis controls and the output:
Use the set_option command for setting implementation options and
vendor-specific controls as needed. See the appropriate vendor
chapter in the Synplify Reference Manual for details.
Set the output file information with project -result_file and project -log_file.
5. Set the file and run options:
Save the project with a project -save command
Run the project with a project -run command
Open the RTL and Technology views:
open_file -rtl_view
open_file -technology_view
6. Check the syntax.
Check case (Tcl commands are case-sensitive).
Start all comments with a hash mark (#).
March 2014 823
Always use a forward slash (/) in directory and pathnames, even on
the Windows platform.
Using Tcl Variables to Try Different Clock Frequencies
To create a single script for multiple synthesis runs with different clock
frequencies, you need to create a Tcl variable for the different settings you
want to try. For example, you might want to try different target technologies.
1. To create a variable, use this syntax:
set variable_name {
first_option_to_try
second_option_to_try
...}
2. Create a foreach loop that runs through each option in the list, using the
appropriate Tcl commands. The following example shows a variable set
up to synthesize a design with different frequencies. It also creates a
separate log file for each run.
The following code shows the complete script:
set try_freq {
85.0
90.0
92.0
95.0
97.0
100.0
)
foreach frequency $try_freq {
set_option -frequency $frequency
project -log_file $frequency.srr
project -run}
Tcl commands that set the
frequency, create separate log files
for each run, and run synthesis
Foreach loop
Set of frequencies
to try
LO
824 March 2014
project -load design.prj
set try_these {
20.0
24.0
28.0
32.0
36.0
40.0
}
foreach frequency $try_these {
set_option -frequency $frequency
project -log_file $frequency.srr
project -run
open_file -edit_file $frequency.srr
}
Using Tcl Variables to Try Several Target Technologies
This technique used here to run multiple synthesis implementations with
different target technologies is similar to the one described in Using Tcl
Variables to Try Different Clock Frequencies, on page 823. As in that section,
you use a variable to define the target technologies you want to try.
1. Create a variable called try_these with a list of the technologies.
set try_these {
STRATIXII CYCLONEII VIRTEX2 # list of technologies
}
2. Add a foreach loop that creates a new implementation for each
technology and opens the RTL view for each implementation.
foreach technology $try_these {
impl -add
set_option -technology $technology
project -run -fg
open_file -rtl_view
}
The following code example shows the script:
March 2014 825
# Open a new project, set frequency, and add files.
project -new
set_option -frequency 33.3
add_file -verilog D:/test/simpletest/prep2_2.v
# Create the Tcl variable to try different target technologies.
set try_these
STRATIXII CYCLONEII VIRTEX2 # list of technologies
}
# Loop through synthesis for each target technology.
foreach technology $try_these {
impl -add
set_option -technology $technology
project -run -fg
open_file -rtl_view
}
Running Bottom-up Synthesis with a Script
To run bottom-up synthesis, you create Tcl scripts for individual logic blocks,
and a script for the top level that reads the other Tcl scripts.
1. Create a Tcl script for each logic block. The Tcl script must synthesize
the block. See Creating a Tcl Synthesis Script, on page 821 for details.
2. Create a top-level script that reads the block scripts. Create the script
with the with the project -new command.
3. Add the top-level data:
Add source and constraint files with the add_file command.
Set the top-level options with the set_option command.
Set the output file information with project -result_file and project -log_file.
Save the project with a project -save command.
Run the project with a project -run command.
4. Save the top-level script, and then run it using this syntax:
source block_script.tcl
When you run this command, the entire design is synthesized, begin-
ning with the lower-level logic blocks specified in the sourced files, and
then the top level.
LO
Chapter 15: Optimizing Processes for Productivity Automating Flows with synhooks.tcl
826 March 2014
Automating Flows with synhooks.tcl
This procedure provides the advanced user with callbacks that let you
customize your design flow or integrate with other products. For example,
you might use the callbacks to send yourself email when a job is done (see
Automating Message Filtering with a Tcl Script, on page 361), or to automati-
cally copy files to another location after mapping. You can use the callback
functions to integrate with a version control system, or generate the files
needed to run formal verification with the Cadence Conformal tool. The
procedure is based on a file called synhooks.tcl, which contains the Tcl
callbacks.
1. Copy the synhooks.tcl file from the installDirectory/examples directory to a
new location.
You must copy the file to a new location so that it does not get
overwritten by subsequent product installations and you can maintain
your customizations from version to version. For example, copy it to
C:/work/synhooks.tcl.
2. Define an environment variable called SYN_TCL_HOOKS, and point it to
the location of the synhooks.tcl file.
3. Open the synhooks.tcl file in a text editor, and edit the file so that the
commands reflect what you want to do. The default file contains
examples of the callbacks, which provide you with hooks at various
points of the design process.
Customize the file by deleting the ones you do not need and by adding
your customized code to the callbacks you want to use. The following
table summarizes the various design phases where you can use the
callbacks and lists the corresponding functions. For details of the
syntax, refer to synhooks File Syntax, on page 770 in the Reference
Manual.
Design Phase Tcl Callback Function
Project Setup Callbacks
Settings defaults for projects proc syn_on_set_project_template
Creating projects proc syn_on_new_project
Opening projects proc syn_on_open_project
Automating Flows with synhooks.tcl Chapter 15: Optimizing Processes for Productivity
March 2014 827
Save the file.
As you synthesize your design, the software automatically executes the
function callbacks you defined at the appropriate points in the design
flow.
Example: proc syn_on_start_run
The following code example gets selected files from the project browser at the
start of a run:
Closing projects proc syn_on_close_project
Application Callbacks
Starting the application after
opening a project
proc syn_on_start_application
Exiting the application proc syn_on_exit_application
Run Callbacks
Starting a run. See Example:
proc syn_on_start_run, on
page 827.
proc syn_on_start_run
Ending a run proc syn_on_end_run
Key Assignment Callbacks
Setting an operation for Ctrl-
F8. See Example: proc
syn_on_press_ctrl_f8, on
page 828.
proc syn_on_press_ctrl_f8
F9
F11
Design Phase Tcl Callback Function
LO
Chapter 15: Optimizing Processes for Productivity Automating Flows with synhooks.tcl
828 March 2014
proc syn_on_start_run {compile c:/work/prep2.prj rev_1} {
set sel_files [get_selected_files -browser]
while {[expr [llength $sel_files] > 0]} {
set file_name [lindex $sel_files 0]
puts $file_name
set sel_files [lrange $sel_files 1 end]
}
}
Example: proc syn_on_press_ctrl_f8
The following code example gets all the selected files from the project browser
and project directory when the Ctrl-F8 key combination is pressed:
proc syn_on_press_ctrl_f8 {} {
set sel_files [get_selected_files]
while {[expr [llength $sel_files] > 0]} {
set file_name [lindex $sel_files 0]
puts $file_name
set sel_files [lrange $sel_files 1 end]
}
}
Using Revision Control Tools Chapter 15: Optimizing Processes for Productivity
March 2014 829
Using Revision Control Tools
Synplify Premier (Beta)
You integrate a third-party revision control tool and use its functionality to
manage design files for large and complex designs in your project. Use the
Configure Revision Control Tools process to help you manage your design files.
Note: Third-Party Revision Control Tool Prerequisite
The following procedure shows you how to configure and use a third-party
revision control tool to manage your design files.
1. Set up the third-party revision control tool, and set all required
environment variables.
2. Select Project->Configure Revision Control (Beta).
By default, the third-party revision control tools supported are Perforce
and CVS. However, you are free to choose any revision control tool of
your choice.
LO
Chapter 15: Optimizing Processes for Productivity Using Revision Control Tools
830 March 2014
March 2014 831
3. Do the following on the dialog box to configure the revision control tool:
Select the Enable Revision Control Tool Integration option. This enables the
other fields and makes the revision control tool commands available
in the Project view.
Select the revision control tool you want to use from the Current
Configuration menu. The synthesis tool automatically includes the
standard default commands for the revision control tool you selected.
You can only edit the Confirmation field; if enabled, you will be asked to
confirm the revision control operation.
In the following example, Perforce is specified as the revision control
tool below.
The tool automatically includes the standard default commands for
the revision control tool specified in a Tcl script file. Click on the Edit
Tcl button, to look over these standard default commands and edit
them in the Tcl script file if needed. For examples of the Tcl script file,
see SCM Tcl Script File, on page 296.
For command syntax, refer to the documentation for the specified
revision control tool.
To create custom commands, click on the Add button. Specify the
command name, if you would like confirmation of this revision
LO
832 March 2014
control operation, and its Tcl command string. The first example
below is a simple command that can be used as defined. However, the
second example is more complex. Click on the Edit Tcl button to add
code for this new revision control command to the Tcl script file as
needed.
To configure a revision control tool of your choice, see Create New
SCM Configuration, on page 291 in the Reference manual.
Click OK.
For more information about options on the Configure Revision Control Tools
dialog box, see Configure Revision Control Tools Command, on page 288
in the Reference manual.
4. Do the following in the Project Files view to specify the files for revision
control:
For revision control on the project file, right-click the file and select
Project.
For revision control support on all the files in the project, right-click
the project file and select All Input Files.
Alternatively you can also set revision control options from the Project
results view by going to the Implementation Directory tab, and selecting
File(s).
March 2014 833
5. Right-click, go to the Revision Control (Beta) menu, and select the revision
control tool command you want to run. The commands vary, according
to the tool you are using:
The synthesis tool uses the revision control tool you configured earlier
and runs the commands with the syntax specified in step 3. The Project
Files view displays icons next to file to indicate their status. The icons
vary with the tool used:
SCM Function SCM Command
To check in the design files ... Check In
To check out the design files ... Check Out (Perforce only)
To add files to the SCM database ... Add Files to Repository
To retrieve the latest version of files ... Get Latest Revision
To discard changes and reverts ... Revert Changes (Perforce)
Discard Changes (CVS)
To provide status for the design files
with respect to the SCM database ...
Refresh File Info
Status Perforce Icon CVS Icon
For Perforce, file is checked in and
locked.
For CVS, file is up-to-date
File is up-to-date. N/A
File has been added to the repository,
but is not checked in.
File is modified. N/A
Indicates a file merge conflict. N/A
File is out-of-sync and requires an
update.
N/A
LO
834 March 2014
March 2014 835
CHAPTER 16
Using Multiprocessing
The following sections describe how to use multiprocessing to run parallel
synthesis jobs and improve runtime:
Multiprocessing With Compile Points, on page 836
Setting Maximum Parallel Jobs, on page 836
License Utilization, on page 837
LO
Chapter 16: Using Multiprocessing Multiprocessing With Compile Points
836 March 2014
Multiprocessing With Compile Points
Use the Configure Compile Point Process command to run multiprocessing with
compile points. This option allows the synthesis software to run multiple,
independent compile point jobs simultaneously, providing additional runtime
improvements for the logical compile point synthesis flows. On the Configure
Compile Point Process dialog box, specify the maximum number of synthesis
jobs you can run in parallel. Note, one license is used for each job. For a
description of how to set the maximum number of parallel synthesis jobs, see
Setting Maximum Parallel Jobs, on page 836.
To use multiprocessing in the Logical Compile Point Synthesis flows for the
Synplify Pro and Synplify Premier tools, see Chapter 13, Working with
Compile Points. For the Synplify Premier tool, the Physical Synthesis switch
must be turned off when you run compile points.
Setting Maximum Parallel Jobs
You can set maximum number of parallel jobs in the following ways:
INI Variable MaxParallelJobs
Tcl Variable max_parallel_jobs
INI Variable MaxParallelJobs
The maximum number of parallel jobs is set in the product ini file. The
following commands are set in the product.ini file (for example,
synplify_premier_dp.ini):
[JobSetting]
MaxParallelJobs=<n>
The MaxParallelJobs value is used by the UI as well as in batch mode. This
value is effective until you specify a new value. To change the number of
parallel jobs you can run, use the Options->Configure Compile Point Process
command from the Project view menu. On the Configure Compile Point Process
dialog box, in the Maximum number of parallel synthesis jobs field you will see the
current ini value. You can specify a new MaxParallelJobs value which is effec-
tive until you change it again. Once you click OK, the new value is saved in
the ini file. For a description of the dialog box, see Configure Compile Point
Process Command, on page 451.
Multiprocessing With Compile Points Chapter 16: Using Multiprocessing
March 2014 837
Tcl Variable max_parallel_jobs
You can also manually set an override value for the maximum number of
parallel jobs. To do this, use the Tcl command:
set_option -max_parallel_jobs numberJobs
You can choose to:
Source the Tcl file containing this option.
Add this option to the Project file.
Set this option from the Tcl command window.
This max_parallel_jobs value is applied to all project files and their respective
implementations. This is a global option. The maximum number of parallel
jobs remains in effect until you specify a new value. This new value takes
affect immediately going forward. However, when you set this option from the
Tcl command window, the max_parallel_jobs value is not saved and will be lost
when you exit the application.
License Utilization
When you decide to run parallel synthesis jobs, a license is used for each
compile point job that runs. For example, if you set the Maximum number of
parallel synthesis jobs to 4, then the synthesis tool consumes one license and
three additional licenses are utilized to run the parallel jobs if they are avail-
able for your computing environment. Licenses are released as jobs complete,
and then consumed by new jobs which need to run.
The actual number of licenses utilized depends on the:
1. Synthesis software scheme for the compile point requirements used to
determine the maximum number of parallel jobs or licenses a particular
design tries to use.
2. Value set on the Configure Compile Point Process dialog box.
3. Number of licenses actually available. You can use Help->Preferred License
Selection to check the number of available license. If you need to increase
the number of available licenses, you can specify multiple license types.
For more information, see Specifying License Types, on page 838.
LO
Chapter 16: Using Multiprocessing Multiprocessing With Compile Points
838 March 2014
Factors 1 and 3 above can change during a single synthesis run. The number
of jobs equals the number of licenses; which then equates the lowest value of
these three factors.
Specifying License Types
You can specify multiple license types to increase the total number of licenses
available for multiprocessing. To do this, you can either:
Use the -licensetype command line option when you execute your tool.
For example, suppose you have two synplifypremier licenses, two
synplifypremier_allvendor licenses, and three synplifypremier_xilinx licenses.
Type the following at the command line:
synplify_premier.exe -licensetype
"synplifypremier:synplifypremier_allvendor:synplifypremier_xilinx"
Use one of the following environment variables specified with the license
type:
SYNPLIFYPRO_LICENSE_TYPE (Synplify Pro tool)
SYNPLIFYPREMIER_LICENSE_TYPE (Synplify Premier and Synplify
Premier with Design Planner tools)
setenv SYNPLIFYPREMIER_LICENSE_TYPE=
"synplifypremier:synplifypremier_allvendor:synplifypremier_xilinx"
Multiprocessing can access any of these license types for additional licenses.
March 2014 839
CHAPTER 17
Clock Conversion
ASICs are often implemented in FPGAs for prototyping. The inherent differ-
ences between ASICs and FPGAs can make this conversion difficult. One
particular source of problems can be attributed to the complex clocking
circuitry of FPGAs that often includes a large number of gated and internally
generated clocks. The Synopsys FPGA synthesis tools provide two features,
Gated Clock Conversion and Generated Clock Conversion, to address the
complex clocking schemes.
These features move the generated-clock and gated-clock logic from the clock
pin of a sequential element to its enable pin. Relocating these clocks allows
the sequential elements to be tied directly to the skew-free source clock and
also reduces the number of clock sources in the design which frees up
routing resources and expedites placement and routing. Dedicated FPGA
clock trees are routed to every sequential device on the die and are designed
with low skew to avoid hold-time violations. Using these global clock trees
allows the programmable routing resources of the FPGA to be used primarily
for logic interconnect and simplifies static timing analysis because checks for
hold-time violations based on minimum delays are unnecessary.
For details, refer to the following topics:
Working with Gated Clocks, on page 840
Optimizing Generated Clocks, on page 883
LO
Chapter 17: Clock Conversion Working with Gated Clocks
840 March 2014
Working with Gated Clocks
Synplify Pro, Synplify Premier;
Altera, Lattice, Xilinx Technologies
This section first describes the gated-clock solution. The information is
organized into the following sections:
Obstacles to Conversion, on page 842
Prerequisites for Gated Clock Conversion, on page 843
Defining Clocks Properly, on page 845
Synthesizing a Gated-Clock Design, on page 850
Accessing the Clock Conversion Report, on page 851
Analyzing the Clock Conversion Report, on page 852
Interpreting Gated Clock Error Messages, on page 854
Disabling Individual Gated Clock Conversions, on page 857
Instantiated Cells, on page 858
Integrated Clock Gating Cells, on page 859
Integrated Clock Gating Stability Latch Removal, on page 864
Using Gated Clocks for Black Boxes, on page 872
OR Gates Driving Latches, on page 873
MUX or XOR Logic in Clock Structure, on page 874
Obstructions to Optimization, on page 876
Unsupported Constructs, on page 877
Other Potential Workarounds to Solve Clock-Conversion Issues, on
page 878
Restrictions on Using Gated Clocks, on page 878
The clock conversion solution separates the gating from the clock inputs, and
combines individual clock trees on the dedicated FPGA global clock trees. The
software logically separates the gating from the clock and routes the gating to
Working with Gated Clocks Chapter 17: Clock Conversion
March 2014 841
the clock enables on the sequential devices, using the programmable routing
resources of the FPGA. The software separates a clock net going through an
AND, NAND, OR, or NOR gate by doing one of the following:
Inserting a multiplexer in front of the input pin of the synchronous
element and connecting the clock net directly to the clock pin
Moving the gating from the clock input pin to the dedicated enable pin,
when this pin is available.
The ungated or base clock is routed to the clock inputs of the sequential
devices using the global FPGA clock resources. Typically, many gated clocks
are derived from the same base clock, so separating the gating from the clock
allows a single global clock tree to be used for all gated clocks that reference
that base clock.
It is not always necessary to convert all clocks from an ASIC design fitting
the design into the FPGA device and meeting timing are the ultimate goals.
However, some situations require unconverted clock structures to be
modified such as:
Clock structures with a large number of loads resulting in congestion
issues
Clock structures resulting in a large clock skew between the starting
and ending clocks on a path that does not meet timing
The following figure illustrates several cases of how gated clocks are
converted.
LO
842 March 2014

Obstacles to Conversion
The following is a summary of issues to look for that can prevent a clock
structure from being converted. More details about each condition are
described later.
Are the clocks defined properly?
Is the Clock Conversion option enabled?
Does the clock structure contain instantiated cells?
d
a
b
clk
Gated Clock
d
a
b
clk
Fixed Gated Clock
d
a
b
clk
Gated Clock
en
D Q
0
1
d
a
b
clk
Fixed Gated Clock
en
clk
en1
en2
d
Gated Clock
d
clk
en1
en2
Fixed Gated Clock
D Q
D Q
EN
D Q
EN
D Q
D Q
EN
March 2014 843
Does the clock structure include MUX or XOR logic (MUX/XOR clock
conversion is only supported in Synplify Premier for the HAPS flow)?
Is something in the clock logic blocking optimization?
Are there any unsupported constructs?
Prerequisites for Gated Clock Conversion
For a gated clock to be converted successfully, the design must meet these
requirements:
Correct Logic Format
Specifically, the combinational logic for the gated clock must satisfy the
following two conditions to have the correct format:
For at least one set of gating input values, the value output for the gated
clock must be constant and not change as the base clock changes.
For at least one value of the base clock, changes in the gating input
must not change the value output for the gated clock.
Condition Description
Combinational
logic only
The gated clock logic must consist only of combinational logic. A
derived clock that is the output of a register is not converted.
Single base
clock
Identify only one input to the combinational logic for the gated
clock as a base clock. To identify a net as a clock, specify a period
or frequency constraint for either the gate or the clock in the
constraint file. This example defines the clk input as the base clock:
create_clock -name {clk} -freq 10.000 -clockgroup
default_clkgroup
Supported
primitives
The sequential primitive clocked by the gated clock must be a
supported object. The tools support gated-clock conversion for
most sequential primitives. Black-box modules driven by gated
clocks can be converted if special synthesis directives are used to
define the clock and clock enable inputs to the black box. See
Using Gated Clocks for Black Boxes, on page 872.
Correct logic
format
See Correct Logic Format, on page 843 for an example of the
correct logic format.
LO
844 March 2014
The correct logic format requirements are illustrated with the simple gates
shown in the following figures. When the software synthesizes a design with
the Gated Clocks option enabled, clock enables for the AND gate and OR gate
are converted, but the exclusive-OR gate shown in the second figure is not
converted. The following table explains.
AND gate
gclks[1]
If either gate[1] or gate[2] is 0, then gclks[1] is 0, independent of the
value of clk which satisfies the first condition. Also, if clk is 0, then
gclks[1] is 0, independent of the values of gate[1] and gate[2] which
satisfies the second condition. Because gclks[1] satisfies both
conditions, it is successfully converted to the clock-enable format.
OR gate
gclks[2]
If either gate[1] or gate[2] is 1, then gclks[2] is 1 independent of the
value of clk which satisfies the first condition. Also, if clk is 1, then
gclks[2] is 1 independent of the value of gate[1] or gate[2] which
satisfies the second condition. Because gclks[2] satisfies both
conditions, it is successfully converted to the clock-enable format.
Exclusive-OR
gate
gclks[3]
Irrespective of the value of gate[3], gclks[3] continues to toggle. The
exclusive-OR function causes gclks[3] to fail both conditions which
prevents gclks[3] from being converted.
D Q
din[1:3] D Q
gate[1:3]
dout[1:3]
D Q
clk
[1]
[1]
[2]
[2]
[3]
[1]
[2]
[3] [1:3]
[1:3]
[1]
[2]
[3] [1:3]
dout_1[1]
dout_1[2]
dout_1[3]
gclks[2]
gclks[3]
gclks[1]
Before Gated Clock Conversion
March 2014 845
Defining Clocks Properly
The most common problems preventing clock conversion from occurring
automatically are related to improperly defined clocks. When defining gated
and generated clocks:
Gated clocks should be defined at the nodes to be connected to the clock
pins of the sequential cells.
Use create_generated_clock constraints to define the relationship between
generated clocks and their sources
If a clock circuit contains both a clock generator and a gating element, a
create_generated_clock constraint is needed. Without this constraint, the
tool does not know the relationship between the gated signal and the
source clock.
D Q
din[1:3]
CE
D Q
gate[1:3]
dout[1:3]
D Q
clk
CE
[1]
[1]
[2]
[2]
[3]
[1]
[2]
[3] [1:3]
[1:3]
[1]
[2]
[3] [1:3]
dout_1[1]
dout_1[2]
dout_1[3]
un15_ce
gclks[3]
ce[1]
After Gated Clock Conversion
The clock enables for the AND and
OR gates are converted, but the
clock enable for the exclusive OR
remains unchanged.
LO
846 March 2014
Defining Clocks Example
Using the above example, the first constraint applied is:
create_clock name clk [get_ports clk] period 10
In the above constraint, get_ports identifies clk as a port. With only the source
clock defined, the tool is unable to determine which input of the AND gate is
the clock and which input is the enable. Accordingly, no conversion is
performed as shown in the following schematic diagram.
March 2014 847
Continuing with the example, a second constraint is added:
create_clock name divclk [get_nets {n:divclk}] period 20
In the second constraint, get_nets identifies divclk as a net. With independent
clock constraints defining the source and generated clocks, the tool now
knows which input of the AND gate is the clock, but still does not know the
relationship between the source and generated clocks. In this case, the clock
gate and data register Z are converted to an enable flip-flop (FDCE) which is
connected to the generated clock as shown in the next schematic.
LO
848 March 2014
For the final example, the second clock constraint is replaced with a gener-
ated clock constraint.
create_generated_clock name divclk [get_nets {n:divclk}]
source [get_ports clk] divide_by 2
Now the tool knows which input of the AND gate is the clock and the relation-
ship between the source and generated clocks. For this case, the entire clock
circuit is converted to an enable on the Z register, and the Z register clock
pin is connected directly to the source clock as shown in the final schematic.
March 2014 849
Internal Clocks
Applying internal clock constraints to output pins of inferred combinational
logic (for example, an AND gate) is not supported. Apply clock constraints
only to nets driven by logical output pins.
Only One Clock per Clock Pin Fan-in Cone
Every fan-in cone of the clock pin of a sequential device should have one
defined clock. As long as one clock is defined, the clock can be traced forward
through unate logic to the clock pins.
LO
850 March 2014
When no clock is defined:
The clock source is derived by tracing the clock pin back to the first non-
trivial (multiple input) gate
Because the tool does not know which input of a multiple-input cell to
trace, a clock is inferred at the output of that cell
Since inferred clocks were not defined by the user explicitly or implicitly,
no conversion occurs
When more than one clock is defined, the tool does not know which clock to
convert, and no conversion occurs.
Synthesizing a Gated-Clock Design
Specific Altera, Lattice, and Xilinx families
To synthesize a gated-clock design:
1. Make sure that the gated clocks have the correct logic format and satisfy
the prerequisites for conversion. See Prerequisites for Gated Clock
Conversion, on page 843 for details.
2. If the gated clock drives a black box, specify the clock and the associated
clock enable signal with using syn_force_seq_prim, syn_isclock, and
syn_gatedclk_en directives. See Using Gated Clocks for Black Boxes, on
3. Make sure that the clock net has a constraint specified in the constraint
file for the current implementation. If you do not specify an explicit
constraint on the clock net or if you set a global frequency constraint,
enabling clock conversion as described in the next step will not have any
effect.
4. Enable the Clock Conversion option.
Select Project->Implementation Options.
On the GCC & Prototyping Tools tab (Synplify Premier) or GCC tab
(Synplify Pro), click on the Clock Conversion check box.
March 2014 851
5. Synthesize the design. For gated clocks, the option converts qualified
flip-flops, counters, latches, synchronous memories, and instantiated
technology primitives. The software logically separates the gating from
the clock and routes the gating to the clock enables on the sequential
devices, using the programmable routing resources of the FPGA. The
ungated base clock is routed to the clock inputs of the sequential
devices using the global clock resources. Because many gated clocks are
normally derived from the same base clock, separating the gating from
the clock allows a single global clock tree to be used for all gated clocks
that reference the same base clock.
See Restrictions on Using Gated Clocks, on page 878 for additional infor-
mation.
6. Check the results in the START OF CLOCK OPTIMIZATION REPORT section of
the log file. See Analyzing the Clock Conversion Report, on page 852 for
an example of this report.
Accessing the Clock Conversion Report
The clock conversion report can be accessed from the log file or from the
Project Status tab.
Log File Access
To access the clock conversion report directly in the log file:
1. Open the log file by clicking the View Log button.
2. In the browser, expand the Mapper Report entry by clicking the adjacent
+ sign and click on the Clock Conversion link to go directly to the clock
conversion report. Note that the browser is only available when the View
log file in HTML option is enabled.
LO
852 March 2014
Project Status Tab Access
To access the clock conversion report directly from the Project Status tab, click
the more link in the Optimizations Summary section at the bottom of the display.
Analyzing the Clock Conversion Report
When clock conversion is enabled, a typical report resembles the following:
March 2014 853
3-line Summary
The 3-line summary provides a quick snapshot of the design.
The first line reports the number of clean clock trees (8 in the above
report) and the number of driven clock pins (434).
The next line reports the number of gated/generated clock trees (2 in the
above report) and the number of driven clock pins (16).
The last line reports the number of instances converted (10 in the above
report) and the number of remaining instances driven by gated/gener-
ated clocks (16).
The following find command can be used to group the converted instances:
find -hier -inst * -filter @syn_gc_converted==1
Non-gated/non-generated Clocks Table
The non-gated/non-generated clocks section provides details of the clean
clocks in the design and also includes any clock trees that never included
gating logic. This section reports the following:
Clock Tree ID created for all instances in the clock tree that lead to the
sample instance. Clicking on an ID opens a filtered technology view of
the source clock.
3-line Summary
Non-gated/non-generated
Clock Tree Table
Gated/generated
Clock Tree Table
LO
854 March 2014
Driving Element identifies the source of the driving clock.
Drive Element Type identifies the type of drive element such as a port
or BUFG.
Fanout lists the clock fanout.
Sample Instance an instance within the clock tree.
The following find command can be used to identify all instances in the clock
path:
find -hier -inst * -filter @syn_sample_clock_path==CKIDxxxx
If a clock is defined within the cone-of-logic for the gated clock, it is reported
in this table.
Gated/generated Clocks Table
The gated/generated clocks section lists a sample failure within each clock
tree in the design with an explanation of why the conversion failed (see the
following section Interpreting Gated Clock Error Messages, on page 854). The
gated/generated clocks section reports the following:
Clock Tree ID created for all instances in the clock tree that lead to the
failed sample instance. Clicking on an ID opens a filtered technology
view of the source clock.
Driving Element identifies the source of the driving clock.
Drive Element Type identifies the type of drive element such as a LUT.
Fanout lists the clock fanout.
Sample Instance an instance within the clock tree.
In the table, failures with common gating-control signals are only reported
once. The software traverses back from the clock pin of the sample instance
until it reaches the driving element at the point of the failure.
Interpreting Gated Clock Error Messages
The following table describes the gated clock conversion error messages
reported in the Gated/Generated Clocks section of the clock conversion report.
March 2014 855
Error Message Explanation
Asynchronous set/reset
mismatch prevents
generated clock conversion
Unshared asynchronous signals have been detected
between a FF-derived clock circuit and its sequential
load.
Can't determine input clock
driver
Clock conversion disabled Gated clocks have been detected, but clock conversion
is not enabled.
Clock propagation blocked
by fixed hierarchy
Clock property has been blocked by a fixed hierarchy
which prevents clock conversion from propagating
upstream.
by hard hierarchy
Clock property has been blocked by a hard hierarchy
upstream.
by locked hierarchy
Clock property has been blocked by a locked hierarchy
upstream.
by syn_keep
Clock property has been blocked by a syn_keep property
upstream.
Clock source is constant
Combinational loop in clock
network
FF-derived clock conversion
disabled
FF-derived clocks have been detected, but clock
conversion is not enabled.
Gating structure creates
improper gating logic
Illegal instance on clock path
Inferred clock from port
Input clock depends on
output
Latch gated by OR originally
on clock tree
LO
856 March 2014
Checking the Log file
Many clock constraint problems can be identified by reviewing the Clock
Summary table in the pre-mapping report section and the Performance
Summary section of the log file shown below:
Clock conversion is attempted on declared, generated, and derived
clocks, and is never performed on inferred clocks or on the system clock.
Multiple clock inputs on
sequential instance
Multiple clocks on
generating sequential
element
Multiple clocks on instance Multiple clocks found feeding an instance of a clock
tree.
Need declared clock or clock
from port to derive clock
from ff
No clocks found on inputs No clocks found feeding an instance of a clock tree.
No generated or derived
clock directive on output of
sequential instance
No hierarchical driver
Signal from port
Unconverted clock gate
Unable to determine clock
driver on net
Unable to determine clock
input on sequential instance
Unable to follow clock
across hierarchy
Unable to use latch as gated
clock generator
Error Message Explanation
March 2014 857
Declared, generated, and derived clocks can still have issues such as
unsupported structures in their clock logic or incorrect constraints.
Inferred clocks and the system clock are created when no clocks are
defined in the fan-in logic of the clock pin of a sequential cell.
Following compilation, the software issues warnings about inferred clocks or
the system clock, that include the clock name and one of the registers driven
by that clock to help the user locate the issue in the HDL Analyst. The
following are examples of these warnings:
@W: MT529 : Found inferred clock clkName which controls numClkPins
sequential elements including instanceName. This clock has no specified
timing constraint which may prevent conversion of gated or generated
clocks and may adversely impact design performance.
@W: MT531 : Found signal identified as System clock which controls
numClkPins sequential elements including instanceName. Using this
clock, which has no specified timing constraint, can prevent conversion
of gated or generated clocks and can adversely impact design perfor-
mance.
Disabling Individual Gated Clock Conversions
By default, enabling gated-clock conversion applies globally to a design. For
critical paths, individual clocked elements can be expressly excluded from
the gated-clock conversion by adding a syn_keep directive directly to the input
LO
858 March 2014
clock net. The syn_keep attribute can be applied in the source code or in a
constraint file. The following example shows a syn_keep attribute applied to
the gclk net in a source file.
module and_gate (clk, en, a, z);
input clk, en, a;
output reg z;
wire gclk /* synthesis syn_keep = 1 */;
assign gclk = en & clk;
always @(posedge gclk) z <= a;
endmodule
The corresponding entry in a constraint file is:
define_attribute {n:gclk} {syn_keep} {1}
Instantiated Cells
Synplify Premier
The Synplify Premier synthesis tool supports conversion of gated- and gener-
ated-clock circuits, created from instantiated FPGA cells, to enable flops that
connect directly to the clock. This feature is enabled via a switch in the GUI.
The equivalent set_option Tcl command for the project file is:
set_option enhanced_optimization 1
If a MUX is described using instantiated LUT primitives, the tool is unable to
recognize the structure as a MUX, and instead sees it as multiple clocks
feeding a LUT (for example, a 3-input AND gate). As a result, no conversion
occurs due to the multiplicity of declared clocks.
Setting on GUI Device Tab
March 2014 859
Integrated Clock Gating Cells
The Synopsys synthesis tools do not read in ASIC cell libraries. To support
conversion of Integrated Clock Gating (IGC) cells, these cells must be modeled
in RTL.
If there are ASIC-only pins on an ICG cell, such as a scan-enable input or an
observation output, the pins must be removed to allow the clock conversion
to occur.
The following example shows an ICG cell with ASIC-only pins and the corre-
sponding Verilog source code.
LO
860 March 2014
module icg (clk, en, scan_en, obs, gclk);
input clk, en, scan_en;
output obs, gclk;
wire t0, t1;
assign t0 = (!clk) ? en : t0;
assign obs = t0;
assign t1 = t0 | scan_en;
assign gclk = t1 & clk;
endmodule
The presence of the scan control and observation point signals forces the tool
to preserve intermediate signals in the clock-gating circuit that prevents it
from being optimized. In this case, the data register is connected directly to
the source clock, but the latch and OR gate for the ICG model remain as part
of the enable logic as shown in the following schematic.
March 2014 861
The following code simplifies the RTL model of the complex IGC cell and
allows the desired gated-clock conversion to occur.
LO
862 March 2014
module icg (clk, en, scan_en, obs, gclk);
input clk, en, scan_en;
output obs, gclk;
wire t0, t1;
assign t0 = (!clk) ? en : t0;
assign obs = 1b0 /* t0 */;
assign t1 = t0 | 1'b0 /* scan_en */;
assign gclk = t1 & clk;
endmodule
In the modified code, the scan_en input, which is generally not used in an
FPGA implementation, is replaced with a constant 0. The obs observation
point output, which normally is not required in an FPGA implementation, is
also tied to a constant 0. These changes remove the intermediate points as
shown in the following schematic. Note that if no other changes are made to
the design, this model still fits because the ports are unchanged. Also, the
0 tied to the obs output propagates to simplify downstream logic.
March 2014 863
Incorrect Phase
When there is an error in the RTL model of an ICG cell such that an incorrect
phase of the clock is connected to the latch:
Only the AND gate is converted leaving the latch driving the enable pin
of the data flip-flops.
LO
864 March 2014
A warning is generated stating Active phase of latch latchName prevents
its use as a stability latch for clock gate clockGateName.
Integrated Clock Gating Stability Latch Removal
Xilinx Technologies
Stability latches in the Integrated Clock Gating (ICG) circuit that are moved to
the enable path of sequential loads after gated and generated clock conver-
sion (GCC) can cause timing violations for Vivado place and route. Therefore,
in the pre-map stage the synthesis tool removes the stability latches in the
ICG cell based on the following:
A latch on the clock path is converted to a mux and flip-flop.
The mux select pin is connected to 1 or 0, depending on the sensitive
clock edges of the sequential loads. For a rising clock edge, the mux
selects 0. For a falling clock edge, the mux selects 1. Then constant
propagation is implemented through the mux.
After GCC, the mux is removed and the flip-flop is retained or removed. The
following examples show how the ICG stability latches are implemented for
various ICG conditions.
Example 1
This example shows a cascading ICG that drives a positive edge flip-flop and
what occurs after GCC optimizations.
Clock signal to latch and cell
must be of opposite phase
March 2014 865
Example 2
This example shows a cascading ICG that drives a negative edge flip-flop and
what occurs after GCC optimizations.
LO
866 March 2014
Example 3
This example shows a cascading ICG that drives a positive and negative edge
flip-flop and what occurs after GCC optimizations.
March 2014 867
You can check the ICG Latch Removal Summary in the pre-map section of the log
file for the:
Number of ICG latches removed
Number of ICG latches not removed
Following message that is generated:
@N: ICG latches not removed are assigned the property icg_retain
set to 1. Use Tcl find to locate the latches with this property.
In the ICG Latch Removal Summary, note that:
LO
868 March 2014
ICGs that drive black boxes are not counted in the Number of ICG latches
not removed.
Latches that are not removed can be optimized away later, after GCC.
These latches removed by GCC are not counted in the ICG Latch Removal
Summary.
Unsupported Loads
The following examples provide conditions why ICG stability latches are not
removed.
Example 1: Unsupported latches not considered to be ICG latches
Latches not considered to be ICG latches, do not get reported in the ICG Latch
Removal Summary.
March 2014 869
The following figure might include an unsupported latch, where an incorrect
phase of the clock is connected to the latch, such that it is not removed.
Example 2: ICGs driving unsupported loads
In the following figure, the ICG circuitry drives a MUX that is an unsupported
load. This results in the ICG circuitry not being removed. Unsupported loads
can also occur for XOR gates and latches with asynchronous signals that are
not tied to constants.
LO
870 March 2014
The following warning messages are written to the log file:
@W:MF760 : | ICG Latch Removal: Unable to remove ICG latch u4.lat because it drives
unsupported instance mux_out.
@W:MF760 : | ICG Latch Removal: Unable to remove ICG latch u5.u2.u3.lat because it
drives unsupported instance mux_out
Example 3: ICGs driving compile points for loads with mixed clock edges
In this scenario, posedge and negedge register loads are inside hard compile
points. Since the registers have two different clock edges and are inside
compile points, the ICG circuitry is not removed.
Note: set/reset tied to constant
March 2014 871
The following warning message is written to the log file:
@W:MF758 : | ICG Latch Removal: Unable to remove ICG latch u5.u2.u3.lat because it
drives a compile point and rising/falling clock edges
Example 4: ICGs driving both black boxes and registers that are replicated
For this scenario, the ICG circuitry driving the black box gets replicated and
is not removed. However, the original ICG circuitry that drives u1.q is
removed.
LO
872 March 2014
The following warning message is written to the log file:
@N:MF761 : | ICG Latch Removal: Blackbox load found on ICG latch u4.lat; latch
replicated and not removed for blackbox load.
Using Gated Clocks for Black Boxes
To convert gated clocks that drive black boxes, you must identify the clock
and clock enable signal inputs to the black box using the syn_force_seq_prim,
syn_isclock, and syn_gatedclk_clock_en directives. Refer to the Reference Manual
for information about these directives. You assume responsibility for the
functionality of the black-box content.
The following are Verilog and VHDL examples of a black box with the required
directives specified.
Verilog
module bbe (ena, clk, data_in, data_out)
/* synthesis syn_black_box */
/* synthesis syn_force_seq_prim="clk" */
;
input clk
March 2014 873
/* synthesis syn_isclock = 1 */
/* synthesis syn_gatedclk_clock_en="ena" */;
input data_in,ena;
output data_out;
endmodule
VHDL
library synplify;
entity bbe is
port (clk : in std_logic;
en : in std_logic;
data_in : in std_logic;
data_out : out std_logic );
attribute syn_isclock : boolean;
attribute syn_isclock of clk : signal is true;
attribute syn_gatedclk_clock_en : string;
attribute syn_gatedclk_clock_en of clk : signal is "en";
end bbe;
architecture behave of bbe is
attribute syn_black_box : boolean;
attribute syn_force_seq_prim : string;
attribute syn_black_box of behave : architecture is true;
attribute syn_force_seq_prim of behave : architecture is "clk";
begin
end behave;
OR Gates Driving Latches
To prevent problems in timing analysis when a latch is being driven by the
OR of a clock and an enable, gated-clock conversion is implemented using
the logic shown in the following diagram.
LO
874 March 2014
As illustrated in the above diagram, the enable (EN) and clock (CLK) feed
separate latches, and XOR gates are used to condition the inputs and
outputs. The conversion masks the combinational path from the timing
engine and duplicates the behavior of the original circuit. Conversion only
occurs if the original latch is not driving a clock network.
MUX or XOR Logic in Clock Structure
If you are running the Synplify Premier tool and targeting a compatible Xilinx
device, the Convert MUX/XOR Gates Clock Tree check box is enabled on the GCC &
Prototyping Tools tab to allow selection of MUX/XOR clock conversion.
set_option -conv_mux_xor_gated_clocks 1
For other FPGA synthesis flows and non-compatible devices, clocks incorpo-
rating MUX or XOR logic in their structure are not converted. Note that
unwanted MUX and XOR logic can be generated for the following RTL
constructs:
(A&B)|(!A&C) counts as a MUX, not simple AND/OR logic
(A&!B)|(!A&B) counts as an XOR, not simple AND/OR logic
D Q
G
CLR
D Q
G
CLK
EN
D Q
G
CLK
EN
March 2014 875
The conversion of MUX and XOR clock structures is area expensive, and
should be used sparingly.
If the clock structure includes MUX or XOR logic, the following conditions
must be met for automatic conversion to occur:
All data inputs to a MUX must be clocks
Exactly one input to a XOR must be a clock
Common MUX/XOR Conversion Issues
The following are common conversion issues with MUX/XOR logic:
XOR conversion with more than one input defined as a clock is not
attempted and no change is made to the clock circuit.
MUX conversion when not all of the data inputs are defined as clocks is
not attempted and no change is made to the clock circuit. The most
common case occurs with scan logic when the definition of the test clock
is removed, but the MUX is left in place. The best solution for this case is
to tie the select input of the MUX (test_enable in the following schematic)
to a constant so that the functional clock is always selected. Constant
propagation subsequently optimizes the MUX away.
LO
876 March 2014
Obstructions to Optimization
The following optimization obstructions in the clock structure prevent
conversion:
Keep_buffers in the Clock Structure
Keep buffers are components that are added to the RTL view netlist to
preserve specific nets. If a net in the clock circuitry is preserved by a keep
buffer, it cannot be optimized away and can prevent conversion of the associ-
ated clock circuit. Keep buffers are the result of syn_keep attributes and
constraints placed on nets such as false path, multi-cycle path, and other
clock constraints. The following Tcl find command can be used to locate the
keep buffers:
find -hier -view keepbuf
In standard flow, a MUX in the
clock logic cannot be converted
With test_en tied to 0, constant propagation
optimizes the MUX to a wire
March 2014 877
Hard Hierarchy Defined on a Clock Logic Block
A hard hierarchy attribute on a block containing a clock structure prevents
conversion by forcing the interface of this block to remain unchanged. More
specifically, if a hard hierarchy is between the clock logic and the data regis-
ters, the conversion cannot occur because the new signals for the enables
cannot be added to the block interface. The following Tcl find command can be
used to locate the hard hierarchies:
find -view * -filter (@syn_hier==hard)
Loads on Intermediate Nodes in the Clock Logic
Intermediate nodes in the clock logic should not have extra loads. For conver-
sion to occur when extra loads are present, the RTL must be modified to
separate the loads that drive clock pins of data registers from the other loads.
Disable Sequential Optimizations Project Option Prevents Latches
from Being Removed
For conversion to occur, the Disable Sequential Optimizations option cannot be
enabled.
Unsupported Constructs
The following are examples of constructs that prevent conversion from occur-
ring.
If the clock circuitry contains logic such that asynchronous set/reset
signals can produce an active edge on the gated-clock line (without any
change in the source clock), the circuit is not converted. Any active
edges on the gated-clock output must be controlled by the source clock.
By default, conversion only occurs if the registers in the generated-clock
logic have the same asynchronous set/reset signals as the data registers
that they control. If this condition is not met, conversion can be forced
by selecting the following option in the GCC & Prototyping Tools tab (avail-
able in Synplify Premier only).
LO
878 March 2014
set_option -force_async_genclk_conv 1
If the wrong phase of the clock is connected to a latch in a gated-clock
circuit, the following warning is reported:
Active phase of latch latchName prevents its use as a
stability latch for clock gate clockGateName
Other Potential Workarounds to Solve Clock-Conversion Issues
If the previous sections do not help resolve your issue, there a few more
things you can try:
Use a syn_direct_enable attribute on one of the gating signals to force the
conversion.
Instantiate BUFGs (Xilinx) or CLKBUFGMUXs (Altera).
Use netlist edit commands to modify the netlist.
Recode RTL to fit one of the cases allowed for automatic conversion.
Restrictions on Using Gated Clocks
Currently, the Clock Conversion option has the following restrictions for
gated clocks:
A syn_keep attribute attached to a net, which should preserve the net
during optimization, is not honored by the Clock Conversion option.
The Clock Conversion option cannot be implemented for inferred counters
in Altera technologies.
March 2014 879
The Clock Conversion option cannot be implemented by the Synplify
Premier tool if the gates associated with the gated clock are assigned to
different design plan regions (see the following figure). The Clock Conver-
sion option can be applied if all gates associated with the gated clock are
assigned to the same design plan region. Also, the flip-flops can be
assigned to any Synplify Premier region.
A global buffer, when instantiated on a gated clock, blocks gated-clock
conversion from being performed (the buffer is viewed as the clock
source by the downstream circuitry). In the circuit below, the clk input to
test_inst remains gated.
Similarly, defining a clock constraint at the output of a gated clock
prevents conversion from continuing upstream.
clk
en1
en2
d
Gated Clock
D Q
Rgn1
Rgn2
Fixed Gated Clock
Cannot Implement
LO
880 March 2014
Issues with Gated/Generated Clock Reporting
Several gated/generated clock reporting issues have been identified:
When both inputs for XOR gates are defined as clocks, the software
incorrectly reports the explanation as No clocks found on input. The
correct explanation is Improper clock gating structure. For HAPs compatible
devices, the correct explanation is Multiple clocks found on inputs.
When both inputs for MUXs are defined as clocks, the software incor-
rectly reports Multiple clocks on instances. The correct explanation is
Improper clock gating structure.
Gated clocks might not be converted for logic from a hierarchy that uses
syn_hier=hard/fixed. In the following example, the comb1 hierarchy has
this attribute. Although the combinational logic within the comb2
hierarchy is outside the scope of syn_hier=hard, the enable logic of
register, out1 does not get converted.
For cascaded ICGs driving posedge flip-flops that use either compile
points or the syn_hier attribute, the tool might produce a circuit with
unused logic that does not get pruned away. See the shaded logic in the
following figure. Depending on how the compile point or syn_hier bound-
aries are defined, the tool can report unused latches as unconverted,
with the explanation Unable to use latch as gated clock generator.
March 2014 881
The explanation Unconverted clock gate message indicates a gated/gener-
ated clock case that is not documented. Report this undocumented case
on SolvNet.
Clock Conversion for Multiple Input Clocks to OR Gate Latch
If multiple clocks are defined as inputs to an OR gate driving a latch, then
clock conversion does not occur and the following message is generated:
Multiple clocks on instance. If this message occurs, make sure that only one clock
is input to the OR gate driving the latch.
LO
882 March 2014
No Gated Clock Conversion for Altera Macros
Gated-clock conversion does not occur for RAM or DSP macros when Altera
Models is off or when QUARTUS_ROOTDIR is not defined. The only exception is
that gated-clock conversion does occur for instantiated altsyncram megafunc-
tions.
No Gated Clock Conversion with altsyncram Megafunctions
Gated-clock conversion does not occur for instantiated altsyncram megafunc-
tions when Altera Models is turned on (default). To use inferred RTL instead of
the altsyncram megafunction, turn off Altera Models. Note, the Altera Models
option will be turned off globally for the design.
Optimizing Generated Clocks Chapter 17: Clock Conversion
March 2014 883
Optimizing Generated Clocks
The Synplify Pro and Synplify Premier tools include an option for generated
clocks that is available for specific Altera, Xilinx, and Lattice families. When
the Clock Conversion option is enabled, the generated-clock logic is replaced
during synthesis with logic that uses the initial clock with an enable. With
generated-clock optimization, the original circuit functionality is preserved
while performance is improved by reducing clock skew. For more information,
see the following topics:
Enabling Generated-Clock Optimization, on page 883
Conditions for Generated-Clock Optimization, on page 884
Generated-Clock Optimization Examples, on page 884
Enabling Generated-Clock Optimization
Generated-clock optimization is enabled by checking Clock Conversion on the
GCC & Prototyping Tools tab (Synplify Premier software) or GCC tab (Synplify Pro
software) of the Implementation Options dialog box.
The Force Generated Clock Conversion with Asynchronous Signals check box is only
available with the Synplify Premier tool and, when checked, enables the
conversion of generated clock-driven datapath latches to a flip-flop and multi-
plexer when the generated-clock logic/datapath latch is set or reset by
asynchronous signals (by default, generated-clock-driven datapath latches
with asynchronous control signals are not converted).
LO
Chapter 17: Clock Conversion Optimizing Generated Clocks
884 March 2014
Conditions for Generated-Clock Optimization
To perform generated-clock optimization, the following conditions must be
met:
1. The combinational logic must be driven by flip-flops.
2. The input flip-flops cannot have an active set or reset (an active-low
reset must be tied high, or an active-high set must be tied low). Similar
rules apply to all the input flip-flops in the cone.
3. All input flip-flops must be driven by the same edge of the same clock.
With generated-clock optimization, you do not have to specify a primary
clock.
Generated-Clock Optimization Examples
Example 1
The following code segment illustrates generated-clock optimization:
module gen_clk(clk1,a,b,c,q);
input clk1, a, b, c;
output q;
reg ao,bo,q;
wire en;
begin
ao <= a;
bo <= b;
end
assign en = ao & bo;
always @(posedge en)
begin
q <= c;
end
endmodule
With generated-clock optimization disabled (Clock Conversion unchecked), the
circuit in the following figure shows a flip-flop (q) driven by a generated clock
that originates from the combinational logic driven by flip-flops ao and bo
which, in turn, are driven by the initial clock (clk1).
March 2014 885
When generated-clock optimization is enabled (Clock Conversion checked), flip-
flop q is replaced with an enable flip-flop. This flip-flop is clocked by the initial
clock (clk1) and is enabled by combinational logic based on the a and b inputs
as shown in the following figure.
Example 2
A design can have a register that is clocked by a generated clock, then
followed by a gated clock. If the generated-clock constraint also includes the
enable, the Clock Conversion option may optimize away the register and replace
it with a constant value. When this occurs, the software converts the gener-
ated and gated-clock logic into a clock and an enable; the enable may never
go active.
Logic
a
b
c
clk1
clk2
Before Generated Clock Optimization
q
b0
a0
After Generated Clock Optimization
Logic
b
a
c
clk1
enable
q
b0
LO
886 March 2014
Example 3
Similar to example 2, a design can have a latch on the datapath that is
clocked by a generated clock (a flip-flop derived clock).
In this case, the circuit is converted to a flip-flop and multiplexer as shown in
the following figure.
March 2014 887
The above conversion does not occur when the latch and generated-clock
logic are either set or reset by asynchronous signals unless either:
The Force Generated Clock Conversion with Asynchronous Signals check box on
the GCC & Prototyping Tools tab of the Implementation Option dialog box is
checked.
The force_async_genclk_conv option of the set_option command is set to 1.
LO
888 March 2014
March 2014 889
CHAPTER 18
Floorplanning with Design Planner
The Synplify Premier Design Planner tool lets you create a design plan to
physically constrain portions of a design to specific regions on a device. It is
important to place physical constraints carefully, and this tool helps you do
this. The topics below describe how to use the tool.
Netlist restructure files usually contain primitives that have been bit sliced.
The design plan (sfp) and netlist restructure files are used during optimiza-
tion to improve the overall design performance.
The following describe the Design Planner tool and bit slicing in more detail:
Using Design Planner, on page 890
Assigning Pins and Clocks, on page 897
Working with Regions, on page 907
Working with Altera Regions, on page 919
Working with Xilinx SSI Devices, on page 923
Working with Xilinx Regions, on page 928
Using Process-Level Hierarchy, on page 930
Bit Slicing, on page 930
LO
Chapter 18: Floorplanning with Design Planner Using Design Planner
890 March 2014
Using Design Planner
The Design Planner functionality is only available for certain Altera and Xilinx
technologies. You can use the Design Planner tool either in combination with
graph-based physical synthesis (Altera Graph-Based Physical Synthesis with
Design Planner, on page 51) or in a design plan-based physical synthesis flow
(Design Plan-based Physical Synthesis, on page 53). You can also use the
design plan-based logic synthesis with Physical Plus (Xilinx Physical Plus, on
page 66). The following describes the basics of using Design Planner:
Starting Design Planner, on page 890
Copying Objects in the Design Planner Tool, on page 892
Controlling Pin Display in the Design Plan Editor, on page 893
Creating and Using a Design Plan File for Physical Synthesis, on
page 896
Starting Design Planner
After the design is compiled, you create a design plan by doing the following:
1. Start with a compiled design.
It is best if you run logic synthesis first to ensure that there are no errors
before you start physical synthesis, but you can run Design Planner on
a design that has just been compiled but not synthesized.
2. Click the New Design Plan icon ( ) in the Project view. Alternatively, you
can also create a new design plan file using File->New from the Project
menu.
3. If you have not run area estimation, or the area estimation file is out-of-
date, the Estimation Needed dialog box appears asking if you want to run
estimation.
If you do not see this box, the No area estimate warning check box on the
Assignments tab of Tools->Design Planner Preferences is disabled.
If you click No, the Design Planner is displayed.
If you click Yes, the tool first runs area estimation, and the Running
Estimation dialog opens and displays the runtime of the job. Once
estimation is complete, the Design Planner opens.
Using Design Planner Chapter 18: Floorplanning with Design Planner
March 2014 891
LO
892 March 2014
The following figure shows the Design Planner and RTL views.
Copying Objects in the Design Planner Tool
You can use the cut, copy, and paste functions in the Design Plan Editor and
Design Plan Hierarchy Browser views instead of drag and drop. Note the
following caveats:
You can only use cut, copy, and paste on assignments (modules, primi-
tives, and nets).
You cannot cut or copy regions using the Design Planner tool and, you
cannot paste to multiple regions.
Design Plan Views
March 2014 893
The following table summarizes the cut and paste operations.
Controlling Pin Display in the Design Plan Editor
The Design Plan Editor contains the device floorplan and region view in the
Design Planner. It lets you view and assign external ports or internal nets to
I/O pins on the device.
1. To expand the pin view, do the following:
Open the Design Planner and toggle on View->Expanded Pin View, or use
Ctrl-e. This enables the expanded pin view in the Design Plan Editor.
The following figure shows the enabled and disabled views for a
design.
To ... Do this ...
Assign a module or
primitive from a HDL
Analyst view
Select the module/primitive in HDL Analyst and
press Ctrl-c to copy it.
Select the destination region in Design Planner and
paste with Ctrl-v.
Assign a net to an I/O block
from HDL Analyst
Select the net in HDL Analyst and copy.
Select the I/O block region and paste it.
Assign a module or
primitive from the Hierarchy
Browser Unassigned Bin
Select the module or primitive in the hierarchy
browser and copy it.
Select the destination region and paste it.
Replicate a module or
primitive using the
Hierarchy Browser
Select the module or primitive within the region
using the hierarchy browser and copy.
Select the destination region and paste. This
displays the Replication dialog box.
Move an assignment using
the Hierarchy Browser view
Select the module or primitive in the region using
the Hierarchy Browser, and cut it using Ctrl-x.
Select the destination region and paste.
LO
894 March 2014
2. To adjust the size of the pins in the view, do the following:
Select View->Adjust Pin View... the Adjust Pin View dialog box appears.
Adjust the view by moving the slider to either a smaller or larger view
of the pins.
Click OK to save your new pin view setting or Cancel to restore your
original pin view setting.
March 2014 895
3. To display the device I/O pin names, in different views, see the table
below:
When you select a pin in the Design Plan Hierarchy Browser, the corre-
sponding pin location is highlighted in the other views. The following
figure shows an example of I/O pins displayed in all three views of the
Design Planner.
To ... Do this ...
List the pin names in the Design
Plan Hierarchy Browser
Select the expand icon next to Pins.
List the pin names in the Design
Plan view
Click the design name in the Design Plan
Hierarchy Browser. This lists the design objects
in the Design Plan view.
Double-click the Pins folder in the Design Plan
view.
View information about the pins
in the Design Plan view
Right-click and select Show/Hide columns, then
select the columns you need in the dialog box:
Clock, Name, Side, Seq, Dir, or Port/Net.
Display the pin number Place your cursor over the pin in the Design
Plan Editor.
Design Plan
Design Plan View Design Plan Editor
Hierarchy Browser
LO
896 March 2014
Creating and Using a Design Plan File for Physical Synthesis
To create a design plan file, you must have the Design Planner option. Even if
you have this option, you do not need to use a design plan file for graph-
based synthesis. However, for older Altera technologies, the design plan file is
required to run physical synthesis. The following procedure shows you how
to generate a design plan file
1. Use the Design Plan editor to interactively assign RTL modules, paths,
or components to regions on the device.
For information about working with regions and assignment of logic, see
Assigning Pins and Clocks, on page 897 and Working with Regions, on
page 907.
For additional, technology-specific information on assigning logic to
regions, see Working with Altera Regions, on page 919 and Working with
Xilinx Regions, on page 928.
When you have finished assigning the logic, the tool generates an sfp
physical constraint file.
2. When you create an RTL region, select Block Region Tool and then
configure the region. See Creating Regions, on page 907 for details.
3. Use the design plan file for physical synthesis.
Add the file to the project.
Go to Implementation Options ->Design Planning and enable the file.
Run physical synthesis.
The physical synthesis tool uses the placement information in the
design plan file as physical constraints for synthesis.
Assigning Pins and Clocks Chapter 18: Floorplanning with Design Planner
March 2014 897
Assigning Pins and Clocks
This section discusses the following general guidelines for displaying and
assigning pin assignments for design planning:
Assigning Pins Interactively, on page 897
Assigning Clock Pins, on page 900
Modifying Pin Assignments, on page 901
Using Temporary Pin Assignments, on page 902
Viewing Assigned Pins in Different Views, on page 904
Viewing Pin Assignment Information, on page 905
Assigning Pins Interactively
You can manually assign pins using the methods described here. You can
either assign the pins in the SCOPE window or use Design Planner to assign
pins.
1. To assign pins directly in the SCOPE window, do the following:
Open the SCOPE Attributes tab.
Select a port. Assign it to a pin location using a pin location
constraint appropriate to your technology or the syn_loc constraint.
Alternatively, manually add constraints to the constraint file.
2. To assign a pin in Design Planner, do the following:
Open the Design Plan window and make sure you can see the pins
clearly. See Viewing Pin Assignment Information, on page 905 for
information on displaying the pins.
Select a pin in the Design Plan RTL view or the Hierarchy Browser for
that RTL view.
Drag the pin to the location you want in the Design Plan. You can
drag it to the appropriate pin in the graphic Design Plan editor view,
or to the appropriate pin name in the Design Plan Hierarchy Browser
or Design Plan view.
LO
Chapter 18: Floorplanning with Design Planner Assigning Pins and Clocks
898 March 2014
The design plan views reflect the new status of the pin. For details, see
Viewing Assigned Pins in Different Views, on page 904.
Drag pins from either
of these views...
..to any of these views.
March 2014 899
This example shows a pin assignment:
3. To assign a bus port (group of signals), drag a bus port from the RTL
view and drop it to one device pin in the Design Plan Editor view.
The software allocates the remaining pin(s) depending upon its location
on the device. Pins located on the left and right sides of the device are
allocated from bottom to top. Pins located on the top and bottom of the
device are allocated from left to right. Pins that are occupied are
skipped. All devices allocate pins using this convention.
For information about viewing pin assignments and related information,
see Viewing Assigned Pins in Different Views, on page 904.
The following figure shows bus port assignment:
LO
900 March 2014
Assigning Clock Pins
Clock pins are displayed in green in the Design Plan Editor to distinguish
them from the signal I/O pins.
There are several methods of assigning I/O pins, so you might encounter pin
assignment conflicts like the following:
The constraint file might contain I/O pin locations that conflict with the
pin locations specified in the sfp file. The SCOPE constraint file typically
takes precedence over the Design Plan file (sfp) when conflicts exist after
pin assignments.
If pin assignments from the back end place-and-route tool are added
into the sfp file, potential pin lock conflicts may occur. In case of a
conflict, the tool generates an appropriate warning message.
Design rule checks are implemented if there are multiple assignments to
the same I/O pins or ports.
The following procedure shows you how to assign clock pins.
1. To assign a clock pin, drag and drop a signal to a clock pin, as described
in Assigning Pins Interactively, on page 897.
A message asks you to confirm the assignment to ensure that the
correct signal gets assigned to the clock pin. After assignment, the pin
changes to pink.
You cannot drag and drop a bus (group of signals) to a clock pin. If you
drag and drop a bus to an I/O pin near a clock pin, the tool skips the
clock pin when it assigns the bus to the I/O pins.
2. To view the information in the Design Plan view, enable the Clock column
on the Select Columns dialog box. This displays whether or not a pin is a
clock (Yes or No).
March 2014 901
Modifying Pin Assignments
The following shows you how to change pin assignments once they have been
made.
1. To undo an assignment, click on the pin in any of the three views, right-
click, and select Delete Pin Assignment.
2. To reassign a port, drag and drop it at a new location in the Design Plan
editor.
3. To change the current order of pin assignments from clockwise to
counter-clockwise or vice versa, do the following:
Select a set of pins in any view of the Synplify Premier Design
Planner.
Design Plan View
Design Plan Editor
Clock Pins
LO
902 March 2014
Right-click and select Reverse Pin Assignments from the pop-up menu.
The reversed pin assignments are displayed in the Design Planner
views.
4. To rearrange or reorder pin assignments for nets or ports, do the
following:
Move the pins to temporary assignments. See Using Temporary Pin
Assignments, on page 902 for details.
Assign them to the desired locations.
Using Temporary Pin Assignments
Use temporary assignments to rearrange or reorder pin assignments for nets
or ports
1. To create a temporary assignment, drag and drop an assigned pin from
the Design Plan editor to the Temporary Assigns icon ( ) in the Hierarchy
Browser.
The Temporary Assigns container lists the pins with temporary assign-
ments. Note that you cannot drag and drop assignments from the HDL
Analyst RTL view to Temporary Assigns.
2. To re-assign a pin with a temporary assignment, do either of the
following:
For assignment to a new location, drag and drop the pin from the
Temporary Assigns container to the new pin or region location in the
Design Plan Editor. You can also reassign the pin using the methods
described in Assigning Pins Interactively, on page 897.
To return the pin to its original placement location, select the
assignment in the Temporary Assigns. Then, right-click and select
Reassign from the pop-up menu.
As pins in the Temporary Assigns container are reassigned, they are
automatically removed from Temporary Assigns.
3. To remove assignments from all the pins, select the Temporary Assigns
icon, right-click, and select Empty.
March 2014 903
4. To sort pin assignments by description, name, or origin in the Design
Plan View, do the following:
Display the appropriate column by right-clicking and selecting Show
Columns->Description/Origin from the popup menu.
Click on the column heading in the Design Plan View to sort.
5. To undo or redo operations in the Temporary Assigns container, use the
Edit->Undo or Edit->Redo commands.
The following figure shows a temporary assignment:
LO
904 March 2014
Viewing Assigned Pins in Different Views
The following table summarizes how pin assignments are displayed in the
Design Plan views:
Design Plan
Hierarchy Browser
Assigned pins include assignment information. Selected
assigned pins are red.
Design Plan view To view information for the pins, select Show/Hide columns
from the popup menu and choose the kinds of information
you want to display for the pins, like pin direction and port
or net information.
Design Plan editor Orange: Selected assigned pins
Red: Unselected assigned pins
Blue: Selected unassigned pins
Green: Unassigned clock pins
Pink: Unselected assigned clock pins
To view the pin number and assignment for a pin, place the
cursor over the pin.
RTL view Assigned ports are displayed in blue. Place your cursor over
a pin to display information about it.
March 2014 905
Viewing Pin Assignment Information
This section lists different methods you can use to obtain information about
your pin assignments. These methods are in addition to the display informa-
tion described in Viewing Pin Assignment Information, on page 905.
1. To view information for a particular pin, use the following:
Tooltips
To display a tooltip, move your cursor over a pin or port in the Design
Plan editor or in the RTL view.
The visual clues described in Viewing Pin Assignment Information, on
page 905.
2. To display connectivity between the I/O pads and the assigned logic for
regions on the device, do the following:
To view connectivity for all regions, right-click in the Design Plan
Editor and select Rats Nest->Show from the pop-up menu.
To view connectivity for one region, select it and right-click in the
Design Plan Editor. Select Rats Nest->Show Selected from the menu.
To disable the connectivity display, right-click in the Design Plan
Editor and select Rats Nest->Hide.
Alternatively, you can also select View->Rats Nest from the Project menu,
then choose the Show, Hide, or Show Selected command.
The display shows lines (rats nesting) to indicate the connectivity.
3. To view pin assignment statistics for the design, right-click on the Pins
folder in the Design Plan Hierarchy Browser, and select Properties from
the pop-up menu.
The Properties dialog box shows the total number of pins, the number of
assigned pins, and the percentage of pins assigned.
LO
906 March 2014
4. Use crossprobing.
When you select assigned ports in any of the Design Planner views or
the HDL Analyst RTL view, the corresponding pins are highlighted in the
other views view. Similarly, if you select a net that has an assigned pin
in the RTL view, the corresponding pin is highlighted in the Design
Planner views. If you select the assigned pin in a Design Planner view,
the corresponding internal net is highlighted in the RTL view.
Working with Regions Chapter 18: Floorplanning with Design Planner
March 2014 907
Working with Regions
This section discusses the following general guidelines for placing and editing
regions in the Design Planner before running physical synthesis:
Creating Regions, on page 907
Using Region Tunneling, on page 909
Viewing Intellectual Property (IP) Core Areas, on page 912
Assigning Logic to Top-level Chip Regions, on page 912
Assigning Logic to Regions, on page 916
Replicating Logic Manually, on page 916
Checking Utilization, on page 917
Creating Regions
Region placement depends on the data flow and pin locations in your design.
The following procedure shows you how to create a region.
1. If needed, select View->Expanded Pin View and adjust the view to display
the device with or without I/O pins.
2. To create a region, right-click in the Design Plan Editor and select Block
Region Tool to begin the region drawing process.
For more information about creating technology-specific regions, refer to
the following table depending on the technology you have selected.
3. Position the cursor where you want to create the region and then drag
the cursor diagonally to create a rectangular area for the region.
For ... See
Altera designs Creating Design Planner Regions for Altera Designs, on
page 920
Xilinx designs Working with Xilinx SSI Devices, on page 923 and Working
with Xilinx Regions, on page 928.
LO
Chapter 18: Floorplanning with Design Planner Working with Regions
908 March 2014
Do not create regions that overlap or are contained within an area
reserved for IP (see Viewing Intellectual Property (IP) Core Areas, on
page 912).
See the following vendor-specific guidelines to determine where to place
the regions.
4. You can configure the region to apply selected tunneling modes. See
Using Region Tunneling, on page 909 for ways to configure regions.
5. Then, assign logic to the region. For more information, see Assigning
Logic to Regions, on page 916.
Altera
Critical path placement Run the target place-and-route tool with no constraints
to obtain the placement of the critical path. Use the
Design Plan Editor to create a region in this area. This is
a good starting point to determine what row to begin
with when placing the critical path on the logic device
using the Synplify Premier Design Planner tool.
Overlapping regions You can overlap regions to optimize placement. However,
be aware that the Synplify Premier Design Planner
software treats overlapping regions no differently than
regions that do not overlap.
Xilinx
Region size The size and location of Xilinx regions can be easily
modified, so a rough estimate is usually sufficient.
Critical path placement You can get a good starting point for region placement
from the Xilinx floorplanner. Run placement and routing
without constraints, then use the floorplanner to
determine where the critical path logic is placed. Use
this information to create a region in the same general
area on the logic device using the Design Planner tool.
Overlapping regions The Synplify Premier Design Planner software supports
overlapping regions, but the Xilinx place-and-route tool
cannot always place these designs. Overlapped regions
can potentially create an error.
March 2014 909
Using Region Tunneling
The Synplify Premier software can apply tunneling optimizations to region
assignments. To do this:
1. Highlight a region in the Design Planner, then right-click and select
Region Type.
2. You can configure the region by selecting one of the following modes
shown in the table below. Some options are vendor-specific.
Note:
It is possible to highlight multiple regions and then select a tunneling
option for those regions simultaneously.
For Altera designs, you cannot forward-annotate soft regions.
However, hard region constraints can be forward-annotated.
3. To view tunneling status for the region, do the following:
To view tunneling status for a region, highlight the region, then right-
click and select the Properties option. From this dialog box, the
tunneling status for the region is displayed.
To display the tunneling status for all the regions, go to the Design
Plan view, right-click and select Show/Hide columns. From the Select
Columns dialog box, check the box next to Tunneling. The view
displays a column with the tunneling status for all the regions.
Set the option to ... To ...
Soft (Tunneling On)
(Xilinx)
Allows components to be moved across the region
boundaries in both directions. This is the default.
Hard (Tunneling Off) Ensures that components are not moved out of the
region, but allow other objects to be moved into the
region.
Keep-out (Xilinx) Ensures that no placement occurs in the region. Use
this option to create decongestion areas for
optimizing your design.
IP Block (Altera) Ensures that the region only contains the IP block.
Use this for encrypted IP, to ensure that nothing
except for the IP logic is placed in this region.
LO
910 March 2014
The Design Planner can display how tunneling is implemented. Also, the
status of the region is saved and written out to the Synplify Premier
physical constraint file (sfp).
March 2014 911
Moving and Sizing Regions
You can move and resize regions using the cursor arrow keys or the mouse
button. The following procedure provides details.
1. To move a regions use the arrow keys or the mouse button.
Select the region.
To use the arrow keys:, use the left, right, up, or down keys to
reposition the region.
To use the mouse button, press the left mouse button while dragging
the region to the desired position on the device.
The tool displays WYSIWYG region boundaries that show you exactly
what you are doing when you move or resize the boundaries.
To preserve the logic and memory resources of a region when it is
moved, hold down the Shift key when you move it.
The tool preserves the logic and memory resources when you move a
region. For example, Xilinx devices can preserve the number of CLBs
and BRAMs and Altera devices can preserve the number of LABs and
ESBs in a region.
2. To resize a region, use the arrow keys or the mouse button.
Select the region.
To use the arrow keys:, press and hold the Ctrl and Shift keys
simultaneously. An initial resizing arrow appears along the edge of
the region. Continue to hold down Ctrl and Shift while pressing the
appropriate arrow keys (left, right, up, or down) to resize the region in
the direction you want. Release the Shift key. You can no longer resize
the region.
To resize a region with the mouse button, press the left mouse button
on any of the handles of the rectangle while dragging the region in the
direction you want the region resized.
The tool does not preserve logic and memory resources when you resize
a region.
LO
912 March 2014
Viewing Intellectual Property (IP) Core Areas
Dedicated areas on the device reserved for IP cores appear as gray boxes in
the Design Plan Editor. A device can contain up to can contain up to four IP
core areas depending on the part specified for the device.
To view information about the IP core, move your cursor over the gray
box to display a tooltip with information. Do not create regions that
overlap or are contained within an IP core area.
Assigning Logic to Top-level Chip Regions
You can specify the top-level device as a region and then assign logic to this
chip region. To do this:
1. Open the Design Plan view.
Notice the Chip Region hierarchy under the device part and package
designation in the Design Plan Hierarchy view.
IP Core
March 2014 913
2. Assign logic to the chip region. To do this, you can:
Highlight logic in the RTL view, then right-click and select
Assign to->Chip from the popup menu.
Design Plan Hierarchy View
LO
914 March 2014
Highlight logic to assign from Logic in the Design Plan Hierarchy view,
then right-click and select Assign to->Chip from the popup menu.
Otherwise, simply drag-and-drop highlighted logic from the Logic to
Chip hierarchy tree in the Design Plan Hierarchy view.
March 2014 915
The chip assignments are reflected in the Design Plan Hierarchy view as
shown in the following figure.
Design Plan Hierarchy View
Drag-and-Drop Logic to Chip Region
LO
916 March 2014
Assigning Logic to Regions
1. To assign individual instances to regions, make sure that Edit Regions is
enabled and do either of the following:
Drag and drop the logic into the region.
Select the instance in an HDL Analyst, Design Plan Hierarchy
Browser, or Design Plan view. Right-click and select Assign to->
regionName. The regions are listed in order of recent use.
For technology-specific tips about assigning logic to regions, see the
following:
Assigning Logic to Altera Design Planner Regions, on page 921
2. To assign a critical path to a region, do the following:
Select the critical path, filtering it if necessary. You can do this from
the log file.
Drag the selected critical path from the RTL view into a region in
Design Planner.
By assigning the critical path instances to the same region, you can
optimize the timing.
3. For critical paths from pin-locked I/Os, assign the critical path to a
region that is close to the pin positions.
Physically constraining logic close the to locked pins minimizes routing
delays.
For information about device utilization, see Checking Utilization, on
page 917.
Replicating Logic Manually
When the fanout from an instance fans goes to instances in several other
instances, you might want to replicate the instance to avoid the routing delay
between the regions. You can use the methods described here.
1. Replicate logic by copying and pasting.
Copy (Ctrl-c) the logic to be replicated from the original region.
Paste (Ctrl-v) the replicated logic in the region where it is required.
March 2014 917
Each region now contains a local copy of the instance. If you replicate an
in a region where the instance does not drive any logic, the tool does not
create a copy of the instance in that region. Therefore, when you look at
the RTL netlist of the region, the replica of the instance does not appear.
2. Assign the same instance logic from the HDL Analyst RTL view to
different regions.
The Instance Replication dialog box opens. Confirm whether or not you
want to replicate the selected logic instance in the specified region.
Checking Utilization
Use the following tips and guidelines for device and region utilization when
assigning logic to regions.
1. To view device utilization, select Run->Estimate Area.
Utilization is reported in the log file.
2. To estimate region utilization, do the following:
To estimate utilization for all the regions, right-click in the Design
Plan Editor view, right-click and select Estimate All Regions.
To estimate region utilization for an individual region, right-click with
a selected region and select Estimate Regions.
Estimates are in terms of instances. As the job runs, the region is
greyed-out and a label in the upper-left corner of the region displays the
elapsed time of the estimation job. The label remains until estimation is
complete. Est Pending appears in the upper-left corner of all regions
waiting for region estimation.
Regions displayed in red have a utilization higher than 80 percent, See
step 4 for more information about utilization.
LO
918 March 2014
3. To view region utilization information, use one of these methods:
For utilization information for the whole design, view the log file.
For utilization information about the current estimation run, view the
status in the Tcl Script window. or select Run->Job Status immediately
after an estimation run.
To view utilization information for a selected region, right-click and
select Properties. You can also view the tooltip information.
To display utilization information for regions in the Design Plan view,
click Regions in the Design Plan Hierarchy Browser. This updates the
Design Plan view with statistics for the regions.
To determine which statistics to display in the Design Plan view,
right-click in this view and select Show/Hide Columns. Select the options
for utilization you want to display. The available options can vary
with the technology.
4. Follow these guidelines for device and region utilization.
Keep device utilization below 90 percent. Higher utilization rates can
lead to problems with timing closure.
If device utilization is over 90 percent, and if the design contains
several finite state machines, try using the sequential encoding style,
(instead of one-hot) to free up more space on the device.
Keep region utilization below 80 percent to allows for Synplify Premier
Design Planner area estimations and for additional area required for
routing and replicating. The place-and-route tools consider the
design plan to be a hard constraint, so if there is not enough area in
the region for routing, the place-and-route tool will error out.
5. If utilization exceeds the guidelines, resize the region to ensure that it is
not over utilized.
Working with Altera Regions Chapter 18: Floorplanning with Design Planner
March 2014 919
Working with Altera Regions
The guidelines in this section provide tips and strategies for using the
Synplify Premier Design Planner for design planning with Altera Stratix and
Cyclone devices. It supports the following technologies:
Stratix families
(Stratix V, Stratix IV (except the FM29, FM35, and FM40 packages),
Stratix III, Stratix II GX, Stratix II, Stratix GX, and Stratix)
Cyclone families
(Cyclone II and Cyclone)
You can use the Design Planner to view the Altera devices, then create
regions and assign critical path logic to them. The Stratix and Cyclone family
of devices use a row and column coordinate system, with the origin (1,1)
located at the lower-left corner of the device. All components align with row
and column boundaries. The device features can include LAB sites (logic
blocks), RAM (for example, M20K, MRAM, M144K, or M9K), and DPS
locations. Depending on the device and part and package used, the number
of these blocks on the device may vary.
LO
Chapter 18: Floorplanning with Design Planner Working with Altera Regions
920 March 2014
The following shows an Altera Stratix V device in the Design Plan Editor.
Creating Design Planner Regions for Altera Designs, on page 920
Assigning Logic to Altera Design Planner Regions, on page 921
Creating Design Planner Regions for Altera Designs
This section contains Stratix- and Cyclone-specific information about
creating regions. For information about how to create a region, see Creating
Regions, on page 907.
For Stratix V devices, FF PLL and the voided spine region are displayed
in the Design Planner. These are keep out locations on the device, so
when you create regions:
LABs
M20K RAMs
FF PLL Sites
DSPs
Voided Spine Region
Working with Altera Regions Chapter 18: Floorplanning with Design Planner
March 2014 921
They can overlap with the FF PLL site or voided spine region.
However, logic assigned to these regions cannot use these resources.
You cannot create a region that is completely contained in the
boundaries of the FF PLL or voided spine region.
You can create a region around any number of LAB, RAM, and DSP
structures on the device. You can create regions that contain only LABs,
only RAMs, only DSPs, or regions that include any combination of LABs,
RAMs, and DSPs, as required. However, you cannot create a region that
is completely contained within the boundaries of one of these blocks.
Regions can be moved or resized.
When you create, move, or resize regions, they snap to the row/column
grid on the device.
Assigning Logic to Altera Design Planner Regions
This section contains tips and guidelines for mapping MACs, RAMs, and
ROMs to regions.
Mapping MACs
1. Enable the Create MAC Hierarchy optimization on the GCC & Prototyping Tools
tab of the Implementation Options dialog box.
For Stratix devices, this option is enabled by default. When enabled, this
option maps MAC configurations together into one MAC block so that
this block can be easily assigned to DSP regions for physical synthesis.
2. Follow these guidelines when assigning MACs:
Place MAC blocks in a region containing DSP resources. If you do not
do this, the MAC block is mapped to logic and a warning message is
generated in the log file (srr). You can display DSP resources after
you estimate utilization. See Checking Utilization, on page 917 for a
procedure.
Do not place signed and unsigned multipliers in the same DSP block.
3. If you are using the syn_multstyle attribute, note the following:
Do not set the attribute value to logic for a MAC. If the attribute is set
to logic, the tool maps the MAC to logic and generates a warning
message in the log file (srr).
LO
Chapter 18: Floorplanning with Design Planner Working with Altera Regions
922 March 2014
Do not place a multiplier with a syn_multstyle=lpm_mult attribute in a
region without DSP resources. If you do, the tool maps the multiplier
to the MAC block and generates a warning message in the log file.
Mapping RAMs and ROMs
1. Place RAM/ROM logic in a region containing RAM/ROM resources.
If you do not, the tool maps the RAM/ROM to logic and generates a
warning message in the log file (srr). You can display RAM and ROM
resources after you estimate utilization. See Checking Utilization, on
page 917 for a procedure.
2. Ensure that the register driving the address or the output register is
assigned to the same region.
If not, the RAM will not be inferred.
3. If you are using the syn_ramstyle attribute, note the following:
Do not set syn_multstyle=logic, and then assign the RAM/ROM logic to a
region with RAM/ROM resources. The tool maps the ROM/ROM
instance to logic, and generates a warning message in the log file
(srr).
Do not assign RAM/ROM logic with an attached syn_ramstyle=blockram
attribute to a region without RAM/ROM resources. If you do so, the
tool maps the RAM/ROM to altsyncram and generates a warning
message in the log file.
Working with Xilinx SSI Devices Chapter 18: Floorplanning with Design Planner
March 2014 923
Working with Xilinx SSI Devices
Xilinx Stacked Silicon Interconnect (SSI) technology allows multiple die to be
combined in a single chip. Specific Xilinx Virtex-7 devices contain multiple
dies (for example, 2000T, 1500T, 1140XT, 870HT, and 580HT). Each die is
called a Super Logic Region (SLR) that is connected together between the
adjacent SLRs. Devices can contain 2, 3, or 4 SLRs.
The Design Planner supports SLR assignments to pre-defined regions. From
the Design Planner you can choose an instance and assign it to an SLR.
These results are written to the design floorplan file (sfp).
Assigning Logic to SLR Regions
To assign logic to SLR regions, do the following:
1. Click on the New Design Plan ( ) icon to bring up the Design Planner
tool.
LO
Chapter 18: Floorplanning with Design Planner Working with Xilinx SSI Devices
924 March 2014
Depending on the number of SLRs for the device, SLR Regions appear in
the Design Plan Tree View as pre-defined regions. For example, they are
named SLR0, SLR1, and SLR2. The bottom-most SLR is 0 and the top-
most SLR is number 3.
2. You can assign logic to an SLR region from the HDL Analyst View in the
following ways:
Select an instance and drag-and-drop it to the SLR Regions bin in the
Design Plan Tree View over the specified SLR.
Select an instance and drag-and-drop it near the edge of an SLR
region in the Design Plan Editor View.
Notice that the SLR region turns the color blue prior to dropping the
instance.
Select an instance, right-click and select the Assign to menu; then
choose from the list of SLR regions (for example, SLR0, SLR1, or
SLR2).
Drop instance to Design Plan Tree View
Drop instance to Design Plan Editor View
March 2014 925
OR
3. You can assign logic to an SLR region from the Design Planner View in
the following ways:
Select an instance from the Logic bin and drop it to an SLR region
over the SLR Region bin in the Design Plan Tree View.
Note: You can assign an instance from the Unassigned Bin, Logic bin,
Temporary Assigns bin, or from an assignment in another SLR region.
Select an instance from the Logic bin and drop it near the edge of an
SLR region in the Design Plan Editor View.
Notice that the SLR region turns the color blue prior to dropping the
instance.
Select an instance, right-click and select the Assign to menu; then
choose from the list of SLR regions (for example, SLR0, SLR1, or
SLR2).
LO
Chapter 18: Floorplanning with Design Planner Working with Xilinx SSI Devices
926 March 2014
4. Save this Design Plan file.
SLR Dependencies
Here are some dependencies to consider when assigning logic to SLRs:
All assignments can be replicated to an SLR region and other regions.
User-defined regions must be fully contained in an SLR region and
cannot cross SLR boundaries.
The SLR assignments are saved to the design floorplan file (sfp). The
content of the SFP file is shown below.
March 2014 927
When SRL assignment conflicts exist, the software honors lower-level
hierarchical instances within a hierarchy. For example, suppose
instance A contains instances B and C. If instance A is assigned to SLR0
and instance B is assigned to SLR1, then the assignments to SLR0 are
maintained for instances A and C. However, the synthesis software still
honors instance B assignment to SLR1.
For more information about assigning SLR regions for the device, see Xilinx
Stacked Silicon Interconnect (SSI) Technology, on page 1043.
LO
Chapter 18: Floorplanning with Design Planner Working with Xilinx Regions
928 March 2014
Working with Xilinx Regions
Here are guidelines for using the Synplify Premier Design Planner with Xilinx
devices. You can interactively create regions and assign logic to them for
Xilinx devices in the Design Plan Editor view. The Design Planner supports
Xilinx Virtex-5 and later technologies.
To manually create regions, you can use the syn_assign_to_region attribute. For
details, see syn_assign_to_region, on page 82.
For more information see the following:
Xilinx Device Resources, on page 928
Creating Regions for Xilinx Designs, on page 929
Xilinx Device Resources
The Xilinx devices can include resources like DSP elements, RAM blocks, I/O
banks, IP, and PCIE bus. The resources are located within the device or along
its perimeter, depending on the technology family you select. The number of
resources vary with the technology family.
Working with Xilinx Regions Chapter 18: Floorplanning with Design Planner
March 2014 929
Creating Regions for Xilinx Designs
The following vendor-specific guidelines are intended to supplement the
procedure described in Creating Regions, on page 907. Use the following
recommendations to help you design plan regions in the Design Plan Editor
for Xilinx devices:
I/O Banks
IP
DSP
RAM Blocks
PCIE
LO
Chapter 18: Floorplanning with Design Planner Using Process-Level Hierarchy
930 March 2014
Base your placement on the Configurable Logic Block (CLB) coordinate
system. Typically, the bottom-left corner is the row 1, column 1 location
on the device.
Physical Plus guides placement for the regions you create on the Xilinx
device.
Using Process-Level Hierarchy
Depending on the technology you use, process-level hierarchy can affect
design performance positively or negatively. The tendency is to affect Xilinx
designs positively and Altera designs slightly negatively.
Process-level hierarchy is turned off by default in the Synplify Premier UI. The
mapper treats designs with and without process-level hierarchy in the same
way. However, if you have process-level hierarchy, there are extensive name
changes, which can affect the mappers and the place-and-route tools.
Bit Slicing
Bit slicing is a technique you can use when a primitive is too large to fit into a
region, or when you want more granularity to control placement. It allows you
to break up large primitives into smaller ones, which you can then place in
different regions.
The following describe bit slicing in more detail
Using Bit Slicing, on page 930
Bit Slice Examples, on page 934
Using Bit Slicing
1. In the Synplify Premier project window, open a new (File->New->Netlist
Restructure File) or an existing nrf file.
Bit Slicing Chapter 18: Floorplanning with Design Planner
March 2014 931
The nrf file is a netlist restructure file that defines the logical division of
primitive outputs. The tool reads the slice_primitive commands in this file
which define the division. For information about this command and its
use in a script, see slice_primitive in the Chapter 2, Tcl Commands of the
Reference Manual.
If you have an existing tcl file, you can view it in this graphical interface
by renaming it with a nrf extension, and then opening it as described.
2. Type in or drag and drop the instance to slice from the RTL view into this
tab.
For bit slicing, you can only divide bus primitives of the following types:
3. Set bit-slicing preferences.
To slice an instance by a specified number of bits per slice or by a
specified number of slices, see the details in Slicing an Instance into a
Specified Number of Slices, on page 932.
To divide an instance into slices of varying widths, see the procedure
in Custom Slicing, on page 933.
To globally bit slice all instances of the same type in the netlist, select
Slice all instances of this type.
buf or register
inv xor mux
tristate and latch
LO
Chapter 18: Floorplanning with Design Planner Bit Slicing
932 March 2014
4. Save the file.
The Project view now shows the netlist restructure folder.
5. Select (Project->Implementation Options) and click the GCC & Prototyping Tools
tab. Make sure that the netlist restructure file that you just created is
checked in the Netlist prototype files section, and click OK.
6. Select Run->Compile Only (F7) to run netlist restructuring on your design.
The sections of the sliced element are displayed and can now be
individually assigned.
Slicing an Instance into a Specified Number of Slices
The following procedure shows you how to slice an instance by a specified
number of bits per slice or into a specified number of slices. To slice into
varying bit widths, see Custom Slicing, on page 933.
1. Open the Bit Slices dialog box by opening an nrf file as described in Using
Bit Slicing, on page 930.
2. Enter a value.
You can now return to the rest of the bit-slicing procedure described in
Using Bit Slicing, on page 930.
To create ... Do this ...
Slices with a
specified number of
bits per slice
Click the Bits per Slice button and enter a value for the
number of bits.
The tool allocates n instance for each group of bits, and
allocates any remaining bits to the last instance. For an
example, see Slicing into Primitives of Equal Size, on
page 934.
A specific number of
slices
Click the Slices button and enter a value for the number
of slices. For an example, see Slicing into Predefined
Primitives, on page 935.
The tool divides the bits equally between the specified
number of instances, and assigns any partial numbers
to the last instance.
March 2014 933
Custom Slicing
The following procedure shows you how to define slices of varying widths. For
a specified number of slices, see Slicing an Instance into a Specified Number of
Slices, on page 932.
1. Open the Bit Slices dialog box by opening an nrf file as described in Using
Bit Slicing, on page 930.
2. Click the Custom button. This enables the MSB/LSB table and the Slice
button.
3. To define a slice, do the following:
Select the top entry in the table, then click on the Slice button. This
displays the Select New Slice MSB.
Either click OK to slice the number of bits into two or enter the
starting MSB for the next slice.
The upper limit of the bit range is always one less than the previously
assigned MSB so that each slice is at least one bit wide. When you click
OK, the table is updated and the Slice button is again enabled, so you
can define a new slice.
4. Continue to select entries in the table and click Slice to redisplay the
Select New Slice MSB popup menu and define the additional slices.
See Slicing into Predefined Primitives, on page 935 for an example of
custom slicing.
5. To undo an entry, merge the entries by doing the following:
LO
934 March 2014
Select two (or more) adjacent slice definitions by holding down the Ctrl
key and clicking the table entries to select them.
Click Join.
You can now return to the rest of the bit-slicing procedure described in
Using Bit Slicing, on page 930.
Setting Viewing Options for Bit Slices
This procedure shows you how to set some viewing options.
1. To keep the current level as it is and only view the effects of bit slicing
one level down in the design hierarchy, go to the Bit Slices tab of the
netlist restructure file GUI and enable Preserve the Hierarchical View.
2. To view information about the bits, do the following:
Select a group of bits in an HDL Analyst view.
Right-click and select Properties. A dialog box displays the bit slicing
properties for the primitive. Click OK to dismiss this dialog box.
Bit Slice Examples
The following examples illustrate two different cases of bit slicing a 96-bit bus
XOR primitive. The following figure shows the primitive before bit slicing.
Slicing into Primitives of Equal Size
In this example, the Bits per Slice value is set to 36. The tool divides the output
of the y[95:0] primitive into three individual primitives. The first two primitives
each contain the requested 36 bits; and the last primitive contains the
remaining 24 bits (y[95:72]). The following figure shows the results of this bit
slicing RTL view.
March 2014 935
Slicing into Predefined Primitives
In this example, the Custom setting is used to define three individual primi-
tives with widths of 48, 32, and 16. For more explanation about defining
custom slices, see Custom Slicing, on page 933.
The RTL view for this bit slicing example is shown in the following figure.
LO
936 March 2014
March 2014 937
CHAPTER 19
Analyzing Designs in Physical Analyst
This document describes typical analysis tasks using graphical analysis with
the Physical Analyst tool. It covers the following:
Analyzing Physical Synthesis Results, on page 938
Using Physical Analyst, on page 941
Displaying and Selecting Objects, on page 947
Querying Physical Analyst Objects, on page 957
Crossprobing in Physical Analyst, on page 971
Analyzing Netlists in Physical Analyst, on page 979
Using Implementation Maps in Physical Analyst, on page 986
For information about analyzing timing in the Synplify Premier Physical
Analyst tool, see Using Auto Constraints, on page 469.
LO
Chapter 19: Analyzing Designs in Physical Analyst Analyzing Physical Synthesis Results
938 March 2014
Analyzing Physical Synthesis Results
This section contains information about tools you can use to analyze physical
synthesis results. See the following:
Analyzing Physical Synthesis Results Using Various Tools, on page 938
Running Multiple Implementations, on page 939
Running Multiple Implementations, on page 939
Checking Altera Pre-Placement Physical Synthesis Results, on page 939
Analyzing Physical Synthesis Results Using Various Tools
Default timing and area reports are presented in the htm or srr log file for the
design project. To view this information, click the View Log button in the
Project view (or View->View Log File). The following htm log file shows both the
Table of Contents and the HTML log file contents for the design.
See Viewing and Working with the Log File, on page 342 for complete infor-
mation on how to interpret the log file results.
In addition, you can generate a stand-alone timing report to display more or
less information than what is provided in the log file. See the following:
Analyzing Physical Synthesis Results Chapter 19: Analyzing Designs in Physical Analyst
March 2014 939
Also, check the place-and-route results to determine if further synthesis is
required. For example, click on Xilinx P&R Report to check the xflow_par.log file to
verify that all constraints were met as shown below. For graph-based physical
synthesis, you can also click on Initial Placement Report to check the xflow_gp.log
file. Click on Quartus P&R Report to check the quartus.log file for place-and-route
results for Altera devices.
Running Multiple Implementations
You can create multiple implementations of the same design so that you can
compare the results of each implementation and place-and-route run. This
lets you experiment with different settings for the same design with different
place-and-route options. Implementations are revisions of your design within
the context of the Synplify Premier software and do not replace external
source code control software and processes.
For the Graph-based physical synthesis with a design plan flow, you can
run the first pass using the Synplify Premier software without a design
plan file (sfp) to synthesize the design. Placement and routing runs
automatically. Then, create a new implementation and apply a design
plan for Design plan-based physical synthesis.
See Working with Multiple Implementations, on page 150 for more informa-
tion.
Checking Altera Pre-Placement Physical Synthesis Results
In Altera designs, graph-based physical synthesis generates an intermediate
file that you can display in the Technology View and use for debugging. Do
the following:
1. After physical synthesis, open the preplace.srm file by double-clicking or
right-clicking the file in the Project view and selecting Open.
The preplace.srm file is an intermediate file that captures the netlist after
RTL physical synthesis and immediately before global placement,
showing the same results as would be obtained from logic synthesis.
This file is located in the physical synthesis implementation results
directory.
LO
Chapter 19: Analyzing Designs in Physical Analyst Analyzing Physical Synthesis Results
940 March 2014
2. To view the corresponding timing slack for all the clocks in the design,
open the log file, and check the Pre-placement Timing Snapshot section of the
log file for the critical path reflected in the preplace.srm file.
For more information on analyzing synthesis results graphically, see the
following:
Using Physical Analyst, on page 941
Chapter 8, Analyzing with HDL Analyst and FSM Viewer
Using Physical Analyst Chapter 19: Analyzing Designs in Physical Analyst
March 2014 941
Using Physical Analyst
After you have placed and routed your design with backannotated informa-
tion, you can use the Physical Analyst tool to analyze the placement and
global routing. For descriptions of the interface, see the Reference Manual.
The Physical Analyst functionality is only available for the Synplify Premier
flows:
Graph-based physical synthesis (Altera Graph-Based Physical
Synthesis, on page 48)
Graph-based physical synthesis with a design plan (Altera Graph-Based
Physical Synthesis with Design Planner, on page 51)
For both these flows, you can also include a place-and-route implementation
with backannotation. The tool will display the placement information after
physical synthesis is run, for the following technologies:
See the following for more information:
Opening the Physical Analyst Interface, on page 941
Zooming in the Physical Analyst, on page 943
Moving Between Views in the Physical Analyst, on page 944
Using the Physical Analyst Context Window, on page 945
Opening the Physical Analyst Interface
The following procedure shows you how to open the tool and the control
panel.
1. Open the Physical Analyst view in any of the following ways:
Click on the Physical Analyst icon ( ) from the Physical Analyst
toolbar.
Select HDL Analyst->Physical Analyst in the Project view.
Xilinx Virtex-6, Virtex-5, and Virtex-4
Altera Stratix IV, Stratix III, Stratix II GX, and Stratix II
LO
Chapter 19: Analyzing Designs in Physical Analyst Using Physical Analyst
942 March 2014
Select the srm file, then right-click and select Open Using Physical
Analyst from the popup menu.
2. To display the control panel for the Physical Analyst, do one of the
following:
Click on the Physical Analyst Control Panel icon ( ) in the Physical
Analyst toolbar.
Select Options->Physical Analyst Control Panel.
Use the keyboard shortcut key Ctrl-k.
March 2014 943
3. To close the Physical Analyst control panel, use any of the toggle
methods listed in the previous step, or right-click in the control panel
and select Hide from the popup menu.
Zooming in the Physical Analyst
Since the objects displayed in the Physical Analyst full view might be very
small, a handy command to use is Zoom Selected. After selecting one or more
objects in the Physical Analyst view, you can access this command by
1. If you do not have objects selected, use any of the following global zoom
commands to change the display:
View->Zoom In from the menu or the Zoom In ( )icon.
View->Zoom Out from the menu or the Zoom Out ( )icon.
View->Full View from the menu or the Full View ( ) icon.
View->Normal View from the menu or the Normal View ( ) icon.
Appropriate mouse strokes.
LO
944 March 2014
For a description of the zoom options, see View Menu, on page 263 in
the Reference Manual. For a description of the mouse strokes, see Help->
Mouse Stroke Tutor.
2. To zoom into a particular object or area, select the objects and then use
the Zoom Selected command in one of the following ways:
Click the Zoom Selected ( ) icon.
Right-click and select Zoom Selected from the popup menu.
Use the following mouse stroke.
The Zoom Selected command centers the selected object or objects in the
view.
Moving Between Views in the Physical Analyst
When you filter or expand your design, you move through a number of
different design views in the same window. For example, you might start with
a view of the entire design, zoom in on an area and filter an object, and finally
expand a connection in the filtered view, for a total of three views.
1. To move back to the previous view, click the Back icon or draw the
appropriate mouse stroke in the Device window.
The software displays the last view, including the zoom factor. This does
not work in a newly generated view because there is no history.
2. To move forward again, click the Forward icon or draw the appropriate
mouse stroke.
The software displays the next view in the display history.
March 2014 945
Using the Physical Analyst Context Window
The Physical Analyst context window occupies the lower portion of the
Control Panel view. The context window provides a point-of-reference to your
location on the device.
For example, suppose you:
1. Zoom in the Physical Analyst tool to get a better view of the objects you
selected on the device.
2. The context window in the control panel displays a rectangle around the
relevant area on the device. This is helpful because you now have a
point-of-reference to your location on the device.
Device View Context Window
Control Panel
LO
946 March 2014
3. Once a rectangle area is drawn in the context window, you can then:
move
scroll
stretch/shrink
this rectangle in the context window. This view will be reflected in the
Physical Analyst view.
4. To reinstate the full context window view, right-click and select Refresh in
this view.
Displaying and Selecting Objects Chapter 19: Analyzing Designs in Physical Analyst
March 2014 947
Displaying and Selecting Objects
This section describes how to display and select objects in the Physical
Analyst view.
Setting Visibility for Physical Analyst Objects, on page 947
Displaying Instances and Sites in Physical Analyst, on page 948
Displaying Nets in Physical Analyst, on page 952
Selecting Objects in Physical Analyst, on page 954
Setting Visibility for Physical Analyst Objects
You determine object visibility and selectability by setting it in the control
panel.
1. Select Options->Physical Analyst Control Panel to display the control panel.
2. To make an object visible, select the Vis box for that object.
This makes the boundaries for the selected type of object visible in the
Device view. You cannot select a visible object, unless it has been made
selectable. For details about object selection, see Displaying Instances
and Sites in Physical Analyst, on page 948, and Displaying Nets in
Physical Analyst, on page 952.
3. To make an object selectable, select the Vis and Sel boxes for that object.
The object must be visible before you can make it selectable. When an
object is selectable, you can get detailed information by rolling the
mouse over it to get a tool tip.
LO
Chapter 19: Analyzing Designs in Physical Analyst Displaying and Selecting Objects
948 March 2014
Displaying Instances and Sites in Physical Analyst
The following procedure shows you how to display objects and sites in the
Physical Analyst window.
1. To display instances, open the Physical Analyst control panel and select
the Vis box for Instances.
The window displays instance bounds, instance locations, and signal
pins if all instances with placement information. It does not display the
signal pins of the instances.
- Signal nets visible and selectable
- Instances visible and selectable
- Instance internals visible
- Do not show enhanced view for instances
- Do not show signal flow
- Show pruned signals
- Sites visible
- Do not show internal signal pins
The Control Panel will display the following in the
Physical Analyst View:
March 2014 949
The following figure shows cell boundaries.
2. To display core cells at a fixed size regardless of zoom level, do the
following:
With the Physical Analyst window active, select View->Configure
Enhanced Instance Display.
Site Rows
Core (CLB) Cell
LO
950 March 2014
Enable the Enhance Instance Shape for Better Visibility option.
Set any other options you want and click OK.
The tool displays the core cells as diamonds of a fixed size.
March 2014 951
3. To display instances and their signal pins, select the Vis boxes for
Instances, Inst Display.
LO
952 March 2014
The Vis box for Signal Pins is selected automatically, and the tool displays
the signal pins. The following figure shows signal pins displayed:
4. To display sites, do the following:
Select the Vis box for Sites.
To view sites more clearly, turn off the visibility of instances.
Displaying Nets in Physical Analyst
When nets are routed, they are connected to their respective instances.
Because of the long load time and the limited visibility when nets are super-
imposed on the view, net routes are not displayed by default. Nets are routed
from output pins to input pins and are shown with their corresponding point-
to-point connections on one layer of the device in the Physical Analyst view.
1. Route the nets, using one of these methods:
Use an on-demand routing command like Expand or Show Critical Path.
For more netlist commands, see Analyzing Netlists in Physical
Analyst, on page 979.
Signal Pins (Inputs)
Signal Pins (Outputs)
March 2014 953
Right-click and select Route Selected Instances. You can choose to
display nets for connected instances only, as well as, from input pins,
to output pins, or to all pins for selected instances.
2. Set the visibility options on the control panel. Select the Vis box for Nets.
You must select this to make the other options available.
The following example shows point-to-point net routing:
3. To reduce clutter in the display, try the following techniques:
Isolate a critical path, or filter the design to show just a few paths you
want to analyze.
In the control panel, select the Vis box for Prune Signals. When enabled,
this option displays net segment that connect to an instance that is
invisible because of filtering, for example, in a diminished color.
4. To view the direction of a signal, do either of the following:
Place the cursor over a net to view the predominant direction of its
signal flow (right, left, up, or down).
LO
954 March 2014
Select the Vis box for Signal Flow. The net is displayed with arrows
showing the direction of its signal flow. The Signal Flow option is useful
when you display the critical path. You can follow the arrows and
lines along the critical path from the start point to the end point.
5. To hide all nets in the display, do either of the following:
Right-click in the Physical Analyst and select Unfilter->Show All Instances,
Hide All Nets from the popup menu.
Click the Reset filter icon ( ).
Selecting Objects in Physical Analyst
Selected objects are highlighted in the Physical Analyst view. If you have
other windows open and crossprobing enabled, you can highlight the selected
object in the other windows too.
Net ALUA[1]
Fanout=13
Connects to SIGNAL PIN I1 (input) (INST UC_ALU_LONGQ_2)
Signal flows right
Critical Path Start
March 2014 955
The following procedure shows you ways to select objects.
1. To select an object, do the following:
In the control panel, select the Sel box for the object to make it
selectable.
Click on the object in the Device view.
2. To select multiple objects, use one of these methods:
Draw a rectangle around the objects.
Select an object, press Ctrl, and click other objects you want to
select. You can also deselect from the list of currently selected
objects while holding the Ctrl key.
Position the cursor over an object and click the right mouse button;
the object is automatically selected in the view. To preserve a prior
selection, hold the Ctrl key and press the right mouse button.
Right-click and choose one of the Select commands from the popup
menu.
3. To limit the selection range, use these techniques:
Use the Physical Analyst control panel to enable or disable a class of
objects to be selected. For example you can disable selection for nets,
and only select instances in an area.
Use the Filter and Unfilter commands to restrict the scope of selection.
Use Find to select the objects you want. You can also use the Find
command to select a subset of objects of a particular type. See Using
Find to Locate Physical Analyst Objects), on page 962.
Use the Go to Location command and specify an object location in
microns to go directly to a coordinate pair location. See Finding
Physical Analyst Objects by Their Locations, on page 966.
4. To select a net or instance that overlaps another, do the following.
Move your cursor over the overlapping object you want to select. The
cursor changes shape to indicate that you need to resolve the
selection.
Click the cursor, and the Resolve Selection dialog box opens.
LO
956 March 2014
Select the object you want from the list and click Close.
Once you have selected an object, the software highlights the selected object
in the Physical Analyst window. If you have other windows open and
crossprobing enabled, the object is highlighted in the other windows.
Querying Physical Analyst Objects Chapter 19: Analyzing Designs in Physical Analyst
March 2014 957
Querying Physical Analyst Objects
The following procedures describe how to view object properties in the
Physical Analyst:
Viewing Properties in Physical Analyst, on page 957
Using Tool Tips to View Properties in Physical Analyst, on page 960
Viewing Properties in Physical Analyst
You can view properties for the device design and for selected objects
displayed in the view using the popup menu commands described here. For
site properties, use tooltips, as described in Using Tool Tips to View Properties
in Physical Analyst, on page 960.
1. To view general information for the design, right-click anywhere in the
Physical Analyst view, and select Physical Analyst Properties from the popup
menu.
The dialog box shows information like the design name, the number of
instances, unplaced instances, routed nets in the design, and the
location of the netlist and floorplan (def) files.
LO
Chapter 19: Analyzing Designs in Physical Analyst Querying Physical Analyst Objects
958 March 2014
2. To view properties for an instance, right-click the instance and select
Properties (Core Cell).
The dialog box lists information like the instance name, type, and pins;
placement information like its placement location and device-specific
location; and its delay, slack, and clock signal. It also indicates whether
the instance is included in the critical path.
3. To view properties for a net, right-click the net and select Properties (Net).
March 2014 959
The dialog box lists information like the net name, logical nets, pin
count, and fanout. It also indicates if the net is a clock and if it has been
globally routed.
4. Click on an item in the list to view a definition of that term below.
LO
Chapter 19: Analyzing Designs in Physical Analyst Querying Physical Analyst Objects
960 March 2014
Using Tool Tips to View Properties in Physical Analyst
You can use this method to view properties for any objects in the design, as
well as for various UI features. For instance, net, and design properties, you
can also use the popup commands described in Viewing Properties in Physical
Analyst, on page 957.
1. Enable View->Tool Tip.
2. Move your mouse over an object.
As you move the mouse over an object, you see information about that
object. Coordinates for the objects are in microns. The following is an
example of information for different objects.
Floorplan site column

Floorplan site
bounds=(1440.00,1540.00) ~ (1445.00,1740.00)
orien=N (0)
site BRAM (Core)
Site row 21
bounds=(1260.00,72.00)~(176.00,3384.00)
orien=N(0)
site CLB (Core)
Floorplan site
bounds=(1440.00,1540.00) ~ (1445.00,1740.00)
orien=N (0)
site BRAM (Core)
Floorplan site
bounds=(1470.00,1540.00)~(1475.00,1740.00)
orien=N(0)
site BMULT (Core)
Core Cell UC_ALU.LONGQ[5]
Type=LUT4_E2AA
Inputs=4
Outputs=1
Location=(1656.00,1503.00)
Device Location=SLICE_X47Y66
Delay=1.9900
Slack=0.5806
bounds=(1260.00,72.00)~(176.00,3384.00)
March 2014 961
3. To display the tooltip information in the Tcl window, do the following:
Select an object directly. Do not use this method with area selections
or when objects are selected using other commands such as Expand or
Find.
Either select View->Selection Transcription or right-click in the Physical
Analyst view and select Selection Transcription from the popup menu.
The tooltip information is displayed in the Tcl window. You can copy and
paste the information from the TCL window into other windows or files
like the SCOPE window, the Find Object dialog box, or a text file.
The following figure shows an example of an object selected on the
device and its tool tip information displayed in the TCL window.
TCL Window
Core Cell mem_add_fast[2]
LO
Chapter 19: Analyzing Designs in Physical Analyst Finding Objects
962 March 2014
Finding Objects
To find and display objects in the Physical Analyst view, use the following
options:
Using Find to Locate Physical Analyst Objects), on page 962
Finding Physical Analyst Objects by Their Locations, on page 966
Using Markers to Find Physical Analyst Objects, on page 967
Identifying Encrypted IP Objects in Physical Analyst, on page 969
Using Find to Locate Physical Analyst Objects)
This procedure shows you how to use the Find command to do a search on the
entire design. The view displayed is flat, although the hierarchy of instance
names is retained. The Find command does not include physical instances in
its search.
1. To find nets, first make sure their display is enabled by selecting View->
Unfilter->Show All or the corresponding command from the popup menu.
2. Right-click and select Find from the popup menu or press Ctrl-f. Move the
dialog box so you can see both the view and the dialog box.
You can also open the dialog box by selecting Edit->Find from the menu or
by clicking the Find icon in the tool bar.
3. Select the tab (at the top of the dialog box) for the type of object. The
Unhighlighted box on the left will list objects of the selected type
(instances, symbols, nets, or ports).
Finding Objects Chapter 19: Analyzing Designs in Physical Analyst
March 2014 963
4. You can optionally restrict the scope of your search for the design in the
following ways:
To filter the search using wildcards, see Using Wildcards with the Find
To further filter the object type, see Using Object Filters with the Find
The Unhighlighted box shows available objects within the scope you set
when you click Find 200 or Find All. Objects are listed in alphabetical
order.
5. Do the following to select objects from the list.
Click First 200 or Find All. The Unhighlighted box shows available objects
(in alphabetical order) within the scope you set when you click Find
200 or Find All. The former finds the first 200 matches, and then you
can click the button again to find the next 200.
Move the objects you want to the Highlighted box by double-clicking
them, or by clicking them to select them, and then clicking the right
arrow. Right-click on the objects you want from the list.
LO
964 March 2014
If the object name exceeds the width of the Unhighlighted box, check
the object name by clicking the entry in the list, and viewing the
entire name in the field below the Unhighlighted box.
Objects transferred to the Highlighted box are automatically highlighted in
the view.
You can leave the dialog box open to do successive Find operations. Close the
dialog box when you are done.
Using Wildcards with the Find Command
The following procedure shows you how to use patterns or wildcards to
restrict the search range with the Find command when you are locating
objects in the Physical Analyst view. You can use wildcards to avoid typing
long path names. Start with a general pattern, and then make it more
specific.
1. Follow the first three steps described in Using Find to Locate Physical
Analyst Objects), on page 962.
2. Type a pattern in the Search By Name field.
When you use wildcards between hierarchies, all pattern matching is
displayed from the top level to the lowest level hierarchy, inclusively.
3. Click First 200 or Find All.
The Unhighlighted box lists the objects that match the wildcard pattern
criteria. If you selected First 200, it lists the first 200 matches, and then
you can click the button again to find the next 200.
* The asterisk matches any sequence of characters.
? The question mark matches any single character.
. The dot (period) explicitly matches a hierarchy separator, so type one dot
for each level of hierarchy. To use the dot as a pattern and not as a
hierarchy separator, type a backslash (\) before the dot.
March 2014 965
4. Select and move the objects you want to the Highlighted box by doing one
of the following:
Select the objects in the Unhighlighted box and click the right arrow.
Double-click individual items in the Unhighlighted box.
The objects are automatically highlighted in the view.
Using Object Filters with the Find Command
Use the Filter Search option on the Find Object dialog box to limit the objects you
are searching for to a particular subcategory. This can be very useful in large
designs.
1. Follow the first three steps described in Using Find to Locate Physical
Analyst Objects), on page 962.
At this point, you have already restricted your search to a certain type of
object by selecting one of the tabs at the top.
2. Select a subcategory from the pull-down list in Filter Search.
The listed subcategories are for the kind of object you have already
selected. For descriptions of the various subcategories, see Object Filter
Search for Find Command, on page 581 of the Reference Manual.
3. Click First 200 or Find All.
The Unhighlighted box lists the objects that match the filtered object
criteria. If you selected First 200, it lists the first 200 matches, and then
you can click the button again to find the next 200.
4. Select and move the objects you want to the Highlighted box by doing one
of the following:
Select the objects in the Unhighlighted box and click the right arrow.
Double-click individual items in the Unhighlighted box.
The objects are automatically highlighted in the view.
LO
966 March 2014
Finding Physical Analyst Objects by Their Locations
The Go to Location command allows you to specify a coordinate pair location or
location of an object, and then zoom in on this location if requested.
This procedure shows you how to use the Go to Location command to search
for objects, such as instances.
1. In the Physical Analyst view, type Ctrl-g or right-click and select Go to
Location from the popup menu.
The command displays the Goto Location dialog box.
2. Do one of the following:
Enter the coordinates of the location (see step 3 for details).
Select a marker from the Marker pull-down. For information about
creating markers at object locations, see Using Markers to Find
Physical Analyst Objects, on page 967.
3. Enter a coordinate pair (X and Y) location value in microns. You can do
this in any of these ways:
Type a coordinate pair in the field.
March 2014 967
The syntax is very flexible, providing various ways to separate
coordinates. You can use a space, or one of the following punctuation
marks: a comma, semi-colon, or colon. Optionally, enclose the
coordinate pair location in parentheses.
Copy and paste a coordinate pair location from a log file (srr) or
timing analyst file (ta).
Copy a location from a def file. The unit of measurement in the def
file is database units. Use the UNITS DISTANCE MICRONS factor from
the def file to convert database units to microns, before using it here.
If you have used the command before and have a history of locations,
select a location from the pull-down list in the History field.
A description of the object shows in the dialog box window, if applicable.
4. Select a zoom mode.
To center the location, without zooming, select Scroll.
To zoom into the selected area, select Zoom to Object.
To zoom at the 100% level, select Zoom Normal.
5. Click OK.
The Physical Analyst view shows the location you specified, at the zoom
level you specified. The command keeps a running history of the
locations you specified, and they appear in the History pull-down the next
time you use the command.
Using Markers to Find Physical Analyst Objects
Markers are bookmarks for physical coordinates in the Physical Analyst view.
Markers are useful for analyzing floorplan placement in the Physical Analyst
view. You can find an object, such as an instance, then create a marker on
this instance. When multiple markers are defined, you can move from marker
to marker, as well as, measure the distance from a marker or between any
two markers.
1. You can create a marker in either of these ways:
Select an object or click on the spot where you want to place the
marker. Type Ctrl-m, or right-click and then select Markers->Add Marker
from the popup menu. If a marker is created at an instance or net
LO
968 March 2014
location, the markers name is Marker_objectName. All other markers
are named Marker1, Marker2, etc.
Click on the spot where you want to create the marker. Either type
Ctrl-g or right-click and select Go to Location to open the Go to location
dialog box. Your coordinates appear in the coordinates field. Check
the Create Marker box in the dialog box. Either specify a name for the
marker, or use the default marker name, which is GotoMarker1,
GotoMarker2, etc. Click OK.
A marker symbol ( ) appears in the Physical Analyst view at the
location specified. As you move the cursor over the marker, a tool tip
shows the marker name and its X and Y coordinates. You can also view
this information by selecting the marker, right-clicking, and selecting
Properties. The marker is automatically added to the list in the Go to
Location dialog box, and you can use it to locate objects, as described in
Finding Physical Analyst Objects by Their Locations, on page 966.
2. To move a marker, select the symbol ( ). Press the mouse button, drag
the marker to its new location, and then release the mouse button.
3. To delete a marker, select the marker and press the Del key.
Alternatively, right-click and select Markers->Remove Selected from the
popup menu. To delete all markers, right-click and select Markers->
Remove All from the popup menu.
March 2014 969
4. To use markers to locate an object, see the procedure described in
Finding Physical Analyst Objects by Their Locations, on page 966.
5. Do the following to use markers for measuring distances:
To measure the distance from a marker to the cursor location, select
the marker and position the cursor. The status bar at the bottom of
the Physical Analyst view displays the manhattan distance (X+Y)
between the two points, calculated in microns. It also displays the XY
coordinates for the cursor.
To measure the distance between two markers, select two markers.
The distance is displayed in the status bar. If you have more than two
markers selected, the distance is not calculated.
6. To navigate from one marker to another, do the following:
To advance to the next marker, right-click and select Markers->Go to
Next from the popup menu, or use the F2 key.
To go to the previous marker, right-click and select Markers->Go to
Previous from the popup menu or use the Shift+F2 keys.
The sequence for the markers is the order in which they were created. If
the view is zoomed, the selected marker is centered in the view.
Identifying Encrypted IP Objects in Physical Analyst
You can use the Physical Analyst to identify cells that belong to an encrypted
IP. When a cell belongs to an encrypted IP, it is implemented as the type LUT.
To view objects that might belong to encrypted IPs in the Physical Analyst
view, perform the following tasks:
1. Select the cell.
2. Right-click and select Properties (Core Cell) from the popup menu.
3. Notice that the Type property is set to LUT in the dialog box.
LO
970 March 2014
Crossprobing in Physical Analyst Chapter 19: Analyzing Designs in Physical Analyst
March 2014 971
Crossprobing in Physical Analyst
Crossprobing is the process of selecting an object in one view and having the
object or the corresponding logic automatically highlighted in other views.
The Physical Analyst responds to incoming cross probes as well as sending
out cross probes in response to selections.
For details, see
Crossprobing from the Physical Analyst View, on page 971
Crossprobing from a Text File to Physical Analyst, on page 974
Crossprobing from the RTL View to Physical Analyst, on page 975
Crossprobing from the Technology View to Physical Analyst, on
page 977
Crossprobing from the Physical Analyst View
1. Set crossprobing options.
To crossprobe automatically from the Physical Analyst view, check
that View->Send Crossprobes when selecting is enabled.
To crossprobe only on demand, disable View->Send Crossprobes when
selecting. This can be more efficient with large designs.
2. To crossprobe to different files and views, follow the appropriate steps:
To Crossprobe to ... Procedure
Source code Make sure that View->Crossprobing->Crossprobing to HDL
Source is enabled.
In the Physical Analyst view, double-click the object
you want to crossprobe.
If the source code file is not open, a Text Editor window
opens to the appropriate section of code (for example,
modules or instances). If the source file is already open,
the software scrolls to the correct section of the code
and highlights it.
LO
Chapter 19: Analyzing Designs in Physical Analyst Crossprobing in Physical Analyst
972 March 2014
RTL view Open the RTL view.
Make sure the crossprobing options (see step 1) are set
for your needs.
In the Physical Analyst view, select the object you want
to crossprobe. The software highlights the
corresponding object in the RTL view.
Technology view Open the Technology view.
Make sure the crossprobing options (see step 1) are set
for your needs.
In the Physical Analyst view, select the object you want
to crossprobe. The software highlights the
corresponding object in the Technology view.
To Crossprobe to ... Procedure
March 2014 973
The following shows on-demand crossprobing from the Physical Analyst view:
LO
974 March 2014
Crossprobing from a Text File to Physical Analyst
Instances from a text file, such as the HDL source code (Verilog/VHDL) or log
file (srr) can be highlighted in the Physical Analyst. Make sure the Physical
Analyst view is already open.
1. Open the Physical Analyst view.
2. In the text file, highlight the appropriate portion of the text, like the
hierarchical instance name.
For some objects in source code files, you might have to select an entire
block of text.
3. Crossprobe the object.
To show only the object selected, click the Filter Schematics icon in the
toolbar.
Right-click in the text file and select Select in Analyst from the popup
menu.
4. Check the Physical Analyst view.
The selected instances are highlighted in this view. If the selected object
does not have visibility enabled for it in the Control panel, the visibility
will be automatically enabled.
March 2014 975
5. If needed, use the Reset filter icon to re-display the unfiltered objects, if
you filtered the view in step 3.
Crossprobing from the RTL View to Physical Analyst
Follow this procedure to crossprobe from the RTL view to the Physical Analyst
view.
2. Enable the View->Cross Probing->Cross Probing from RTL Analyst option.
3. Click the object (instance or macro) in the RTL view to highlight and
crossprobe it. You can use the schematic view, hierarchy browser, or the
Object Query dialog box to select the object.
Physical Analyst View
Log File
LO
976 March 2014
You can cross probe hierarchical objects in the RTL view to the set of
objects for which the hierarchy is synthesized in the Physical Analyst
view. You cannot cross probe primitives in the RTL view which do not
have a counterpart in the mapped netlist. The tool highlights all objects
relating to the RTL object. For example, if you selected a module, all
mapped objects with physical information that implement the module in
the Physical Analyst view are highlighted.
HDL Analyst View
Core cell va_start_byte_add[8:0]
View
Physical Analyst
March 2014 977
Crossprobing from the Technology View to Physical Analyst
Follow this procedure to crossprobe from the RTL view to the Physical Analyst
view.
2. Enable the View->Cross Probing->Cross Probing from Tech Analyst option.
3. Click the object in the Technology view to highlight and crossprobe. You
can use the schematic view, hierarchy browser, or the Object Query dialog
box to select the object.
When you select an instance in the Technology view, the placed primi-
tive that corresponds to that instance in the Physical Analyst is
highlighted.
4. To automatically route cross-probed instances, enable the View->Cross
Probing->Auto route cross probe insts option (the option is enabled by
default).
The following shows cross probing from the Technology view to the
Physical Analyst view when this option is enabled.
LO
978 March 2014
Technology View
Physical Analyst View
Analyzing Netlists in Physical Analyst Chapter 19: Analyzing Designs in Physical Analyst
March 2014 979
Analyzing Netlists in Physical Analyst
In the Physical Analyst view, there are a number of commands for tracing
logic and analyzing the netlist, which can be accessed from the right-click
popup menus. These commands are context-sensitive, depending on the
selected object and where you click. See Chapter 4, User Interface Commands
of the Reference Manual for a complete list of View menu and Physical Analyst
popup menu commands.
Filtering the Physical Analyst View, on page 979
Expanding Pin and Net Logic in Physical Analyst, on page 980
Expanding and Viewing Connections in Physical Analyst, on page 985
Filtering the Physical Analyst View
Filtering is a useful first step in analysis, because you can focus on the
relevant parts of the design. Some commands, like the Expand Paths
commands, automatically generate filtered views. This procedure only
discusses manual filtering, where you use the Filter command to isolate
selected objects.
1. Select the objects that you want to isolate.
2. Select the filter command, using one of these methods:
Select Filter->Show Selected from the Physical Analyst View menu or
from the right-click popup menu.
Click the Filter Schematics icon ( ).
Press Alt and draw a narrow V-shaped mouse stroke in the schematic
window. See Help->Mouse Stroke Tutor for an illustration.
The software filters the design and displays the selected objects in a
filtered view. You can now analyze the objects and perform operations
like tracing paths, building up logic, filtering further, finding objects,
hiding objects, or crossprobing.
3. To return to the previous view, click the Back ( ) icon.
LO
Chapter 19: Analyzing Designs in Physical Analyst Analyzing Netlists in Physical Analyst
980 March 2014
Expanding Pin and Net Logic in Physical Analyst
When you are working in a filtered view, you might need to include more logic
in your selected set to analyze your design. This section describes commands
that expand logic fanning out from pins or nets; to expand paths, see
Expanding and Viewing Connections in Physical Analyst, on page 985.
Use the Expand commands with the Filter and Nets->Visible commands to isolate
and connect the logic that you want to examine.
1. To expand logic from a pin, do the following in the Physical Analyst view.
To view ... Do this ...
All cells connected
to a pin
Select a pin on the cell instance.
Right-click and select Expand->Selected Pins. See
Expanding Logic Example, on page 981.
If you change your selection to all output pins, all input
pins, or all pins, you can use the same command to
expand from these points.
All cells that are
connected to a pin,
up to the next
register/port
Select a pin on the cell instance.
Right-click and select Expand to Register/Port->Selected
Pins. See Expanding Logic to Register/Port Example,
on page 982.
If you change your selection to all output pins, all input
pins, or all pins, you can use the same command to
expand to registers and ports from these points.
March 2014 981
Expanding Logic Example
LO
982 March 2014
Expanding Logic to Register/Port Example
March 2014 983
2. To expand logic from a net, use the commands shown in the following
table.
To ... Do this ...
Select all instances on
a net
Select a net and select Select Net Instances->All Pins.
The software shows an unfiltered view that includes
all the instances connected to the net along the
signal path.
You can also choose to show output pins or input
pins with this command.
See the following example.
Highlight all visible
instances on a net
Select a net and select Highlight Visible Net Instances->All
Pins. You see a filtered view of all instances
connected to the selected net along the signal path.
You can also select to show output pins or input
pins.
Select the net driver Select a net and select Select Net Driver. The software
shows an unfiltered view that includes the driver of
the net.
Go to the net driver Select a net and select Go to Net Driver. The software
shows and scrolls to the driver of the net.
LO
984 March 2014
This example shows instances on a critical path. First, the critical path
was filtered. Then one of the nets on the critical path selected and the
Select Net Instances->All Pins selected. The figure shows the results.
March 2014 985
Expanding and Viewing Connections in Physical Analyst
This section describes commands that expand logic between two or more
objects. To expand logic out from a net or pin, see Expanding Pin and Net
Logic in Physical Analyst, on page 980. You can also isolate the critical path
or use the Timing Analyst to generate a schematic for a path between objects,
as described in Using Auto Constraints, on page 469.
Use the following path commands with the Filter and Nets->Visible commands to
isolate and connect the logic that you want to examine.
To expand and view connections between selected objects, do the following:
1. Select two or more objects.
2. To expand the logic, select Expand Paths->All Pins from the popup menu.
Alternatively, you can select to expand from selected pins.
LO
Chapter 19: Analyzing Designs in Physical Analyst Using Implementation Maps in Physical Analyst
986 March 2014
Using Implementation Maps in Physical
Analyst
Currently, the Implementation Maps are a Beta feature in the Physical
Analyst tool.
Physical Analyst can display color-coded maps which overlay the device
providing information about the design after it has been synthesized. The
following Implementation Maps are available in the Synplify Premier Physical
Analyst tool for Xilinx devices:
Routing Congestion
Block Utilization
Block Inputs
Slack
To bring up the implementation maps:
1. Open the Physical Analyst view ( ).
2. Click on the Maps tab in the Physical Analyst control panel.
Using Implementation Maps in Physical Analyst Chapter 19: Analyzing Designs in Physical Analyst
March 2014 987
3. Select the type of map to display from Select Map pull-down menu on the
Physical Analyst control panel.
You can choose:
None - No maps are displayed in the Physical Analyst view.
Routing Congestion - See Using the Routing Congestion Map, on
page 989
Block Component Utilization - See Using the Block Component Utilization
Map, on page 991
Block Input Utilization - See Using the Block Input Utilization Map, on
page 992
Slack Distribution - See Using the Slack Distribution Map, on page 993
4. You can use these maps in conjunction with congestion or utilization
map controls and settings. For more information, see Implementation
Maps Controls and Settings, on page 988.
LO
988 March 2014
5. You can crossprobe from any implementation map to the HDL Analyst
view. For more information, see Crossprobing from Implementation Maps,
on page 995.
Implementation Maps Controls and Settings
The implementation maps include the following controls and settings on the
Maps control panel:
Display mode
Slider scale
Histogram
Two display modes are available. When you enable Show visible design objects,
both the map and instances are displayed in the Physical Analyst view.
Otherwise, only the map without instances is shown. Show visible design objects
is turned off by default.
Two slider scale modes are available; they are Linear and Log.
In the Linear mode, the threshold and alert sliders and histograms move
at a linear rate. The Linear mode is the default setting.
In the Log mode, the threshold and alert sliders and histograms move
at a logarithmic rate.
The Threshold and Alert sliders adjust the threshold and the alert percentage
levels, respectively, for the implementation maps. The combination of these
values is reflected in the color bar which shows a progression of colors from
the threshold level to the alert level. The thermal map uses colors ranging
from blue (cool) to red (burn); magenta is used as the alert color.
Histogram - The histograms display bar charts that shows the distribution of
routing congestion, block or input pin utilization, or slack utilization for the
design. You can select either Linear or Log mode.
March 2014 989
Using the Routing Congestion Map
The Routing Congestion map displays estimated routing congestion based on
placement. Input and output nets for each CLB contribute to routing
demands for the design as compared to the routing resources of the
technology. Routing congestion areas most likely will cause detours for
routing the design. Use the routing congestion map to give you quick
feedback on how likely this design can be routed using the back-end tool. The
colors of the map alert you to potential congestion and routing problems you
might encounter.
To display the Routing Congestion map, select Routing Congestion from the
drop-down menu on the control panels Maps pane. When routing congestion
is selected, the routing congestion map is displayed and tool tips reporting
the congestion for cell locations are available. You can zoom in or out of this
view at any time.
LO
990 March 2014
The thermal map for congestion applies the following conditions:
Threshold percentage value is fixed at 40 and Alert percentage value is
fixed at 49. You cannot use the slider to change the limits.
Thermal map displays the following colors:
Congestion value of 0 is black
Congestion values between 1 and 40 use the coolest color of dark
blue
Congestion values between 40 and 49 use thermal colors that range
from dark blue to red
Congestion values greater than 49 use the alert color of magenta
March 2014 991
Use the tool tip to display the severity for the congestion.
<40Low
40-45Med
>45High
Using the Block Component Utilization Map
The Block Component Utilization map provides visual and analytical display
of the percentage of utilization for each CLB in the placeable area. The block
utilization data is available after the synthesis tool places the design.
To display the Block Utilization map, open the Physical Analyst and select
Block Utilization from the drop-down menu on the control panels Maps pane.
When Block Utilization is selected, the block utilization map is displayed and
tool tips reporting the percentage of utilization for each CLB are available.
You can zoom in or out of this view at any time.
LO
992 March 2014
The thermal map for block utilization fixes the Threshold percentage value at 0
and Alert percentage value at 100. You cannot use the slider to change the
limits.
Using the Block Input Utilization Map
The Block Input Utilization map provides visual and analytical display of the
number of input pins for each CLB in the placeable area. The block input pin
data is available after the synthesis tool places the design.
March 2014 993
To display the Block Inputs map, open the Physical Analyst and select Block
Inputs from the drop-down menu on the control panels Maps pane. When Block
Inputs is selected, the block input pins map is displayed and tool tips reporting
the number of input pins used for each CLB location are available. You can
zoom in or out of this view at any time.
The thermal map for block inputs fixes the Threshold percentage value at 40
and Alert percentage value at 49. You cannot use the slider to change the
limits.
Using the Slack Distribution Map
The Slack map provides visual and analytical display of the instances with
slack values between 2.0 ns and -2.3237 ns. Use the threshold and alert
limits to adjust the display for slack values within these specified limits. The
available instance slack is displayed after the design is synthesized.
LO
994 March 2014
To display the Slack Distribution map, open the Physical Analyst and select
Slack Distribution from the drop-down menu on the control panels Maps pane.
When Slack Distribution is selected, the slack map is displayed and tool tips
reporting information about the core cell and its corresponding slack value
are included. You can zoom in or out of this view at any time.
March 2014 995
Crossprobing from Implementation Maps
Crossprobing is feasible from any of the implementation maps.
1. Bring up any of the implementation maps from the Physical Analyst
view: Congestion map, block utilization map, block inputs map, or slack
map.
2. Turn on the Show visible design objects option, so that instance locations
are displayed in the Physical Analyst view as well.
3. Zoom in to a hot spot region. Select an instance or instance region.
LO
996 March 2014
4. Open the HDL Analyst RTL or Technology view. Then, select Filter
Schematic ( ).
March 2014 997
CHAPTER 20
Optimizing for Specific Targets
This chapter covers techniques for optimizing your design for various
vendors. The information in this chapter is intended to be used together with
the information in Chapter 10, Inferring High-Level Objects.
This chapter describes the following:
Optimizing Altera Designs, on page 998
Optimizing Lattice Designs, on page 1010
Optimizing Lattice iCE40 Designs, on page 1024
Optimizing Microsemi Designs, on page 1027
Optimizing Xilinx Designs, on page 1032
LO
Chapter 20: Optimizing for Specific Targets Optimizing Altera Designs
998 March 2014
Optimizing Altera Designs
This section includes some Altera technology-specific tips for optimizing your
design. These tips are in addition to the general guidelines described in Tips
for Optimization, on page 576. This section discusses the following topics that
are specific to Altera technologies:
Working with Altera PLLs, on page 998
Specifying Altera I/O Locations, on page 1001
Packing I/O Cell Registers in Altera Designs, on page 1001
Specifying HardCopy and Stratix Companion Parts, on page 1003
Specifying Core Voltage in Stratix III Designs, on page 1004
Using LPMs in Simulation Flows, on page 1005
Improving Altera Physical Synthesis Performance, on page 1007
Working with Quartus II, on page 1007
In addition, you can use the techniques described in these other topics,
which apply to other vendors as well as Altera:
Defining Black Boxes for Synthesis, on page 490
Initializing RAMs, on page 554
Inferring Shift Registers, on page 559
Working with LPMs, on page 565
Passing Information to the P&R Tools, on page 1092
Generating Vendor-Specific Output, on page 1096
Working with Altera PLLs
The synthesis software recognizes the Altera PLL component, altpll, from the
Stratix, Cyclone, and Arria GX device families. The following procedure shows
you how to use this component in your designs. The procedure uses the
Altera Megafunction wizard to generate structural VHDL or Verilog files for
the Altera PLLs.
Optimizing Altera Designs Chapter 20: Optimizing for Specific Targets
March 2014 999
1. If you are using VHDL, the altpll component normally will be declared in
the MegaWizard file, and you can comment out the LIBRARY and USE
clauses in the file. The following shows an example of the lines to be
commented out:
LIBRARY altera_mf;
USE altera_mf.altera_mf_components.all;
If the component declaration in the MegaWizard file is not compatible
with a particular Quartus software version, use the appropriate vhd file
packaged with the Synopsys software in the corresponding
lib/altera/quartus_IInn directory. For example, the altera_mf.vhd file for use
with Quartus 10.1 is in the quartus_II101 subdirectory.
2. If you are using Verilog, no action is necessary as the mapper
understands the altpll component.
For compatibility with different Quartus versions, altera_mf.v files are
packaged with the software in the lib/altera/quartus_IInn directory. Use the
file from the directory that corresponds to the Quartus version that you
are using.
3. Instantiate the altpll component in your design.
4. Add the MegaWizard Verilog or VHDL files to your project.
5. Open SCOPE and define the PLL input frequency in the SCOPE window.
The synthesis software does not use the input frequency from the Altera
MegaWizard software. Based on the input value you supply, the software
generates the PLL outputs. All PLL outputs are assigned to the same
clock group.
6. Set the target technology and the Quartus version (Implementation
Options->Implementation Results), and synthesize as usual. The software
uses the altpll component information and the constraints when
synthesizing your design. The synthesis software forward-annotates the
PLL input constraints to Quartus.
Instantiating Special Buffers as Black Boxes in Altera Designs
You can instantiate special buffers, like global buffers for clocks, sets/resets,
and other heavily loaded signals, as black boxes in your design. See the Altera
documentation for details about special buffers and the number of resources
available for the part you are using.
LO
1000 March 2014
1. Define a black-box module for your special buffer with the syn_black_box
directive.
See the examples below and syn_black_box, on page 91 in the Reference
Manual for syntax details.
2. Use this black-box module to buffer the signals you want assigned to
special buffers.
3. Synthesize the design and place-and-route as usual.
The Altera tools accept the black box.
Verilog Example of Instantiating Special Buffers as Black Boxes
module global(a_out, a_in) /* synthesis syn_black_box */ ;
output a_out;
input a_in;
/* This continuous assignment is used for simulation,
but is ignored by synthesis. */
assign a_out = a_in;
endmodule
module top(clk, pad_clk) ;
output pad_clk;
input clk;
// pad_clk is the primary input
global clk_buf(pad_clk, clk);
endmodule
VHDL Example of Instantiating Special Buffers as Black Boxes
library ieee;
library synplify;
entity top is
port (clk : out std_logic;
pad_clk : in std_logic);
end top;
architecture structural of top is
-- In this example, "global" is an Altera vendor macro directly
-- instantiated in the Altera VHDL design as a black box.
March 2014 1001
component global
port(a_out : out std_logic; a_in : in std_logic) ;
end component;
-- Set the syn_black_box attribute on global to true.
attribute syn_black_box of global: component is true;
-- Declare clk, the internal global clock signal
begin
-- pad_clk is the primary input
clk_buf: global port map (clk, pad_clk);
end structural;
Specifying Altera I/O Locations
You can specify I/O locations in Altera designs using the syn_loc attribute. If
you do not specify I/O locations, the P&R tool automatically assigns them
locations.
1. If you used the QSF2SDC utility, to translate Altera QSF
set_location_assignment and set_instance_assignment constraints, do nothing.
The utility automatically assigns the syn_loc attribute to the pins with
constraints.
2. To define an I/O location manually, use the following syntax:
Packing I/O Cell Registers in Altera Designs
You can improve input or output path timing in designs by packing registers
into I/O cells with the syn_useioff attribute.
1. To pack the registers globally, set syn_useioff=1 on the top-level module or
architecture. Specify the attribute in the source code, the SCOPE
interface, or directly in the constraint file.
Top-level sdc file define_attribute {portName} syn_loc {pinNumbers}
Verilog object /* synthesis syn_loc = "pinNumbers" */
VHDL attribute syn_loc of object : objectType is "pinNumbers"
LO
1002 March 2014
2. To set the attribute locally, set syn_useioff=1 on a port.
The order of precedence used when there are conflicts for packing is
registers, followed by ports, and finally global.
If syn_useioff is enabled for Arria GX and Stratix families, registers are not
packed into Multiply/Accumulate (MAC) blocks.
The syn_useioff attribute is supported in the compile point flow.
Format Example
Verilog module test(d, clk, q) /* synthesis syn_useioff=1 */;
VHDL architecture rtl of test is
attribute syn_useioff : boolean;
attribute syn_useioff of rtl : architecture is true;
Constraint
file syntax
define_global_attribute syn_useioff 1
Format Example
Verilog module test(d, clk, q);
input [3:0] d;
input clk;
output [3:0] q /* synthesis syn_useioff=1 */;
reg q;
VHDL entity test is
port (d : in std_logic_vector (3 downto 0);
clk : in std_logic;
q : out std_logc_vector (3 downto 0);
attribute syn_useioff of q : signal is true;
end test;
Constraint file
syntax
define_attribute {p:q[3:0]} syn_useioff 1
March 2014 1003
Specifying HardCopy and Stratix Companion Parts
For Stratix II, Stratix III, and Stratix IV devices, you can specify an associated
HardCopy II, HardCopy III, or HardCopy IV companion part to allow you to
migrate from Stratix to HardCopy in Quartus. By default, no companion part
is specified for a Stratix device family. However, for a HardCopy device family,
a Stratix companion part must be specified.
You select the companion device in the Device tab of the Implementation Options
dialog box as in the following example:
You can use any of the following methods to specify companion parts:
Select the companion device in the Device tab of the Implementation Options
dialog box as shown here:
Use this Tcl command, where partName is the part name and number:
set_option -part_companion partName
LO
1004 March 2014
When you specify a companion part, the mapper targets the device with the
least resources. For example, if your Stratix device has five memories and the
companion HardCopy device has four memories, the mapper only uses four
memory resources and maps the rest to logic.
Specifying Core Voltage in Stratix III Designs
For some Stratix III devices, you can specify core voltage. Do the following:
1. Click Implementation Options and do the following:
On the Device tab, set Technology to a Stratix III device.
Set Speed to -4.
This makes the Core Voltage option available.
2. Set Core Voltage to the value you want, and click OK.
Alternatively, you can use the corresponding Tcl command: set_option
-voltage voltageValue.
For example:
set_option -voltage 1.1V
set_option -voltage none
March 2014 1005
Using LPMs in Simulation Flows
This section describes how to use instantiated LPMs in simulation flows. For
information about instantiating LPMs, see Working with LPMs, on page 565.
Simulation Flows
The simulation flows vary, depending on the method used to instantiate the
LPMs. For information about instantiating LPMs, see Instantiating Altera
LPMs Using VHDL Prepared Components, on page 570, Instantiating Altera
LPMs as Black Boxes, on page 566, and Instantiating Altera LPMs Using a
Verilog Library, on page 572. The following table summarizes the differences
between the flows:
Black Box Method Simulation Flow
Use the following flow when you instantiate LPMs as Verilog or VHDL black
boxes. You can use this procedure for any LPM supported by Altera.
1. Use the Altera MegaWizard Plug-In Manager to create an LPM
megafunction with the same module and port names as the black-box
module in your synthesis design.
Black Box Flow Verilog Library/VHDL
Prepared Component Flows
Applies to any LPM Yes No
Synthesis LPM timing
support
No Yes
Synthesis procedure Many steps Simple
RTL simulation Complicated steps Easy
Post-synthesis (.vm)
simulation
Yes No
Post-P&R (.vo) simulation Yes Yes
Software version Any version
Max+PlusII
Quartus II 1.0 or
earlier
Quartus II 1.1 or later
LO
1006 March 2014
2. Compile the following:
Test bench
The design (RTL, post-synthesis vm file, or the post-P&R vo file)
The v file you generated in the previous step
3. Compile the LPM megafunction simulation model: 220model.v or
altera_mf.v.
4. For vm or vo simulation, compile the primitive simulation model.
5. Simulate the design.
Library/Prepared Component Simulation Flow
Use this simulation procedure when you use a Verilog library or VHDL
prepared components to instantiate the LPMs. You can use this flow for vo
simulation if your design contains the supported LPMs.
1. Instantiate the LPMs.
For VHDL designs, use the prepared components methods described
in Instantiating Altera LPMs Using VHDL Prepared Components, on
page 570 or Instantiating Altera LPMs as Black Boxes, on page 566.
For Verilog designs, use the library methods described in
Instantiating Altera LPMs Using a Verilog Library, on page 572 or
Instantiating Altera LPMs as Black Boxes, on page 566.
2. Compile the test bench and design. The design can be either RTL or the
post-P&R vo file.
3. Compile the LPM megafunction simulation model: 220model.v or
altera_mf.v.
4. For vo simulation, compile the primitive simulation model. For example
apex20Ke_atoms.v.
5. Simulate the design.
March 2014 1007
Improving Altera Physical Synthesis Performance
The Synplify Premier tool is timing-driven; optimizations depend on timing
constraints and are applied until all constraints are met. Therefore, it is very
important that you adequately apply timing constraints and not over-
constrain the tool. This section includes guidelines for applying constraints.
Verify the consistency of constraints between synthesis and P&R:
Clock constraints
Clock-to-clock constraints
IO delays
Max-delay paths
DCM parameters
Register packing into IOB
SYN_LOC on IO pins and pad types
Placement constraints on instances
Ensure that the final physical synthesis slack is negative, but no more
than 10-15% of the clock constraint.
Working with Quartus II
The following procedures show you how to use the synthesis information to
run Quartus II in an integrated mode with the Synopsys FPGA synthesis tool,
directly from the synthesis interface, or in a standalone batch mode. Each
procedure assumes that you have set the QUARTUS_ROOTDIR environment
variable to point to your Quartus II installation directory. After synthesis, the
Verilog netlist (vqm), forward annotated timing constraints and pin assign-
ments (tcl/scf) are placed in the named Quartus project.
Integrated Mode
To run Quartus II in an integrated mode:
1. In the project view, click the Add P&R Implementation button to display the
Add New Place & Route Job dialog box.
LO
1008 March 2014
2. Optionally assign a P&R job name and click OK. The job is displayed in
the project view under the active implementation.
3. Right click on the RTL source file and select File Options to display the File
Properties dialog box.
4. In the File type field drop-down menu, select either Clearbox Verilog or
Clearbox VHDL according to the RTL file type and then click OK.
5. Click the Run button; the clearbox netlist is copied to the PR_1 directory,
the design is synthesized, and then placed and routed.
Synthesis Interface
To place and route interactively from the synthesis interface, select Quartus II->
Launch Quartus from the Options menu. This command opens the Quartus II
GUI and automatically runs Quartus II with the project settings from the
March 2014 1009
synthesis run. You can monitor placement and routing as it progresses, see
errors and warning messages, check what percentage of the job has
completed, and execute other Quartus II commands.
Batch Mode
To run Quartus II in batch mode, select Quartus II->Run Background Compile from
the Options menu. This command runs place and route using the default
Quartus settings and the information in the projectName_cons.tcl and project-
Name.tcl files to set up and compile the Quartus project and to read the
forward-annotated information from the prior synthesis run. Quartus log files
are updated with placement, routing, and timing data as the design compiles.
LO
Chapter 20: Optimizing for Specific Targets Optimizing Lattice Designs
1010 March 2014
Optimizing Lattice Designs
The Synplify and Synplify Pro synthesis tools include support for Lattice
technologies. This section describes the following techniques for working with
Lattice designs:
Instantiating Lattice Macros, on page 1010
Using Lattice GSR Resources, on page 1012
Inferring Carry Chains in Lattice XPLD Devices, on page 1013
Inferring Lattice PIC Latches, on page 1013
Controlling I/O Insertion in Lattice Designs, on page 1021
Forward-Annotating Lattice Constraints, on page 1022
For additional information about working with Lattice designs, see Passing
Information to the P&R Tools, on page 1092 and Generating Vendor-Specific
Output, on page 1096.
Instantiating Lattice Macros
You can instantiate Lattice macros that are predefined in the Lattice libraries
that come with the tool, in the installDirectory/lib directory.
1. To use a Verilog macro library, add the appropriate library to your
project, making sure that it is the first file in the source files list.
The Verilog macro libraries are under the installDirectory/lib directory: Add
the library appropriate to the technology and language (v or vhd) you are
using
ORCA device
families
installDirectory/lib/lucent/orca*
Replace the asterisk with either 2, 3, or 4, according to the
ORCA series you are using
LatticeXP device
families
installDirectory/lib/lucent/xp
installDirectory/lib/lucent/xp2
installDirectory/lib/lucent/xp3
LatticeSC/SCM
device families
installDirectory/lib/lucent/sc
installDirectory/lib/lucent/scm
Optimizing Lattice Designs Chapter 20: Optimizing for Specific Targets
March 2014 1011
2. To use a VHDL macro library, add the appropriate library and use clauses
to your VHDL source code at the beginning of the design units that
instantiate the macros.
You only need the VHDL macro libraries for simulation, but it is good
practice to add them to the code. The library names may vary,
depending on the map file name, which is often user-defined. The
simulator uses the map file names to point to a library.
MachXO device
families
installDirectory/lib/lucent/machxo
installDirectory/lib/lucent/machxo2
ECP/EC device
families
installDirectory/lib/lucent/ec
installDirectory/lib/lucent/ecp
installDirectory/lib/lucent/ecp2
nstallDirectory/lib/lucent/ecp3
ispXPGA devices installDirectory/lib/lattice/lava1
CPLD devices installDirectory/lib/cpld/lattice
CPLD devices library lattice;
use lattice.components.all;
ORCA device
families
Replace the asterisk with the series number (2, 3, or 4) for
the Lattice ORCA Series 2, Series 3, or Series 4 macro
library you are using.
library orca*;
use orca*.orcacomp.all;
LatticeXP device
families
library xp;
use xp.components.all
library xp2;
library xp3;
LatticeSC/SCM
device families
library sc;
use sc.components.all
library scm;
use sc.components.all
LO
1012 March 2014
3. Instantiate the macros from the library as described in Instantiating
Black Boxes and I/Os in Verilog, on page 490 and Instantiating Black
Boxes and I/Os in VHDL, on page 492.
Using Lattice GSR Resources
The following procedure describes how to use GSR (global set/reset)
resources and check resource usage. The GSR resource is a prerouted signal
that connects to the reset input of every flip-flop, regardless of any other
defined reset signals.
1. For the LatticeECP/ECP2/EC, LatticeXP2/XP, LatticeSC/SCM,
MachXO, and ORCA families, you can control the use of GSR resources
as follows:
To improve routability and performance, use the dedicated GSR
resource. Select Project ->Implementation Options and enable the Force
GSR Usage option on the Device tab.
When you set this option, the synthesis software creates a GSR
instance to access the resource. It uses the GSR resource for reset
signals, instead of general routing. All registers are reset. when the
GSR is activated, even if some flip-flops do not have a reset.
If a global set/reset does not correctly initialize the design, turn off
the option. Select Project ->Implementation Options and disable the Force
MachXO device
families
library machxo;
use machxo.components.all
library machxo2;
use machxo.components.all
ECP/EC device
families
library ec;
use ec.components.all
library ecp;
use ecp.components.all;
library ecp2;
use ecp2.components.all;
library ecp3;
use ecp2.components.all;
ispXPGA device
families
library lava;
use lava.components.all;
March 2014 1013
GSR Usage option on the Device tab. When this option is off, the
software does not use the GSR resource unless all flip-flops have
resets, and all resets use the same signal.
2. To optimize area, set the Resource Sharing option, as described in Sharing
Resources, on page 602.
3. To check resource usage, do the following:
Select View Log and check the Resource Usage section. For ORCA
families, you can compare the LUTs in the synthesis usage report to
the occupied PFUs (function units) in the report generated after
placement and routing. Each PFU consists of four 4-input LUTs and
four registers. An occupied PFU means that least one LUT or register
was used.
Inferring Carry Chains in Lattice XPLD Devices
For XPLD devices, you can control the inference of carry chains with the
syn_use_carry_chain attribute. By default, all counters are implemented as
carry chains when they are over 4 bits wide. To override this, set the
syn_use_carry_chain attribute with a value of 0 on the registers of the counter or
adder.
Inferring Lattice PIC Latches
The following procedure shows you how to control the inference of program-
mable I/O cells (PICs) in Lattice designs.
1. For the software to automatically infer PICs, make sure of the following:
The latch must be at the input port.
The latch must be directly driven by the input FPGA pad.
The design has one of the supported input control schemes: no clear
or reset controls, and asynchronous clear or asynchronous resets.
LO
1014 March 2014
After synthesis, the tool implements the following primitives for the
PICs:
See Examples of PIC Latches, on page 1015 for examples of inferred PIC
latches.
2. If you do not want to infer a PIC, set syn_keep on the input data net for
the latch.
After synthesis, the tool implements the latch as either a core latch with
the LATCH primitive or as a mux, depending on the Lattice technology
you selected. The following figure shows an input latch with no reset or
clear implemented as a mux and a core latch in different technologies.
IF1S1D Latches with asynchronous clear
Latches with GSR used for clear
IF1S1B Latches with asynchronous reset
Latches with GSR used for reset.
March 2014 1015
Examples of PIC Latches
The following examples show how the tool infers PICs from the code:
Positive Level Data Latch with No Resets or Clears, on page 1016
Negative Level Data Latch with No Resets or Clears, on page 1017
Positive Level Data Latch with Asynchronous Reset, on page 1018
Positive Level Data Latch with Asynchronous Clear, on page 1020
With syn_keep: Implemented as Mux
With syn_keep: Implemented as Core Latch
LO
1016 March 2014
Positive Level Data Latch with No Resets or Clears
With this code, the tool implements the IFS1S1B latch primitive in the
Technology view:
VHDL library ieee;
entity inlatch is port
(clk : in std_logic;
din : in std_logic;
dout: out std_logic);
end entity inlatch;
architecture bhve of inlatch is
begin
process(clk,din)
begin
if clk='1' then
dout <= din;
end if;
end process;
end bhve;
Verilog module inlatch (clk,din,dout);
input clk; input din; output dout;
reg dout;
always @(clk)
begin
if(clk)
dout <= din;
end
endmodule
March 2014 1017
Negative Level Data Latch with No Resets or Clears
VHDL library ieee;
(clk : in std_logic;
din : in std_logic;
dout: out std_logic);
end entity inlatch;
begin
process(clk,din)
begin
if clk='0' then
dout <= din;
end if;
end process;
end bhve;
Verilog module inlatch (clk,din,dout);
input clk; input din; output dout;
reg dout;
always @(clk)
begin
if(!clk)
dout <= din;
end
endmodule
LO
1018 March 2014
With this code, the tool implements the IFS1S1B latch primitive in the
Technology view:
Positive Level Data Latch with Asynchronous Reset
The tool infers the IFS1S1B latch primitive in the Technology view with the
code shown below:
March 2014 1019
VHDL library ieee;
(clk : in std_logic; aset: in std_logic;
din : in std_logic; dout: out std_logic);
end entity inlatch;
begin
process(clk,din,aset)
begin
if aset ='1' then
dout <='1';
elsif clk='1' then
dout <= din;
end if;
end process;
end bhve;
Verilog module inlatch(clk,din,aset,dout);
input clk; input din; input aset; output dout;
reg dout;
always @(clk or aset)
begin
if(aset)
dout <= 1'b1;
else if (clk)
dout <= din;
end
endmodule
LO
1020 March 2014
Positive Level Data Latch with Asynchronous Clear
With this code, the tool infers the IFS1S1D primitive in the Technology view:
VHDL library ieee;
(clk : in std_logic; aclr: in std_logic;
din : in std_logic; dout: out std_logic); }
end entity inlatch;
begin
process(clk,din,aclr)
begin
if aclr ='1' then
dout <='0';
elsif clk='1' then
dout <= din;
end if;
end process;
end bhve;
Verilog module inlatch(clk,din,aclr,dout);
input clk; input din; input aclr; output dout;
reg dout;
always @(clk or aclr)
begin
if(aclr)
dout <= 1'b0;
else if (clk)
dout <= din;
end
endmodule
March 2014 1021
Controlling I/O Insertion in Lattice Designs
You can control I/O insertion globally, or on a port-by-port basis.
1. To control the insertion of I/O pads at the top level of the design, use the
Disable I/O Insertion option as follows:
Select Project->Implementation Options and click the Device panel.
If you do not want to insert any I/O pads in the design, enable Disable
I/O Insertion
Do this if you want to check the area your blocks of logic take up,
before you synthesize an entire FPGA. If you disable automatic I/O
insertion, you do not get any I/O pads in your design, unless you
manually instantiate them.
If you want to insert I/O pads, disable the Disable I/O Insertion option.
When this option is set, the software inserts I/O pads for inputs,
outputs, and bidirectionals in the output netlist. Once inserted, you
can override the I/O pad inserted by directly instantiating another
I/O pad.
2. To force I/O pads to be inserted for input ports that do not drive logic,
follow the steps below.
To force I/O pad insertion at the module level, set the syn_force_pads
attribute on the module. Set the attribute value to 1. To disable I/O
pad insertion at the module level, set the syn_force_pads attribute for
the module to 0.
LO
1022 March 2014
To force I/O pad insertion on an individual port, set the
syn_force_pads attribute on the port with a value to 1. To disable I/O
insertion for a port, set the attribute on the port with a value of 0.
Enable this attribute to preserve user-instantiated pads, insert pads on
unconnected ports, insert bi-directional pads on bi-directional ports
instead of converting them to input ports, or insert output pads on
unconnected outputs.
If you do not set the syn_force_pads attribute, the synthesis design
optimizes any unconnected I/O buffers away.
Forward-Annotating Lattice Constraints
You can forward-annotate multicycle and false path constraints to Lattice
place-and-route tool by following the procedure below. For additional infor-
mation about forward-annotation, see Generating Constraint Files for Forward
Annotation, on page 132.
1. To forward-annotate a from, to, or through multicycle constraint, open the
SCOPE spreadsheet and do either of the following:
Click the Multi-Cycle Paths tab. Depending on the type of constraint you
want to set, select or type the instance name under the To, From or
Through column. Next, set the number of clock cycles under the Cycles
column.
When you set this constraint, the software runs timing-driven
synthesis and then forward-annotates the constraint.
Click the Other tab. In the Command column, type define_multicycle_path.
In the Arguments column, type -from and the source port or register
name, and -to and the destination port or register name. For example:
-from in0_int -to output 2.
When you set this constraint from the Other tab, the software forward-
annotates the constraint, but does not run timing-driven synthesis
using this constraint.
2. To forward-annotate a false path constraint, open the SCOPE
spreadsheet and do either of the following:
Click the False Paths panel. Depending on the type of constraint you
want to set, select or type the instance name under the To, From or
March 2014 1023
Through column. When you set this constraint, the software runs
timing-driven synthesis and then forward-annotates the constraint.
Click the Other tab. In the Command column, type define_false_path. In
the Arguments column, type -from and the source port or register name,
and -to and the destination port or register name. For example:
When you set this constraint from the Other tab, the software forward-
annotates the constraint, but does not run timing-driven synthesis
using this constraint.
3. Select Project->Implementation Options and enable the Write Vendor Constraint
File option on the Implementation Results tab.
4. Run your design. The synthesis tool creates the $DESIGN_synplify.lpf file in
the same directory as your results files.
5. Start the Lattice ispLEVER place-and-route tool and run the Map stage
(after importing the $DESIGN_synplify.lpf file).
6. Run the PAR and BIT stages in ispLEVER.
Command Arguments
define_false_path -from in1_int -to output
define_false_path -from in* -to out*
LO
Chapter 20: Optimizing for Specific Targets Optimizing Lattice iCE40 Designs
1024 March 2014
Optimizing Lattice iCE40 Designs
This section describes the following topics when working with Lattice iCE40
designs:
Using Sequential Logic
Using Combinational Logic
Handling Tristates
Handling I/Os and Buffers
Using Sequential Logic
The synthesis software infers or instantiates the following Lattice iCE40
sequential logic depending on the control signal.
Primitive Description
SB_DFF D flip-flop
SB_DFFE D flip-flop with clock enable
SB_DFFSR D flip-flop with synchronous reset
SB_DFFR D flip-flop with asynchronous reset
SB_DFFSS D flip-flop with synchronous set
SB_DFFS D flip-flop with asynchronous set
SB_DFFESR D flip-flop with clock enable and synchronous reset
SB_DFFER D flip-flop with clock enable and asynchronous reset
SB_DFFESS D flip-flop with clock enable and synchronous set
SB_DFFES D flip-flop with clock enable and asynchronous set
SB_DFFN D flip-flop - negative edge clock
SB_DFFNE D flip-flop - negative edge clock and clock enable
SB_DFFNSR D flip-flop - negative edge clock with synchronous reset
SB_DFFNR D flip-flop - negative edge clock with asynchronous reset
SB_DFFSS D flip-flop - negative edge clock with synchronous set
Optimizing Lattice iCE40 Designs Chapter 20: Optimizing for Specific Targets
March 2014 1025
Limitations
The synthesis software does not support initial values on flip-flops for the
Lattice iCE40 technology. The Power ON state for Lattice iCE40 flip-flops is 0.
Using Combinational Logic
The synthesis software handles combinational logic as follows:
This logic is mapped to the 4-input LUT (SB_LUT4).
All data path operators (adders, subtractors, comparators, or multi-
pliers) is mapped to carry chain logic (SB_CARRY) and additional LUT4s
(SB_LUT4).
Handling Tristates
The synthesis software handles tristates as follows:
Internal tristates are not supported and are converted to MUXes
whenever possible. An error is generated if an internal tristate cannot be
converted to a MUX.
Tristates connected to an output port are absorbed into the I/O pad.
SB_DFFNS D flip-flop - negative edge clock with asynchronous set
SB_DFFNESR D flip-flop - negative edge clock, enable and synchronous
reset
SB_DFFNER D flip-flop - negative edge clock, enable and asynchronous
reset
SB_DFFNESS D flip-flop - negative edge clock, enable and synchronous
set
SB_DFFNES D flip-flop - negative edge clock, enable and asynchronous
set
Primitive Description
LO
Chapter 20: Optimizing for Specific Targets Optimizing Lattice iCE40 Designs
1026 March 2014
Handling I/Os and Buffers
The synthesis software handles I/Os and buffers as follows:
The SB_IO primitive is used for inserting I/O pads.
Since DDR inferencing is not supported, only input, output, and enable
registers are packed into the I/O pads when available.
The synthesis software does not infer SB_IO_DS, but allows for its
instantiation.
SB_GB is used for global buffers, such as clocks.
SB_GB_IO is used for external clocks and SB_GB is used for internal
clocks.
Instantiated buffers are retained as is.
Undriven pins in instantiated instances are left floating as it is in the
RTL. Input pins in the RTL should not be connected to a floating net.
The SB_WARMBOOT primitive can be instantiated and is treated as a
black box.
Optimizing Microsemi Designs Chapter 20: Optimizing for Specific Targets
March 2014 1027
Optimizing Microsemi Designs
The Synplify and Synplify Pro synthesis tools support Microsemi designs. The
following procedures Microsemi-specific design tips.
Using Predefined Microsemi Black Boxes, on page 1027
Using Smartgen Macros, on page 1028
Working with Radhard Designs, on page 1028
Specifying syn_radhardlevel in the Source Code, on page 1029
For additional Microsemi-specific information, see Passing Information to the
P&R Tools, on page 1092 and Generating Vendor-Specific Output, on
page 1096.
Using Predefined Microsemi Black Boxes
The Microsemi macro libraries contain predefined black boxes for Microsemi
macros so that you can manually instantiate them in your design. For infor-
mation about using ACTGen macros, see Using Smartgen Macros, on
page 1028. For general information about working with black boxes, see
Defining Black Boxes for Synthesis, on page 490.
To instantiate an Microsemi macro, use the following procedure.
1. Locate the Microsemi macro library file appropriate to your technology
and language (v or vhd) in one of these subdirectories under
installDirectory/lib.
Use the macro file that corresponds to your target architecture. If you
are targeting the 1200XL architecture, use the act2.v or act2.vhd macro
library.
2. Add the Microsemi macro library at the top of the source file list for your
synthesis project. Make sure that the library file is first in the list.
proasic ProASIC (PA), ProASIC
PLUS
,

ProASIC3/3E/3L,
Fusion/SmartFusion, and IGLOO/IGLOO+/IGLOOe macros
microsemi Macros for all other Microsemi technologies.
LO
Chapter 20: Optimizing for Specific Targets Optimizing Microsemi Designs
1028 March 2014
3. For VHDL, also add the appropriate library and use clauses to the top of
the files that instantiate the macros:
library family;
use family.components.all ;
Specify the appropriate technology in family; for example, act3.
Using Smartgen Macros
The Smartgen macros replace the ACTgen macros, which were available in
the previous Designer 6.x place-and-route tool. The following procedure
shows you how to include Smartgen macros in your design. For information
about using Microsemi macro libraries, see Using Predefined Microsemi Black
Boxes, on page 1027. For general information about working with black
boxes, see Defining Black Boxes for Synthesis, on page 490.
1. In Smartgen, generate the function you want to include.
2. For Verilog macros, do the following:
Include the appropriate Microsemi macro library file for your target
architecture in your the source files list for your project.
Include the Verilog version of the Smartgen result in your source file
list. Make sure that the Microsemi macro library is first in the source
files list, followed by the Smartgen Verilog files, followed by the other
source files.
3. Synthesize your design as usual.
Working with Radhard Designs
The following procedure outlines how to specify radhard values for a design
with the syn_radhardlevel attribute. Remember that the attribute is not recur-
sive. It only applies to all registers at the level where it is set and does not
affect lower-level registers.
You specify radhard values in modules and architecture in both the Attri-
butes panel in SCOPE and in the source code. However, for registers, it must
be specified in the source code only.
March 2014 1029
1. Add to your project the Microsemi macro files appropriate to the radhard
values you plan to set in the design. The macro files are in
installDirectory/lib/microsemi:
For ProASIC3/3E devices only, you do not need to add the Microsemi
macro file to your project.
2. To set a global or default syn_radhardlevel attribute, do the following:
Set the value in the source file for the module. The following sets all
registers of module_b to tmr:
Make sure that the corresponding Microsemi macro file from step 1 is
the first file listed in the project, if required.
Specifying syn_radhardlevel in the Source Code
For a module, you can attach the syn_radhardlevel attribute either in the Attri-
butes panel of the SCOPE window or in the source code. For a register, you
can only apply this attribute in the source code.
To set attributes in SCOPE, see How Attributes and Directives are Specified,
on page 10 in the Attribute Reference manual. The following procedure
outlines how to set this attribute in the source code.
1. To set a global or default value, make sure that the corresponding
Microsemi macro file is the first file listed in the project, if required.
Radhard Value Verilog Macro File VHDL Macro File
cc cc.v cc.vhd
tmr tmr.v tmr.vhd
tmr_cc tmr_cc.v tmr_cc.vhd
VHDL Verilog
library synplify;
attribute syn_radhardlevel of
behav: architecture is "tmr";
module module_b (a, b, sub,
clk, rst) /*synthesis
syn_radhardlevel="tmr"*/;
LO
Chapter 20: Optimizing for Specific Targets Optimizing Microsemi Designs
1030 March 2014
2. To set a syn_radhardlevel value for all the registers of a module, do the
following:
Set the value in the source file. The following sets all registers of
module_b to tmr:
Add the appropriate Microsemi macro file (tmr.v or tmr.vhd) to the
project, unless you are working with a ProASIC3, ProASIC3E, or
ProASIC3L target. You do not need to add the Microsemi macro file to
your project for these devices. The macro files are in the
installDirectory/lib/microsemi.
The attribute is not recursive. When used at the module or architecture
level, it only applies to the registers at that level, and does not affect
lower-level registers.
3. To set a syn_radhardlevel value on a per-register basis, do the following:
Set the value on the register in the source file for the module. For
example, to set the value of register bl_int to tmr, enter the following in
the module source file:
Add the appropriate Microsemi macro file (tmr.v or tmr.vhd for this
example) to the project, unless you are working with a ProASIC3,
ProASIC3E, or ProASIC3L target. You do not need to add the
Microsemi macro file to your project for these devices.
VHDL Verilog
library synplify;
behav: architecture is "tmr";
module module_b (a, b, sub,
clk, rst) /*synthesis
syn_radhardlevel="tmr"*/;
VHDL Verilog
library synplify;
bl_int: signal is "tmr"
reg [15:0] a1_int, b1_int
/* synthesis syn_radhardlevel =
"tmr" */;
March 2014 1031
Use a register-level attribute to override a default value with another
value, or set it to none to ensure that a global default value is not applied
to the register.
4. To prevent a default from being applied to a register or module/entity,
set syn_radhardlevel to none for that register, module, or entity.
LO
Chapter 20: Optimizing for Specific Targets Optimizing Xilinx Designs
1032 March 2014
Optimizing Xilinx Designs
This section contains tips for working with Xilinx designs:
Designing for Xilinx Architectures, on page 1033
Specifying Xilinx Macros, on page 1033
Specifying Global Sets/Resets and Startup Blocks, on page 1036
Inferring Wide Adders, on page 1037
Instantiating CoreGen Cores, on page 1040
Packing Registers for Xilinx I/Os, on page 1043
Specifying Xilinx Register INIT Values, on page 1046
Initializing Xilinx RAM, on page 1048
Specifying RLOCs, on page 1062
Specifying RLOCs and RLOC_ORIGINs with the synthesis Attribute, on
page 1064
Using Clock Buffers in Virtex Designs, on page 1065
Working with Clock Skews in Xilinx Virtex-5 Physical Designs, on
page 1067
Reoptimizing with EDIF Files, on page 1069
Improving Xilinx Physical Synthesis Performance, on page 1070
Running Post-Synthesis Simulation, on page 1071
Instantiating Special I/O Standard Buffers for Virtex, on page 1068
For additional Xilinx-specific techniques, see Xilinx Partition Flow, on
page 1135, Xilinx Partition Flow for Versions Before ISE 12.1, on page 1140,
Working with Gated Clocks, on page 840, Automatic RAM Inference, on
page 529, and Inferring Shift Registers, on page 559. Note that some of these
features are not available in the Synplify product.
Optimizing Xilinx Designs Chapter 20: Optimizing for Specific Targets
March 2014 1033
Designing for Xilinx Architectures
The tips listed here are in addition to the technology-independent design tips
described in Tips for Optimization, on page 576.
For critical paths, attach the xc_fast attribute to the I/Os.
To ensure that frequency constraints from register to output pads are
forward annotated to the P&R tools, add default input_delay and
output_delay constraints of 0.0 in the synthesis tool. The synthesis tool
forward-annotates the frequency constraints as PERIOD constraints
(register-to-register) and OFFSET constraints (input-to-register and
register-to-output). The place-and-route tools use these constraints.
Run successive place-and-route iterations with progressively tighter
timing constraints to get the best results possible.
When using VHDL, specify a UNISIM library using the following syntax:
library unisim;
use unisim.vcomponents.all;
Remove any other package files with user-defined UNISIM primitives.
Note: If you are using ISE11 for a VHDL design targeting Virtex 2 or
Virtex 2 Pro device, you must manually add the unisim_m10i.vhd library
before synthesizing the design, because ISE11 does not support these
Virtex families. For Verilog designs, the tool automatically add the
corresponding unisim_m10i.v file so you do not need to do it manually.
Specifying Xilinx Macros
The synthesis tool provides Xilinx macro libraries that you can use to instan-
tiate components like I/Os, I/O pads, gates, counters, and flip-flops. Using
the macros from these libraries allows you to perform a subsequent
simulation run without changing your code.
1. To use the Verilog macro library, review the unisim.v macro library in the
installDirectory/lib/xilinx directory for the available macros. The unisim.v file
is automatically added to your project file when you select a Xilinx target
device.
2. To use a VHDL library, do the following:
Review the unisim.vhd macro library in the installDirectory/lib/xilinx
directory to check the macros that are available.
LO
1034 March 2014
Add the corresponding library and use clauses to the beginning of the
design units that instantiate the macros, as in the following example:
library unisim;
You do not need to add the macro library files to your the source files for
your project.
3. Instantiate the macro component in your design.
4. To instantiate an I/O pad with different I/O standards, do the following:
Specify the macro library as described in the first two steps.
Instantiate the I/O pad component in your design. You can
instantiate IBUF, IBUFG, OBUF, OBUFT, and IOBUF components.
In the source files, define the generic or parameter values for the I/O
standard. Use an IOSTANDARD generic/parameter to specify the I/O
standard you want. Refer to the Xilinx documentation for a list of
supported IOSTANDARDs. For certain pad types, you can also specify
the output slew rate (SLEW) and output drive strength (DRIVE). See
OBUF Instantiation Example, on page 1035 for an example.
March 2014 1035
OBUF Instantiation Example
The following examples show the declaration of OBUF in macro library files:
To use the macro libraries to instantiate I/O pad types, define the
generic/parameter values in the Verilog or VHDL source files. The following
examples show how to instantiate OBUF pads with an I/O standard value of
LVCMOS2, an output slew value of FAST, and an output drive strength of 24.
VHDL component OBUF
generic (
IOSTANDARD : string := "default";
SLEW : string := "SLOW";
DRIVE : integer := 12
);
port (
O : out std_logic;
I : in std_logic;
);
end component;
attribute syn_black_box of OBUF : component is true
Verilog module OBUF(O, I); /* synthesis syn_black_box */
parameter IOSTANDARD="default";
parameter SLEW="SLOW";
parameter DRIVE=12;
output O;
input I;
endmodule
VHDL Data : OBUF
generic map (
IOSTANDARD => "LVCMOS2",
SLEW => "FAST",
DRIVE => 24
)
port map (
O => o1,
I => i1
);
Verilog OBUF Data(.O(o1), .I(i1));
defparam Data.IOSTANDARD = "LVCMOS2";
defparam Data.SLEW = "FAST";
defparam Data.DRIVE = 24;
LO
1036 March 2014
The resulting EDIF file contains the following, which corresponds to the
instantiations:
(instance (
rename dataZ0 "data")
(viewRef PRIM (cellRef OBUF (libraryRef VIRTEX)))
(property iostandard (string "LVCMOS2"))
(property slew (string "FAST"))
(property drive (integer 24) )
)
Specifying Global Sets/Resets and Startup Blocks
The global set/reset (GSR) resource is a pre-routed signal that goes to the set
or reset input of each flip-flop in your design. Using this resource instead of
general routing for a set or reset signal can have a significant positive impact
on the routability and performance of your design. The synthesis tools infer
this resource automatically in most cases, but you can also specify access to
the GSR resource with a Xilinx startup block.
1. Specify access to the GSR as follows:
To automatically use the GSR if needed, select Implementation Options ->
Device, and set Force GSR Usage to auto. With this setting, the tool
automatically determines if it needs to use the GSR.
To use the GSR, set Force GSR Usage to yes.
If you do not want to use the GSR, set Force GSR Usage to no.
2. For Xilinx XC designs, specify global sets/resets (GSR) as follows:
For a design with a single GSR, the synthesis tools automatically
connect it to a startup block, even if the flip-flops have no sets/resets
specified. If you need to change this setting, select Project->
Implementation Options ->Device, and set Force GSR Usage to no. With this
setting, all flip-flops must have a set or reset and the set or reset
must be the same before GSR is used.
For designs with multiple GSRs, the synthesis tool does not
automatically create a startup block for GSR. If you still want to use
one of the set or reset signals for GSR, you must instantiate a
STARTUP_GSR component manually, as described in the next step.
3. To instantiate a start-up block manually, do the following:
March 2014 1037
Go to the installDirectory/lib/xilinx directory and locate the appropriate
Xilinx startup blocks in either the Verilog (unisim.v) or VHDL
(unisim.vhd) format.
Instantiate the startup block component in your design. Where there
is more than one component listed, you can use them independently,
because the blocks are merged to form a single block in the EDIF file.
Inferring Wide Adders
For Virtex-5 and Virtex-6 designs, you can map wide adder/subtractor struc-
tures to DSP48Es. Xilinx architectures let you use cascading DSP48Es and
the CARRYCASCOUT pin to support a structure with up to three pipeline
registers with different synchronous control signals. It supports two or three
signed/unsigned inputs (with carry/borrow).
The following shows the implementation of wide adders with one pipelined
register and no pipelined registers as DSP48Es:
To automatically map to DSP48Es in the synthesis tools, do the following:
1. Make sure the structure you want to map conforms with these rules:
The adder/subtractor does not have more than 96 bits.
All registers share the same control signals (enables, clocks, reset).
Registers with different control signals are mapped to the DSP48E, but
they are kept outside the DSP48E.
LO
1038 March 2014
The adder does not have a 48-bit input and a 49-bit output.
2. Set syn_dspstyle to dsp48.
You must set this attribute, or the tool does not infer a DSP48E. See
syn_dspstyle, on page 126 for the syntax for this attribute.
If your structure has less than three pipelined registers, you see an
advisory message in the log file, because three pipelined registers give
the best performance.
March 2014 1039
The following is an example of how the synthesis tool maps an adder->
register->register structure with 96-bit signed input and output to a DSP48E:
RTL View
Technology View
LO
1040 March 2014
Instantiating CoreGen Cores
Predesigned IP cores save on design effort and improve performance. The
process for handling IP cores is slightly different for CoreGen and Virtex PCI
cores. The following procedure describes how to instantiate a CoreGen
module. For Virtex PCI cores, see Instantiating Virtex PCI Cores, on
page 1041.
1. Use the Xilinx CORE generator to create structural EDIF netlists and
generate timing and resource usage information for synthesis.
For legacy cores, generate a single flat edf netlist file.
For newer cores, generate a top-level flat edn or edf netlist file that
instantiates ndf files for each hierarchical level in the design.
2. Open the synthesis software, and add the generated files (edf only for
legacy cores; edn or edf and ndf for newer cores) to your project.
3. Define the core as a black box by adding the syn_black_box attribute to
the module definition line, or by using the Coregen v file. The following is
an example of the attribute:
module ram64x8(din, addr, we, clk, dout)/* synthesis syn_black_box
*/;
input[7:0] din;
input [5:0] addr;
input we, clk;
output [7:0] dout;
endmodule;
4. Make sure the bus format matches the bus format in the core generator,
using the syn_edif_bit_format and syn_edif_scalar_format directives if needed.
module ram64x8(din, addr, we, clk, dout)
/* synthesis syn_black_box syn_edif_bit_format = "%u<%i>"
syn_edif_scalar format ="%u" */;
5. Instantiate the black box in the module or architecture.
ram64x8 r1(din, addr, we, clk, dout);
If you supplied structural EDIF netlists, the software optimizes the
design based on the information in the structural netlists. The generated
reports contain the optimization information.
March 2014 1041
Instantiating Virtex PCI Cores
For Virtex PCI cores, you can use either a top-down or bottom-up method-
ology. This figure shows a design that is used in the explanations of both
methodologies, below.
Bottom-Up Method
The bottom-up method synthesizes lower-level modules first. The synthesized
modules are then treated as black boxes and synthesized at the next level.
The following procedure refers to the figure shown above.
1. Synthesize the user-defined application (PING64) by itself.
Make sure that the Disable I/O Insertion option is on.
Specify the syn_edif_bit_format = "%u<%i>" and syn_edif_scalar_format =
"%u" attributes. These attributes ensure that the EDIF bus names
FF
PCIM_LC
BUFG
I/O
FF
FF
FF
FF
FF
I/O
I/O
I/O
BUFG
PCI_LC_I
CFG
PCIM_TOP
PING64
LO
1042 March 2014
match the Xilinx upper-case, angle bracket style bus names and the
Xilinx upper-case net names, respectively.
The software generates an EDIF file for this module.
2. Synthesize the top-level module that contains the PCI core, with the
Disable I/O Insertion option enabled and the EDIF naming attributes
described in the previous step. Use the following files to synthesize:
The top-level module (PCIM_LC) file, with the PCI core (PCI_LC_I)
declared as a black box with the syn_black_box attribute.
A black box file for the core (PCI_LC_I), that only contains information
about the PCI core ports. This file is the source file that is generated
for simulation, not the ngo file.
The appropriate synthesis Virtex file (installDirectory/lib/xilinx) that
contains module definitions of the I/O pads in the top-level module,
PCIM_LC.
The software generates an EDIF file for this module.
3. Synthesize the top level (PCIM_TOP) with Disable I/O Insertion off. Use the
following files:
The source file for CFG.
A black box file for PING64.
A black box file for PCIM_LC.
A top-level file that contains black box declarations for PING64 and
PCIM_LC.
The software generates an EDIF file for the top level.
4. Place and route using the Xilinx ngo file for the core, and the three EDIF
files generated from synthesis: one for each of the modules PING64 and
PCIM_LC, and the top-level EDIF file. Select the top-level EDIF file when
you run place-and-route.
Top-down Methodology
The top-down method instantiates user application blocks and synthesizes
all the source files in one synthesis run. This method can result in a smaller,
faster design than with the bottom-up method, because the tool can do cross-
boundary optimizations. The following procedure refers to the design shown
in the previous figure.
March 2014 1043
1. Create your own configuration file for your application model (CFG).
2. Edit the top-level source file to do the following:
Instantiate your application block (PING64) in the top-level source file.
Add the ports from your application.
3. Add the appropriate synthesis Virtex file (installDirectory/lib/xilinx) to the
project. This file contains module definitions of the I/O pads in the
PCIM_LC module.
4. Specify the top-level file in the project.
5. Synthesize your design with the following files:
Virtex module definition file (previous step)
Source files for top-level design, user application (PING64), PCIM_LC,
and CFG
Simulation wrapper file for PCI core
The software generates an EDIF file for the top level.
6. Place and route the design using the top-level EDIF file from synthesis
and the Xilinx ngo file for the PCI core.
Packing Registers for Xilinx I/Os
When a register drives an input or output, you might want to pack it in an
IOB instead of a CLB, as in these cases:
The chip interfaces with another, and you have to minimize the register-
to-output or input-to-register delay.
You have limited CLB resources, and packing the registers in an IOB
can free up some resources.
To pack registers in an IOB, you set the syn_useioff attribute.
1. To globally embed all the registers into IOBs, attach the syn_useioff
attribute to the module in one of these ways:
Add the attribute in the SCOPE window, attaching it to the module,
architecture, or the top level. Check the Enable box, set the Attribute
column to syn_useioff, the Object column to <global>, and the attribute
value to 1. The constraint file syntax looks like this:
LO
1044 March 2014
define_global_attribute syn_useioff 1
To add the attribute in the Verilog source code, add this syntax to the
top level:
module global_test(d, clk, q) /* synthesis syn_useioff = 1 */;
To add the attribute in the VHDL source code, add this syntax to the
top level architecture declaration:
architecture rtl of global_test is
attribute syn_useioff of rtl : architecture is true;
For details about attaching attributes using the SCOPE interface and in
the source code, see Specifying Attributes and Directives, on page 169.
When set globally, all boundary registers and (OE) registers associated
with the data registers are marked with the Xilinx IOB property. This
property is forward annotated in the EDIF netlist and used by the Xilinx
place-and-route tools to determine how the registers are packed. All
marked registers are packed in the corresponding IOBs.
2. To apply syn_useioff to individual registers or ports, use one of these
methods:
Add the attribute in the SCOPE window, attaching it to the ports you
want to pack, and set the attribute value to 1. The resulting
constraint file syntax looks like this:
define_attribute {p:q[3:0]} syn_useioff 1
To add the attribute in the Verilog source code, add this syntax:
module test is (d, clk, q);
input [3:0] d;
input clk;
output [3:0] q /* synthesis syn_useioff = 1 */;
reg q;
March 2014 1045
To add the attribute in the VHDL source code, add syntax as shown
inside the entity for the local port:
entity test is
port (d : in std_logic_vector(3 downto 0);
clk : in std_logic
q : out std_logic_vector(3 downto 0);
attribute syn_useioff of q : signal is true;
end test;
The software attaches the IOB property as described in the previous step,
but only to the specified flip-flops. Packing for ports and registers
without the attribute is determined by timing preferences. If a register is
to be packed into an IOB, the IOB property is attached and forward
annotated. If it is to be packed into a CLB, the IOB property is not
forward annotated.
In Virtex designs where the synthesis software duplicates OE registers,
setting the syn_useioff attribute on a boundary register only enables the
associated OE register for packing. The duplicate is not packed, but
placed in a CLB. The packed registers are used for data path, and the
CLB registers are used for counter implementation.
In Virtex designs where a shift register is at a boundary edge and the
syn_useioff attribute is enabled, the software extracts only the initial or
final SRL16 shift register from the LUT for packing. The shift register
that is implemented in the technology view is smaller because of the
extraction.
3. If you set multiple syn_useioff attributes at different levels of the design,
the tool uses the most specific setting (highest priority).
This table summarizes syn_useioff priority settings, from the highest
priority (register) to the lowest (global):
I/O Type
syn_useioff Value
Description
Register 1 Packs registers into the I/O pad cells,
overriding port or global specifications.
0 Does not pack registers into I/O pad cells,
overriding port or global specifications.
LO
1046 March 2014
The syn_useioff attribute is supported in the compile point flow.
Specifying Xilinx Register INIT Values
You can specify initial values for registers so that the RTL, gate-level simula-
tion, and the final implementation results match. You can specify INIT values
for registers either with the HDL initialization specification built into Verilog
or VHDL, or by adding the synthesis attribute. You can then pass the values to
the Xilinx P&R tools.
Both methods are described in the following procedure, but the HDL specifi-
cation method is recommended.
1. To ensure that the register is not optimized away during synthesis, set
the syn_preserve directive on the register in the source code.
Use this directive even if you define the INIT values with a constraint in
the sdc file. If you do not have this directive, the register can be removed
during optimization.
2. To set a register value using the HDL initialization feature, use the
following syntax:
Port 1 Packs registers into the I/O pad cells,
overriding any global specification.
0 Does not pack registers into I/O pad cells,
overriding any global specification.
Global 1 Packs registers into the I/O pad cells.
0 Does not pack registers into I/O pad cells.
HDL Initialization reg myreg=0;
initial myreg=0; (Verilog only)
I/O Type
syn_useioff Value
Description
March 2014 1047
This is the preferred method to pass INIT values to the Xilinx place-and-
route tools.
3. To set a register value using the synthesis attribute, add the attribute to
the register in the source code or the constraint file, and specify the INIT
value as a string:
Xilinx ISE 8.2sp3 and later versions require that the INIT value be a
string rather than an integer. For code examples, see INIT Values, on
4. To specify different INIT values for each register bit on a bus, do the
following:
Set syn_preserve on the register as described in step 1, so that it is not
optimized away. You can now either use the HDL specification or set
an attribute.
To specify the values using the HDL specification, use the syntax as
shown in the following examples:
To specify the value with the INIT attribute in the sdc constraint file,
set INIT values for the individual register bits on the bus. Specify the
register using the i: prefix, with periods as hierarchy separators.
Verilog HDL Initialization reg error_reg = 1b0;
reg [7:0] address_reg = 8hff;
VHDL HDL Initialization signal tmp: std_logic = 0;
Verilog reg [3:0] rst_cntr /* synthesis INIT="1" */;
VHDL attribute INIT: string;
attribute INIT of rst_cntr : signal is "1";
SDC define_attribute {i:rst_cntr} INIT {"1"}
Verilog HDL Bus Initialization reg [7:0] address_reg = 8hff;
VHDL HDL Bus Initialization signal q: std_logic_vector
(11 downto 0) := X"755";
LO
1048 March 2014
The following specifies INIT values for individual bits of rst_cntr, which
is part of the init_attrver module, under the top-level module:
define_attribute {i:init_attrver.rst_cntr[0]} INIT {"0"}
The tool forward-annotates the values to the Xilinx P&R tool in the EDIF
netlist. Note that the INIT value is forward-annotated as is (as an integer,
not binary). You must ensure that the value is specified in the correct
format for P&R.
If the register is an asynchronous output register with an initial value,
the mapper preserves the initial value and packs the register into the
Block RAM.
Initializing Xilinx RAM
In addition to the methods described in Initializing RAMs, on page 554, you
can also define and forward-annotate Xilinx RAM initialization values as
summarized in this table:
Verilog
$readmemebh or $readmemh
See Initializing RAMs with $readmemb and $readmemh, on page 558.
INIT property in defparam statement
See Specifying the INIT Property for Xilinx RAMs (Verilog), on page 1049.
INIT property in global comment (/* synthesis INIT or /*synthesis
INIT_xx=<value>
See Specifying the INIT Property for Xilinx RAMs (Verilog), on page 1049.
VHDL
March 2014 1049
Note the following differences between the above methods:
You can use the INIT property with any code. The $readmemb and
$readmemh system tasks are only applicable in Verilog.
The Verilog initial values only affect the output of the compiler, not the
mapper. They ensure that the synthesis results match the simulation
results, and are not forward-annotated.
Specifying the INIT Property for Xilinx RAMs (Verilog)
You can initialize and forward-annotate the values for Xilinx Verilog RAMs by
specifying the INIT property. In Verilog, you can do this by using the
defparams statement or by specifying the property in a global comment. The
following examples illustrate these two methods.
Using defparam to Specify Initialization Values for Xilinx RAMs, on
page 1049
Using Global Comments to Specify Initialization Values for Xilinx RAMs,
on page 1050
Using defparam to Specify Initialization Values for Xilinx RAMs
1. Include defparam statements in the Verilog file, using one statement for
each word. Use the following syntax for the INIT property:
defparam name.INIT_xx=value;
INIT property on label
See Specifying the INIT Property for Xilinx RAMs (VHDL), on page 1052.
Attributes
INIT property in SCOPE
See Specifying the INIT Property with Attributes, on page 1053.
define_attribute statements in the sdc file
See Specifying the INIT Property with Attributes, on page 1053.
name Is the name of the RAM.
xx Indicates the part of the RAM you are initializing. It can be any hex
number from 00 to FF.
value Sets the initialization value in hex.
LO
1050 March 2014
The following example for Virtex block RAM would have 16 statements,
because it is 4K bits in size. Each statement has 64 hex values in each
INIT, because there are 16 INIT statements (64 x 4 and 256 x 16 = 4K).
RAMB4_S4 pkt_len_ram_lo (
.CLK (clock),
.RST (1'b0),
.EN (1'b1),
.WE (we),
.ADDR (address),
.DI (data),
.DO (q)
);
defparam pkt_len_ram_lo.INIT_00=
"00170016001500140013001200110010000f000e000d000c000b000a00090008 ";
"00270026002500240023002200210020001f001e001d001c001b001a00190018;
"00370036003500340033003200310030002f002e002d002c002b002a00290028";
...
defparam pkt_len_ram_lo.INIT_0F=
"0107010601050104010301020101010000ff00fe00fd00fc00fb00fa00f900f8";
When you synthesize the design, the software forward-annotates the
RAM initialization information to the Xilinx P&R software in the EDIF
netlist. The INIT values are forward-annotated as is, and you must
ensure that the values are in the right format before P&R.
Using Global Comments to Specify Initialization Values for Xilinx RAMs
1. Add the INIT property.
Attach the INIT property to the instance as shown:
Define the INIT_xx=value property as follows:
RAM /* synthesis INIT = "value" */
Block RAM /* synthesis INIT_xx = "value" */
March 2014 1051
Keep the entire statement on one line. Let your editor wrap lines if it
supports line wrap, but do not press Enter until the end of the
statement.
2. For RAM, specify a hex value for the INIT statement as shown here:
RAM16X1S RAM1(...) /* synthesis INIT = "0000" */;
3. For Virtex block RAM, specify 16 different INIT statements. End the
initialization data with a semicolon.
All Virtex block RAMs have 16 INIT statements because they are all
4Kbits in size, although they are configured differently: 4Kx1, 2Kx2,
1Kx4, 512x8, and 256x16.
he following example for Virtex block RAM would have 16 statements,
because it is 4K bits in size. Each statement has 64 hex values in each
INIT, because there are 16 INIT statements (64 x 4 and 256 x 16 = 4K).
RAMB4_S4 pkt_len_ram_lo (
.CLK (clock),
.RST (1'b0),
.EN (1'b1),
.WE (we),
.ADDR (address),
.DI (data),
.DO (q)
)
/* synthesis
INIT_00="00170016001500140013001200110010000f000e000d000c000b000a00090008"
INIT_01="00270026002500240023002200210020001f001e001d001c001b001a00190018"
INIT_02="00370036003500340033003200310030002f002e002d002c002b002a00290028"
...
INIT_0F="0107010601050104010301020101010000ff00fe00fd00fc00fb00fa00f900f8"
*/;
RAM initialization information to the Xilinx place-and-route software.
xx Indicate the part of the RAM you are initializing with a number from
00 to FF.
value Set the initialization value, in hex. You have 64 hex values in each INIT
(64 x 4 = 256 and 256 x 16 = 4K), because there are 16 INIT
statements.
LO
1052 March 2014
The INIT values are forward-annotated as is, and you must ensure that
the values are in the right format before P&R.
Specifying the INIT Property for Xilinx RAMs (VHDL)
1. Add the INIT property.
Attach the INIT property to the label as shown:
Keep the entire statement on one line. Let the editor wrap lines if it
supports line wrap, but do not press Enter until the end of the
statement.
2. For RAM, specify hex values for the INIT statement as shown:
attribute INIT of RAM1 : label is "0000";:
3. For Virtex block RAM, specify 16 different INIT statements.
Define the INIT_xx=value property as follows:
1Kx4, 512x8, and 256x16.
End the initialization data with a semicolon.
RAM initialization information to the Xilinx place-and-route software.
The INIT values are forward-annotated as is, and you must ensure that
the values are in the right format before P&R.
RAM attribute INIT of object : label is "value";
Block RAM attribute INIT_xx of object : label is "value";
xx Indicate the part of the RAM you are initializing with a number from
00 to FF.
value Set the initialization value, in hex. You have 64 hex values in each INIT
(64 x 4 = 256 and 256 x 16 = 4K), because there are 16 INIT
statements.
March 2014 1053
Specifying the INIT Property with Attributes
When you set the INIT property in the source code, it is difficult to pass on the
values if the RAM instances are mapped to registers. When you specify INIT as
an attribute, either in the SCOPE window or the constraint file, you are
working with a mapped RAM, and the values are passed to the P&R tool. You
can use this method to specify the initialization values for a RAM whether you
are using Verilog or VHDL.
1. Compile and map the design.
2. Select the RAM in the SCOPE window.
Open SCOPE and go to the Attributes panel.
Open the Technology view. Drag and drop the RAM into the window.
3. Define the INIT (RAM) or INIT_xx = value (Block RAM) property in SCOPE.
Alternatively you can edit the sdc file using define_attribute statements.
1Kx4, 512x8, and 256x16.
initialization values as constraints in the sdc file. The following example
shows a value of ABBADABAABBADABA defined for INIT_00 and INIT_01 on
mem.mem_0_0 in the sdc file:
define_attribute {i:mem.mem_0_0} INIT_00 {ABBADABAABBADABA}
define_attribute {i:mem.mem_0_0} INIT_01 {ABBADABAABBADABA}
These initialization values are forward-annotated as constraints to the
place-and-route software. The INIT values are forward-annotated as is,
and you must ensure that the values are in the right format before P&R.
xx Indicates the part of the RAM you are initializing with a number from
00 to FF.
value Sets the initialization value, in hex. You have 64 hex values in each
INIT (64 x 4 = 256 and 256 x 16 = 4K), because there are 16 INIT
statements.
LO
1054 March 2014
Initializing Xilinx Select RAM
For select RAM in some Virtex architectures, you can specify an initial value
and have it honored.
1. Specify the initial value in the RTL using $readmemb or another
supported mechanism.
See Initializing Xilinx RAM, on page 1048 for details.
If the tool maps the ram1 to a supported select RAM in Virtex 4 and later
designs, it automatically distributes the initial value you specified. The
INIT values are forward-annotated as is, and you must ensure that the
values are in the right format before P&R.
Inserting Xilinx I/Os and Specifying Pin Locations
By default, the synthesis tools automatically insert I/Os for inputs, outputs,
and bidirectionals (such as IBUFs and OBUFs). You can change this by
enabling Disable IO Insertion in the Device tab of the Implementation Options dialog
box. You can also insert I/Os manually by instantiating them.
Whether you use the automatic or manual method, you can specify pin
locations for the I/Os with the xc_loc attribute. By default, or if no location is
specified, the Xilinx tool assigns pin locations automatically.
The following provide details:
Assigning Pin Locations for Automatically Inserted Xilinx I/Os, on
page 1054
Manually Inserting Xilinx I/Os in Verilog, on page 1057
Manually Inserting Xilinx I/Os in VHDL, on page 1059
Assigning Pin Locations for Automatically Inserted Xilinx I/Os
The synthesis tool automatically inserts the I/Os (unless you have checked
Disable IO Insertion in the Device tab of the Implementation Options dialog box). The
following procedure shows you how to assign pin locations for automatically
inserted I/Os in a Verilog or VHDL design.
1. Create a new top-level module or entity and instantiate it in your Verilog
or VHDL design.
March 2014 1055
This module/entity holds I/O placement information. Creating this lets
you keep your vendor-specific information separate from the rest of your
design. Your original design remains technology-independent.
For example, this is a Verilog counter definition:
module cnt4 (cout, out, in, ce, load, clk, rst);
// Counter definition
endmodule
You create a top-level module that instantiates your design:
module cnt4_xilinx (cout, out, in, ce, load, clk, rst);
2. If you do not want to specify locations, specify the inputs or outputs as
usual. The following is an example of Verilog inputs in the top-level
module:
input ce, load, clk, rst;
The Xilinx place-and-route tool automatically places these inputs.
3. Optionally, specify I/O locations in the new top-level module, by setting
the xc_loc attribute.
You can specify the xc_loc attribute in the Attribute panel of the SCOPE
spreadsheet, as shown below.
Alternatively, you can specify it in the HDL files, as described in
Manually Inserting Xilinx I/Os in Verilog, on page 1057 and Manually
Inserting Xilinx I/Os in VHDL, on page 1059. See xc_loc, on page 518 in
the Reference Manual for syntax details.
The following Verilog code includes xc_loc attributes that specify the
following locations:
cout at A1
out in the top left (TL) of the chip
in[3] at P20, in[2] at P19, in[1] at P18, and in[0] at P17
LO
1056 March 2014
output cout /* synthesis xc_loc="A1" */;
output [3:0] out /* synthesis xc_loc="TL" */;
input [3:0] in /* synthesis xc_loc="P20,P19,P18,P17" */;
4. Instantiate the top-level module or entity with the placement
information you specified in your design. For example:
cnt4 my_counter (.cout(cout), .out(out), .in(in),
.ce(ce), .load(load), .clk(clk), .rst(rst));
endmodule
The synthesis tools automatically insert I/Os for inputs, outputs, and
bidirectionals (such as IBUFs and OBUFs). The Xilinx place-and-route
tool automatically selects locations for I/Os with no xc_loc attribute
defined. If you specified xc_loc settings, they are honored.
VHDL Automatic I/O Insertion Example
library synplify;
entity cnt4 is
port (cout: out bit;
output: out bit_vector (3 downto 0);
input: in bit_vector (3 downto 0);
ce, load, clk, rst: in bit );
end cnt4;
architecture behave of cnt4 is
begin
-- Behavioral description of the counter.
end behave;
-- New top level entity, created specifically
-- to place I/Os for Xilinx. This entity is typically
-- in another file, so that your original
-- design stays untouched and technology independent.
entity cnt4_xilinx is
-- Place a single I/O for cout at location A1.
attribute xc_loc : string;
attribute xc_loc of cout: signal is "A1";
March 2014 1057
-- Place all bits of "output" in the
-- top-left of the chip.
attribute xc_loc of output: signal is "TL";
-- Place input(3) at P20, input(2) at P19,
-- input(1) at P18, and input(0) at P17
attribute xc_loc of input: signal is "P20, P19, P18, P17";
-- Let Xilinx place the rest of the inputs.
end cnt4_xilinx;
-- New top level architecture instantiates your design.
architecture structural of cnt4_xilinx is
-- Component declaration for your entity.
component cnt4
end component;
begin
-- Instantiate your VHDL design here:
my_counter: cnt4 port map (cout, output, input,
ce, load, clk, rst);
end structural;
Manually Inserting Xilinx I/Os in Verilog
To insert a Xilinx I/O manually, you must instantiate a black box macro for
that I/O from the Xilinx library file. You can then choose to assign it a
location or have the Xilinx tool automatically select one for it.
To insert an I/O manually and then use automatic location assignment, do
the following:
1. Add the installDirectory/lib/xilinx/unisim.v macro library file to the top of the
source files list for your project.
2. Create instances of I/Os by instantiating a black box in your Verilog
source code.
These black boxes are empty Verilog module descriptions, taken from
the Xilinx macro library you specified in step 1. You can stop at this
step, and the Xilinx tool will automatically assign locations for the I/Os
you specified.
LO
1058 March 2014
To insert an I/O manually and specify pin locations, do the following:
1. Create a new top-level module and instantiate your Verilog design.
2. Add the installDirectory/lib/xilinx/unisim.v macro library file to the top of the
source files list for your project.
source code.
4. Specify I/O locations by adding the xc_loc attribute to the I/Os.
See Verilog Manual I/O Insertion Example, on page 1058 for an example
of the code.The Xilinx tool honors any locations assigned with the xc_loc
attribute, and automatically selects locations for any remaining I/Os
without definitions.
Verilog Manual I/O Insertion Example
module cnt4 (cout, out, in, ce, load, clk, rst);
/* Your counter definition goes here, */
endmodule
/* Create a top level to place I/Os specifically
for Xilinx. Any top level pins which do not have
I/Os will be automatically inserted */
module cnt4_xilinx(cout, out, in, ce, load, clk, rst);
output [3:0] out;
output cout;
input [3:0] in;
input ce, load, clk, rst;wire [3:0] out_c, in_c;
wire cout_c;
/* The xc_loc attribute can be added right after the
instance name like that shown below, or right before
the semicolon. */
IBUF i3 /* synthesis xc_loc="P20" */ (.O(in_c[3]), .I(in[3]));
OBUF o3 /* synthesis xc_loc="TL" */ (.O(out[3]), .I(out_c[3]));
OBUF cout_p /* synthesis xc_loc="BL" */ (.O(cout), .I(cout_c));
March 2014 1059
cnt4 it(.cout(cout_c), .out(out_c), .in(in_c),
.ce(ce), .load(load), .clk(clk), .rst(rst));
endmodule
Manually Inserting Xilinx I/Os in VHDL
To insert an I/O manually and then use automatic location assignment, do
the following:
1. Add the corresponding library and use clauses to the beginning of your
design units that instantiate the macros.
library unisim;
The Xilinx unisim.vhd macro library is always visible in the synthesis tool,
so do not add this library file to the source files list for your project. To
see which design units are available, use a text editor to view the file
located in the installDirectory/lib/xilinx directory. Do not edit this file in any
way.
source code.
These black boxes are empty Verilog module descriptions, taken from
the Xilinx macro library you specified in step 1. You can stop at this
step, and the Xilinx tool will automatically assign locations for the I/Os
you specified.
To insert an I/O manually and specify pin locations, do the following:
1. Create a new top-level module and instantiate your VHDL design.
2. Instantiate the Xilinx I/Os.
3. Add the appropriate library and use clauses to the beginning of design
units that instantiate the I/Os.
library unisim;
See the source code in VHDL Manual I/O Insertion Example, on
page 1060 for an example.
4. To specify I/O locations, add the xc_loc attribute to the I/O instances for
which you want to specify the locations.
LO
1060 March 2014
5. If you leave out the xc_loc attribute, the Xilinx place-and-route tool will
choose the locations.
VHDL Manual I/O Insertion Example
The following example is a behavioral D flip-flop with instantiated data input
I/O. The other ports will have synthesized I/Os.
library ieee, synplify;
-- Library and use clauses for access to the Xilinx Macro Library.
library unisim;
entity place_example is
port (q: out std_logic;
d, clk: in std_logic );
end place_example;
architecture behave of place_example is
signal dz: std_logic;
attribute xc_loc of I1: label is "P3";
begin
I1: IBUF port map (I=>d,O=>dz);
process (clk) begin
q<=dz;
end if;
end process;
end behave;
Working with Xilinx Buffers
By default, the synthesis tools do not automatically infer Xilinx buffers. If you
want the tools to infer Xilinx buffers, you must use attributes, as described
below.
1. To infer BUFGMUX components, do the following:
Attach the syn_insert_buffer attribute to the mux instance. If you need
information on how to do this, see Specifying Attributes and
Directives, on page 169.
March 2014 1061
Set the attribute value to bufgmux. When you set this value, the tool
infers a BUFGMUX_1 if the muxed clock operates on the negative edge;
otherwise it infers a BUFGMUX. If you do not specify this value, by
default the tool infers the LUT that drives the BUFG.
For details about the syn_insert_buffer syntax, see syn_insert_buffer, on
page 224 in the Reference Manual
2. To infer IBUFDS, IBUFGDS, OBUFDS, OBUFTDS, and IOBUFDS differential
buffers, do the following:
Attach the syn_diff_io attribute to the inputs of the buffer.
Set the value to 1 or true.
For details about the syn_diff_io syntax, see syn_diff_io, on page 106 in
The syn_diff_io attribute is supported in the compile point flow.
Working with Xilinx Regional Clock Buffers
The Xilinx regional clock buffer (BUFR) available for Virtex-6, Virtex-5, and
Virtex-4 devices is a special buffer used to connect the clock nets in the same
region and adjacent regions, independent of the global clock tree. The BUFR
can drive the I/O logic and logic resources (CLB, block RAM, and DSP) in the
existing and adjacent clock regions. They can be driven by clock capable pins,
local interconnects, Gigabit Transceiver (GT), and Mixed-Mode Clock
Manager (MMCM) high-performance clocks. The BUFR can be used as a clock
divider in low power and low skew operations.
By default, the synthesis tools do not automatically infer the Xilinx BUFR. If
you want the tools to infer Xilinx regional clock buffers, you must use the
attribute, as described below.
module
bufgmux_1(c1,c2,sel,din,d
out);
input c1,c2,sel;
input [20:1] din;
output reg [20 : 1] dout;
wire clk;
assign clk = sel ? c1 :
sel
c2
c1
clk
din[20:1]
dout[20:1]
0
D[19:0] Q[19:0] 1
dout[20:1]
LO
1062 March 2014
1. To infer BUFR primitives, do the following:
Apply the syn_insert_buffer attribute on a port or net.
Set the attribute value to BUFR.
For details about the syn_insert_buffer syntax, see syn_insert_buffer, on
page 224 in the Reference Manual
2. Check the log file for the number of BUFRs connected in the region. The
report specifies:
The output of the BUFR used on the clock net should be defined as
the derived clock and the timing report should be specified for the
clock signal.
If inferred
Clock Buffers:
Inserting Clock buffer on net clk1_en, Inserting Clock buffer
for port clk,
Not inferred
Warning: BUFR not inserted on net <name>
Resource utilization
Mapping to part: xc6vlx75tff484-1
Cell usage:
BUFR 2 uses
Specifying RLOCs
RLOCs are relative location constraints. They let you control placement in
critical sections, thus improving performance. You specify RLOCs using three
attributes, xc_map, xc_rloc, and xc_uset. As with other attributes, you can
define them in the source code, or in the SCOPE window.
You can also specify RLOCs directly, as described in Specifying RLOCs and
RLOC_ORIGINs with the synthesis Attribute, on page 1064.
1. Create the modules you want to constrain, and specify the kind of Xilinx
primitive you want to map them to, using the xc_map attribute. The
modules can have only one output.
March 2014 1063
This Verilog example shows a 4-input Spartan XOR module:
module fmap_xor4(z, a, b, c, d) /* synthesis xc_map=fmap*/ ;
output z;
input a, b, c, d;
assign z = a ^ b ^c ^d;
endmodule
This is the equivalent VHDL example:
library IEEE;
entity fmap_xor4 is
port (a: in std_logic;
b: in std_logic;
c: in std_logic;
d: in std_logic
);
end fmap_xor4;
architecture rtl offmap_xor4 is
attribute xc_map : STRING;
attribute xc_map of rtl: architecture is "fmap";
begin
z <= a xor b xor c xor d;
end rtl;
2. Instantiate the modules you created at a higher hierarchy level.
3. Group the instances together (xc_uset attribute) and specify the relative
locations of instances in the group with the xc_rloc attribute.
This example shows the Verilog code for the top-level CLB that includes
the 4-input module in the previous example:
module clb_xor9(z, a) ;
output z;
input [8:0] a;
wire x03, x47;
fmap_xor4 x03 /*synthesis xc_uset="SET1" xc_rloc="R0C0.f" */
(z03, a[0], a[1], a[2], a[3]);
Family xc_map Value Max. Module Inputs
Virtex and Spartan-3
families
lut 4
LO
1064 March 2014
fmap_xor4 x47 /*synthesis xc_uset="SET1" xc_rloc="R0C0.g" */
(z47, a[4], a[5], a[6], a[7]);
hmap_xor3 zz /*synthesis xc_uset="SET1" xc_rloc="R0C0.h" */
(z, z03, z47, a[8]);
//Code for Virtex differs because it includes the slice
fmap_xor4 x03 /*synthesis xc_uset="SET1" xc_rloc="R0C0.S0" */
(z03, a[0], a[1], a[2], a[3]);
fmap_xor4 x47 /*synthesis xc_uset="SET1" xc_rloc="R0C0.S0" */
(z47, a[4], a[5], a[6], a[7]);
hmap_xor3 zz /*synthesis xc_uset="SET1" xc_rloc="R0C0.S1" */
(z, z03, z47, a[8]);endmodule
4. Create a top-level design and instantiate your design.
Specifying RLOCs and RLOC_ORIGINs with the synthesis Attribute
You can specify RLOCs and RLOC_ORIGINs with the synthesis attribute, and
then pass them to the Xilinx P&R tools. Alternatively, you can specify RLOCs
using the three attributes described in Specifying RLOCs, on page 1062.
1. In the source code, use the synthesis attribute to specify the RLOC and
RLOC_ORIGIN values:
For code examples, see RLOC Constraints, on page 528 in the Reference
Manual.
2. To specify different RLOC and RLOC_ORIGIN values for bits on a bus, do
the following:
Specify the RLOC_ORIGIN for the Verilog module or VHDL architecture
in the source file. See step 1 for the syntax.
Define RLOCs for the individual register bits as constraints in the sdc
file. Do not define RLOCs for individual bits in the source code, or you
will get a Xilinx ISE error.
Verilog /* synthesis RLOC_ORIGIN="X0Y2" RLOC="X0Y0" */;
VHDL attribute RLOC_ORIGIN : string;
attribute RLOC_ORIGIN of behave : architecture is "X0Y2";
attribute RLOC : string;
attribute RLOC of q : signal is "X0Y0";
March 2014 1065
define_attribute {i:tmp[0]} RLOC {"X3Y0"}
The tool forward-annotates the values to the Xilinx P&R tool in the EDIF
netlist.
Using Clock Buffers in Virtex Designs
The software can infer a buffer called BUFGDLL that includes the CLKDLL
primitive. BUFGDLL consists of an IBUFG followed by a CLKDLL (Clock Delay
Locked Loop) followed by a BUFG. To use this CLKDLL primitive, you must
specify the xc_clockbuftype attribute. The following steps show you how to add
the attribute in SCOPE or the HDL files.
1. To specify the attribute in the SCOPE window, use the procedure
described in Specifying Attributes Using the SCOPE Editor, on page 174
to add the xc_clockbuftype attribute to a port.
The software infers a buffer as shown in the following figure.
The output EDIF netlist contains text like the following:
(instance clk_ibuf (viewRef PRIM (cellRef BUFGDLL (libraryRef VIRTEX) ) )
LO
1066 March 2014
2. To specify the attribute in Verilog, add the attribute as shown in this
example.
module test(d, clk, rst, q);
input [1:0] d;
input clk /* synthesis xc_clockbuftype = "BUFGDLL" */, rst;
output [1:0] q;
//other coding
3. To specify the attribute in VHDL, add the attribute as shown in this
example.
entity test_clkbuftype is
port (d: in std_logic_vector(3 downto 0);
clk, rst : in std_logic;
q : out std_logic_vector(3 downto 0)
);
attribute xc_clockbuftype of clk : signal is "BUFGDLL";
end test_clkbuftype
March 2014 1067
Working with Clock Skews in Xilinx Virtex-5 Physical Designs
The Synplify Premier software supports clock skews for Virtex-5 devices , and
the SRM clock insertion delay property (Clock input arrival_time). Clock inser-
tion delay models are included for the following components:
DCM
BUFG
BUFR
BUFIO
Flip-flops generating clocks
This feature ensures that cross-clock paths are compared correctly. Also, it
has a large impact on timing constraints for I/O paths, since any clock delay
will be added to the output delay and subtracted from the setup delay. This
results in improved timing correlation between the Synplify Premier software
and Xilinx timing.
Example1: Calculating Slack with Clock Skew
Clock skew is utilized to calculate the slack in the following Virtex-5 example:
Source DCM (clock insertion delay = 0.000ns)
Load IBUFG (clock insertion delay = 4.157ns)
- (Setup Time): 0.004
+ (Clock Delay at Ending Point): 4.157
+ (Clock Latency at Ending Point): 0.000
= Required Time: 9.153
- (Propagation Time): 0.746
- (Clock Latency at Starting Point): 0.000
= Slack (non-critical): 8.407
LO
1068 March 2014
Example 2: Calculating Slack Using Clock Skew
Clock skew is utilized to calculate the slack in the following Virtex-5 example:
Source IBUFG (clock insertion delay = 4.157ns)
Load DCM (clock insertion delay = 0.000ns)
- (Setup Time): 0.004
+ (Clock Latency at Ending Point): 0.000
= Required Time: 4.996
- (Propagation Time): 0.745
- (Clock Delay at Starting Point): 4.157
- (Clock Latency at Starting Point): 0.000
= Slack (critical): 0.094
The Synplify Premier software does not automatically forward annotate
constraints for derived clocks. Therefore, a clock generated from a set of flip-
flops and logic requires you to add a constraint in the UCF file. As a recom-
mendation, derive the clock period the same as the original clock and add a
2-cycle multicycle path from the clock to itself. Better solutions will be
provided in the future.
Instantiating Special I/O Standard Buffers for Virtex
The software supports all the I/O Virtex standards, like HSTL_*, CTT, AGP,
PC133_*, PC166_*, etc. You can either instantiate these primitives directly, or
specify them with the xc_padtype attribute.
1. To instantiate I/O buffers, use code like the following to specify them.
module inst_padtype(a, b, clk, rst, en, bidir, q) ;
input [0:0] a, b;
input clk, rst, en;
inout bidir;
output [0:0] q;
reg [0:0] q_int;
wire a_in, q_in;
IBUF_AGP i1 (.O(a_in), .I(a) ) ;
IOBUF_CTT i2 (.O(q_in), .IO(bidir) , .I(q_int), .T(en) ) ;
OBUF_F_12 o1 (.O(q), .I(q_in) ) ;
March 2014 1069
always @(posedge clk or posedge rst)
if (rst)
q_int <= 1b0;
else
q_int <= a_in & b;
endmodule
2. To specify the I/O buffers with an attribute, add the attribute in the
SCOPE window (refer to Specifying SCOPE Constraints, on page 263 for
details) or in the source code, as the following example illustrates.
module inst_padtype(a, b, clk, rst, en, bidir, q) ;
input [0:0] a /* synthesis xc_padtype = "IBUF_AGP" */, b;
input clk, rst, en;
inout bidir /* synthesis xc_padtype = "IOBUF_CTT" */;
output [0:0] q /* synthesis xc_padtype = "OBUF_F_12" */;
reg [0:0] q_int;
assign q = bidir;
assign bidir = en ? q_int : 1bz;
always @(posedge clk or posedge rst)
if (rst)
q_int <= 1b0;
else
q_int <= a & b;
endmodule
Reoptimizing with EDIF Files
You can add an EDIF file created by the Synplify Pro or Synplify Premier
software as a lower level module or you can resynthesize an EDIF file created
by the Synplify Pro or Synplify Premier tool at the top level of the hierarchy to
further refine and optimize your design.
To add an EDIF file created by the tool as a lower level module, follow these
steps:
1. Disable I/O insertion when creating the EDIF file as the file will not be
instantiated at the top level of the hierarchy.
2. Make sure the EDIF file name matches the module name.
3. Create a project and add the EDIF file to the design.
LO
1070 March 2014
To resynthesize an EDIF file created by the Synplify Pro or Synplify Premier
tool at the top level of the hierarchy, do the following:
1. Make sure your design does not include any mixed-language files.
2. Check that the EDIF file name matches the module name.
3. Create a project and add the EDIF file to the design.
4. Specify the EDIF file as the top-level design module by doing the
following:
Click Implementation Options and go to the Verilog or VHDL tab.
Enter the module name in the Top Level Module/Entity field. If your
module is not in the work library, first specify the library as
libraryName.moduleName.
Click OK.
5. Resynthesize your design.
Improving Xilinx Physical Synthesis Performance
The Synplify Premier tool is timing-driven; optimizations depend on timing
constraints and are applied until all constraints are met. Therefore, it is very
important that you adequately apply timing constraints and not over-
constrain the tool. This section includes guidelines for applying constraints.
Verify the consistency of constraints between synthesis and P&R:
Clock constraints
Clock-to-clock constraints
IO delays
Max-delay paths
DCM parameters
Register packing into IOB
March 2014 1071
LOC/RLOC constraints on macros (BUFG, DCM, RAMB, DSP, MULT,
etc.)
LOC/RLOC constraints on instances (Register, LUT, SRL, RAMS,
RAMD, etc.)
AREA_GROUP constraints
IDELAYCTRL and IDELAY constraints
Ensure that the final physical synthesis slack is negative, but no more
than 10-15% of the clock constraint.
Check the log file for Pre-placement timing snapshot.
If it indicates that a clock has positive slack at this point, but in the final
results the clock has negative slack, use the -route constraint for the
clock. This lets you to control the amount of early timing optimizations
for the clock domain. However, large -route values can degrade perfor-
mance. Therefore, to determine the correct -route value to use, start with
smaller values and increase iteratively. For example, start with half the
difference between the estimate and actual slack, or 5% of the clock
estimate, whichever is the smallest.
Experiment with ignoring the relationally-placed macro (RPM)
constraints.
RPMs (also known as RLOCs) can negatively affect results. You can
compare placement results using the Synplify Premier tool by setting the
global attribute xc_use_rpms to 0. For details on this attribute, see
xc_use_rpms, on page 544 in the Reference Manual.
Ensure placement for I/Os, Block Rams, and DSP48 devices.
This version of the tool uses the Xilinx placer to generate locations for
I/Os and block components. To avoid block component placement
problems, you need to lock placement. See Generating a Xilinx Coreloc
Placement File, on page 253 for information.
Running Post-Synthesis Simulation
For post-synthesis simulation with a Xilinx design, do the following:
1. Run synthesis as usual.
The run generates a vhm file, which references the synplify library:
LO
1072 March 2014
library synplify;
use synplify.components.all;
library UNISIM;
use UNISIM.VCOMPONENTS.all;
2. Set up the libraries.
Create a library called synplify and compile synplify.vhd into it. The
synplify.vhd file is located in installDirectory/lib/vhdl_sim.
Create a library called UINISIM, and compile the UNISIM simulation
library provided by Xilinx into it.
3. Compile the vhm file into work. For example:
vcom -work synplify installDirectory/lib/vhdl_sim/synplify.vhd
Working with Xilinx Place-and-Route Software
The following procedure shows you how to run the Xilinx place-and-route tool
from within the synthesis software.
1. Set the XILINX environment variable to point to your Xilinx software
installation directory.
2. Start the synthesis software and open a synthesized design.
3. Start the place-and-route software:
To start Xilinx Design Manager, select Options->Xilinx->Start Design
Manager.
To start Xilinx floorplanner, select Options->Xilinx->Start Floorplanner.
To start the ISE tool, select Options->Xilinx->Start ISE Project Navigator.
Limitations Using the Xilinx ISE Tool
Be aware of the following limitations when using the Xilinx ISE tool:
When you invoke the Xilinx ISE tool in either foreground or background
from Options->Xilinx->Start ISE Project Navigator, the synplicity.ucf file is not
added to the Project file automatically. You must manually add the
synplicity.ucf file to the project.
March 2014 1073
When you launch Xilinx ISE from the synthesis tool, default settings are
used. Any setting changes that you make to the Xilinx project seem to
disappear when you subsequently launch ISE.
Changes made to the Xilinx project are saved in the npl file in the working
directory. To override normal defaults, open the npl file saved previously,
before launching ISE.
LO
1074 March 2014
March 2014 1075
CHAPTER 21
Analyzing Power Activity
The Synplify Premier Activity Analysis feature can be used for designs
targeting Xilinx technologies. This feature captures switching activity data so
that you can analyze and ultimately optimize design power.
The following topics describe the details:
Activity Analysis Design Flow, on page 1076
Activity Analysis for Power Improvement Flow
Xilinx Place and Route from Synplify Premier
LO
Chapter 21: Analyzing Power Activity Activity Analysis Design Flow
1076 March 2014
Activity Analysis Design Flow
With the Activity Analysis feature, you run initial synthesis. You then option-
ally specify analysis design constraints to override the defaults and resynthe-
size using the analysis design constraints (adc) file. This generates the activity
report or SAIF file, which contains logic state and switching transition data for
each net in the design. You can use the data to optimize power in your
design. You can also read the SAIF file into third-party tools (such as Xilinx
ISE) for power-aware routing.
This is an overview of the flow:
The details of the steps are described here:
Specifying Activity Analysis Constraints, on page 1077
Assigning Activity Analysis Constraints, on page 1078
Generating the SAIF File, on page 1078
Generate the Activity
Analysis Report (SAIF)
Assign Analysis
Design Constraints
(optional)
Activity Analysis Generation
Place and route
(third party)
Power Analysis
(third party)
After Synthesis
(.srm)
Activity Analysis Design Flow Chapter 21: Analyzing Power Activity
March 2014 1077
Specifying Activity Analysis Constraints
You can override the defaults for logic state and state transitioning using the
syn_state1_prob and syn_trans_prob attributes, respectively, which are the
analysis design constraints (adc) for activity analysis reporting. Specify adc
constraints only if you want to override the default probabilities for logic state
high (default is 0.5) and logic state transitioning (default is 0.2). You can set
these attributes on input ports. (See syn_state1_prob, on page 1081 and
syn_trans_prob, on page 1082 for more details.)
To define analysis design constraints:
1. Select File->New.
Click on Analysis Design Constraints.
Enter the file name.
Specify the path name if you want to change the default location.
Click OK.
This opens the SCOPE editor.
LO
1078 March 2014
2. Click on the Attributes tab and specify the probability values.
Set the constraints on input ports. See syn_state1_prob and
syn_trans_prob below for more details.
Assigning Activity Analysis Constraints
After you synthesize the design, you can assign analysis design constraints.
This task consists of assigning the syn_state1_prob and/or syn_trans_prob attri-
butes. You only need to create these constraints if you want to override the
tools defaults for state or switching probabilities. See syn_state1_prob and
syn_trans_prob for default information.
To assign constraints, follow these steps:
1. Define constraints in an analysis design constraint file (adc). See
Specifying Activity Analysis Constraints, on page 1077 for details.
2. Add the adc files to your project.
Generating the SAIF File
The SAIF file is the activity analysis report.
1. From the GUI, select Analysis->Activity Analysis Generation.
Activity Analysis Design Flow Chapter 21: Analyzing Power Activity
March 2014 1079
2. Enter the parameters for the report:
Enter a name for the file in SAIF File.
In the Constraint Files section, check the activity design constraint files
(adc) that you want to include in the analysis data. The adc file
contains constraints defined by the syn_state1_prob and syn_trans_prob
attributes. See Specifying Activity Analysis Constraints, on page 1077
for information on specifying these constraints.
Click Generate.
This generates the saif file.
3. Analyze the information in the Technology view.
When you generate an activity analysis report using the Annotated SRM
File switch, the Technology view provides information on the net
switching and transitioning data. The data includes information for
transitioning (pwr_trans_formal) and logic state (pwr_state1_formal) values
from the simulation tool. It also includes a .pwr_rename value.
LO
1080 March 2014
4. After you have generated the saif file, you can optionally use it with
third-party tools:
Estimate the power consumption for the design using a third-party
power analysis tool and the saif file as input. If you are targeting
Xilinx technologies, see Activity Analysis for Power Improvement Flow,
Run place and route for power driven-optimization using the saif file
as input. If you are targeting Xilinx technologies, see Xilinx Place and
Route using SAIF, on page 1088 for information.
Activity Analysis Constraints Chapter 21: Analyzing Power Activity
March 2014 1081
Activity Analysis Constraints
There are two activity analysis constraints that you can use to override the
default settings. Enter these constraints in the SCOPE Attributes tab.
syn_state1_prob, on page 1081
syn_trans_prob, on page 1082
The relationship between state and transition probabilities is as follows:
t is less than or equal to 2 * min (s, 1-s)
For example, if syn_state1_prob is 0.7, then syn_trans_prob cannot be larger than
0.6.
syn_state1_prob
Overrides the default probability for specified input ports to remain at logic
state 1 for the duration period. (A duration period default is 1 second.) This
attribute assigns the probability for logic state 1. The default value is 0.5 (or
50 percent)50 percent of the time the signal is high, and the other 50
percent of the time, the signal is low. Use this attribute only if you want to
override the default value of 0.5 for a high signal; value must greater than or
equal to 0, and less than or equal to 1.
.adc File Syntax and Examples
define_attribute syn_state1_prob {p:port} {probability_value}
The syntax above sets the logic state probability for specified input ports. For
example:
define_attribute syn_state1_prob {p:x[7:0]} {0.8}
See Also
syn_trans_prob, below.
Clock and Reset, on page 1082.
Assigning Activity Analysis Constraints, on page 1078.
LO
Chapter 21: Analyzing Power Activity Activity Analysis Constraints
1082 March 2014
syn_trans_prob
Overrides the default probability for logic state transition. The default transi-
tion probability is 0.2 (or 20 percent)20 percent of the time, the signal
switches from high to low or from low to high. (The default transition period is
1 second.) Use this attribute only if you want to override the default value of
0.2; value must greater than or equal to 0, and less than or equal to 1.
.adc File Syntax and Examples
define_attribute syn_trans_prob {p:port} {probability_value}
The syntax above sets the state transition probability for specified input ports.
For example:
define_attribute syn_trans_prob {p:x[7:0]} {0.1}
See Also
syn_state1_prob, above.
Clock and Reset, on page 1082.
Assigning Activity Analysis Constraints, on page 1078.
Clock and Reset
For multiple clock domains (clock groups), by default the software uses the
fastest clock on the port as the reference clock. The default values are in the
following table. For resets, the tool detects any input port reset and assigns
the defaults shown below.
You can override these defaults by specifying the syn_state1_prob or
syn_trans_prob in the adc file. (See Specifying Activity Analysis Constraints, on
page 1077.)
Clock Defaults Reset Defaults
state=1
transitions=2
state=0.001
transition=0
Activity Analysis for Power Improvement Flow Chapter 21: Analyzing Power Activity
March 2014 1083
Activity Analysis for Power Improvement
Flow
You can use the SAIF file from the Synplify Premier tool in Xilinx ISE power
analysis using (version 10.1 or later).
Topics include:
Power Improvement Flow
Xilinx Power Analysis
XPower Report
Xilinx Place and Route using SAIF
Power Improvement Flow
Rerun Synthesis
Using .saif File
Generate the Activity
Analysis Report (SAIF)
SAIF for Power Improvement
(Switching Activity Interchange
Format File .saif)
Synthesize the Design
(Synplify Premier Tool)
Compare
results
(Switching Activity Interchange
Format File .saif)
LO
Chapter 21: Analyzing Power Activity Activity Analysis for Power Improvement Flow
1084 March 2014
Here is the flow:
2. Generate the saif file. See Assigning Activity Analysis Constraints, on
page 1078.
3. Input the saif file into Xilinx ISE to obtain an XPower report. See Xilinx
Power Analysis, on page 1084.
4. Use the saif file in the Xilinx ISE place and route tool to enable power-
aware placement and routing.
5. Then, recalculate the power using XPower analysis to determine how
much improvement is gained by the SAIF and Xilinx ISE power-aware
placement and routing.
6. Compare the results in Step 5 to the one obtained in Step 3 above.
To use the saif file with Power Analysis in ISE:
1. Right-click on XPower Analyzer, and select Properties.
March 2014 1085
2. Enter the path name and saif file in the Load Simulation File field.
3. Click Run.
This generates the power report. See XPower Report, on page 1085, for
an example.
XPower Report
This following figures include sections of a sample Xilinx XPower report.
LO
1086 March 2014
...
...
continued...
March 2014 1087
See the Xilinx documentation for the details on this report.
Power Details:
Clocks
Logic
Inputs
Power Improvement Guide
Outputs
LO
1088 March 2014
Xilinx Place and Route using SAIF
You can use the saif file in Xilinx ISE place and route tool using (version
10.1 or later). To use the saif file with ISE place and route:
1. Right-click on Place and Route, and select Properties.
2. Select the Power Reduction option.
3. Enter the path name and saif file in the Power Activity File field.
4. Click Run.
This generates the power report. See XPower Report, on page 1085, for
an example.
March 2014 1089
In the Synplify Premier tool, you can optionally add the -power and -activityfile
options to your Xilinx options file (xf.opt) and run place and route from the
synthesis environment. The following example shows where to add these
options to the file.
FLOWTYPE = FPGA;
#######################
## lib/xilinx/xf.opt ##
## Test file created ##
#######################
...
###########################
## Place & Route Options ##
###########################
## Type "par -h" for a detailed list of par command line options
###########################
Program par
-w; # Overwrite existing placed and routed
ncd
-power on;
-activityfile X:\testing\s2p.v5\results_2\s2p.saif;
-intstyle xflow; # Message Reporting Style: ise, xflow,
or silent
-ol high; # Overall effort level
-t 1; # Placer cost table entry.
#-xe c;
<design>_map.ncd; # Input mapped NCD file
<inputdir><design>.ncd; # Output placed and routed NCD
<inputdir><design>.pcf; # Input physical constraints file
END Program par
...
This generates the power report. See XPower Report, on page 1085, for an
example of this report.
LO
1090 March 2014
March 2014 1091
CHAPTER 22
Working with Synthesis Output
This chapter covers techniques for optimizing your design for various
vendors. The information in this chapter is intended to be used together with
the information in Chapter 10, Inferring High-Level Objects.
This chapter describes the following:
Passing Information to the P&R Tools, on page 1092
Generating Vendor-Specific Output, on page 1096
Invoking Third-Party Vendor Tools, on page 1098
LO
Chapter 22: Working with Synthesis Output Passing Information to the P&R Tools
1092 March 2014
Passing Information to the P&R Tools
The following procedures show you how to pass information to the place-and-
route tool; this information generally has no impact on synthesis. Typically,
you use attributes to pass this information to the place-and-route tools. This
section describes the following:
Specifying Pin Locations, on page 1092
Specifying Locations for Microsemi Bus Ports, on page 1093
Specifying Macro and Register Placement, on page 1094
Passing Technology Properties, on page 1094
Specifying Padtype and Port Information, on page 1094
Specifying Pin Locations
In certain technologies you can specify pin locations that are forward-
annotated to the corresponding place-and-route tool. The following procedure
shows you how to specify the appropriate attributes. For information about
other placement properties, see Specifying Macro and Register Placement, on
page 1094.
1. Start with a design using one of the following vendors and technologies:
Altera, Lattice, Microsemi, or Xilinx families.
2. Add the appropriate attribute to the port. For a bus, list all the bus pins,
separated by commas. To specify Microsemi bus port locations, see
Specifying Locations for Microsemi Bus Ports, on page 1093.
To add the attribute from the SCOPE interface, click the Attributes tab
and specify the appropriate attribute and value.
To add the attribute in the source files, use the appropriate attribute
and syntax. See the Reference Manual for syntax details.
Family Attribute and Value
Altera syn_loc {pin_number}
Passing Information to the P&R Tools Chapter 22: Working with Synthesis Output
March 2014 1093
Specifying Locations for Microsemi Bus Ports
You can specify pin locations for Microsemi bus ports. To assign pin numbers
to a bus port, or to a single- or multiple-bit slice of a bus port, do the
following:
1. Open the constraint file an add these attributes to the design.
2. Specify the syn_noarrayports attribute globally to bit blast all bus ports in
the design.
define_global_attribute syn_noarrayports {1};
3. Use the alspin attribute to specify pin locations for individual bus bits.
This example shows locations specified for individual bits of bus
ADDRESS0.
define_attribute {ADDRESS0[4]} alspin {26}
The software forward-annotates these pin locations to the place-and-
route software.
Lattice loc {pin_number}
Microsemi syn_loc {pin_number}
or
alspin {pin_number}
Xilinx syn_loc {pin_number}
or
xc_loc {pin_number}
See Specifying RLOCs, on page 1062 for details
about relative placement.
LO
Chapter 22: Working with Synthesis Output Passing Information to the P&R Tools
1094 March 2014
Specifying Macro and Register Placement
You can use attributes to specify macro and register placement in Microsemi
designs. The information here supplements the pin placement information
described in Specifying Pin Locations, on page 1092 and bus pin placement
information described in Specifying Locations for Microsemi Bus Ports, on
page 1093.
Passing Technology Properties
The following table summarizes the attributes used to pass technology-
specific information for certain vendors. For details about the attributes in
the table, see the Reference Manual.
Specifying Padtype and Port Information
For many vendors, you can use attributes to specify technology-specific port
information or padtype.
For ... Use ...
Relative placement of Microsemi
macros and IP blocks
alsloc
define_attribute {u1} alsloc {R15C6}
Placement of Lattice ORCA input or
output registers next to I/O pads
orca_padtype
define_attribute { load } orca_padtype "IBT"
Vendor Attribute for passing properties
Lattice ORCA orca_props
define_attribute {p:data_in} orca_props {LEVELMODE=LVDS}
Xilinx Specify the Xilinx properties directly in the source code. The
software passes them to the place-and-route tool. For example:
attribute INIT of RAM1 : label is "0000";
or
/* synthesis INIT_xx = "value" */
Passing Information to the P&R Tools Chapter 22: Working with Synthesis Output
March 2014 1095
Information Vendor Attribute
Altera altera_io_powerup
define_attribute {seg [31:0]} altera_io_powerup {high}
Padtype Lattice ORCA orca_padtype
define_attribute {AIN[3]} orca_padtype {IBT}
Xilinx xc_padtype
define_attribute {a[3:0]} xc_padtype {IBUF_GTLP}
Xilinx xc_isgsr
define_attribute {bbgsr.gsrin} xc_isgsr {1}
Xilinx xc_pullup/xc_pulldown
define_attribute { port_name } xc_pulldown { 1 }
LO
Chapter 22: Working with Synthesis Output Generating Vendor-Specific Output
1096 March 2014
Generating Vendor-Specific Output
The following topics describe generating vendor-specific output in the
synthesis tools.
Targeting Output to Your Vendor, on page 1096
Customizing Netlist Formats, on page 1097
Targeting Output to Your Vendor
You can generate output targeted to your vendor.
1. To specify the output, click the Implementation Options button.
2. Click the Implementation Results tab, and check the output files you need.
The following table summarizes the outputs to set for the different
vendors, and shows the P&R tools for which the output is intended.
Vendor Output Netlist P&R Tool
Altera Arria, Cyclone,
Max-II, and Stratix
Verilog (.vqm) Quartus II
Lattice (newer device
families)
EDIF (.edf) Diamond
Lattice Classic
(Mach/isp device
families)
EDIF (.edf) or .src ispExpert
Lattice Classic (Orca) EDIF (.edn) ispLEVER
Microsemi EDIF (.edn)
*_sdc.sdc
Libero SoC or IDE
Xilinx 7 Series EDIF/VM
(.edf or .vm)
Vivado
Xilinx Virtex-6 and
Spartan-6 and earlier
families
EDIF (.edf) Design Manager or ISE
Project Navigator
Xilinx CoolRunner EDIF (.edf) or .src Web Fitter for EDIF files,
Minc for *.src files
Generating Vendor-Specific Output Chapter 22: Working with Synthesis Output
March 2014 1097
3. To generate mapped Verilog/VHDL netlists and constraint files, check
the appropriate boxes and click OK.
See Specifying Result Options, on page 161 for details about setting the
option. For more information about constraint file output formats and
how constraints get forward-annotated, see Generating Constraint Files
for Forward Annotation, on page 132.
Customizing Netlist Formats
The following table lists some attributes for customizing your Microsemi,
Altera, and Xilinx output netlists:
For ... Use ...
Netlist formatting syn_netlist_hierarchy (Altera, Xilinx, Microsemi)
define_global_attribute syn_netlist_hierarchy {0}
EDIF formatting
(Xilinx)
syn_edif_bit_format (Xilinx)
define_global_attribute syn_edif_bit_format {%n<%i>}
syn_edif_name_length (Xilinx)
define_global_attribute syn_edif_name_length { restricted }
syn_edif_scalar_format (Xilinx)
define_global_attribute syn_edif_scalar_format {%u}
Bus specification syn_noarrayports (Altera, Xilinx, Microsemi)
define_global_attribute syn_noarrayports {1}
LO
Chapter 22: Working with Synthesis Output Invoking Third-Party Vendor Tools
1098 March 2014
Invoking Third-Party Vendor Tools
You can invoke third-party tools from within the Synopsys FPGA synthesis
products, and configure the locations and common arguments for the tools.
This capability lets you modify source files or libraries or debug problems
from within the third-party tool, without leaving the synthesis environment.
You can invoke preconfigured tools or add your own. The process consists of
two steps:
Configuring Tool Tags, on page 1098
Invoking a Third-Party Tool, on page 1099
Configuring Tool Tags
A tool tag is a configuration definition for a tool you want to invoke from the
synthesis interface. You define a tool tag to set up the third-party tool you
want to use. The synthesis software has some popular applications already
configured for you to use when the synthesis software starts up: System
Designer, Altera MegaWizard, Xilinx EDK, and Xilinx Coregen. The following proce-
dure shows you how to define your own tool tags, or add command
arguments. Use this to specify other tools, other versions of a tool, or to run a
tool with different arguments.
1. Select Options->Configure 3rd Party Tool Options from the Project view.
Invoking Third-Party Vendor Tools Chapter 22: Working with Synthesis Output
March 2014 1099
2. Define the application tag information for the tool you want to invoke.
Specify the application you want to invoke in Application Tag Name.
Specify how you want to invoke the application tool. If you want to
run the tool directly from the UI, select Direct Execution. If your
application is a Tcl procedure, select TCL Mode.
Specify the location of the application executable or Tcl procedure
name in Application Name with Path or Tcl Procedure Name.
Specify any command arguments you want in the Command Argument if
any field. You can use this to define a new tool tag or to add
arguments to a tool tag that is already defined.
For a list of predefined command arguments, click the + button and
select them from the list. Otherwise, type the command arguments.
For the System Designer and other internal Synopsys tools, you must
select $SynCode from the Command Argument if any field.
Click Apply.
Click Close.
The tool saves these settings in the FPGA synthesis tool .ini file and
retrieves them for subsequent invocations. For information about
invoking a third-party tool, see Invoking a Third-Party Tool, on
page 1099, next.
Invoking a Third-Party Tool
You can define tool tags globally and then use these tool tags to run the third-
party tool from the Project view for the specified tool tag only. Some common
tool tags are preconfigured and are read when the application starts up. You
can add or modify existing tool tags or define your own Tcl procedures to
invoke within the FPGA synthesis tools.
1. Define a tool tag for your application, as described in Configuring Tool
Tags, on page 1098.
2. Right-click in the Project view on a file or folder which is configured to
run the vendor tool, and select Launch Tools->Run Vendor Tool from the
popup menu.
This dialog box automatically displays tool tag information associated
with the file or folder. If no tool tag information is specified, look for the
parent hierarchy and edit or change it, if necessary.
LO
1100 March 2014
3. To associate a file or folder with a particular third-party tool, do the
following:
Select the file or folder in the Project view. If you select a folder, the
third-party tool is associated with all the files in the folder. If you
associate a tool with a file, this setting overrides the folder setting.
Right-click a file or folder and select Launch Tools->Run Vendor Tool from
the popup menu.
In the Vendor Tool Invocation dialog box, select the application in
Application Tag Name.
Include any additional options you want to use with this file when
you invoke the vendor tool. You can set command arguments now, if
you did not configure them earlier.
Verify the command string in the dialog box.
Click Save, and Close. The third-party tool is associated with the file or
folder and appears in the Launch Tools menu.
4. To invoke an associated third-party tool for a file or folder, do the
following:
Right-click the file or folder in the Project view.
Select Launch Tools-><Third-Party Tool> from the popup menu. The
synthesis tool automatically runs the tool or Tcl procedure as
specified.
Invoking Third-Party Vendor Tools Chapter 22: Working with Synthesis Output
March 2014 1101
5. To invoke the tool at the same time that you associate a third-party tool
with a file or folder, or to add additional arguments on the fly, do the
following:
Right-click a file or folder and select Launch Tools->Run Vendor Tool from
the popup menu.
In the Vendor Tool Invocation dialog box, select the application in
Application Tag Name.
Include any additional options you want to use with this file when
you invoke the vendor tool. You can set command arguments now, if
you did not configure them earlier.
Verify the command string in the dialog box.
Click Save. The tool and arguments you specified is associated with
the file or folder and appears in the Launch Tools menu.
If you defined a new tool tag, the 3rd Party Tool Configuration dialog box
appears. After saving the settings here, go back to the Vendor Tool
Invocation dialog box. You are prompted to save this information to the
project file before invoking the third-party tool.
Click the Run button in the Vendor Tool Invocation dialog box. The
synthesis tool launches the third-party tool or runs the Tcl procedure
with the arguments you specified.
These settings are saved in the FPGA synthesis tool ini file, from where
it can be retrieved for subsequent invocations.
LO
1102 March 2014
March 2014 1103
CHAPTER 23
Running Post-Synthesis Operations
The following topics describe how to run post-synthesis operations, like
place-and-route and verification, with compatible tools:
Running P&R Automatically after Synthesis, on page 1104
Running Altera Quartus II Incrementally, on page 1108
Running Xilinx Vivado Place-and-Route, on page 1114
Running Vivado Incrementally, on page 1126
Running Xilinx ISE Incrementally, on page 1131
Working with the Identify Tools, on page 1142
Netlist Editing, on page 1151
VIF Formal Verification Flows, on page 1156
Simulating with the VCS Tool, on page 1162
Using VCD/Identify with HDL Analyst, on page 1167
LO
Chapter 23: Running Post-Synthesis Operations Running P&R Automatically after Synthesis
1104 March 2014
Running P&R Automatically after Synthesis
Altera, Microsemi, Xilinx
You can run place-and-route automatically from within the tool or in batch
mode for certain vendor devices. The following diagram illustrates the flow.
For detailed procedures, see the following:
Integrating Synthesis and Place-and-Route in One Run, on page 1104
Running the Integrated Synthesis and Xilinx ISE Flow, on page 1105
Releasing the Synthesis License During Place and Route, on page 1107
Integrating Synthesis and Place-and-Route in One Run
Altera, Xilinx
You can run the place-and-route tool for your target technology automatically
after synthesis.
1. Check the Release Notes and make sure that you are using the correct
version of the P&R tool.
2. Set the PATH variable to point to the place-and-route tool.
3. To manually launch the P&R tool in Altera and Xilinx technologies, do
the following:
For Altera designs, select the run option you want from the Options->
<Altera_tool> menu. The tool launches and displays the P&R tool
interface. You can configure your settings and run P&R.
For Xilinx designs, select the run option you want from the Options->
Xilinx menu. The tool launches and displays the place-and-route tool
user interface, places the synthesis-generated netlist in a Xilinx
project, and names the project. Configure your Xilinx project settings
in the place-and-route tool. Depending on the device family and the
P&R tool, follow the detailed setup steps in Running the Vivado Flow,
on page 1118, or Running the Integrated Synthesis and Xilinx ISE
Flow, on page 1105.
Running P&R Automatically after Synthesis Chapter 23: Running Post-Synthesis Operations
March 2014 1105
4. To automatically run the P&R tool after synthesis completes, do the
following:
If necessary, set up a place-and-route implementation as described in
Creating a Place and Route Implementation, on page 229. You need a
P&R implementation for physical synthesis flows, or if you want to
use post-P&R data for backannotation.
Click on the Add P&R Implementation button. In the dialog box, select
the P&R implementation you want to run and enable Run Place & Route
following synthesis.
The tool automatically runs P&R after synthesis.
Running the Integrated Synthesis and Xilinx ISE Flow
Xilinx
This is not a Vivado P&R flow, but you can run this with the ISE P&R tool.
1. In the Implementation Results tab of the Implementation Options dialog
box, disable Use Vivado for Place and Route.
The Result Format is set to edif output. For this flow, the synthesis tool
maps the output netlist to edif format and the timing constraints and
netlist properties to the synplicity.ucf file. You must run ISE place and
route.
LO
Chapter 23: Running Post-Synthesis Operations Running P&R Automatically after Synthesis
1106 March 2014
2. Select the appropriate constraint file for your design.
The format of timing constraints in the sdc or fdc file must be the
Synopsys standard timing format; if the file contains any legacy timing
constraints such as define_clock, the synthesis tool generates an error
message. To convert these constraints for Vivado flows, see the sdc2fdc,
on page 106.
3. Set P&R options as described in Running P&R Automatically after
4. Run synthesis and place-and-route with ISE.
See the guidelines below for some tips. You can release the synthesis
tool license while place-and-route is running by following the instruc-
tions in Releasing the Synthesis License During Place and Route, on
page 1107.
Running P&R Automatically after Synthesis Chapter 23: Running Post-Synthesis Operations
March 2014 1107
Guidelines for Running Xilinx P&R
The following table lists some tips for running various phases of Xilinx place-
and-route:
Releasing the Synthesis License During Place and Route
When invoking a third-party place-and-route tool from the FPGA synthesis
tool, you can choose to have place and route continue to run even after
exiting the synthesis tool so that it does not consume an FPGA license. The
software lets you release the license for the synthesis tool and run the place-
and-route tool in batch mode.
To release the FPGA license, specify the following command:
toolName -batch -license_release
Where toolName can be any of the following keywords: synplify,
synplify_pro, synplify_premier, or synplify_premier_dp.
In synthesis batch mode (synbatch), the -license_release option obtains all the
synthesis licenses that are checked out for the session and checks them in
immediately after the place-and-route job is launched.
When licenses are released, you see the following message is generated:
Exiting session due to -license_release option
NGDBuild Use the user constraint file (synplify.ucf) generated after synthesis.
From the command line, read the .ucf file into Xilinx place-and-route
NGDBuild with the -uc command.
MAP Do not map to 5-input functions. Do not use the -k command line
option. For information about using map with compile points, see
Synthesizing Compile Points, on page 644.
PAR Do not use the default effort level of std. Instead, set it to high using the
-ol high command line option. For information about using par with the
Synplify Pro and Synplify Premier tools compile-point synthesis flows,
see Synthesizing Compile Points, on page 644.
LO
Chapter 23: Running Post-Synthesis Operations Running Altera Quartus II Incrementally
1108 March 2014
Running Altera Quartus II Incrementally
Altera
The Altera place-and-route tool supports incremental place and route. It
preserves design implementation data so that it can make incremental place-
and-route updates as needed. For complete details on this flow, see the Altera
documentation. You can leverage this Quartus functionality by combining it
with synthesis compile points to create an integrated flow from RTL partitions
to place-and-route. There are two ways to use compile points in Altera flows,
based on your design goals:
Quartus II Incremental Compilation Flow with Fast Fit
Use this flow when you are trying to save runtime as you iterate through
the flow and make changes. Typically, you use this earlier in the design
cycle. In this flow, Quartus II runs with the Fast Fit option. To get even
more runtime savings, combine the Fast Fit flow with automatic compile
points, fast synthesis, and multiprocessing during synthesis.
Quartus II Incremental Compilation Flow
Use this flow when you are trying to converge, and design preservation
and stability are your primary goals. The same manual RTL compile
points defined during synthesis are maintained through place and
route. If a compile point is modified, Quartus reruns place and route for
only those partitions that have been modified; all others are preserved.
To reduce runtime while running this flow, use multiprocessing.
Quartus II Incremental Compilation Flow with Fast Fit
Use this flow in the Synplify Premier tool for incremental changes when you
are trying to reduce runtime (see Running Altera Quartus II Incrementally, on
page 1108). For the Synplify Pro tool, you must enable the Fast Fit option
Design Goal Altera Flow
Save runtime, or iterate through P&R incrementally. Incremental P&R
with Fast Fit
Stabilize the design and preserve completed parts of the design.
Only run incremental P&R on the parts that have changed.
Incremental P&R
Running Altera Quartus II Incrementally Chapter 23: Running Post-Synthesis Operations
March 2014 1109
manually. Use the Fast Fit option when you need to make minor changes to a
design, like making small HDL changes, moving pin locations, changing attri-
butes, or modifying timing constraints.
The following procedure describes the details of running synthesis and the
Fast Fit flow:
1. Set up the synthesis project.
Create compile points, as described in Synthesizing Compile Points,
on page 644. You can create automatic or manual compile points,
but inferring automatic compile points speeds up runtime.
In the Synplify Premier tool, enable Fast Synthesis mode. This
automatically enables the Quartus Fast Fit option. If you are using the
Synplify Pro tool for synthesis, you must manually set the Fast Fit
option in the Quartus tool.
To speed up runtime, use multiprocessing.
Target a supported Altera device.
Click the Add P&R Implementation button in the Project view and set up
a place-and-route implementation so that it runs automatically after
synthesis. See Running P&R Automatically after Synthesis, on
2. Do an initial run of synthesis, placement, and routing. Enable the
Quartus Fast Fit option.
Quartus runs automatically after synthesis completes. It uses low effort
to place and route the design.
3. Implement small changes to the design.
4. Rerun synthesis and P&R.
When you rerun synthesis and P&R on subsequent runs, the tools work
incrementally and only rerun the compile points that have been
modified. Compile points that were not affected by changes are
preserved from the previous run. This results in significant runtime
improvements, as the entire design does not need to be rerun.
LO
1110 March 2014
Quartus II Incremental Compilation Flow
In the Altera Quartus II Incremental Compilation flow, the synthesis software
automatically generates a Tcl script which creates design partition assign-
ments. The Quartus II software use this Tcl script to determine if partitions
should be preserved from previous place and route results when you recom-
pile the design. If a partition is removed, the Tcl script detects this and
forward-annotates an updated VQM netlist.
Use this flow when your goal is to stabilize your design. This figure summa-
rizes the flow for working with Quartus incremental compilation, and the
steps that follow it provide more detail:
1. Set up the project.
Select the target device. Quartus II Incremental Compilation supports
most Stratix and newer device families.
Set implementation options and constraints.
March 2014 1111
2. Compile the design, and define manual compile points in the top-level
constraint file.
Click the Compile Points tab, and set compile points, as described in
Defining Manual Compile Points, on page 652.
Set the compile point type to hard, locked or locked, partition to run this
flow. The following example shows the compile point for v:ff_cp.
Create a compile point constraint file and set constraints for each
compile point you define. This is especially important if you use a
bottom-up flow.
Save the constraint file.
3. Click Run to synthesize the design and check the compile point summary
in the log file.
Check the log file for messages like those displayed below.
LO
1112 March 2014
The synthesis tool generates a VQM file where the compile points are
defined with syn_hier="locked,partition" attributes. For subsequent
synthesis runs, the tool also automatically generates a Tcl script which
creates design partition assignments.
See the post synthesis results for the specified implementation directory,
located in the design.tcl file under the Incremental Compilation header. Each
compile point design partition defined with syn_hier="locked,partition"
generates a vqm netlist file that is used by Quartus II for incremental
place and route.
4. Run the Quartus II place-and-route tool.
The Quartus II software uses the compile point VQM files, as well as the
Tcl script file generated from the synthesis tool to determine if partitions
should be preserved from previous place and route results when you
recompile the design.
5. Make any required changes, and re-synthesize the modified design.
The synthesis tool only resynthesizes and optimizes the updated
modules. In the VQM file generated for this synthesis run, the tool does
not change the timestamp of a compile point if it has not changed since
the previous run; it preserves the old timestamp. Updated modules get a
new timestamp.
Mapper Messages
March 2014 1113
For an incremental run, the software only resynthesizes compile points
whose logic, implementation options, or timing constraints have
changed.
The following figure illustrates incremental synthesis by comparing
compile point summaries. After the first run, a logic change in the ff_cp
module. The figure shows that incremental synthesis resynthesizes ff_cp
(logic change), but does not resynthesize test because the logic did not
change.
6. Rerun the Quartus II tool to place and route the design.
The Altera Quartus II software checks the compile point file with the
corresponding file from the previous run, and incrementally places and
routes only those partitions that have changed, using the information
from the updated files. It leaves the other partitions untouched, re-using
information from the previous run.
Incremental Run Log Summary
Not resynthesized
Logic changes; compile
point resynthesized
LO
Chapter 23: Running Post-Synthesis Operations Running Xilinx Vivado Place-and-Route
1114 March 2014
Running Xilinx Vivado Place-and-Route
Xilinx
Xilinx Vivado Integrated Design environment (IDE) is the recommended
place-and-route tool for designs using the Xilinx 7 Series (Virtex-7, Kintex-7,
and Artix-7) devices. This place-and-route tool is not backward compatible,
so does not support Xilinx Virtex-6 and older devices.
The FPGA synthesis tools can be run with the Vivado place-and-route tool for
the following processes: Synplify Pro logic synthesis, Synplify Premier with
fast synthesis, and Synplify Premier with enhanced optimization.
For details, see the following sections:
Vivado Place-and-Route Design Flow, on page 1115
Setting Vivado Environment Variables, on page 1117
Running the Vivado Flow, on page 1118
Customizing Vivado Place and Route Options, on page 1122
Running Xilinx Vivado Place-and-Route Chapter 23: Running Post-Synthesis Operations
March 2014 1115
Vivado Place-and-Route Design Flow
There are two Vivado place-and-route (P&R) design flows, Flow 1, and Flow 2.
The diagram shows the required inputs and outputs with these flows for the
synthesis tools to run Vivado successfully. In both flows, design constraints
are forward-annotated to place-and-route through an xdc file. The file
includes Synopsys standard timing constraints and non-timing design
constraints.
Flow 1 (Default)
The synthesis tool generates an edif netlist for place and route.
Constraints are forward-annotated through an _edif.xdc file.
Flow 2
The synthesis tool generates a vm structural Verilog netlist for place and
route instead of the edif netlist. Constraints are forward-annotated
through an xdc file.
LO
1116 March 2014
The _edif.xdc and xdc constraint files are separate for each flow and include
formats that cannot be mixed.
For details about running through these flows, see the following topics:
Setting Vivado Environment Variables, on page 1117
Running the Vivado Flow, on page 1118
Customizing Vivado Place and Route Options, on page 1122
Limitations to Vivado Support, on page 1116
Limitations to Vivado Support
Vivado P&R support includes the following limitations:
Designs with IP cores
For secure and non-secure NGC/NGO cores, you must use the
synthesis flow that generates the edif netlist and xdc constraint file
for Vivado P&R.
For secure cores that are generated with Vivado software, the
encrypted IP cannot be integrated into the Vivado flow so you must
black box it in the synthesis tools.
Input constraints in UCF/NCF file format are not supported in the
synthesis tools. You must manually convert the constraints to FDC file
format, before adding the constraints for synthesis and that are forward
annotated to the Vivado P&R tool.
Input constraints in XDC file format are not supported in the synthesis
tools. You must manually convert these timing constraints to Synopsys
timing constraints format (SDC/FDC) before adding the constraints for
synthesis and that are forward-annotated to the Vivado P&R tool. Also,
other non-timing constraints in the XDC file must be added to the
Vivado P&R run.
On Linux, Vivado P&R only runs on Red Hat Enterprise Linux 5 or later.
March 2014 1117
Setting Vivado Environment Variables
To successfully launch the Vivado tool, do the following:
1. Check the Release Notes and make sure that you are using the
recommended versions of the ISE and Vivado tools.
2. Set both the XILINX and XILINX_VIVADO environment variables to point to
their respective installation locations.
On Linux platforms, set it at as follows:
XILINX=/remote/edaTools/14.1/ISE_DS/ISE
XILINX_VIVADO=/remote/edaToolkits/Vivado/2012.1
For Windows, set the variables from the Control Panel:
Make sure that the ISE and Vivado variables point to the same Xilinx
version; for example ISE 14.3 and Vivado 2012.3. This is because the
LO
1118 March 2014
Vivado tool uses some ISE executables, so you must point to compatible
versions of these tools.
The XILINX variable is used for ngc2edif conversion as well as to load
BRAM primitives (BRAM_SDP_MACRO) automatically from the Xilinx
installation. If you do not have a variable set for a valid Xilinx installa-
tion at runtime, manually add the BRAM_TDP_MACRO.v file containing
the unimacro definition to the project.
Running the Vivado Flow
To run the integrated synthesis and Vivado P&R flow using either an edif or vm
netlist (Flows 1 and 2 in Vivado Place-and-Route Design Flow, on page 1115),
follow the steps below:
1. Create a synthesis project file, and set Vivado environment variables as
described in Setting Vivado Environment Variables, on page 1117.
2. Specify the netlist flow.
On the Implementation Results tab of the Implementation Options panel,
enable Use Vivado for Place and Route.
For the Edif netlist flow, select edif from the Result Format pull-down
menu. This is the default.
For the Structural Verilog netlist flow, select vm from the Result Format
pull-down menu. The Write Mapped Verilog Netlist option is enabled and
greyed out. You cannot change this setting.
March 2014 1119
3. Set other options and synthesize as usual.
After synthesis, the tool generates the following files, depending on
which output netlist flow you specified:
4. If you want to generate a netlist in another format without rerunning
synthesis, do the following:
Change the Result Format on the Implementation Results tab of the
Implementation Options panel. The figure below shows it being set to
edif after a vm run.
EDIF Flow Structural Verilog Flow
edif Netlist vm Netlist
(Can be used for simulation and formal verification, as
well as Vivado P&R)
_edif.xdc Constraints xdc Constraints
Enable/Disable
Select vm/edif
LO
1120 March 2014
Select the Run->Write Output Netlist Only menu option from the Project
view. This generates only the netlist.
You can also choose to run the integrated synthesis and ISE place-
and-route flow instead, but this is not a Vivado P&R flow. For
information about this flow, see Running the Integrated Synthesis and
Xilinx ISE Flow, on page 1105.
Select the appropriate constraint file for your design.
The sdc or fdc file can only contain Synopsys standard timing
constraints and non-timing design constraints. If the sdc file contains
any legacy timing constraints such as define_clock, the synthesis tool
generates an error message. To convert these constraints for Vivado,
see sdc2fdc, on page 106.
5. Add a place-and-route implementation to your project by right-clicking
the implementation and selecting Add Place & Route or by clicking the Add
P&R Implementation button in the Project view.
For details, see Creating a Place and Route Implementation, on
page 229. Once you click OK, the P&R implementation directory (pr_1) is
created in your project by default. In the following example, the P&R
March 2014 1121
directory name has been changed to par_1. All P&R revisions are written
to this directory.
6. Run Vivado place-and-route.
To integrate the P&R step and run the place-and-route tool
automatically after synthesis, enable the Run Place & Route following
synthesis option.
After synthesis, the tool writes output files to the par_1 P&R directory
by default, but you can specify another directory, if necessary. The
synthesis tool also copies the netlist and constraint files to the par_1
P&R directory.
The synthesis tool also generates the run_vivado.tcl file in the par_1 P&R
directory, and then calls and executes run_vivado.tcl in batch mode.
You can also use the run_vivado.tcl file to run manually in batch mode.
You can edit the place-and-route options before running Vivado,
LO
1122 March 2014
using the procedure described in Customizing Vivado Place and Route
Check the P&R results in the vivado.log file.
Customizing Vivado Place and Route Options
After synthesis in the Vivado flow, the tool automatically generates a
run_vivado.tcl file which contains default options to run Vivado. You can use
the default file, or create a new options file or customize an existing options
file, as described below.
1. Right-click the place and route implementation and select P&R Options.
2. To create a new options file for run_vivado.tcl, follow these steps:
Click Create New Options File in the Add New Place & Route Task dialog box.
The tool creates a new run_vivado.tcl file using the standard options as
the template. For subsequent designs, you can select any P&R
options file from the list to use as a template.
Open this file in the Project view, and specify the options you want.
See Vivado P&R Option File, on page 1123 for an example of the file
and a description of some of the options.
March 2014 1123
3. To edit an existing options file, click Existing Options File, open the file in
the Project view by double-clicking it, and edit the options.
Vivado P&R Option File
Some of the important Vivado place-and-route options are listed in the
following table, but refer to the Xilinx documentation for a definitive list of the
Vivado Tcl commands and their syntax. An example of the options file that is
generated after synthesis follows the table.
#################################################
### SET DESIGN VARIABLES ###
#################################################
set DesignName CameraOpenSource"
set FamilyName "VIRTEX7"
set DeviceName "XC7VX980T"
Option Description
link_design Creates a design from a netlist. Equivalent to the ISE ngdbuild
command.
link_design [-name <arg>] [-part <arg>] [-constrset <arg>] [-top <arg>]
[-quiet] [-verbose]
opt_design Performs logic optimizations on the input netlist. Equivalent to
the ISE MAP command. All optimizations are on by default.
opt_design [-sweep] [-retarget] [-propconst] [-remap] [-resynth <arg>]
[-mode <arg>] [-effort_level <arg>] [-quiet] [-verbose]
place_design Automatically places ports and cells while optimizing for timing,
wire length and congestion. Equivalent to the ISE MAP command.
place_design [-effort_level <arg>] [-no_timing_driven] [-quiet] [-verbose]
route_design Routes the placed design. Equivalent to the ISE PAR command.
route_design [-unroute] [-re_entrant <arg>] [-nets <args>] [-physical_nets]
[-pin <args>] [-effort_level <arg>] [-no_timing_driven] [-preserve]
[-delay] [-free_resource_mode] -max_delay <arg> -min_delay <arg>
[-quiet] [-verbose]
set_param
write_ncd.noDRC
1|0
Use it to turn off checks before writing an ncd and to enable the
checks after the ncd is written. Do this to prevent the flow from
erroring out because not all the I/O pads and pins are specified.
write_checkpoint Use this to save intermediate netlists at any point in the P&R run.
report_* Generates various kinds of reports.
BITSTREAM Generates a bitstream even if you have errors.
LO
1124 March 2014
set PackageName "FFG1930"
set SpeedGrade "-1"
set TopModule CameraOpenSource"
set PartName "XC7VX980TFFG1930-1"
set InputMode "EDIF
#################################################
### SETUP DESIGN ###
#################################################
set_property target_part ${PartName} [current_fileset -constrset]
set_property design_mode GateLvl [current_fileset]
if {${InputMode} == "EDIF"} {
set_property edif_top_file ${DesignName}.edf [current_fileset]
if {[file exists ${DesignName}.edf]} {read_edif
${DesignName}.edf }
if {[file exists ${DesignName}_edif.xdc]} { read_xdc
${DesignName}_edif.xdc }
set TopModule [find_top]
}
if {${InputMode} == "VM"} {
if {[file exists ${DesignName}.vm]} { read_verilog
${DesignName}.vm }
if {[file exists ${DesignName}.xdc]} { read_xdc
${DesignName}.xdc }
set TopModule [find_top]
set_property top ${TopModule} [current_fileset]
}
#################################################
### RUN DESIGN ###
#################################################
link_design
if {[file exists "clock_groups.tcl"]} {source clock_groups.tcl}
opt_design
place_design
catch {set_param write_ncd.noDrc 1}
write_ncd -force ${DesignName}_place.ncd
route_design
#set_property BITSTREAM.General.UnconstrainedPins {Allow}
[current_design]
write_ncd -force ${DesignName}.ncd
March 2014 1125
#################################################
### GENERATE REPORTS ###
#################################################
write_checkpoint -force post_place
report_utilization -file area.txt
report_utilization -slr -file slr.txt
report_timing_summary -nworst 3 -max_paths 3
write_checkpoint -force post_route
write_pcf -force ${DesignName}.pcf
report_io -file pinloc.txt
report_drc -file post_route_drc.txt
write_xdc -no_fixed_only -constraints valid -force
${DesignName}_post_par.xdc
#################################################
### SAVE VIVADO PROJECT ###
#################################################
save_project_as -force ${DesignName}
save_design -force
#################################################
### GENERATE BITSTREAM ###
#################################################
set_property BITSTREAM.CONFIG.OVERTEMPPOWERDOWN {Enable}
[current_design]
set_property BITSTREAM.GENERAL.COMPRESS {True} [current_design]
write_bitstream -force ${DesignName}.bit
LO
Chapter 23: Running Post-Synthesis Operations Running Vivado Incrementally
1126 March 2014
Running Vivado Incrementally
The incremental Xilinx Vivado flow saves runtime by preserving and reusing
placement and routing information for parts of the design that have not
changed, and only rerunning placement and routing for the modified parts of
the design. The Vivado incremental flow is the equivalent of the ISE Smart-
Guide flow, which is described in Xilinx SmartGuide Flow, on page 1132.
Use this flow when you are trying to save runtime as you iterate through and
make changes. This flow is best suited to designs with long place-and-route
runtimes. The initialization overhead of the incremental flow might not gain
you a lot in designs with shorter runtimes.
Running Vivado Incrementally Chapter 23: Running Post-Synthesis Operations
March 2014 1127
The following procedure provides details of the incremental Vivado flow:
1. Complete an initial synthesis run, followed by place-and-route with
Vivado.
Set up your design for running with Vivado, making sure that you
use version 2012.4 or later. See Running Xilinx Vivado Place-and-
Route, on page 1114 if you need details.
In the Implementation Results tab of the Implementation Options dialog box,
enable the Use Vivado for Place and Route option.
Add a place-and-route job to the synthesis implementation and
enable the Incremental Place and Route option in the Add New Place and
Route Task dialog box.
LO
1128 March 2014
Set other options and constraints and run synthesis and place-and-
route. The tool generates a vivado.log file under the pr_1 directory. The
log reports the runtime, which in the example below is 00:00:00.14.
The tool saves routed design information to a checkpoint file called
post_route.dcp.
Running Vivado Incrementally Chapter 23: Running Post-Synthesis Operations
March 2014 1129
2. Make changes to the design.
This flow offers the most runtime savings when the design has only
small changes and is very similar to the reference design. It is most
effective when design changes amount to less than 10 percent of the
design. If many changes are made to critical path placement and
routing, this incremental is not as useful, as much of the placement and
routing cannot be reused.
3. Rerun synthesis and place-and-route with the Incremental Place and Route
option enabled.
Vivado runs initial placement by matching objects in the current design
against objects from the previous run. The post_route.dcp file from the
previous run is used as a reference. During routing, Vivado removes
routing to objects that are no longer in the design. It uses unchanged
routing from the checkpoint database.
If you check the vivado.log file, it reports that it is running incrementally,
and also reports the runtime. In this example, the incremental runtime
is 00:00:00.03.
If you check the run_vivado.tcl file under the pr_1 directory, it too
reports that the incremental flow was run:
LO
1130 March 2014
Running Xilinx ISE Incrementally Chapter 23: Running Post-Synthesis Operations
March 2014 1131
Running Xilinx ISE Incrementally
Xilinx
The Xilinx ISE place-and-route tool has two incremental flows, both of which
take advantage of the compile points defined during synthesis. Both flows use
compile points to run incremental place-and-route, but you use them for
different purposes:
Xilinx SmartGuide Flow
Use this flow when you are trying to save runtime as you iterate through
the flow and make changes. Typically, you use this earlier in the design
cycle. In this flow ISE runs with SmartGuide enabled. With this setting,
the tool reuses place-and-route information from the previous run for
unchanged partitions, and only places and routes the partitions that
were modified. To get even more runtime savings, combine the Smart-
Guide flow with automatic compile points, fast synthesis, and multipro-
cessing during synthesis. For complete details on SmartGuide, see the
Xilinx documentation.
Xilinx Partition Flow
Use this flow when you are trying to converge, and design preservation
and stability are your primary goals. The same manual RTL compile
points defined during synthesis are maintained through place and
route. If a compile point is modified, the Xilinx tool reruns P&R for only
those partitions that have been modified; all others are preserved. To
reduce runtime while running this flow, use multiprocessing.
For versions prior to ISE 12.1, the Partition flow involved manual steps.
For a description of this flow, see Xilinx Partition Flow for Versions Before
ISE 12.1, on page 1140.
Design Goal Xilinx Flow
Save runtime, or iterate through P&R incrementally. SmartGuide Flow
Stabilize the design and preserve completed parts of the design.
Only run incremental P&R on the parts that have changed.
Partition Flow
LO
Chapter 23: Running Post-Synthesis Operations Running Xilinx ISE Incrementally
1132 March 2014
Xilinx SmartGuide Flow
Use the SmartGuide flow for incremental changes when you are trying to
reduce runtime, as described in Running Xilinx ISE Incrementally, on
page 1131. Use the SmartGuide option when you need to make minor
changes to a design: make HDL changes to a small number of modules (logic
changes of approximately 10% or less), move pin locations, change attributes,
or modify timing constraints. Do not use this flow if you have changes on the
critical path.
The following procedure describes the details of running synthesis and the
SmartGuide flow:
1. Make sure to use Xilinx ISE 12.1 or later version of the P&R tool.
Create compile points, as described in Synthesizing Compile Points,
on page 644. You can create automatic or manual compile points,
but inferring automatic compile points speeds up runtime.
To speed up runtime, use multiprocessing. In the Synplify Premier
tool you can additionally specify Fast Synthesis mode to reduce runtime
even further.
Target a supported Xilinx device.
Go to the Implementation Results panel of the Implementation Options
dialog box, and define the top-level design name for the project in the
Result Base Name field. This name must be identical to the top-level
module file name.
March 2014 1133
In the Device tab of the Implementation Options dialog box, disable Use
Xilinx Xflow. SmartGuide uses the xtclsh flow, so this option must be
disabled. If you do not do so, you see a popup warning later when you
specify SmartGuide.
Set SmartGuide for the Xilinx P&R tool, by clicking the Add P&R
Implementation button in the Project view and selecting the Smart Guide
option in the resulting Add New Place and Route Task dialog box.
LO
1134 March 2014
3. Do an initial run of synthesis, placement, and routing.
4. Implement small changes to the design.
5. Rerun synthesis and P&R.
When you rerun synthesis and P&R with the SmartGuide option
enabled, ISE uses the ncd file from the previous run as a guide. It
preserves any unchanged components and incrementally places and
routes those that were modified. SmartGuide can provide significant
runtime improvements, as the entire design does not need to be rerun.
March 2014 1135
Xilinx Partition Flow
Like the SmartGuide flow, the Partition flow is based on compile points, but it
is focused on achieving design stability. It lets you preserve and lock down
parts of the design as you iterate through the design, because it only reruns
the modified modules. Partitions that have not changed are preserved from
the previous implementation. Note that this flow is based on manual compile
points, for better control.
The figure below summarizes the process, which is then explained in more
detail in the subsequent steps.
1. Make sure to use version 12.1 or later of the Xilinx ISE place-and-route
tool.
If you have an older version of ISE, use the procedure described in Xilinx
Partition Flow for Versions Before ISE 12.1, on page 1140.
2. Set up a project as usual, and set implementation options.
LO
1136 March 2014
Select a Xilinx target device that the Xilinx Partition flow supports.
To use the partition flow, enable Use Xilinx Partition Flow from the Device
tab. This automatically enables the Use Xilinx Xflow option.
For the Synplify Premier tool, set these additional options: disable
all the netlist prototyping tools options on the GCC & Prototyping Tools
tab, and disable the Physical Synthesis option. If you do not disable
Physical Synthesis, the tool removes the XML partitions to run
physical synthesis.
3. Compile the design, and define manual compile points in the top-level
constraint file.
Click the Compile Points tab, and set compile points, as described in
Defining Manual Compile Points, on page 652.
Set the compile point type to hard, locked or locked, partition to run the
Xilinx Partition flow. The following example shows three compile
points set as locked compile points: ALU, comb_logic, and mult.
March 2014 1137
Create a compile point constraint file for each compile point. This is
especially important if you use a bottom-up flow.
Set the clock constraint for the compile point. This can be the same
as the top level.
Save the constraint file.
4. For best results, follow these additional guidelines:
Register the compile point I/Os to mitigate QoR loss.
Set a clock
constraint for
the compile
point
Set up a
constraint
file for the
compile
point
LO
1138 March 2014
If you are using a bottom-up flow, disable I/O insertion and clock
buffer insertion in lower-level compile points.
5. Set up the P&R tool to run automatically after synthesis completes, by
doing the following:
Click on the Add P&R Implementation button in the Project view to create
an initial P&R implementation. When you re-run this P&R
implementation, the incremental results are written to this directory.
Select the P&R implementation you want to run and enable Run Place
& Route following synthesis in the dialog box.
You can also run place and route manually as a separate process after
synthesis is done. To do this, first run the Tcl command for the stand-
alone XML converter first, as described in Using Compile Points in a
Standalone Xilinx Partition Flow Run, on page 1139.
6. Run synthesis and place and route.
Click Run to start the process.
The tool first synthesizes the compile points and then synthesizes the
top level. See Synthesizing Compile Points, on page 644 for details
about this process. It forward-annotates the compile point
information along with a timestamp for each compile point in the
xpartition.pxml file. If you have set it up, the ISE tool runs automatically
after synthesis is complete, and honors the compile points as
partitions.
After P&R, check generated reports and the log file for any compile
point or Xilinx Partition flow messages.
7. To run the design incrementally, do the following:
Make the needed design changes to the source or constraint files.
Do not make any changes to the Xilinx ISE P&R environment.
Click Run to run incremental synthesis and incremental P&R in the
Xilinx tool.
The synthesis software runs incrementally, only resynthesizing compile
points whose logic, implementation options, or timing constraints have
changed.
The ISE tool also runs incrementally. It compares the partition
timestamps in the xpartition.pxml file for the previous and current imple-
mentations, and preserves partitions that have not changed. It only
March 2014 1139
reruns P&R on partitions that have been resynthesized. The PAR log file
reports the details:
Partition Implementation Status
-------------------------------
Preserved Partitions:
Partition "/top"
Partition "/top/A"
Implemented Partitions:
Partition "/top/D"
Attribute STATE set to IMPLEMENT
Using Compile Points in a Standalone Xilinx Partition Flow Run
When you run the P&R tool separately, from outside the synthesis tool, you
must first run the sxml2pxml Tcl command for the standalone XML converter.
1. Set up the compile point design and synthesize as usual.
2. After synthesis, run the sxml2pxml Tcl command in one of these ways:
Open the Synplify Pro or Synplify Premier GUI, then type the
command in the TCL Script window.
Write this command into a Tcl script file, then run the Synplify Pro or
Synplify Premier tool in batch mode.
Run the Synplify Pro or Synplify Premier tool in batch mode,
specifying the command with the -tclcmd option.
This command generates a Xilinx xpartition.pxml file with compile point
information for the specified implementation directory and design. For
the Tcl command syntax, see sxml2pxml, on page 159.
3. Place and route the design with the Xilinx ISE tool.
LO
1140 March 2014
Xilinx Partition Flow for Versions Before ISE 12.1
For older versions of the software (before ISE12.1), use the following proce-
dure to use compile points with the Xilinx Partition flow. It is similar to the
newer Partition flow described in Xilinx Partition Flow, on page 1135, but you
have to execute some of the steps manually.
1. If necessary, set the SYN_XILINX_PR_USE_XTCLSH environment variable
to 1.
This is the default in the latest releases of the synthesis tools, so you do
not have to set it. This setting ensures that the tool generates the
run_ise.tcl script file after synthesis. For subsequent synthesis runs,
the tool recognizes the script file and does not overwrite it.
2. Set up the design.
Set up the project file and define manual compile points.
Target a Xilinx device that the Partition flow supports.
Specify implementation options and constraints, as usual.
3. Click Run to synthesize the design.
The synthesis tool generates an EDIF file where the compile points are
defined with "PARTITION" properties. Each compile point also includes a
timestamp for when the module was last synthesized. Later, the place
and route tool uses the time stamp as the basis for comparison to deter-
mine which modules need to be incrementally updated.
4. Run place and route.
Make sure you set the system path variables for the Xilinx place-and-
route tool
Run the P&R project tcl script using this command: xtclsh.exe.
5. Perform the following tasks when ISE placement and routing completes.
Check generated reports.
Make any necessary major design changes to the source or constraint
files and place and route the design.
6. Go back to the synthesis tool and re-synthesize the modified design.
The synthesis tool only resynthesizes and optimizes the updated
modules. In the EDIF file generated for this synthesis run, the tool does
March 2014 1141
not change the timestamp of a compile point if it has not changed since
the previous run; it preserves the old timestamp. Updated modules get a
new timestamp.
7. Rerun the ISE tcl script and place and route the design.
The Xilinx tool compares the compile point timestamps to the corre-
sponding timestamps from the previous run, and incrementally places
and routes only those blocks with updated timestamps. It leaves the
other blocks untouched. The EDIF file also specifies whether an updated
compile point needs to be re-placed and re-routed, or only re-routed.
The default specifies incremental placement and routing.
LO
Chapter 23: Running Post-Synthesis Operations Working with the Identify Tools
1142 March 2014
Working with the Identify Tools
The Synopsys Identify tool set is a dual-component system that is a valuable
part of the HDL design flow process. The system consists of the Identify
instrumentor and Identify debugger.
The Identify instrumentor allows you to select your design instrumenta-
tion at the HDL level and then create an on-chip hardware probe.
The Identify debugger interacts with the on-chip hardware probe and
lets you do live debugging of the design.
The combination of these tools allows you to probe your HDL design in the
target environment. The combined system allows you to debug your design
faster, easier, and more efficiently.
The Synplify, Synplify Pro, and Synplify Premier synthesis tools have
integrated the Identify instrumentor into the synthesis user interface. This
section describes how to take advantage of this integration and use the
Identify instrumentor:
Launching from the Tool, on page 1142
Handling Problems with Launching Identify, on page 1146
Using the Identify Tool, on page 1147
Using Compile Points with the Identify Tool, on page 1149
Launching from the Tool
This section describes how to launch the Identify tool from the Synplify
Premier, Synplify Pro, and Synplify software.
Define a Synplify Pro or Synplify Premier project that you can pass to and
launch in the Identify instrumentor. For the Synplify Pro and Synplify
Premier tools, you must create an Identify implementation in order to run the
Identify instrumentor. If you already have an Identify implementation, open it
and use the Identify tool as described in Using the Identify Tool, on
page 1147.
Working with the Identify Tools Chapter 23: Running Post-Synthesis Operations
March 2014 1143
Do the following to add an Identify implementation:
1. In the synthesis interface, open the design you want to debug.
2. Do one of the following tasks to add an Identify implementation:
With the project implementation selected, right-click and select New
Identify Implementation from the pop-up menu.
Select Project->New Identify Implementation.
An Implementation Options dialog box appears where you can set the
options for your implementation. Note that the options apply only for
logic synthesis and not for physical synthesis. An Identify implementa-
tion is created.
LO
1144 March 2014
3. To run Identify instrumentor, select the Launch Identify Instrumentor icon
( ) in the toolbar or select Run->Identify Instrumentor.
The Identify interface opens. You can now use the Identify tool as
described in Using the Identify Tool, on page 1147 For complete details,
consult the Identify documentation.
If you run into problems while launching the Identify instrumentor, refer to
Handling Problems with Launching Identify, on page 1146.
Synplify
The Synplify synthesis tool does not support multiple implementations. The
following procedures describe how to launch an Identify implementation, and
how to modify an existing implementation.
Creating a New Identify Implementation
1. Make sure that your PATH environment variable points to the Identify bin
directory.
2. Create or open a project.
3. Right-click on the implementation and select New Identify Implementation
from the popup menu.
4. Set any implementation options and close the dialog box; dismiss the
multiple implementation warning.
5. Select Options->Configure Identify Launch to display this dialog box:
March 2014 1145
6. Check the Identify installation. If the Use current Identify Installation field
entry in the dialog box is not correct, either:
click the Locate Identify Installation button and enter the path to the
Identify installation directory. Use the browse button if necessary.
set the SYN_IDENTIFY_EXE environment variable to point to the
Identify installation. This path is the directory path displayed in the
Use current Identify Installation field. You must restart the synthesis tool
whenever you change the environment variable setting.
Select the appropriate license option and click OK to launch the Identify
instrumentor for the new implementation.
7. Instrument the design as required, save the instrumentation, and exit
the Identify instrumentor. See Using the Identify Tool, on page 1147 for
an overview, or the Identify documentation for details.
8. Synthesize the instrumented implementation (rev_n_identify) in the
Synplify tool (the schematic will show the added IICE circuitry).
After the design has been synthesized, place and route your design.
Program the device, install the device in the target system, and complete
the cable interface. You can now run the Identify debugger on the
instrumented design (designName.prj) to verify correct operation.
LO
1146 March 2014
Modifying or Re-instrumenting an Existing Design
To modify or re-instrument an existing design:
1. Load the project containing the Identify implementation.
2. From the menu bar, select Run->Run TCL Script.
3. Navigate to the lib directory and run (open) the relaunch_identify.tcl script
to launch the Identify instrumentor.
4. Re-instrument the design as required, save the instrumentation, and
exit the Identify instrumentor.
5. Re-synthesize the instrumented implementation (rev_n_identify).
After the design has been re-synthesized, place and route your design.
Program the device and reinstall the device in the target system. You can now
rerun the Identify debugger on the instrumented design (designName.prj) to
verify correct operation.
Handling Problems with Launching Identify
If you have not installed Identify correctly, you might run into problems when
you try to launch it from the synthesis tools. The following describe some
situations:
If the Launch Identify Instrumentor icon ( )and the Run->Identify Instrumentor
menu command are inaccessible, you are either on an unsupported
platform or you are using a technology that does not support this
feature.
If you have the Identify software installed but the synthesis application
cannot find it, select Options->Configure Identify Launch.
March 2014 1147
In the resulting dialog box, either:
check the Use Current Identify Installation entry. This entry is set by the
SYN_IDENTIFY_EXE environment variable to point to the Identify
installation. If this path is incorrect, change the environment variable
setting and restart the synthesis tool. button and specify the correct
location in the Locate Identify Installation field. You can use the Browse
button to open the Select Identify Installation Directory dialog box and
navigate to your current Identify installation directory.
click the Locate Identify Installation button and specify the correct
location in the corresponding field. Use the browse button to open the
Select Identify Installation Directory dialog box and navigate to your current
Identify installation directory.
Using the Identify Tool
This procedure provides an overview of how to use the Identify instrumentor.
For detailed information about the tool, refer to the Identify RTL debugger
documentation.
1. The Identify instrumentor software interface opens, with an Identify
project automatically set up for the design to be instrumented and
debugged (IICE tab). The following figure shows the main project window.
LO
1148 March 2014
2. Do the following in the Identify instrumentor interface:
Instrument the design. For details of using the Identify instrumentor,
refer to the Identify RTL debugger documentation.
Save the instrumented design.
The Identify instrumentor tool exports the instrumented design to the
synthesis software. It creates an instrumentation subdirectory under
your synthesis working directory called designName_instr, which contains
the following:
A synthesis project file
An instr_sources subdirectory for the instrumented HDL files
Tcl scripts for loading the instrumented design
3. Return to the synthesis interface and view the instrumented design that
contains the debugging logic.
March 2014 1149
In the synthesis interface, open the project file for the instrumented
design, which is in the instr_sources subdirectory listed in the
Implementations Results view for your original synthesis project.
Open the RTL view to see the inserted debugging logic.
4. Place and route the instrumented design after synthesis.
5. Use the Identify debugger tool to debug the instrumented design.
Using Compile Points with the Identify Tool
You can use compile points to run incrementally. This can reduce runtime
while running synthesis, and also while running the Identify flow. The
following figure illustrates this:
LO
1150 March 2014
When you use Identify instrumentation, the tool creates extra IICE logic at
the top level of the design and the corresponding interface to the signals that
need to be debugged. If you define compile points, the tool need only rerun
the compile points that have changed because of the insertion of this logic.
On subsequent runs, it can incrementally re-instrument only those compile
points where there are instrumentation changes or design modifications.The
following procedure describes the steps to follow to implement the flow and
take advantage of incremental synthesis and instrumentation:
1. Create a synthesis implementation with compile points.
2. Set up the Identify implementation:
Generate the Identify implementation by right-clicking the FPGA
synthesis implementation and selecting New Identify Implementation from
the popup menu.
Copy the compile point subdirectories manually to the new Identify
implementation directory.
3. Run the tools.
Run synthesis.
Before running the Identify tool, enable the top-level constraint file
and all compile point constraint files in the Identify implementation.
Instrument the design. The tool inserts additional logic for
instrumentation.
4. Resynthesize the design.
The tool runs incrementally, only resynthesizing the compile points
affected by the inserted instrumentation logic. If you make any other
design changes, the tool incrementally synthesizes the affected compile
points.
5. Rerun instrumentation.
The tool runs incrementally, and only re-instruments the affected
compile points.
Netlist Editing Chapter 23: Running Post-Synthesis Operations
March 2014 1151
Netlist Editing
Synplify Premier
The tool provides tools to edit the RTL netlist so that you do not have to
modify the HDL source for small changes to the netlist. You can also use
netlist editing to insert or stitch IP blocks into the design at a desired level
of hierarchy, by connecting the blocks to ports and nets within the core
design.
Netlist editing is useful in the following scenarios:
Implementing engineering change orders (ECOs)
Rerouting a fast clock from an external source to an internal (DCM)
source
Inserting IP blocks in an RTL netlist (srs file)
Use netlist editing at the RTL level. You can add other RTL views (srs files) or
primitives to the RTL view of the design to be synthesized. Netlist editing
support can only be used within the top-down flow.
These topics provide further information:
RTL-Level Flow
Specifying Netlist Editing Commands, on page 1152
RTL-Level Flow
Netlist editing commands are written to a tcl file; this file can be:
Included in your project using Add Prototype file on the GCC & Prototyping
Tools tab of the Implementation Options dialog box.
Read by the edit_netlist command and applied to the specified netlist file.
The netlist optimizer reads these commands and performs netlist editing. You
may need several iterations through this process until the desired results are
achieved.
The basic RTL-level flow is:
1. Load the database (i.e., ip.srs file) with the RTL netlist to be edited.
LO
Chapter 23: Running Post-Synthesis Operations Netlist Editing
1152 March 2014
2. Create and compile the project with the IP or modules you want to insert
into the main design to generate the ip.srs file.
3. Add the netlist editing commands to a tcl file. See Specifying Netlist
Editing Commands, on page 1152.
4. Run the netlist optimizer on the project with the source, ip.srs, and tcl
files to generate the srs file.
5. Run the mapper on the generated srs file.
Alternatively, you can load the Verilog database; the netlist optimizer does
not understand the Verilog database, and you must load the *.syn file avail-
able in the lib/xilinx or lib/altera folder. Apply the netlist editing commands in
the tcl file. You can use the views directly from the xilinx.syn or altera.syn file to
create instances. Run the netlist optimizer and then run the mapper.
RTL Flow Examples
The following lines in the prj file add and enable an RTL netlist editing script
for the project:
add_file -tcl "netlist_edit.tcl"
set_option -nfilter_user_path "netlist_edit.tcl"
See Sample Netlist Editing Tcl File, on page 1153 for an example of a Tcl file
with netlist editing commands.
Specifying Netlist Editing Commands
1. Write netlist editing commands to a tcl file.
See Netlist Editing Commands, on page 173 in the Command Reference
for details about the commands you can use. For a sample Tcl file, see
Sample Netlist Editing Tcl File, on page 1153.
Netlist editing commands typically apply to the current view. All path
names used in netlist editing commands are relative to the module of
the current view. The current view must be unique; if it is not, a modifi-
cation in the current view affects all modules of that view.
2. Check file syntax and save the Tcl file.
Check that path and pin names in the commands are correct, and that
there are no case mistakes. Syntax errors are usually reported, but
March 2014 1153
incorrect connections may not be detected until much later in the design
flow. The following syntax error indicates an incorrect path or pin name:
Could not find pin "pathName.pinName" in module "modName"
3. Add the file to the project.
Open the Implementation Options dialog box, and go to the GCC &
Prototyping Tools tab.
Specify the Tcl file with the netlist editing options in the Add Prototype
file option.
4. Disable netlist optimizations.
If you do not disable the optimizations, the synthesis process can
optimize the design before the netlist edits are applied.
Make sure that all optimizations are disabled before running the
netlist editing Tcl script. In the GUI, disable the individual
optimization check boxes on the GCC & Prototyping Tools panel or
comment out the individual commands in the project file.
If you want optimizations, add the optimization commands to the end
of the netlist editing Tcl script so that the optimizations are performed
on the edited netlist.
5. Run synthesis.
The netlist optimizer reads the commands and edits the netlist accord-
ingly. It uses the edited netlist for synthesis.
Sample Netlist Editing Tcl File
The following example adds an RTL (srs) IP block and/or library primitives to
the RTL database (srs) for a project.
#Set the module to edit
define_current_view top
create_port {out[0:3]} -direction out
create_net {out[0:3]}
create_instance inst_A nle2_add_select
connect_net {out[0:3]} {inst_A.out[0:3]} {p:out[0:3]}
connect_net {d1[0:3]} {inst_A.a[0:3]}
connect_net {d2[0:3]} {inst_A.b[0:3]}
connect_net {d3[0:3]} {inst_A.c[0:3]}
LO
Chapter 23: Running Post-Synthesis Operations Netlist Editing
1154 March 2014
connect_net {d4[0:3]} {inst_A.d[0:3]}
connect_net {d5[0:3]} {inst_A.e[0:3]}
connect_net clk1 inst_A.clk
connect_net sel inst_A.s0
connect_net reset inst_A.s1
#Insert an inv pair from the technology library (unisim.v)
#on the net driven by top_mult.out2[0]
insert_buffer -inverter_pair {top_mult.out2[0]} INV
Netlist Editing Command Conventions
Netlist editing commands can be used with both collections and Tcl lists. All
arguments used with the netlist editing commands must correspond to an
existing object in the design or to a constant. The possible objects are:
connector (pin or bit port)
net
instance
view
library file
data-base file
Each of the above objects can be identified with a simple name or hierarchical
path name. Additionally, a name can be prefixed by a qualifier to further
define the object type to the command. These qualifiers are:
t: denotes a pin name
p: denotes a port name
i: denotes an instance name
v: denotes a view name
In some commands (for example, in single-argument commands), the quali-
fiers can be omitted. In multi-argument commands, the arguments must be
separated by spaces.
The following are examples of object names:
i:instName denotes an instance
March 2014 1155
i:instPath.instName denotes an instance within the netlist of the instance
instPath
t:instName.pinName denotes an instance pin
p:portName denotes a top-level port
p:instName.portName denotes a port within the netlist of the instance
instName
n:netName denotes a net
n:instName.netName denotes a net within the netlist of the instance
instName
v:viewName denotes a view
Using the edit_netlist Command
The edit_netlist command applies netlist-editing commands from a specified Tcl
file directly to the named srs netlist file. The results are written to a separate
file to preserve the original netlist. For more information and command
syntax, see edit_netlist, on page 51 of the Command Reference.
LO
Chapter 23: Running Post-Synthesis Operations VIF Formal Verification Flows
1156 March 2014
VIF Formal Verification Flows
During synthesis, the Synplify Pro tool performs several sequential optimiza-
tions and design transformations to improve delay and area. These transfor-
mations make it difficult for a formal verification tool to match registers in the
result netlist with the corresponding registers in the source HDL (a prerequi-
site for verifying equivalence). To solve this, the Synplify Pro software provides
a Tcl file interface that lets you integrate with verification tools. This proprie-
tary format is called the Verification Interface Format or VIF. This feature is
currently available for only Altera technologies.
Overview of the VIF Flow, on page 1156
Generating VIF Files, on page 1157
Using VIF with Cadence Conformal, on page 1160
Handling Equivalency Check Failures, on page 1161
Overview of the VIF Flow
The Synplify Pro VIF flow is based on a Tcl file generated during synthesis.
This file has a vif extension. It contains a vendor-independent list of the
design transformations performed during synthesis so that the verification
tool can do equivalence checking and match up the post-synthesis registers
with the original golden netlist.
VIF Formal Verification Flows Chapter 23: Running Post-Synthesis Operations
March 2014 1157
The following diagram summarizes the two ways in which you can use the .vif
file as input. Subsequent sections show you how to use the generated vif file
to verify your logic with the Conformal tools.
Generating VIF Files
1. In the Synplify Pro interface, select Project->Implementation Options and set
the following on the Device tab:
Set Technology to an Altera family that supports the VIF flow.
Disable optimizations like Retiming and Pipelining on the Options tab and
Clock Conversion on the GCC or GCC & Prototyping Tools tab. Disabling
these options is recommended because the verification tool requires a
HDL
FPGA Synthesis
Verilog Netlist
(.vm)
.vif
VIF Translator
Verification Model Library
from FPGA Vendor
Equivalence Checking Tool
Verification File
Enable
Verification Mode
LO
1158 March 2014
one-to-one correspondence between the design objects in the
reference and implementation designs to successfully complete, and
the optimizations make it hard to verify this. The downside to
disabling the optimizations is performance loss.
Enable Verification Mode. The equivalent prj file syntax is set_option
-verification_mode 1. This is an optional step that disables optimizations
that can not be easily verified, like the inference of resettable SRLs.
Enabling Verification Mode could result in sub-optimal area or
performance results, because the optimizations were not run.
You enable Verification Mode to make it easy for the verification tool to
synchronize registers. Sequential optimizations are hard to verify
because registers are moved or optimized away. For a list of VIF
optimization commands, see step 4, below. Verification Mode is different
from the Disable Sequential Optimizations option. The former disables
many FPGA optimizations, where the latter only disables sequential
optimizations.
Note: Verification Mode requires that the Write Mapped Verilog Netlist option
be enabled as well. See step 2.
2. Go to the Implementation Results tab and do the following:
Enable Write Mapped Verilog Netlist. This option generates the vif file. The
equivalent project file syntax is set_option -write_verilog 1. When enabled,
this option creates a verif directory under the results/implementation
directory. The verif directory contains the design.vif file.
3. Synthesize the design as usual.
The Synplify Pro tool generates the vif file and stores it in the project/verif
directory.
4. Go to the verif directory and check the vif file to see how the
optimizations were handled.
March 2014 1159
The following table lists the VIF commands used to map some synthesis
optimizations. For details of the command syntax, refer to VIF
Commands, on page 172 in the Reference Manual.
5. Use the vif file as input to any formal verification tool that supports a
Tcl interface. Use one of the following methods:
If you are using the Cadence Conformal tool, run the translation
script vif2conformal.tcl which is in the install dir/lib directory (see Using
VIF with Cadence Conformal, on page 1160 for details). This
translates the .vif file commands to commands for the Conformal tool.
If you are using another verification tool that does not directly
support VIF commands, create a script that translates the vif file
commands to native Tcl commands.
If you are using a verification tool that supports the VIF commands in
its Tcl framework, use the file directly.
6. In the verification tool, use the information from the vif file along with
the synthesis output when you check logic equivalence against the
golden netlist.
Optimization VIF Command
FSM register mapping vif_set_fsmreg
FSM state encoding vif_set_state_map
Register merging vif_set_merge
Register replication vif_set_equiv
Pruning of duplicate registers vif_set_constant, vif_set_transparent
Black boxes for undefined modules vif_set_map_point
Port direction changes vif_set_port_dir
LO
1160 March 2014
Using VIF with Cadence Conformal
The Synplify Pro software includes Tcl scripts for use with the Cadence
Conformal tool. You can convert vif files manually or automatically.
Converting VIF Manually
The following procedure describes how to convert vif files manually.
1. Source the vif2conformal.tcl file by typing one of the following commands in
the Synplify Pro Tcl window:
source synplify_pro_install_dir/lib/vif2conformal.tcl
or
source $LIB/vif2conformal.tcl
2. In the Tcl window, navigate to the verification folder containing the
design.vif file, and type the following command:
vif2conformal design.vif
The vif2conformal.tcl script runs on the design.vif file and translates the
information into Conformal side files (*.vtc, *.vsc, *.vmc, and so on). You
can now run Conformal using these files.
Automating VIF Conversion with Synhooks
You can create a script using the synhooks.tcl file (see Automating Flows with
synhooks.tcl, on page 826) to automate the generation of verification files. An
example of this file, synhooks_for_vif2conformal.tcl, is located in the
install_dir/examples directory.
The synhooks_for_vif2conformal.tcl Tcl script sets your environment to automat-
ically convert the Synplify Pro generated vif file to Conformal-specific side
files at the end of each synthesis run. Use either of the following methods to
convert your files:
Set the environment variable SYN_TCL_HOOKS to point to the
synhooks_for_vif2conformal.tcl file. For example:
SYN_TCL_HOOKS=install_dir/examples/synhooks_for_vif2conformal.tcl
March 2014 1161
Source the synhooks_for_vif2conformal.tcl file in the Synplify Pro Tcl window
to set up automatic conversion. For example:
% source install_dir/examples/synhooks_for_vif2conformal.tcl
For this method, you must source the synhooks_for_vif2conformal.tcl file
every time you start a new project; otherwise the tool is reopened. The
automatic conversion setup is lost once you close a Synplify Pro project
or restart the tool.
Handling Equivalency Check Failures
If your design fails the equivalency check, try the following tips and
techniques to debug the results.
Check the log file report and fix the errors reported.
Check the optimization mapping in the vif file. See step 4 of Overview of
the VIF Flow, on page 1156 for a list of commands.
LO
Chapter 23: Running Post-Synthesis Operations Simulating with the VCS Tool
1162 March 2014
Simulating with the VCS Tool
The Synopsys VCS tool is a high-performance, high-capacity Verilog
simulator that incorporates advanced, high-level abstraction verification
technologies into a single, open, native platform. You can launch this simula-
tion tool from the synthesis tools on Linux and Unix platforms by following
the steps below. The VCS tool does not run under the Windows operating
system.
1. Set up the tools.
Install the VCS software and set up the $VCS_HOME environment
variable to define the location of the software.
Set up the place-and-route tool.
In the synthesis software, either select Run->Configure and Launch VCS
Simulator, or click the icon.
If you did not set up the $VCS_HOME environment variable, you are
prompted to define it. The Run VCS Simulator dialog box opens. For
descriptions of the options in this dialog box, see Configure and Launch
VCS Simulator Command, on page 391 of the Reference Manual.
2. Choose the category Simulation Type in the dialog box to configure the
simulation options.
Specify the kind of simulation you want to run.
RTL simulation Enable Pre-Synthesis
Post-synthesis netlist simulation Enable Post-Synthesis
Post-P&R netlist simulation Enable Post P&R
Simulating with the VCS Tool Chapter 23: Running Post-Synthesis Operations
March 2014 1163
Choose the category VCS Options in the dialog box to set options such
as the following VCS commands.
The options you set are written out as VCS commands in the script. If
you leave the default settings the VCS tool uses the FPGA version of VCS
and opens with the debugger (DVE) GUI and the waveform viewer. See
the VCS documentation for details of command options.
3. If your project has Verilog files with ìnclude statements, you must use
the +incdir+ fileName argument when you specify the vlogan command.
You enter the +incdir+ in the Verilog Compile field in the VCS Options dialog
box, as shown below:
To set ... Type the option in ...
VLOGAN command options for compiling and
analyzing Verilog, like the -q option
Verilog Compile
VHDLAN options for compiling and analyzing VHDL VHDL Compile
VCS command options Elaboration
SIMV command options, like -debug Simulation
LO
1164 March 2014
Example Verilog File:
ìnclude "component.v"
module Top (input a, output x);
...
endmodule
The syntax for the VCS commands must reflect the relative location of
the Verilog files:
If the Verilog files are in the same directory as the top.v file, specify:
- vlogan -work work Top.v +incdir+ ./
If the Verilog files are in the a directory above the top.v file, specify:
- vlogan -work work Top.v +incdir+ ../include1 +incdir+
../ include2
If the Verilog files are in directories below and above the top.v file,
specify:
- vlogan -work work Top.v +incdir+ ./include_dir1
+incdir../include_dir2
4. Specify the libraries and test bench files, if you are using them.
Simulating with the VCS Tool Chapter 23: Running Post-Synthesis Operations
March 2014 1165
To specify a library, click the green Add button, and specify the library
in the dialog box that opens. Use the full path to the libraries. For
pre-synthesis simulation, specifying libraries is optional.
For post-synthesis and post-P&R synthesis, by default the dialog box
displays the UNISIM and SIMPRIM libraries in the P&R tool path. You
can add and delete libraries or edit them, using the buttons on the
side. To restore the defaults, click the Verilog Defaults or VHDL Defaults
button, according to the language you are using.
If you have test bench files, choose the category Test Bench Files in the
dialog box to specify them. Use the buttons on the side to add, delete,
or edit the files.
For Xilinx designs, choose the category Vendor Version to specify the
ISE version to use, 10.3 or 11.2. The ISE 11.2 directory structure was
changed for VHDL simulation libraries.
5. Specify the top-level module and run directory.
Choose the category Top Level Module in the dialog box to specify the
top-level module or modules for the simulation.
If necessary, choose the category Run Directory near the bottom of the
dialog box to edit the default run directory listed in the field. The
default location is in the implementation results directory.
6. Generate the VCS script.
To view the script before generating it, click the View Script button on
the top right of the dialog box. A window opens with the specified VCS
commands and options.
To generate the VCS script, click Save As, or run VCS by clicking the
Run button in the upper right. The tool generates the XML script in
the directory specified.
Add
Edit
Delete
LO
1166 March 2014
7. To run VCS from the synthesis tool interface, do the following:
If you do not already have it open, open the Run VCS Simulator dialog
box by clicking the icon.
To use an existing script, click the Load From button on the lower right
and select the script in the dialog box that opens. Then click Run in
the Run VCS Simulator dialog box.
If you do not have an existing script, specify the VCS options, as
described in the previous five steps. Click Run.
The tool invokes VCS from the synthesis interface, using the commands
in the script.
Limitations
If Verilog include paths have been added to your project file, these paths are
not automatically added to the VCS script. Add the Verilog include paths
manually by using one of the following workarounds:
From the Run VCS Simulator dialog box, add +incdir+includePath in the
Verilog Compile options field.
Modify the VCS script file, adding the +incdir+includePath to all or any
relevant vlogan commands.
Using VCD/Identify with HDL Analyst Chapter 23: Running Post-Synthesis Operations
March 2014 1167
Using VCD/Identify with HDL Analyst
Synplify Premier
The synthesis tool integrates VCD/Identify with HDL Analyst views, providing
a way to watch nets annotated in the HDL Analyst from the Control Panel
signal watch list.
See the following topics:
Using the VCD-HDL Analyst Integration, on page 1167
Using the Identify-HDL Analyst Integration, on page 1182
Extracting VCS Test Benches for Submodules, on page 1189
Although the feature is available on both Linux and Windows, Windows
platforms have some limitations:
A previously generated VCD file is required. You can generate the VCD
file in a test bench or after an Identify debugging session, or by
converting a VPD file using the vpd2vcd utility.
VCD file generated from an Identify debugging session
The DVE integration tool is not available on Windows. See Use DVE, on
page 1178 for information about DVE.
Using the VCD-HDL Analyst Integration
Load the VCD file for the design into the HDL Analyst view. Values from the
VCD file can be annotated on the schematic in the Technology view. You can
perform pin point analysis for small sections of the design, when the design
does not behave according to the design specification.
You can trace specific signals and cone of logic that is suspected of causing a
problem through the schematic to identify the faulty behavior. Having the
simulation values annotated on the schematic helps to debug the design
easily.
For the VCD-HDL Analyst flow, you must complete these tasks:
Verify Design Behavior
Load the VCD File in HDL Analyst
LO
Chapter 23: Running Post-Synthesis Operations Using VCD/Identify with HDL Analyst
1168 March 2014
Set Nets for Watching
Debug After Loading VCD and Watching Nets
Display Simulation Values
Use DVE
Verify Design Behavior
Use VCD and HDL Analyst to verify design behavior at different design stages:
Load the VCD File in HDL Analyst
To load the VCD file in HDL Analyst, follow this procedure:
1. Open the HDL Analyst Technology view.
2. To invoke the Control Panel, click the ( ) icon or select
HDLAnalyst->VCD->VCD Panel (Ctrl+R) from the Project menu.
Phase Tools
Design phase Use the VCD simulator to simulate the design and DVE
(Discovery Virtual Environment to verify the output waveform
for the overall design.
After simulation
result analysis
Use the VCD-HDL Analyst integration to narrow down and
target specific signals that you can correlate to on the
schematic in the Technology view.
March 2014 1169
Use the Move this panel to alternate location ( ) icon to change the VCD
Panel view to a location beneath the HDL Analyst view.
LO
1170 March 2014
3. To load the simulation VCD file, click the Open a VCD File icon ( ) or
select HDL-Analyst->VCD->Load VCD File from the Project menu.
Then, locate the VCD file using the browse capability to fill in the VCD
File field of the Load Simulation VCD File dialog box.
Locate the top-level scope, which is the path through the test bench
to the root module displayed by the HDL Analyst. Use the Locate Top
Level Scope to fill in this field on the Load Simulation VCD File dialog box.
After you select the simulation VCD File and top-level scope, click the
Load button to load the VCD file. Check the bottom of the dialog box
for load messages.
March 2014 1171
To locate the top-level scope, click Locate Top Level Scope. This brings
up the Select Top Level Module Path dialog box, where you can identify
the top-level module.
To prune the scope tree, click Prune Scope Tree. This brings up the
Prune Scope Hierarchy dialog box. Check the root scopes to be included
in the hierarchy. If none of the scopes are checked, then the scope for
the top-level module is loaded. Click the Clear All button to ensure that
none of the root scopes are checked. Once you have pruned the scope
tree, the paths for the scopes to be loaded are shown in the box to the
right of the Prune Scope Tree button.
When loading a pruned VCD file, you cannot watch nets originating
in hierarchy levels that are not loaded. If you try to watch such a net,
the following message is generated: No matching signal.
LO
1172 March 2014
You can load VCD files for submodules that contain data only for the
submodule hierarchy of the netlist viewed in HDL Analyst. To select a
submodule, expand the drop-down menu for the Top Level Module and
Paths group and chose the desired module.
Alternatively, you can use the sch_sim_load Tcl command to load the VCD
file. For details, see sch_sim_load, on page 104 in the Reference manual.
March 2014 1173
4. To re-load a VCD file, use the re-load icon ( ) on the Control Panel or
the HDL Analyst->VCD->Reload VCD File option from the project menu.
The previously loaded VCD file is re-opened in a new invocation of the
HDL Analyst view.
5. To unload the VCD file, use HDL Analyst->VCD->Unload the VCD File option.
This option frees up memory used by the simulation data without
having to close and re-open the Analyst view.
Set Nets for Watching
You can use any of the following methods to set nets (excluding power
connections) for watching:
You can watch nets on a sheet by selecting one of the following options
from HDL Analyst->VCD:
Automatically Watch Sheetswhile navigating to a sheet, all nets on the
sheet are added to the watch list.
Watch Sheetwatch all nets on the current sheet.
Un-Watch Sheetremove watching all nets on the current sheet.
Alternatively, right-click in the Control Panel and select Automatically
Watch Sheets, Watch Sheet, or Un-Watch Sheet when watching nets in the
HDL Analyst View.
Drag-and-drop a net, instance, or port from the HDL Analyst View to the
Control Panel.
Drag-and-drop a net, instance, or port from the Hierarchy Browser of
the HDL Analyst View to the Control Panel.
Use Tcl commands for watching nets. For example:
Use the find -net command to select nets and then use the following
syntax to watch the collection of nets:
sch_sim_watch -add -coll [-select] [names]
Use the following command syntax to watch the nets:
sch_sim_watch -add netNames
Use the following command syntax to remove all nets to be watched
from the Control Panel signal list:
LO
1174 March 2014
sch_sim_watch -clear
For details, see sch_sim_watch, on page 106 in the Reference manual.
The tool does not allow you to watch mismatched nets and issues a warning
in the Tcl window. Also, you can click on the alert icon ( ) in the Control
Panel to see these error messages.
Debug After Loading VCD and Watching Nets
Use the options on the Control Panel to control the different aspects of the
debugging process. The following figure shows the Control Panel in the HDL
Analyst View.
The Control Panel changes to a gradient blue color to indicate an active
session when the simulation file is loaded. You can then perform the tasks
described below to debug the design.
1. Do this to manipulate the time for observation:
Specify the direct time in the required time field and click the Click to
set time icon ( ).
March 2014 1175
Move the time slider or use the arrows to move to the next transition.
Move the time slider left or right to decrease or increase the time. Use
the arrows to move time forward or backward to the next transition. If
no net is selected, the tool specifies the next transition among all nets
in the list. If some nets are selected, the tool selects the next
transition among the selected nets. The edit box next to the slider
includes the step size. The + or - buttons moves to the next step size.
Move the magenta bar to select the current time in the Waveform
pane. Click the ( ) icon to toggle the Waveform pane on or off. Left-
click in the Waveform pane to set the current time.
For additional options that you can use in the Waveform pane, right-
click and select options from the popup menu.
For all the time observations mentioned above, the corresponding values
for the watched nets can be observed in the HDL Analyst View, Control
Panel value column, and Waveform pane.
Find time from selected value.
Select the required signal name from the list in the Control Panel.
Select the data format from the drop-down menu and enter the
appropriate value to find its corresponding time.
LO
1176 March 2014
Use the arrows to find the time with respect to the previous/next
occurrences of the value.
Add time markers relative to the current time:
- Use the Add Marker icon to add a new marker at the current time.
- Move to the specified marker, next, or previous marker.
- Delete markers.
2. You can observe values for nets in different ways:
Observing in the Control Panel
The net values are displayed under the Prev | Curr | Next column,
respectively. The rows under the Name column display its
corresponding signal names.
Observing in the HDL Analyst View
Use the Annotate Values option to control whether to display the net
values in the HDL Analyst view. To enable this option, select
HDL-Analyst->VCD->Annotate Values.
The values can be displayed for each net/bus net in order of
previous, current, and next values. To choose a display option, right-
click and select VCD->Annotate from the popup menu.
Name of Marker
Delete Marker
Add Marker
Move to Marker Time
Move to Previous Marker
Move to Next Marker
March 2014 1177
Choose a radix (for example, Hex, Binary, Octal, or Decimal).
For a bus net, values of the entire bus as well as individual bits are
displayed.
A tool tip is provided that displays information such as simulation
values and fanout for the nets.
Observing in the optional Waveform pane
The values for signals can be observed in waveform format using the
Waveform pane.
Observing in multiple HDL Analyst views
Open multiple Analyst views.
Synchronize time changes in each view with respect to reference time
to observe differences in simulation results.
Observing using the DVE Waveform viewer
LO
1178 March 2014
Observe values with the information for watched signals using script
files. See Use DVE, on page 1178 for more information.
Crossprobing between the Control Panel and the HDL Analyst View
Crossprobing between HDL Analyst nets and signals listed in the
Control Panel is possible.
Display Simulation Values
Use the sch_sim_disp Tcl command to display simulation values for signals.
You can display current nets being watched or a list of specified nets not
included in the watch list; display simulations value to the Tcl window or
write to an output file; and create a file for importing to a spreadsheet. See
sch_sim_disp, on page 103 in the Reference manual for details.
Use DVE
DVE (Discovery Virtual Environment) is an interactive waveform viewer that
you can launch and configure within the VCD-Analyst Integration tool. You
can also do the following:
Configure DVE. See Configuring DVE, on page 1178 for details.
Import watched signals from DVE to the VCD-Analyst Integration tool.
See Importing Signals from DVE to the VCD-Analyst Integration Tool, on
Export watched signals from the VCD-Analyst Integration tool to DVE.
See Exporting Nets to DVE from the VCD-Analyst Integration Tool, on
Note: You must have a VCS license and run the DVE tool on a Linux
platform. Also, set the environment variable VCS_HOME in the
VCS_HOME/bin installation directory.
Configuring DVE
To configure your DVE environment, do the following:
1. Select HDL Analyst->VCD->DVE->Configure DVE.
March 2014 1179
2. From the dialog box, specify the signals that you want to view in DVE:
None or Analyst Sim Fileselect no signals or signals from the HDL
Analyst simulation VCD file.
Other VCD or VPDspecify the path to another simulation VCD file.
Sessionyou can re-load a saved DVE session Tcl file.
3. Use Transfer Signals Group to transfer specified simulation VCD file signals
to a user-specified group. Enable Open a new wave window (when not opening
session), to automatically open a waveform view in DVE.
4. You can specify any arguments to pass on to DVE, if necessary.
Note, you must set the environment variable VCS_HOME to bring up
DVE.
LO
1180 March 2014
Importing Signals from DVE to the VCD-Analyst Integration Tool
To import watched signals from DVE to the VCD-Analyst Integration tool, do
the following:
1. Select HDL Analyst->VCD->DVE->Import Signals from DVE.
2. From the dialog box, specify the session script file saved from DVE.
3. Then, click the Get button, to extract the signal list from DVE.
4. Select the signals to import to the VCD-Analyst Integration tool: All,
None, or check selected signals.
March 2014 1181
5. If you specify a DVE session file group, you can synchronize the signals
in this group to match watched signals in the Control Panel.
Exporting Nets to DVE from the VCD-Analyst Integration Tool
To export watched nets from the VCD-Analyst Integration tool to DVE, do the
following:
1. Select HDL Analyst->DVE->Export Signals to DVE.
2. Specify the export path DVE script file to which selected nets are to be
exported.
3. Specify the DVE session file group that contains the nets to be exported.
You can enable Sync Group to synchronize the DVE nets to match the
watched signals in the Control Panel.
LO
1182 March 2014
4. Select the nets to export to the VCD-Analyst Integration tool: All, None,
or check selected signals.
5. Then, source the script file in a DVE session.
Launching DVE
Click the DVE button on the Control Panel or select HDL
Analyst->VCD->DVE->Launch DVE to bring up the DVE interface shown below.
Using the Identify-HDL Analyst Integration
Synplify Premier
You can instrument signals in the Identify Debugger, capture them in a VCD
file, and display them in the HDL Analyst view. You can only do this for pre-
synthesis RTL files, and the VCD file can only be opened in Identify mode.
March 2014 1183
To use this integration, follow these steps:
1. Set up the project file.
Create a project and use Identify to instrument the design.
Debug the design on an FPGA and generate the VCD file from the
Identify Debugger. See the Identify documentation for details.
2. Load the project file.
3. Open the HDL Analyst RTL view.
4. To invoke the Identify-VCD HDL Analyst, click the ( ) icon or select
HDL-Analyst->VCD->VCD Panel (Ctrl+R) from the Project menu.
5. To load the Identify VCD file, click the Open a VCD File icon ( ) or select
HDL-Analyst->VCD->Load VCD File from the Project menu.
LO
1184 March 2014
Make sure the Identify Debug option at the bottom of the dialog box is
checked; this enables the Identify-VCD HDL Analyst flow. If you do
not check this option, the tool loads the VCD netlist without
validating it or reporting warnings.
Enable Validate VCD File with Netlist to report any mismatches between
the nets in the instrumented design and the VCD file.
Click Show Mismatches to display any mismatches. If there are none,
you see a message that the VCD file was loaded successfully.
6. To watch nets for the instrumented signals on a particular HDL Analyst
sheet, select one of the following options from HDL Analyst->VCD:
Automatically Watch Sheetswhile navigating to a sheet, all nets on the
sheet are added to the watch list.
Watch Sheetwatch all nets on the current sheet.
Un-Watch Sheetremove watching all nets on the current sheet.
You can also right-click and select these options on the waveform viewer
as displayed in the following figure. The identify trigger position is
indicated by the red cursor.
March 2014 1185
7. To view values for the signals, select all the signals in the waveform
viewer and go to HDL-Analyst->VCD->VCD Properties. Check the box for the
Annotate option.
LO
1186 March 2014
8. To annotate values on the waveform viewer to their respective HDL
Analyst sheet, check the Annotate box on the Control Panel. Select a
particular signal on the Control Panel to observe its corresponding
signal and values displayed on the sheet. You can display the
previous/current/next values for the signal.
March 2014 1187
9. You can load, re-load, or unload the VCD file. To do this, go to
HDL-Analyst and select one of the following options:
To load the Identify VCD file, click the Open a VCD File icon ( ) or
select HDL-Analyst->VCD->Load VCD File from the Project menu.
To re-load an Identify VCD file, use the re-load icon ( ) on the
Control Panel or the HDL Analyst->VCD->Reload VCD File option from the
project menu.
In the case where the Identify debugger generates revised VCD files,
changes to a VCD file must be handled after it is loaded. The reload
policy implemented provides the following options:
Autoautomatically reloads the VCD file
Askasks if the VCD file should be reloaded
Nevernever reloads the VCD file
Auto is the default. You can set the reload policy on the VCD Properties
dialog box. To do this, right-click in the Control Panel and select VCD
Properties or select HDL Analyst->VCD->VCD Properties option from the
project menu.
When an Identify VCD file is reloaded, the tool preserves information
as much as possible, such as the current time and watched signals.
LO
1188 March 2014
To unload the Identify VCD file, use HDL Analyst->VCD->Unload the VCD
File option.
This option frees up memory used by the Identify debug data without
having to close and re-open the Analyst view.
10. You can change the format of signals by selecting a signal, then
right-click and select the Format option on the Control Panel or use
HDL-Analyst->VCD->VCD Properties.
March 2014 1189
Extracting VCS Test Benches for Submodules
Synplify Premier, Linux
When debugging, you can often narrow down the faulty behavior to a partic-
ular instance or module. For more granular verification at this point, it would
be easier to work with a test bench for just that module or instance. Test
bench extraction automatically extracts RTL test benches for design submod-
ules, and runs the VCS simulator that is derived from the top-level RTL test
bench. This hierarchical approach improves the time for initial board bring-
up and allows you to internally sign off a submodule or IP.
The automatic process launches the VCS vcat utility to automatically
generate the test benches. It reads selected information from the full RTL
simulation VCD file to provide information about design scopes needed to run
vcat and to determine simulation times and parameters. The test process
also identifies if simulation data exists for the selected module (xDUT) in the
RTL Analyst view, and applies appropriate naming conventions so that
multiple test bench files can co-exist in the same directory.
Test bench extraction must be run with the Synplify Premier tools on Linux,
since vcat and vcs are only available on this platform.
Using Test Bench Extraction
This procedure describes the steps required for test bench generation and
simulation.
Create a synthesis project for the full design.
Run simulation to create the full RTL simulation VCD file. For
information about VCS simulation, see Simulating with the VCS Tool,
on page 1162.
2. Extract the test bench for the submodule.
Open the RTL Analyst view for the full design implementation.
Locate and select the module to be extracted (xDUT) from the
schematic or hierarchy browser. You must select only one
hierarchical instance in the schematic view.
Right-click and select VCD->Test Bench Extraction to display the Test
Bench Extraction dialog box.
LO
1190 March 2014
Generate the test bench files by clicking Gen Test Bench. See Test
Bench Architecture, on page 1191 for information about the test
bench.
3. Launch the VCS simulator for the xDUT module from the Test Bench
Extraction dialog box.
For a description of the fields used in this dialog box, see the Test Bench
Extraction Command, on page 531.
March 2014 1191
4. Debug the module for errors.
See the log file produced by the simulation.
View the simulation VCD file produced by the xDUT simulation in
DVE or other waveform viewer.
The main simulation Verilog file generates output indicating the success
or failure of the simulation. The file reports ports that are monitored, the
PASS/FAIL status for each port, and details about mismatches and
where they occur (port, time, expected value, actual value).
Test Bench Architecture
When you click the Gen Test Bench button, the software creates a test bench
file that contains the main module, as well as, the stimulus and golden
modules generated by vcat.
Main Module
The main module includes the following:
Instantiations of the stimulus and golden modules generated by vcat.
See Golden Module, on page 1192 and Stimulus Module, on page 1192.
A clock signal delay, delayed by the amount specified on the Test Bench
Extraction dialog box is used for signal comparison and reporting.
At the positive edge of the delayed clock, the outputs of the stimulus and
golden modules are captured for registers.
At the negative edge of the clock and for the reset line with the value
specified on the Test Bench Extraction dialog box, the registers holding the
stimulus and golden outputs are compared. Any differences are
reported, which indicate the expected (Golden) and actual (xDUT) values
and the time of comparison.
A final summary of the simulation is displayed. This includes a table of
PASS/FAIL status for ports.
LO
1192 March 2014
Golden Module
The golden module includes the following:
The golden module has outputs that correspond to the xDUT outputs.
Using blocking assignments that are delayed by the amount specified on
the Test Bench Extraction dialog box, the outputs are forced to the expected
values based on the RTL full simulation.
Stimulus Module
The stimulus module includes the following:
The stimulus module instantiates the xDUT module.
Inputs and outputs connect to the xDUT.
Using block assignments that are delayed by the amount specified on
the Test Bench Extraction dialog box, the inputs for the xDUT are forced to
the values that occurred in the RTL full simulation.
Limitations to Consider
Consider the limitations for the following:
Port Names
Race Conditions
Multiple Clocks
Test Bench File Order
Port Names
The extracted test bench uses the RTL netlist to determine input and output
port names of the submodule (xDUT). For simulation to work correctly, these
must match the port names of the submodule in the synthesized netlist.
Note: If you get VCS port mismatch errors, check that you are using
the correct RTL simulation.
March 2014 1193
Race Conditions
You might need to correct race conditions by adjusting signal arrival times.
Beginning at time 0, vcat applies the signals with blocking assignments in
the stimulus/golden test bench files. Specify an offset on the Test Bench Extrac-
tion dialog box, to offset this time. You can also manually edit the files for
more complex modifications.
Multiple Clocks
Test bench extraction does not support multiple clocks. In this case, you are
required to manually edit the main test bench module.
Test Bench File Order
The main test bench file and the stimulus file generated by vcat contain a
timescale directive. However, the module generation (Golden) file does not.
Therefore, the best order for passing the files to vcs is
Main test bench file (.vt)
Stimulus file (instPath_vcat_stimulus.cfg)
Golden file (instPath_vcat_golden.cfg)
LO
1194 March 2014
March 2014 1195
CHAPTER 24
Verifying Results with Formality
The increase in the size and complexity of FPGA devices has caused design
verification to become more critical in the design process. While simulation
and prototyping are still the norm for verifying design functionality, formal
verification methods have become invaluable in ironing out implementation
issues.
Formal verification uses exhaustive mathematical techniques to verify design
functionality. The advantage of formal verification over traditional verification
using test vectors is a significant savings in verification time. The accuracy
and speed of formal verification has increased its acceptance among
designers working with large designs. There are two types of formal verifica-
tion: equivalence checking and model checking. Equivalence checking uses
mathematical techniques to determine if a modified or revised design is
logically equivalent to the original design.
This document describes how to use the Synopsys
Formality
equivalence
checker to verify results from the Synplify
Premier FPGA tool.

Overview of the Formality Application, on page 1196
The Design Flow, on page 1198
Finite State Machine Design Example, on page 1205
Tips and Guidelines, on page 1210
Note: The Synplify Premier tool supports this Formality flow with
Synplify Premier compiler output only.
LO
Chapter 24: Verifying Results with Formality Overview of the Formality Application
1196 March 2014
Overview of the Formality Application
The Formality equivalence checker uses formal techniques to prove and verify
the functional equivalence of two designs or two technology libraries. You can
use this tool to compare a gate-level netlist to its register transfer level (RTL)
source, or to a modified version of that gate-level netlist.
Formality equivalence checking techniques are static and do not require
simulation vectors. Consequently, for design verification you only need to
provide a functionally correct, or golden, design (the reference design) and a
modified version of the design (the implementation design). The tool uses
mathematical techniques to compare the two and determine whether the
modified version is functionally equivalent to the golden design.
The tool methodology fragments the design into compare points. A compare
point is a design object used as a combinational logic endpoint during verifi-
cation. It could be an output port, register, latch, black box input pin, or net
driven by multiple drivers. The Formality tool uses the following design
objects to create compare points automatically:
Primary outputs
Sequential elements
Black box input pins
Nets driven by multiple drivers, where at least one driver is a port or
black box
The Formality checker verifies a compare point by comparing the logic cone
from a compare point in the implementation design against a logic cone for a
matching compare point from the reference design, as shown in the following
figure:
Overview of the Formality Application Chapter 24: Verifying Results with Formality
March 2014 1197
It tries to match each primary output, sequential element, black box input
pin, and qualified net in the implementation design with a comparable design
object in the reference design. For the tool to perform a complete verification,
all compare points must be verifiable. There must be a one-to-one correspon-
dence between the design objects in the reference and implementation
designs.
When functions defining the cones of logic for a matched pair of compare
points (one from the reference design and one from the implementation
design) are functionally equivalent, the tool reports that they have been
successfully verified. If all compare points in the reference design pass verifi-
cation, the result for the entire design is a successful verification.
LO
Chapter 24: Verifying Results with Formality The Design Flow
1198 March 2014
The Design Flow
The following figure summarizes the design flow between the synthesis tools
and the Formality equivalence checker.
The following sections explain the details of the flow and the files:
Verifying the Design with Formality Equivalence Checking, on
page 1198
Generating VIF Files, on page 1201
The svf File, on page 1204
Verifying the Design with Formality Equivalence Checking
The following procedure describes the details of the process summarized in
the previous figure. For an actual example, see Finite State Machine Design
Example, on page 1205.
The Design Flow Chapter 24: Verifying Results with Formality
March 2014 1199
1. Read through the guidelines and set up your design for formal
verification.
See Tips and Guidelines, on page 1210 for details.
2. Compile the design by entering project -run compile_vm in the Synplify
Premier tool, and generate vm and vif files as described in Generating
VIF Files, on page 1201.
3. Convert the vif file into an svf file (setup verification file for Formality
guidance) by doing the following:
In the Synplify Premier Tcl window, source the vif2formality Tcl script
by typing either of the following commands:
source synplify_install_dir/lib/vif2formality.tcl
source $LIB/vif2formality.tcl
Go to the implementation/verif/post_compile directory, and type the
following command:
v2f design.vif
The vif2formalityl.tcl script runs on the design.vif file and translates the
information into an svf file for Formality verification. See The svf File, on
page 1204 for a description of this file.
4. Provide the following inputs for Formality:
RTL Gate-level post-synthesis netlist (.vs, .vm)
Xilinx library files For Xilinx designs, do the following:
Download the Xilinx Formality library from the Xilinx
website:
http://www.xilinx.com/support/download/caesol.htm
Set $XILINX to point to the Xilinx library. For example:
setenv XILINX xilinx_install/m14_4/ISE
Untar the library to $XILINX/verilog/xeclib.
design.svf Formality guidance file. See The svf File, on page 1204
for more information.
design.tcl Formality setup file that is generated by the synthesis
tool. See FSM Tcl File Example, on page 1209 for an
example.
LO
1200 March 2014
5. Run the Formality equivalence checker by typing the following in a csh
window:
formality -file design_compile.tcl | tee result.log
The tool fragments the design into compare points and then verifies
them by comparing the logic cone from a compare point in the imple-
mentation design against a logic cone for the corresponding compare
point from the reference design.
If there are syntax errors in the svf file, the Formality tool discards the
entire file. If there is an interpretation error, it discards that operation
and continues the equivalence check.
After it completes, the Formality tool reports one of the following:
Succeeded Implementation is equivalent to the reference (golden) design.
Failed Implementation is not equivalent to the reference. This could be
because of a logic difference or a setup problem. See Tips and
Guidelines, on page 1210 for information.
Inconclusive No compare points failed, but the analysis is incomplete. This
could be because of a timeout or the complexity of the design.
Not run A problem earlier in the flow prevented verification from
running.
March 2014 1201
Generating VIF Files
As part of synthesis, the FPGA synthesis tools perform various optimizations
and design transformations to improve timing and area. These transforma-
tions make it difficult for a formal verification tool to match registers in the
output netlist with the corresponding registers in the source HDL. To address
the undesired trade-off between QoR and verifiability, the Synplify Premier
tool provides a Tcl file interface that lets you integrate with verification tools.
This proprietary format is called the Verification Interface Format or VIF. This
feature is currently available for only Xilinx technologies. The following proce-
dure shows you how to specify and generate this file:
1. In the synthesis tool, select Project->Implementation Options and do the
following on the Device tab:
Set Technology to a Xilinx family that supports the verification flow.
Disable optimizations like Retiming and Pipelining on the Options tab and
Clock Conversion on the GCC or GCC & Prototyping Tools tab. Disabling
these options is recommended because the verification tool requires a
one-to-one correspondence between the design objects in the
reference and implementation designs to successfully complete, and
the optimizations make it hard to verify this. The downside to
disabling the optimizations is performance loss.
Open the prj file and add the Verification Mode (set_option
-verification_mode 1) command.
LO
1202 March 2014
This setting makes it easy for the verification tool to synchronize
registers. In this mode, synthesis does not perform various
optimizations that move registers or optimize them away, because
this makes the design hard to verify. The scope of this setting is
broader than the Disable Sequential Optimizations option, because Disable
Sequential Optimizations only disables sequential optimizations. For a
list of the verification mode optimizations, refer to the FPGA Synthesis
Reference Manual.
2. Go to the Implementation Results tab and do the following:
Ensure that Write Mapped Verilog Netlist is enabled. This setting
generates the vif file. The equivalent project file syntax is set_option
-write_verilog 1. When enabled, this option creates a verif directory
under the results/implementation directory. The verif directory contains
the design.vif file.
Note that this option is automatically set when Verification Mode is
enabled.
March 2014 1203
3. Generate a vm file after compilation by adding the following command to
the project file:
project -run compile_vm
The synthesis software generates a vm file that reflects the design after
compilation but before mapping and stores it in the
project/verif/post_compile directory. It also generates a vif file in this direc-
tory.
4. Go to the verif/post_compile directory and check the vif file to see how the
optimizations were handled.
For details of the VIF commands refer to the FPGA Synthesis Reference
manual.
You can now convert the vif file into an svf (setup verification for
Formality) guidance file and use it to run equivalence checking, as
described in Verifying the Design with Formality Equivalence Checking,
on page 1198.
LO
1204 March 2014
The svf File
The Setup Verification for Formality (svf) script is a file that contains
Formality commands. Use the vif2formality Tcl script to convert a FPGA
synthesis vif file into an svf file.
The svf commands provide guidance so that the Formality tool can account
for the transformations made by the synthesis optimizations. For example,
the synthesis tool might duplicate a register to improve drive strength, and
this file records the register duplication. When the Formality tool reads the
svf, it can account for the extra register during compare point matching and
verification. See FSM svf File Example, on page 1209 for an example of this
file. The following example shows some file syntax that informs the Formality
tool that X-reg and Y_reg are tied to 1'b0 and 1'b1 in the netlist.
guide_reg_constant -design vcr {X_reg} 0
guide_reg_constant -design vcr {Y_reg[0]} 1
The svf file supports the following:
Guide_reg_merging
Guide_reg_duplication
Guide_reg_constant
Guide_FSM_reencoding
Finite State Machine Design Example Chapter 24: Verifying Results with Formality
March 2014 1205
Finite State Machine Design Example
This section runs through the flow using a finite state machine (FSM) design
as an example.
Verifying a Finite State Machine Design Example, on page 1205
RTL Code Example for a Finite State Machine, on page 1206
FSM Tcl File Example, on page 1209
FSM svf File Example, on page 1209
Verifying a Finite State Machine Design Example
The following procedure takes a specific example, a finite state machine,
through the steps for equivalence checking. See RTL Code Example for a
Finite State Machine, on page 1206 for the example code.
1. Compile the code shown in RTL Code Example for a Finite State Machine,
on page 1206 in Synplify Premier tool, going through the steps described
in Verifying the Design with Formality Equivalence Checking, on
page 1198 and generating the vif file as described.
2. In the Tcl window of the synthesis tool, run the vif2formality.tcl script as
described in Verifying the Design with Formality Equivalence Checking,
on page 1198.
This generates the design.tcl and design.svf files in the verif directory.
These files are also reproduced in FSM Tcl File Example, on page 1209
and FSM svf File Example, on page 1209.
3. Verify the design by doing the following:
Start the Formality tool.
Select File->Run Script and run the tcl file generated in the previous
step.
For successful verification, the Formality report should not have any
unmatched points. With this example, you see that there are two regis-
ters in the reference design that are unmatched.
LO
Chapter 24: Verifying Results with Formality Finite State Machine Design Example
1206 March 2014
4. Set these registers as constants by setting the following commands in
the svf file:
guide_reg_constant design vcr {forward_tape_reg} 0
guide_reg_constant design vcr {current_state_reg[0]} 1
5. Select File->Run Script and run the tcl file again to verify the design.
The design no longer contains any unverified points or aborted points,
and passes the equivalence check successfully.
RTL Code Example for a Finite State Machine
This is the RTL code for the FSM example used in Verifying a Finite State
Machine Design Example, on page 1205.
// Copyright (c) 2010 by Synopsys, Inc.
// You may distribute freely, as long as this header
// remains attached.
// VCR tape player and recorder state machine 10 States
`define stop 4'h0
`define will_forward 4'h1
`define forward 4'h2x
`define will_rewind 4'h3
`define rewind 4'h4

March 2014 1207
`define pause 4'h5
`define will_play 4'h6
`define play 4'h7
`define will_record 4'h8
`define record 4'h9
module vcr(stop_tape, pause_tape,
forward_tape, rewind_tape,
play_tape, record_tape,
clk,
stop_button, pause_button,
forward_button, rewind_button,
play_button,record_button,
is_stopped, reset);
output stop_tape, pause_tape, forward_tape, rewind_tape,
play_tape, record_tape;
input clk, stop_button, pause_button, forward_button,
rewind_button,
play_button, record_button, is_stopped, reset;
reg stop_tape, pause_tape, forward_tape, rewind_tape,
play_tape, record_tape;
reg [3:0] current_state, next_state; reg
[4:0] get_next_state;
always @ (posedge clk)
begin: this_always
reg state_independent;
stop_tape = 0;
pause_tape = 0;
play_tape = 0;
record_tape = 0;
forward_tape = 0;
rewind_tape = 0;
// SET OUTPUTS
case(current_state)
`stop,`will_play,`will_record,
`will_forward,`will_rewind: stop_tape = 1;
`pause: pause_tape = 1;
`play: play_tape = 1;
`record: record_tape = 1;
`forward: forward_tape = 1;
`rewind: rewind_tape = 1;
endcase
LO
Chapter 24: Verifying Results with Formality Finite State Machine Design Example
1208 March 2014
// STATE TRANSITIONS
if (!reset) // synchronous reset
next_state = `stop;
else begin
// go to next state
// state independent transitions
get_next_state = {1'b1, current_state};
if (stop_button)
get_next_state = `stop;
else if (record_button && play_button)
get_next_state = `will_record;
else if (play_button)
get_next_state = `will_play;
else if (forward_button)
get_next_state = `will_forward;
else if (rewind_button)
get_next_state = `will_rewind;
else
// next state is state-dependent and we are not setting it here
get_next_state = {1'b0, current_state};
{state_independent, next_state} =get_next_state;
// do state-dependent transitions
if (!state_independent)
if (is_stopped)
case(current_state)
`will_forward: next_state = `forward;
`will_rewind: next_state = `rewind;
`will_play: next_state = `play;
`will_record: next_state = `record;
endcase
else if (current_state == `play && pause_button)
next_state = `pause;
else if (current_state == `pause && pause_button)
next_state = `play;
end // outer if
current_state = next_state;
end // always block
endmodule
March 2014 1209
FSM Tcl File Example
This is the Tcl file generated as a result of running the FSM design described
in Verifying a Finite State Machine Design Example, on page 1205.
set synopsys_auto_setup true
set_svf statmch2.svf
set XILINX [get_unix_variable "XILINX"]
set hdlin_library_directory $XILINX/verilog/xeclib/unisims
read_verilog -r -vcs "-y $XILINX/verilog/xeclib/unisims -y
$XILINX/verilog/xeclib/simprims +libext+.v" -01 "../statmch2.v "
set_top vcr
read_verilog -i -vcs "-y $XILINX/verilog/xeclib/unisims -y
$XILINX/verilog/xeclib/simprims +libext+.v" -01 " ../statmch2.vm "
set_top vcr
current_design $ref
ungroup -all -flatten
#set_parameters -retimed $ref
set signature_analysis_match_compare_points false
match
set signature_analysis_match_compare_points true
match
verify
FSM svf File Example
This is the Tcl file generated as a result of synthesizing the FSM design
described in Verifying a Finite State Machine Design Example, on page 1205.
# Active SVF file statmch2.svf
guide
guide_environment \
{ { bus_dimension_separator_style ][ } \
{ bus_extraction_style %s\[%d:%d\] } \
{ bus_naming_style %s[%d] } \
}
guide_fsm_reencoding -design { vcr } \
-previous_state_vector {current_state_reg[3] \
current_state_reg[2] \
current_state_reg[1] current_state_reg[0] } \
-current_state_vector { current_state[8] current_state[7] \
current_state[6]| \
current_state[5] current_state[4] current_state[3] \
LO
Chapter 24: Verifying Results with Formality Tips and Guidelines
1210 March 2014
current_state[2]\
current_state[1] current_state[0] } \
-state_reencoding { \
{ S0 2#0000 2#000000001 } \
{ S1 2#0001 2#000000010 } \
{ S2 2#0011 2#000000100 } \
{ S3 2#0100 2#000001000 } \
{ S4 2#0101 2#000010000 } \
{ S5 2#0110 2#000100000 } \
{ S6 2#0111 2#001000000 } \
{ S7 2#1000 2#010000000 } \
{ S8 2#1001 2#100000000 } \ }
guide_reg_constant -design vcr {forward_tape_reg} 0
guide_reg_constant -design vcr {current_state_reg[0]} 1
setup
Tips and Guidelines
See the following for additional information on getting the best out of the
Formality equivalence checking flow:
Guidelines for Successful Verification, on page 1210
Writing RTL for Verification used in ASIC Prototyping, on page 1211
Limitations to Verification with Formality, on page 1214
Verification Mode Dependencies, on page 1215
Guidelines for Successful Verification
The following tips provide some guidelines for successfully checking your
design with the Formality tool:
Map all key points correctly and completely before beginning formal
verification. Unmapped points result in non-equivalences during the
comparison phase of formal verification.
Generally, non-equivalent points are the result of missing or incorrect
mapping rules. Evaluate any non-equivalent points carefully to deter-
mine the cause. In most cases, fixing annotations resolves the problem.
Tips and Guidelines Chapter 24: Verifying Results with Formality
March 2014 1211
Search for errors and warnings in the formal verification tool log file and
resolve them.
Although the final goal is a top-down verification run with no non-equiv-
alent points, it is recommended that you begin verification at the sub-
module level and work up to the top level. Small issues at the sub-
module level can translate into a large number of unmapped or non-
equivalent points at the top level. There is a smaller amount of design
logic at the sub-module level, so it is much easier to deal with and
resolve annotation issues at this level.
When extracting a sub-module from an entire design for verification,
preserve the sub-module interface as it is in the RTL. Synthesis tools
perform optimizations across hierarchies and can alter module level
interfaces. For module-level verification, you can either apply synthesis
attributes to the module to preserve the interface, or synthesize the
module by itself.
Writing RTL for Verification used in ASIC Prototyping
If you are targeting an FPGA to prototype an ASIC design, follow these guide-
lines to help the verification process run smoothly:
The Synplify synthesis tools ignore simulation-specific constructs like
$DISPLAY and $SETUPHOLD but the Formality checker does not. Enclose
these constructs in the //synthesis translate_off/on pragmas.
Always size datatypes. For example, use 1`b0 instead of`b0.
Do not use duplicate modules or entities in the same project. The
synthesis tools permits the allow multiple modules option, which allows the
tool to select the last read definition when it encounters multiple
contents for the same module or entity. This option causes ambiguity in
the Formality checker and is not permitted. Make sure each project has
only one definition of each module or entity.
When using custom packages, for operators like + and -, provide the
function definition as part of the project. For example, include the
package definition file in the project if you use a non-standard package.
Assume you use the following non-standard library:
library std_developerskit;
User std_developerskit.synth_regpak.all;
LO
1212 March 2014
You must then add the following file to the prj:
vhdl_src/std_developerskit/synthreg.vhd.
Use synopsys full_case and synopsys parallel_case with caution. If you specify
full_case and do not define all the cases, it can cause simulation issues
because simulators do not honor this directive. The board behavior is
not affected.
Use pragmas and synthesis directives with caution, because they direct
the synthesis tools to remove logic based on these directives. As these
directives are typically specified by the designer, it is assumed that the
board behavior will be correct. However, simulators do not read these
directives and do not do any reachability analysis.
Avoid using multiple drivers, where a net is driven both by a constant
and an active signal. The synthesis tools now resolve this to a constant,
but a simulator might not do the same. The Formality tool treats this as
a wired AND.
Up until the 2010.09 release, the synthesis tools errored out by default
in these situations. Although it is not recommended, you can enable the
Resolve Mixed Drivers option to revert to the old behavior. See the FPGA
Reference Manual for details about this option.
Gated clock structures
By default, the synthesis tools convert gated clock structures for optimal
performance. The conversion is needed for the prototype to work on the
board but poses issues for verification and cannot be easily verified. As
gated clocks are used extensively in ASICs that are implemented in
FPGAs, you can help the verification process by doing the following:
Identify and constrain the correct clocks in the Synplify design.
Put the gated clock logic in its own hierarchy wherever possible, so it
can be isolated during verification.
RTL RAMs
RAMs are typically implemented as block RAMs in FPGAs, and these
RAMs do not have good verification models. Enclose any RTL code
that the synthesis tools infer as a RAM in a separate hierarchy. This
is to enable black boxing of the RAMs and the continued verification
of the rest of the design. Put the RAM code in a separate design
hierarchy with a fixed boundary (syn_hier =fixed).
March 2014 1213
If the code implies the use of register banks instead of a RAM
implementation, use the syn_ramstyle=register attribute to force the
synthesis tool to implement it as registers, which can be formally
verified.
Complex SystemVerilog data types
The synthesis tools do not generate guidance information for formal
verification for SystemVerilog RTL with complex port types, like the use
of structs or multi-dimensional arrays. Consider this example of complex
coding:
module test (
sig1,
sig2,
input type1 sig1;
typedef struct packed {
logic ns;
.
.
.
logic [4:0] typ;
logic [1:0] fmt; }
type1;
After synthesis, the sig1 struct type port is changed to input [90:0] sig1;
and the Formality tool cannot match the original port name to the
synthesized port name.
sig1[typ][0] ------> sig1 [2]
sig1[fmt][1] ------> sig1 [1]
sig1[fmt][3] ------> sig1 [3]
Try to avoid using such structures. If you must use them, you must
manually create a guide file before running Formality as follows:
Set_user_match type port r:/WORK/test/sig1\[fmt][1]
i:/WORK/test/sig1[1]
As a workaround user can choose to hand type the guidance informa-
tion but could be very time consuming.
Multipliers
Small multiplier structures (<13 bits) that are implemented as logic can
be verified formally. For larger structures, enclose them in a separate
LO
1214 March 2014
hierarchy so that it can be black-boxed. Verify the black blocks by other
means like simulation.
DSP blocks
Logic inferred as DSP blocks are difficult to verify because pipelined
registers from surrounding logic to go into the DSP block. The current
workaround is to direct the tool to implement the DSP blocks as logic
using the syn_dspstyle attribute, or to enclose the DSP structure in its
own hierarchy so it can be black-boxed. Verify these black blocks by
some other means like simulation.
Retiming
Turn off retiming option whenever possible. Wherever possible, turn it
off on specific blocks, not globally.
syn_hier=fixed
When synthesizing, it helps to use the syn_hier=fixed attribute on all
levels of hierarchy. Add simple collection command like the following to
the Synplify sdc file:
define_scope_collection all_views {find -hier -view {*}}
define_attribute {$all_views} {syn_hier} {fixed}
Registers with set and reset pins
Black-box any blocks containing RTL code that describes registers with
both set and reset pins. The Xilinx tool does not have a single equivalent
primitive that has both pins. It uses two registers, which causes
problems for the Formality checker.
Limitations to Verification with Formality
Currently, there are some limits to formal verification with the Formality tool:
In FSM designs, the FSM state register may be merged or duplicated in
synthesis. This makes it hard to generate the guide information for
Formality.
Formality can only verify RAM as flip-flops. The tool treats block RAMs,
DSPs, and SRLs as black boxes.
March 2014 1215
For Xilinx RAMs you can work around the limited functionality by
setting RAMs to flip-flops or select RAM. When RAM is inferred as block
RAM, set black_box methodology basically ignores the RAM verification.
For multipliers, the tool can only verify up to 13-bit multipliers that are
implemented as logic. It does not handle multipliers that are imple-
mented in macros, like DSPs.
Verification Mode Dependencies
Here are dependencies to consider when using Verification Mode:
Verification Mode is only supported in the Synplify Premier tool.
Verification Mode is not the same as Disable Sequential Optimizations. Verification
Mode disables many FPGA optimizations that includes sequential
optimizations. Disable Sequential Optimizations only disables advanced
sequential optimizations.
Enabling Verification Mode results in a QoR trade-off.
Verification Mode honors attributes like syn_hier=hard and syn_keep=1.
During Verification Mode, optimizations like gated clock conversion and
generated clock conversion, pipelining, and retiming should be turned
off. It is recommended that you disable these optimizations because they
might make it hard for the Formality tool to find matching compare
points.
LO
1216 March 2014
March 2014 1217
CHAPTER 25
Prototyping
Synplify Premier
ASIC or SoC designs are usually much larger, and also faster than FPGA
designs. Additionally, there are various architectural differences between the
two, so that the translation from ASIC to FPGA for prototyping is not straight-
forward.
This chapter describes the functionality that the Synplify Premier tool
provides to make it easy for the prototyper to automate or simplify ASIC-to-
FPGA translation and synthesis for prototypes.
Partitioning ASIC Designs for Prototyping, on page 1218
Converting ASIC Designs for FPGA Prototyping, on page 1220
Getting an Initial Prototype, on page 1225
Ensuring Fast Turnaround for Prototypes, on page 1227
Optimizing QoR for Prototypes, on page 1228
Debugging Prototype Designs, on page 1229
LO
Chapter 25: Prototyping Partitioning ASIC Designs for Prototyping
1218 March 2014
Partitioning ASIC Designs for Prototyping
Synplify Premier
ASIC or SoC designs are generally much larger than FPGAs, and must be
divided into FPGA-sized partitions before you can synthesize a prototype on
an FPGA. Even if the design fits on a single FPGA, you still might want to
partition the design in the interests of parallel development and processing,
faster turnaround times, and modular design.
This section describes some of the features provided by the Synplify Premier
tool to facilitate partitioning. If your design has already been partitioned in a
multi-FPGA tool like the Synopsys Certify product, you might choose to go
directly to the actual synthesis of the prototype
When you partition the design, the emphasis is on getting initial estimates
and on setting up the partitions and black boxes. You run a quick, top-down
synthesis pass to estimate available resources and determine how to define
the partitions. You can then define the partitions.
Single-FPGA Flows (as opposed to Certify)
Pre-partitioned design: fast synthesis, hierarchical design, compile
points, resource estimation, top-down flow
Post-partitioned design: bottom-up or top-down, synthesis, timing,
area, verification
Partition into multiple FPGAs
Run fast synthesis, top-down
Check resource estimates
Define subprojects (partitions)
Synplify Premier
Certify
ASIC
Multiple FPGAs
Single FPGA
Partitioning ASIC Designs for Prototyping Chapter 25: Prototyping
March 2014 1219
Functionality for Partitioning
The Synplify Premier tool provides various features that facilitate the parti-
tioning of the ASIC design. The following table categorizes the features by the
design goals that are important at this stage:
Feature More Information
Initial Estimation
Fast synthesis Chapter 12, Fast Synthesis
Top-down synthesis Top-Down Synthesis for Hierarchical Projects, on page 94
Resource estimates Checking Resource Usage, on page 354
Graphic RTL
visualization
Partitioning
Hierarchical design Hierarchical Project Management Flows, on page 87
Compile points Chapter 13, Working with Compile Points
Bottom-up
synthesis
Turnaround Time
Multiprocessing Chapter 16, Using Multiprocessing
LO
Chapter 25: Prototyping Converting ASIC Designs for FPGA Prototyping
1220 March 2014
Converting ASIC Designs for FPGA Prototyping
Before an ASIC SoC design can be mapped to an FPGA, some parts of the
design must be replaced or reworked because of architectural differences
between FPGAs and ASICs. These are some typical issues that must be
addressed:
ASIC gated clock and generated clock structures do not fit on the FPGA.
Internal fix clock sources and PLLs must be replaced.
ASIC memories cannot be used on the FPGA. You can replace simple
memories with FPGA equivalents generated with dedicated tools from
FPGA vendors. For more complex memories, you must write replace-
ment models for the FPGA.
Latches and asynchronous delays must be reworked or replaced
ASIC analog modules require wrappers before they can be used on the
FPGA.
I/O control logic for dedicated boards
The following sections describe some of the issues in more detail:
General Guidelines for Prototyping, on page 1221
Identifying FPGA-Hostile RTL, on page 1221
Converting SoC Constructs, on page 1222
Converting Memories, on page 1222
Converting Clocks, on page 1222
Converting Constraints, on page 1223
Checking Resources, on page 1224
Importing VCS Projects, on page 1224
Converting ASIC Designs for FPGA Prototyping Chapter 25: Prototyping
March 2014 1221
General Guidelines for Prototyping
The following guidelines describe some of the best practices to follow with
ASIC designs that are to be prototyped in FPGAs:
Avoid latches because they are hard to time on an FPGA
Avoid combinatorial loops
To keep the RTL portable, do not include optimizations like clock gating,
test insertion, and low-power in the RTL. Leave optimizations to the SoC
tools and keep the RTL pure as far as possible.
Use define and ifdef to include or remove prototyping edits. Use these
constructs to isolate BIST (built-in self test), memory instantiations, etc.
Isolate RTL changes to within the library elements rather than outside
them in the RTL structure. This improves portability and keeps the
prototyping code as close to the original as possible.
Share make files between SoCs and FPGAs by using macro-driven
branching for different targets.
Keep source changes low-impact by using wrappers to make changes.
Replace files instead of editing them, and backannotate all changes.
Identifying FPGA-Hostile RTL
The following ASIC structures do not easily map to FPGA architectures:
Asynchronous logic, latches, block inferences
ASIC memory is too big and must be split across multiple RAMs
Clocks with gating
Clock muxing, for embedded test logic, for example
Top-level pads
Gate-level netlists
SoC leaf cells instantiations
SoC memories
SoC-specific IP without RTL
BIST instantiated in the RTL
LO
1222 March 2014
Converting SoC Constructs
The following ASIC components are FPGA-hostile, and must be converted for
FPGA design:
Top-level pads
Gate-level netlists
Leaf cell instantiations in the RTL
SoC memories
SoC-specific IP, if the source RTL is not available
BIST and other test circuitry. Handle them by leaving these signals
dangling.
Gated clocks generally overflow the FPGA clock resources
Complex generated clocks need to be simplified to fit the FPGA
resources
Asynchronous delays in latches need to be removed, reworked or
replaced. Replace by clocked processes
Analog modules need wrappers to interface to external circuitry
Clock sources--fix clock source, replace PLL
Converting Memories
ASIC memory is typically too large for FPGA memory structures. Complex
memories must be mapped to FPGA models; less complex ones can be
directly replaced by memories generated by tools like Altera MegaWizard.
Converting Clocks
ASIC clocks are typically quite complex, with numerous clocks that are
balanced in the design through clock tree synthesis. Even though proto-
typing is done before clock tree synthesis, the clocking scheme in the RTL
might still be too sophisticated for an FPGA and must be simplified before the
design can be prototyped as an FPGA.
Converting ASIC Designs for FPGA Prototyping Chapter 25: Prototyping
March 2014 1223
Unlike ASICs, FPGAs have a finite number of balanced clock resources that
are part of the architecture. A gated clock adds extra delay and upsets the
balance, introducing timing violations and other glitches in the process.
Clock Generation
To generate FPGA clock equivalents, instantiate any features that are not
inferred using the architectural features available in the target architecture,
such as clock managers and programmable clock generators such as phase-
locked loops (PLLs).
When possible suppress clock muxes. If they cannot be removed or reworked,
modify the constraints and declare the clock at the mux output.
Clock Distribution
The synthesis tools automatically map global clocks to the global clocking
resources on the FPGA. Use attributes to specify regional clocks.
Gated Clocks
FPGAs have dedicated low-skew clock distribution nets and un-gated clocks,
but SoC designs use gated clocks. To make it possible to use the same RTL
for both SoC and FPGA designs, the Synplify Premier tool provides the
functionality to automate the translation. The functionality moves the SoC
clock gating from the clock pins of sequential elements to the enable pins.
This provides a logically-equivalent FPGA version, without altering the
original RTL.
Converting Constraints
Use the following find commands to find unconverted clocks for analysis:
find seq hier {*} filter {@clock==*clockNamePattern*}
select [find seq hier {*} filter {@clock==*clockNamePattern*}]
LO
1224 March 2014
Checking Resources
It is essential that you check available resources when you map an ASIC to
an FPGA.
1. Run synthesis.
For first-pass resource estimation, run fast synthesis.
For optimized synthesis, synthesize as normal.
2. Check the Resource Usage report for I/Os, random logic, flip-flops,
memory, and clocks. Aim for 50% utilization.
Importing VCS Projects
1. Load the project files.
2. Use the dh_module_sources attribute to get a list of source files defining a
module hierarchy. Edit the RTL and use define to isolate RTL differences
and to drive system configuration. The defines in the following snippet
specify Virage models for memories in the FPGA design:
`define OR1200_ASIC
////////////////////////////////////////////////////////
//
// Typical configuration for an ASIC
//
ìfdef OR1200_ASIC
//
// Target ASIC memories
//
//`define OR1200_ARTISAN_SSP
//`define OR1200_ARTISAN_SDP
//`define OR1200_ARTISAN_STP
`define OR1200_VIRAGE_SSP
`define OR1200_VIRAGE_STP
3. Add parameterized models for memories and clocks with the add_files
command.
4. Load constraints.
5. If you have DesignWare IP, point to the DC directory from Project->
Implementation Options->Verilog->Use DesignWare Foundation Libraries. Leave the
Getting an Initial Prototype Chapter 25: Prototyping
March 2014 1225
location blank if you have defined the location with the $SYNOPSYS
variable.
Getting an Initial Prototype
Synplify Premier
Once your design is partitioned into an FPGA, you must clean up the RTL so
that there are no errors. When the RTL has no errors, you can generate an
initial prototype for the partitioned design, either with the Project->Design Intent
command or by running synthesis as usual.
See the following procedures for details:
Synthesizing an Initial Prototype from the Tool, on page 1225
Tool Functionality for Creating an Initial Prototype, on page 1226
Synthesizing an Initial Prototype from the Tool
You can create an initial prototype after you have taken care of the RTL errors
identified earlier.
1. Set up the top-level design if it was not set up during partitioning.
Define subprojects for hierarchical design and allocated timing and
resource budgets to them.
Import IP automatically. The tool includes functionality to
automatically incorporate IP from various sources such as
DesignWare, Altera, and Xilinx, including Vivado.
Define black boxes as needed.
2. Compile the top level using the Continue on Error (CoE) option.
3. Fix any errors before proceeding.
4. Develop and synthesize subprojects independently.
5. Synthesize the entire design, running either top-down synthesis or
bottom-up synthesis. Use fast synthesis, multiprocessing, and CoE to
ensure quick run times.
LO
Chapter 25: Prototyping Getting an Initial Prototype
1226 March 2014
6. Run integrated place-and-route.
Tool Functionality for Creating an Initial Prototype
This table shows where to find more information:
Bottom-up
synthesis
IP Chapter 14, Working with IP Input
Continue on Error Using Continue on Error, on page 366
Graphic RTL
visualization
Integrated place and
route
Chapter 23, Running Post-Synthesis Operations
Ensuring Fast Turnaround for Prototypes Chapter 25: Prototyping
March 2014 1227
Ensuring Fast Turnaround for Prototypes
Synplify Premier
Fast turnaround is particularly important when synthesis is run top-down on
an SoC design during the early stages of protoyping. The following list
provides some techniques you can use to ensure a fast turnaround:
Create hierarchical designs so that the design can be developed in
parallel and so that errors can be easily isolated and solved.
Use synthesis techniques that minimize runtime, like fast synthesis,
incremental synthesis, CoE, and multiprocessing.
Lower resource utilization by creating more FPGAs.
Relax timing constraints.
Run integrated place and route.
Functionality for Fast Turnaround
This table shows where to find more information on features you can use for
fast turnaround times. For details on techniques to minimize runtime, refer
to the Runtime Methodology Guide, available on Solvnet.
Incremental synthesis Resynthesizing Incrementally, on page 661
Continue on Error Using Continue on Error, on page 366
Multiprocessing Chapter 16, Using Multiprocessing
Integrated place and
route
Incremental place and
route
LO
Chapter 25: Prototyping Optimizing QoR for Prototypes
1228 March 2014
Optimizing QoR for Prototypes
Synplify Premier
The following are some guidelines to achieve the best performance in the
prototype:
Set accurate and complete constraints
Increase pipelining, because highly pipelined designs are faster.
Reduce congestion.
Avoid or reduce high fanout.
Use design optimizations such as state machine inference, retiming, and
pipelining.
Tweaking to improve QoR --NEED INFO
Making incremental updates to the design e.g. importing a
subproject/ updating a CP
Incremental compiler
Functionality for QoR
This table shows where to find more information on features you can use to
accomplish your QoR goal.
FSM Compiler Optimizing State Machines, on page 605
Retiming Retiming, on page 584
Pipelining Pipelining, on page 580
Timing analysis Chapter 9, Analyzing Timing
Optimizing Timing Optimizing for Timing, on page 578
Timing for
hierarchical projects
Setting Initial Timing Budgets for Instance-Based
Subprojects, on page 201
Compile point timing Interface Timing for Compile Points, on page 637
Congestion analysis Analyzing Congestion After Logic Synthesis, on page 378
Debugging Prototype Designs Chapter 25: Prototyping
March 2014 1229
Debugging Prototype Designs
The FPGA synthesis software provides access to tools to analyze and debug
the prototype design, from simple visual analysis to test probes and signal
tracing. The latter are accomplished through the Synopsys Identify product,
which is closely integrated with the synthesis software. The tool also lets you
cosimulate using HAPS60 or HAPS70 hardware.
Inspecting Errors Visually, on page 1229
Addressing Common Synthesis Issues, on page 1231
Debugging by Probing Signals, on page 1232
Cosimulating with UMRBus and HAPS-70/HAPS-60, on page 1233
Running Co-Emulation with SCE-MI, on page 1236
Inspecting Errors Visually
The FPGA synthesis tool includes two graphical views that show schematic
views of the design after compiling (RTL view) and after mapping (Technology
view). The RTL view represents the design with technology-independent
components like adders, registers, and state machines. The Technology view
shows the actual implementation, with target-specific primitives like look-up
tables, registers, and DSP slices. The views feature crossprobing back to the
RTL and to timing reports.
The RTL view displays modules with errors or the parent modules of inter-
faces with errors with red boxes:
LO
Chapter 25: Prototyping Debugging Prototype Designs
1230 March 2014
You can also use Tcl commands like the following to find erroneous instances
and modules:
For more information about using these features, see the following topics:
All instances with
errors
c_list [find -hier -inst * -filter @is_error_blackbox==1]
All modules with
errors
get_prop -prop inst_of [find -hier -inst * -filter @is_error_blackbox==1]
RTL View Chapter 8, Analyzing with HDL Analyst and FSM Viewer
RTL View, on page 76 in the Reference Manual
Technology View Chapter 8, Analyzing with HDL Analyst and FSM Viewer
Technology View, on page 77 in the Reference Manual
Crossprobing Crossprobing, on page 421
Tcl find Chapter 3, Tcl Find, Expand, and Collection Commands in the
Command Reference Manual
March 2014 1231
Addressing Common Synthesis Issues
Often a prototype design does not synthesize because the design is not
completely FPGA-ready. A design could have thousands of files and it is quite
easy to miss something when converting the ASIC design to an FPGA-friendly
design.
The following guidelines address some common issues arising from ASIC to
FPGA conversion.
Handling Missing or Misplaced Clock Constraints
Missing clock constraints is the situation that occurs when a sequential
element is missing. In the misplaced clock constraints scenario, a clock is
disassociated from its source, often because a black box was created between
the clock source and its destination.
Here are some techniques to debug and deal with these errors:
1. Check the gated clock report for clocks that were not successfully
converted, and add a more complete set of clock constraints as needed
to fix the problem. This report is available after the compile stage.
2. Check if the black boxes in your design affect clock paths. If they do,
specify the enable pin for the black box and its polarity with the
syn_gatedclk_en and syn_gatedclk_en_polarity directives. You can search for
and extract converted instances and clock pins based on a property.
Handling Mismatched Ports
Typically, parts of the design originate from different sources, and this can
result in mismatches in port specifications. For example, a top-level VHDL
entity can instantiate a Verilog module called sub. The top level might declare
sub as having 4-bit ports, while the actual module might have 3-bit ports.
To trace mismatches like this back to the source RTL, check the value of the
orig_inst_of* property using the following Tcl command:
get_prop -prop orig_inst_of {v:instanceName}
The property returns the original RTL name for the module. For example, if
specify the command for the instance sub_3a, and it returns sub, sub is the
name of the original RTL module.
LO
1232 March 2014
Checking Constraints
If your constraints are not adequate or incomplete, or if you have overcon-
strained your design, you can encounter problems. To avoid these issues,
follow these guidelines:
Define all primary clocks and clock groups.
Define all asynchronous clocks.
Define all false paths and multicycle paths.
Specify derived clocks.
Run the constraints checker (Run->Constraint Check or project -run
constraint_check) and fix all errors flagged in the projectName_cck.rpt file.
Generate a clock synchronization report (Analysis->Timing Analyst->Generate
Asynchronous Clock Report option or set_option -reporting_async_clock). Check
all paths that start and end in different clock domains in the resulting
projectName_async_clk.rpt.csv file.
Debugging by Probing Signals
To debug the prototype, you must create additional circuitry and preserve
some nodes, which you can then probe or tap into to analyze the data
produced by the operating design. One such tool is the Synopsys Identify RTL
Debugger product, which lets you pinpoint signals and then sample them to
analyze data. It also relates back to the original RTL, which narrows down the
choices and makes it easier to find the problem.
This method alters the RTL. If you do not want to alter the RTL, use the
syn_probe attribute (syn_probe, on page 334 in the Attributes and Directives
Reference) to insert test probes without altering the RTL.
The following procedure provides a high-level guide to debugging with the
Identify software.
1. Use the Identify Instrumentor interface to specify, in the RTL, the probes
to use for monitoring the design. Identify signals and conditions that
you want to probe and add watchpoints (signals or nodes to be observed)
and breakpoints (RTL control flow statements) to relevant places in the
design. The combination of the two allows you to define specific
conditions of interest at very specific nodes. The Identify Instrumentor
functionality is included with the FPGA synthesis tool.
March 2014 1233
2. Synthesize the FPGA design. The tool creates additional probe and
communication logic, that is referred to as ICCE.
3. Use the Identify Debugger functionality to run the design and observe
the data. The watchpoints and breakpoints inserted previously sample
the data. The tool writes out the results to a VCD file that relates back to
the RTL. You can also use a waveform viewer to visually analyze the
information.
4. Fix any bugs you find, and run incremental synthesis.
5. For large designs, use the following techniques:
Share IICEs and multiplex samples to maximize the number of
observed signals and improve coverage. Multiplexed samples let you
switch between signal groups, and avoid re-instrumentation and the
consequent resynthesis when the design is re-instrumented.
To minimize the strain on resources, store the sampled data off the
chip in SRAM memory cards, thus increasing the depth of sampled
data.
Cosimulating with UMRBus and HAPS-70/HAPS-60
You can connect the HAPS-70 and HAPS-60 systems to run cosimulation and
debug the FPGA. For detailed information, see the UMRBus Handbook. Briefly
explained, the functionality is based on the following parts:
HAPS-70 or HAPS-60 system
UMR (universal multi-resource) bus, which allows transactions to inter-
face with user code. Proprietary format.
CAPIM (Consumer Application Interface Module) which are automati-
cally added by the tool or manually added to the FPGA. A CAPIM is a
block that connects the host to the user RTL through the UMRBus.
LO
1234 March 2014
The following steps detail the procedure summarized in the flow diagram
above.
1. Instrument the design.
2. Set options.
Set the FPGA target (Device panel of the Implementation Options dialog
box) to Synopsys HAPS-60 or Synopsys HAPS-70.
Specify UMRBus as the cable type.
3. Set up clocks and resets.
HAPS GCLK0 is reserved for the UMRBus clock. If a design clock is
assigned to GCLK0, manually lock this pin location; if not, the tool
automatically assigns it as the UMRBus clock.
Constrain GCLK0 to 100 MHz.
The UMRBus reset is always connected to AM8 (HAPS-60) or AG44
(HAPS-70). If a design reset is locked to these pins, it is integrated
into the UMRBus reset.
March 2014 1235
The tool automatically inserts CAPIMs for the UMRBus at Address 45
and above. It chains user-instantiated and tool-inserted CAPIMs
together. The CAPIM details are reported, as in this example:
@N: BN506 |Found 4 UMR CAPIMs in the design:
CAPIM Bus FPGA Width Addr Type Comment
------------------------------------------------------------------------------------------------------
I_CAPIM_1 1 mb_uB 8 0x1 0x8001 NA [ User added CAPIM ]
I_CAPIM_CTRL 1 mb_uA 8 0x3 0xc000 NA
I_1 1 mb_uA 8 0x3c 0x1d - [Tool added CAPIM for SCE-MI]
I_1 1 mb_uA 8 0x3d 0x1c -
I_2 1 mb_uA 8 0x3e 0x1b -
=========================================================
The tool creates the top-level ports for the UMRBus and defines pin
locations. It also specifies the I/O standard for the UMRBus port.
5. If you want to eliminate the automatic process and do it manually,
follow these steps:
Set syn_umr_disable_automation to 1 to disable the automatic process,
and disable the chaining and unchaining of CAPIMs.
Manually instantiate the CAPIMs.
To modify the CAPIM address, use this Tcl command: device
capimbaseaddr address.
Manually chain the CAPIMs.
LO
1236 March 2014
Add ports with pin locations, define the I/O standards, and the I/O
buffer.
Specify clock constraints as needed.
6. Place and route the design as usual.
7. Debug the design.
Running Co-Emulation with SCE-MI
The FPGA synthesis tool also lets you run co-emulation using Standard Co-
Emulation API: Modeling Interface (SCE-MI) 2.0. The SCE-MI standard
provides a transaction-level interface with a multi-channel message passing
environment and a Direct Programming Interface (DPI) function similar to
SystemVerilog.
Transaction-based verification is at a higher level of abstraction than the
signal level. It minimizes the amount of data exchanged between the host and
the prototyping system, and can be as much as 10,000 times faster than
cycle-accurate simulation. It provides accurate modelling and lets you
leverage prototyping hardware earlier in the design cycle with an interface to
live devices.
SCE-MI provides a transport infrastructure between the transactor models in
the emulator and C/C++/SystemC (untimed or RTL) models on the worksta-
tions. The infrastructure is composed of message channels that run between
the software and hardware sides of the SCE-MI infrastructure. SCE-MI
connects untimed software models to structural hardware transactor and
Design Under Test (DUT) models.
There are two use models:
Use the UMRBus PLI Interface environment, which works with a
simulator. This mode does not require the actual HAPS-60 system to be
connected.
Implement the design in hardware and emulate the design using a C-
testbench.
Both models enable a design to be verified using a C/C++ based testbench.
The required infrastructure for the communication between the software and
hardware is provided/generated automatically by the Certify tool with the
March 2014 1237
user writing DPI-like functions in Verilog for the hardware side. Certify gener-
ates a wrapper file for the software according to these DPI-like functions
which requires development of a software application.
The following figure shows the SCE-MI flow:
1. Insert SCE-MI infrastructure.
2. Synthesize and partition.
3. Place and route the design.
4. Configure the hardware system.
5. Compile the software model in the testbench.
6. Run the testbench.
LO
1238 March 2014
March 2014 1239
Index
Symbols
_conv.prj file 330
_conv.sdc file 330
.acf file 133
.adc file 464
.cdc file
specifying attributes and directives 172
.edf file 1040
.ini file
parallel jobs 820
.lpf file 133, 1023
.ndf file 1040
.vhm file 1071
.vqm file
Clearbox 748
Numerics
3rd party vendor tools
invoking 1098
A
ACTgen macros 1028
adc constraints 464
adc file
creating 464
object names 468
adc file, using 462
adders
SYNCore 689
wide. See wide adders/subtractors.
adjust pin view (Design Planner) 894
alspin
bus port pin numbers 1093
Alt key
column editing 112
mapping 425
Altera
byte-wide write enable inference 553
Clearbox. See Clearbox
converting pin assignments to SDC 247
converting PIN files 247
design tips 998
forward-annotation 133
grey box See grey box
I/O packing 1001
inferring LUTRAMs 538
instantiating LPMs as black boxes 566
LPM megafunction example
(Verilog) 566
LPM megafunction example
(VHDL) 568
netlist 1096
P&R file for untranslated settings 772
packing I/Os 1001
physical synthesis flows 57
place-and-route option file 234
PLLs. See altplls
Quartus batch mode 1009
Quartus integrated flow 1007
Quartus interactive flow 1008
shift registers 559
simulating LPMs 1005
Verilog LPM library 572
Altera incremental flows 1108
Altera MegaWizard
generating LPM files 566
Altera shift registers
report 561
Altera STRATIX (Design Planner)
additional tips 919
altpll
component declaration files 999
constraints 999
using 998
altshift_tap, set implmentation style 559
ALTSYNCRAM for LPMs 566
Index
1240 March 2014
analysis design constraint file (.adc) 464
analysis design constraints
design scenarios 463
analysis design constraints (adc) 462
analysis design constraints (adc), using
with sdc 464
analyzing netlists (Physical Analyst) 979
archive utility
using 214
archiving projects 214
area estimation, Design Planner 890
area, optimizing 577
ASICs 1217
clocking different from FPGA 1222
converting for FPGA prototyping 1220
partitioning 1218
asterisk wildcard
Find command 413
asymmetric RAM
inferring 546
instantiating as a black box 546
attr_applied.sdc file 772
attr_unapplied.sdc file 772
attributes
adding 169
adding in constraint files 130
adding in SCOPE 174
adding in Verilog 171
adding in VHDL 170
collections 292
effects of retiming 588
for FSMs 502, 610
inferring RAM 531
pipelining 582
syn_hier (on compile points) 656
VHDL package 170
attributes in .cdc file 172
Attributes panel
using SCOPE 264
audience for the document 31
auto constraints, using 469
Auto route cross probe insts
command 971
AutoConstraint_design_name.sdc 472
automatic compile points
compared to manual 626
flow 644
using with manual 658
B
B.E.S.T 429
back annotation
coreloc.sdc constraint file 252
place-and-route data 252
backslash
escaping dot wildcard in Find
command 413
in Find command (Physical
Analyst) 964
batch mode 812
using find and expand 287
Behavior Extracting Synthesis
Technology. See B.E.S.T
bit slicing 930
legal primitives 931
black box instantiation
true dual-port asymmetric RAM 546
black boxes 490
adding constraints 494
adding constraints in SCOPE 497
adding constraints in Verilog 496
adding constraints in VHDL 495
continue on error 369
EDIF naming consistency 499
for IP cores 1040
gated clock attributes 872
instantiating in Verilog 490
instantiating in VHDL 492
passing VHDL boolean generics 123
passing VHDL integer generics 124
pin attributes 498
prepared component method
(Altera) 571
setting in hierarchical projects 206
specifying timing information for Xilinx
cores 1040
black_box compile point 632
Block Inputs Map
Physical Analyst 992
block RAM
inferring 533
modes 529
Index
March 2014 1241
types 529
Block Utilization Map
block-based subprojects
compared to instance-based 178
block-first hierarchical development
flow 89
blocking-style license queuing 815
blocks
defining for hierarchical projects 179
bookmarks
in source files 112
using in log files 345
bottom-up design flow
compile point advantages 624
bottom-up hierarchical synthesis
flow 92
breaking up large primitives (Synplify
Premier) 930
browsers 400
buffering
crontrolling 600
BUFG
clock priority (Legacy) 323
for fanouts 601
BUFGCTRL
false paths (Legacy) 324
BUFGDLL 1065
BUFGMUX
clock priority (Legacy) 323
BUFGMUX_1 inference 1061
BUFGMUX_CTRL
BUFGMUX/BUFGMUX_1 inference 1060
BUFR clock buffers 1061
buses
INIT values for bits 1047
RLOC values for bits 1064
byte-enable RAM
inferring 552
byte-enable RAMs
SYNCore 678
byte-wide write enalbe
inferring 553
C
c_diff command, examples 294
c_intersect command, examples 294
c_list command
different from c_print 296
example 298
using 298
c_print command
different from c_list 296
using 297
c_symdiff command, examples 295
c_union command, examples 294
callback functions, customizing flow 826
carry chains
inferring 1013
case sensitivity
Find command (Tcl) 281
cdc file syntax 173
cells
enhancing display in Physical
Analyst 949
chip regions (Design Planner) 912
Clearbox
adding instantiated file 747
implementing megafunctions with 738
inferring megafunctions 739
instantiating megafunctions 743
instantiating with netlist 746
using 738
using instantiated netlists in
Quartus 748
clock and path constraints
setting 265
clock buffers 1065
clock constraints
setting 265
setting (Legacy) 306
clock conversion report
accessing 851
analyzing 852
clock DLLs 1065
clock groups
effect on false path constraints 279
clock path skew (Synplify Premier) 377
Index
1242 March 2014
clock pins (Design Planner) 900
clock skew (Synplify Premier) 377
clock skew example (Synplify
Premier) 1067, 1068
clock trees 455
clocks
converting ASIC to FPGA 1222
implicit false path 279
Clocks panel
using SCOPE 263
CoE. See continue on error 366
collections
adding attributes to 292
adding objects 293
concatenating 293
constraints 291
copying 297
creating from common objects 293
creating from other collections 291
creating in SCOPE 290
creating in Tcl 292
crossprobing objects 291
definition 289
diffing 293
highlighting in HDL Analyst views 296
listing objects 297
listing objects and properties 296
listing objects in a file 297
listing objects in columnar format 296
listing objects with c_list 296
special characters 295
Tcl window and SCOPE
comparison 289
using Tcl expand command 285
using Tcl find command 283
viewing 295
Collections panel
using SCOPE 263
column editing 112
combination hierarchical synthesis
flow 96
commands
Auto route cross probe insts (Physical
Analyst) 971
Go to Location (Physical Analyst) 966
Highlight Visible Net Instances
(Physical Analyst) 983
Markers 967
netlist editing 1152
Select Net Instances 983
Send Crossprobes when selecting
Signal Flow 954
slice_primitive 931
comments
source files 112
compilation process 368
compile point types
black_box 632
hard 629
locked 630
locked,partition 632
compile points
advantages 624
Altera incremental flows 1108
analyzing results 656
automatic compile point flow 644
automatic timing budgeting 637
child 627
constraint files 634
constraints for forward-annotation 644
constraints, internal 644
creating constraint file 654
defined 624
defining in constraint files 652
described 626
fast synthesis 659
feature summary 633
Identify flow 1149
incremental synthesis 661
manual compile point flow 648
multiprocessing 660
nested 627
optimization 641
order of synthesis 641
parent 627
preserving with syn_hier 656
Quartus II Incremental
Compilation 1111
resynthesis 642
setting constraints 655
setting type 653
syn_hier 656
synthesis process 640
synthesizing 644
types 628
Index
March 2014 1243
using automatic and manual compile
points together 658
using syn_allowed_resources
attribute 656
Xilinx incremental flows 1131
compile points and hierachical project
management 87
Compile Points panel 264
compile-point flow
Xilinx 1135
compile-point synthesis
interface logic models 636
compile-point synthesis flow
defining compile points 652
compiler directives 102
using New Constraint File 104
compiler directives (Verilog)
specifying 164
compiler directives syntax 105
compiler errors
Conformal 1160
congestion
using estimation report 378
congestion analysis after logic synthesis
using 378
congestion analysis report 378
congestion map
controls 988
constants
extracting from VHDL source code 167
constraint file
coreloc.sdc 254
constraint files
applying to a collection 291
compile point 634, 644
creating in a text editor 130
editing 271
effects of retiming 588
forward-annotating 132
options 159
setting for compile points 655
vendor-specific 132
constraints
altplls 999
defining clocks (Legacy) 301
defining register delays (Legacy) 302
specifying through points 275
translating Altera I/O constraints 318
translating with ise2syn 808
translating Xilinx contraints for logic
synthesis 326
types 263
types (legacy) 303
Vivado flow 1116
context
for object in filtered view 432
context help editor 108
SystemVerilog 108
context window (Physical Analyst) 945
continue on error 158, 366
analyzing errors 368
compilation 367
compile points 373
reporting 368
contraints
using FDC template command 261
control panel
Physical Analyst view 942
core voltage, Stratix III 1004
CoreGen 1040
coreloc.sdc 254
coreloc.sdc file 252
cores, instantiating in Xilinx
designs 1040
counters
SYNCore 696
create_fdc_template
using 261
critical paths
delay 457
flat view 456
hierarchical view 456
negative slack on clock enables
(Legacy) 312
slack time 457
using -route 579
viewing 455
critical paths (Design Planner)
assigning to regions 916
Index
1244 March 2014
critical paths (Physical Analyst)
tracing backward 487
tracing forward 485
crossprobing 421
and retiming 588
collection objects 291
filtering text objects for 426
from FSM viewer 428
from log file 345
from message viewer 358
from text files 424
from text files to Physical Analyst 974
Hierarchy Browser 421
importance of encoding style 428
paths 425
RTL view 422
Technology view 422
Technology view to Physical
Analyst 977
Text Editor view 422
text file example 425
to FSM Viewer 428
to place-and-route file 397
Verilog file 422
VHDL file 422
View Cross Probing commands 971
within RTL and Technology views 421
crossprobing (Physical Analyst)
auto route crossprobing 977
RTL view 971, 975
Technology view 971
crossprobing commands (Synplify
Premier)
current level
expanding logic from net 436
expanding logic from pin 436
searching current level and below 410
custom folders
creating 144
hierarchy management 144
customization
callback functions 826
D
data block 705
data key 705
default enum encoding 166
define_attribute 177
Delay Paths panel
using SCOPE 264
design flow
customizing with callback
functions 826
design flows
hierarchical project management 87
team design 87
design guidelines 576
design hierarchy
viewing 430
design plan
options 160
Design Plan Editor view
preserving region resources 911
design plan file
creating 896
logic synthesis 45
physical synthesis 54, 896
Design Planner 890
assigning pins 897
creating chip regions 912
displaying IP core areas 912
guidelines 889
logic synthesis 45
opening 890
physical synthesis 54
working with SSI devices 923
design planning 890
design size
amount displayed on a sheet 397
design views
moving between views 396
DesignWare
building blocks 724
DW_Foundation_Arith package 726
foundation library 724
importing cores 728
license queuing 817
minPower library 725
multiprocessing licenses 725
device options
See also implementation options
directives
Index
March 2014 1245
adding 169
adding in Verilog 171
adding in VHDL 170
black box 495, 496
for FSMs 502
specifying for Verilog compiler 164
syn_state_machine 608
syn_tco 496
adding black box constraints 495
syn_tpd 496
syn_tsu 496
directives in .cdc file 172
dissolving instances for flattening
hierarchy 443
distributed RAM
inferring 542
distributed TMR 506
example 508
DLLs
dot wildcard
Find command 413
drivers
preserving duplicates with
syn_keep 592
selecting 439
dual-port RAMs
SYNCore parameters 675
DW_Foundation_Arith package 726
E
ECC RAM 517
EDIF
structural, for Xilinx IP cores 1040
EDIF files
reoptimizing 1069
Editing window 111
editor
compiler directives 102
editor view
context help 108
EDK
specifying cores as white boxes 809
EDN core 795
emacs text editor 116
encoding styles
and crossprobing 428
default VHDL 166
FSM Compiler 607
encrypted IP objects (Physical Analyst)
identifying cells 969
encryption
synenc 728
encryption flow. See ReadyIP, encryptIP
encryptip output constraints 717
encryptip output method
effect on output netlists 716
encryptIP script
controlling output 715
encrypting IP 714
output methods 715
encryptP1735 script
encrypting multiple files 713
location 709
public keys respository file 713
use models 709
encryptP1735P script
encrypting IP 708
enhanced optimization
compared to fast synthesis 41
using 42
environment variables
PAR_BELDLYRPT 230
SYN_TCL_HOOKS 826
equivalence checking
VIF file 1156
equivalency checking
handling failure 1161
error codes 813
error correction code. See ECC 517
error messages
gated clock report 854
error mitigation. See high reliability
errors
black boxing 368
continuing 158, 366
definition 111
filtering 357
Index
1246 March 2014
sorting 357
source files 110
Verilog 110
VHDL 110
expand
batch mode 287
Expand command
connection logic 439
connections in Physical Analyst 985
pin and net logic 435
using 436
expand command
different from Tcl search 416
Expand command (Physical Analyst) 980
expand command (Tcl). See Tcl expand
command
Expand Inwards command
using 436
Expand Path Backward command 487
Expand Path Forward command 485
Expand Paths command
different from Isolate Paths 439
expand pin view (Design Planner) 893
Expand to Register/Port command
using 436
Expand to Register/Port command
expanding
connections 439
connections (Physical Analyst) 985
pin and net logic 435
pin and net logic (Physical Analyst) 980
F
false paths
defining between clocks (Legacy) 317
I/O paths 279
impact of clock group assignments 279
impact of clock group assignments
(Legacy) 316
ports 279
ports (Legacy) 316
registers 279
registers (Legacy) 316
setting constraints (Legacy) 316
fanout
replicating instances (Design
Planner) 916
fanouts
buffering vs replication 600
hard limits 599
soft global limit 598
soft module-level limit 599
using syn_keep for replicaton 593
using syn_maxfan 598
fast synthesis
compile points 659
using 618, 619
fast turnaround
prototypes 1227
fault tolerance. See high reliability
feature comparison
FPGA tools 27
FIFOs
compiling with SYNCore 666
files
.acf 133
.lpf 133, 1023
.prf file 359
altpll component declarations 999
dependent list 193
filtered messages 361
fsm.info 608
log 342
message filter (prf) 359
output 1096
rom.info 403
searching 211
statemachine.info 449
synhooks.tcl 826
Tcl 819
See also Tcl commands
Tcl batch script 813
Filter Schematic command, using 433
Filter Schematic icon, using 433
filtering 433
advantages over flattening 433
using to restrict search 410
filtering (Physical Analyst) 979
Find command
410
browsing with 409
Index
March 2014 1247
hierarchical search 411
long names 409
message viewer 357
reading long names 412
search scope, effect of 413
search scope, setting 411
searching the mapped database 412
searching the output netlist 418
setting limit for results 412
using in RTL and Technology views 410
using wildcards 413
wildcard examples 415
find command
different from Tcl search 416
hierarchy 416
nuances and differences 417
Find command (Physical Analyst)
using Filter Search option 965
using wildcards 964
find command (Tcl)
See Tcl find command
finding information
information organization 32
finding objects
Fix Gated Clocks option. See gated
clocks
Flatten Current Schematic command
transparent instances 441
using 441
Flatten Schematic command
using 441
flattening 440
See also dissolving
compared to filtering 433
dissolving instances 443
hidden instances 442
using syn_hier 596
using syn_netlist_hierarchy 596
floorplan file. See sfp file, design plan file
floorplan. See Design Planner
formal verification
Formality 1195
Formality
using 1195
forward annotation
frequency constraints in Xilinx 1033
vendor-specific constraint files 132
forward-annotation
compile point constraints 643
constraints 1022
Xilinx core files 797
foundation library 724
FPGA Design Constraints Editor
using TCL View 269
FPGAs
partitioning 1218
frequency
clocks (Legacy) 309
defining for non-clock signals
(Legacy) 310
internal clocks (Legacy) 309
setting global 158
from constraints 274
FSM Compiler
advantages 605
enabling 607
FSM encoding
user-defined 504
using syn_enum_encoding 504
FSM Explorer 605
running 611
when to use 605
FSM view
crossprobing from source file 424
FSM Viewer 446
crossprobing 428
fsm.info file 608
FSMs
See also FSM Compiler, FSM Explorer
attributes and directives 502
defining in Verilog 500
defining in VHDL 501
definition 500
Hamming3 521
optimizing with FSM Compiler 605
properties 449
safe. See safe FSMs
single-bit errors 521
state encodings 448
transition diagram 446
viewing 446
Index
1248 March 2014
G
gated clocks
attributes for black boxes 872
conversion example 844
conversion requirements 843
defining (Legacy) 314
error messages 854
examples 841
procedure for fixing 850
restrictions 878
gated-clock conversion
excluding elements 857
Generated Clocks panel
using SCOPE 263
generated-clock conversion 883
generics
extracting from VHDL source code 167
passing boolean 123
passing integer 124
global comments
initializing Xilinx RAM 1050
global optimization options 155
global sets/resets
Xilinx designs 1036
Go to Location command 966
adding markers 968
graph-based physical synthesis
Altera 57
description 48
logic synthesis validation phase 48
physical synthesis phase 49
grey box
netlist file 752
grey box flow
MegaCore with greybox netlist 752
grey boxes
using 749
greybox flow
MegaCore with IP package 756
NIOS II cores 759
SOPC cores 759
GSR resources 1012
GSR, Xilinx 1036
H
Hamming Distance 3 521
HAPS technology selection 153
HDL Analyst
See also RTL view, Technology view
critical paths 455
crossprobing 421
filtering schematics 433
Push/Pop mode 403, 406
quick load option 158
traversing hierarchy with mouse
strokes 401
traversing hierarchy with Push/Pop
mode 403
using 429
HDL Analyst Quick Load option 158
HDL Analyst tool
deselecting objects 394
selecting/deselecting objects 394
HDL Analyst views
highlighting collections 296
HDL views, annotating timing
information 453
help
information organization 32
hidden instances
consequences of saving 431
flattening 442
restricting search by hiding 410
specifying 431
status in other views 431
hierarchical design
expanding logic from nets 436
expanding logic from pins 435
hierarchical instances
dissolving 443
hiding. See hidden instances, Hide
Instances command
multiple sheets for internal logic 432
pin name display 434
viewing internal logic 431
hierarchical objects
pushing into with mouse stroke 402
traversing with Push/Pop mode 403
hierarchical project management and
compile points 87
Index
March 2014 1249
hierarchical project management flows
bottom-up development flow 89
bottom-up synthesis flow 92
top-down development flow 90
top-down synthesis flow 94
hierarchical project managment flows
mixed block synthesis flow 96
hierarchical projects 87
analyzing 209
configuring for synthesis 205
instance-based synthesis 181
multiple implementations 194
synthesis options 205
hierarchical search 410
hierarchy
flattening 441
netlist restructuring 229
traversing 400
hierarchy browser
clock trees 455
controlling display 397
crossprobing from 421
defined 400
finding objects 408
traversing hierarchy 400
hierarchy management (custom
folders) 144
high reliability
distributed TMR 506
ECC RAM 517
FSMs with Hamming3 521
local TMR 516
safe FSMs 519
using safe FSM 519
using TMR 506
high reliability design 505
Highlight Visible Net Instances
command 983
hyper source
example 731
for IPs 729
for prototyping 729
IP design hierarchy 729
threading signals 730
I
I/O insertion 603, 1021
VHDL manual (Xilinx) 1059
I/O locations
assigning automatically (Xilinx) 1054
manually assigning (Xilinx) 1059
I/O pads
specifying I/O standards 268
I/O paths
false path constraint 279
I/O standards
specifying 268
I/O Standards panel
using SCOPE 264
I/Os
auto-constraining 470
constraining 267
constraining (Legacy) 315
packing in Altera designs 1001
packing in Xilinx designs 1043
preserving 604, 1022
specifying pad type (Xilinx) 1068
Verilog black boxes 490
VHDL black boxes 492
I/Os (Design Planner)
critical paths from pin-locked I/Os 916
IBUFDS
inference 1061
IBUFGDS
inference 1061
ICG
stability latch removal 864
Identify
compile points 1149
Implementation Maps
Physical Analsyt 986
implementation options 152
design plan file 160
device 152
global frequency 158
global optimization 155
netlist optimizations 228
part selection 152
specifying results 161
implementations
copying 151
deleting 151
multiple. See multiple
implementations.
Index
1250 March 2014
overwriting 151
renaming 151
Incremental Compiler
using 125
incremental flows
Quartus Fast Fit 1109
SmartGuide 1132
Vivado 1126
Xilinx partion (before ISE 12.1) 1140
Xilinx partition 1135
Incremental Mode option
using Incremental Compiler 125
incremental synthesis
compile points 661
locked,partition compile points 632
other tools 664
inference
BUFGMUX/BUFGMUX_1 1061
Xilinx BUFGMUX/BUFGMUX_1 1060
Xilinx I/O buffers 1060
INIT property
initializing Xilinx RAMs, Verilog 1049
initializing Xilinx RAMs, VHDL 1052
specifying with attributes 1053
initial values
on primitives 558
initializing 554
initializing RAM 554
INITvalues
Xilinx registers 1046
Input and output constraints
defining 267
input constraints, setting 267
input constraints, setting (Legacy) 315
Inputs/Outputs panel
using SCOPE 264
instance-based subproject
compared to block-based 178
instance-based synthesis
instances
preserving with syn_noprune 592
properties 389
properties of pins 389
instances (Physical Analyst)
adding markers 967
displaying instances 948
Integrated Clock Gating (ICG)
stability latch removal 864
ILM See interface logic models
interface logic models 636
interface timing 637
IOBUFDS
inference 1061
IP
encryption-decryption flow 703
importing from SOPC Builder 761
license queuing 817
re-encryption 706
Vivado 779
IP core areas (Design Planner) 912
IP cores 1040
Vivado 1116
IP design hierarchy
hyper source 729
IP encryption flow overview 702
IP encryption scheme 707
IP license queuing 817
IP vendors
directory structure for package 720
encrypting IP 707
package file list for ecnypted IP
flow 719
packaging for evaluation 717
supplying vendor information 722
IPs
Altera 734
encrypting 707
encryption flow 702
SYNCore 666
SYNCore byte-enable RAMs 678
SYNCore counters 696
SYNCore FIFOs 666
SYNCore RAMs 671
SYNCore ROMs 684
SYNCore subtractors 689
system-level models, providing 721
using hyper source for debug 729
IP-XACT models 717
is_error_blackbox property 370
ise2syn
Index
March 2014 1251
description 800
relationship with ucf2sdc 800
ise2syn utility
converting Xilinx projects 800
using 800
Isolate Paths command
different from Expand Paths 439, 440
ispLEVER
forward-annotating constraints
for 1022
iterations
reducing with compile on error 366
J
job management
up-to-date checking 337
K
key assignments
customizing 827
key block 705
keywords
completing words in Text Editor 112
L
latches
generated-clock conversion 883
Lattice
constraint file 133
forward annotation 133
I/O insertion 603
macro libraries 1010
PICs 1013
Lattice netlist 1096
lcell primitive
Clearbox 738
libraries
Xilinx post-synthesis simulation 1072
library extensions 117
license queuing 815
blocking-style 815
DesignWare IP 817
IP 817
license release (synthesis)
after P&R 1107
license_release 1107
licenses
DesignWare multiprocessing 725
lists
dependent files 193
local TMR
RAM 516
location constraints
RLOC_ORIGIN 1064
RLOCs with synthesis attribute 1064
RLOCs with xc_attributes 1062
log file
remote access 348
log files
checking FSM descriptions 611
checking information 342
crossprobing to Physical Analyst 974
pipelining description 583
retiming report 587
setting default display 342
shift register report (Altera) 561
state machine descriptons 607
viewing 342
logic
expanding between objects 439
expanding from net 436
expanding from net (Physical
Analyst) 983
expanding from pin 435, 980
logic preservation
syn_hier 596
syn_keep for nets 592
syn_keep for registers 592
syn_noprune 592
syn_preserve 592
logic synthesis
in Altera physical synthesis flow 62
in physical synthesis flows 41
translating UCF constraints 326
with design plan 45
logical folders
creating 144
LPM_RAM_DQ
VHDL example 571
Index
1252 March 2014
LPMs
Altera megafunction example
(Verilog) 566
Altera megafunction example
(VHDL) 568
black box method simulation flow 1005
comparison of Altera instantiation
methods 565
creating synthesis projects 775
generics method, Cypress 570
in .vqm 566
including in physical synthesis 734
instantiating as black boxes 565
instantiating as black boxes
(Altera) 566
instantiating with a Verilog library
(Altera methodology) 566
instantiating with a Verilog library
(Synplicity methodology) 572
instantiating with VHDL prepared
components 570
prepared components (Altera),
example 570
using in Altera simulation flows 1005
Verilog library simulation flow 1006
VHDL prepared component simulation
flow 1006
VHDL prepared components
instantiation example 571
LPMs, Altera 565
LUTRAMs, inferring 538
M
mac_mult primitive
Clearbox 738
mac_out primitive
Clearbox 738
macro libraries
Lattice 1010
macro libraries (Xilinx) 1033
macros (Xilinx) 1033
manhattan distance (Physical
Analyst) 969
manual compile points
compared to automatic 626
flow 648
using with automatic 658
markers (Physical Analyst)
adding 967
adding with Go to Location 968
deleting 968
finding objects with 966
measuring with 969
moving 968
navigating between 969
using 967
Markers command 967
max_parallel_jobs variable 821
maximum parallel jobs 820, 836
MaxParallelJobs variable 820
MegaCore
grey box flow with grey box netlist 752
greybox flow with IP package 756
MegaCore IP 756
Megacore IPs
importing in a Quartus design 774, 775
megafunctions
altplls 998
creating synthesis project 775
grey boxes 749
including in physical synthesis 734
inferring Clearbox information 739
instantiating Clearbox 743
instantiating Clearbox with netlist 746
using Clearbox 751
using grey box netlist 752
MegaWizard
importing cores from 756
Megawizard
altplls 998
memory usage
maximizing with HDL Analyst 445
Message viewer
filtering messages 358
keyboard shortcuts 357
saving filter expressions 359
searching 357
using 356
using the F3 key to search forward 357
using the Shift-F3 key to search
backward 357
messages
demoting 363
filtering 358
promoting 363
Index
March 2014 1253
saving filter information from command
line 360
saving filter information from GUI 359
severity levels 364
suppressing 363
writing messages to file 361
Microsemi
ACTgen macros 1028
output netlist 1096
pin numbers for bus ports 1093
minPower library 725
mitigation technology 505
mixed block hierarchical synthesis
flow 96
mixed designs
troubleshooting 123
mixed language files 120
mouse strokes
pushing/popping objects 401
mouse strokes (Physical Analyst)
navigating between views 944
multicycle constraints
forward-annotating 1022
multicycle paths
setting constraints (Legacy) 307
running from project 150
multipliers
pipelining restriction 580
multipliers, pipelining 580
multiprocessing
compile points 660
maximum parallel jobs 820, 836
multisheet schematics 395
for nested internal logic 432
searching just one sheet 410
N
name spaces
output netlist 418
technology view 412
navigating among design views 396
ncf file
cores 797
ncf files
output physical constraints
(Legacy) 320
translating to sdc 329
using as input for logic design 326
commands 1152
RTL-level 1151
Tcl commands 1152
netlist editing commands 1152
netlists
importing from Vivado 779
restructuring options 228
netlists (Physical Analyst)
analyzing 979
netlists for different vendors 1096
nets
expanding logic from 436
preserving for probing with
syn_probe 592
preserving with syn_keep 592
properties 389
selecting drivers 439
nets (Physical Analyst)
adding markers 967
expanding logic from 983
resetting the display 954
routing 952
selecting instances 983
signal flow 954
unfiltering for Find command 962
New property 391
NGC cores 795
NGO core 795
NIOS II, importing as greybox 760
non-secure core flow
synthesis 798
notes
filtering 357
sorting 357
notes, definition 111
Index
1254 March 2014
O
objects
finding on current sheet 410
flagging by property 390
selecting/deselecting 394
objects (Physical Analyst)
finding 962
finding by location 966
overlapping 955
select overlapping 955
selecting 955
OBUFDS
inference 1061
OBUFTDS
inference 1061
open_design
with find and expand 287
optimization
for area 577
for timing 578
generated clock 883
logic preservation. See logic
preservation.
mapper effort. See fast synthesis 579
preserving hierarchy 596
preserving objects 592
tips for 576
optimizing
enhanced logic optimizations 43
options
HDL Analyst Quick Load 158
options file (place-and-route) 234
orig_inst_of property 392
output constraints, setting 267
output constraints, setting (Legacy) 315
output files 1096
specifying 161
output netlists
finding objects 418
overutilization 355
P
package library, adding 138
pad types
industry standards 268
PAR_BELDLYRPT 230
parallel jobs 820
parameter passing 124
boolean generics 123
parameters
extracting from Verilog source code 164
part selection options 152
partition flow, Xilinx 1135
partitioning (Synplify Premier)
bit slicing 930
path constraints
false paths 279
pathnames
using wildcards for long names
(Find) 413
paths
crossprobing 425
tracing between objects 439
tracing from net 436
tracing from pin 435
paths (Physical Analyst)
tracing between objects 985
tracing from net 983
tracing from pin 980
pattern matching
pattern searching 211
PDF
cutting from 112
Physical Analyst
analyzing netlists 979
context window 945
control panel 942
crossprobing from text files 974
crossprobing RTL view 975
crossprobing to Technology view 977
displaying instances 948
identifying encrypted IP objects 969
opening 941
overlapping objects 955
properties 957
using Block Inputs Map 992
using Block Utilization Map 991
using implementation maps 986
Index
March 2014 1255
using Routing Congestion map 989
using Slack Map 993
Physical Analyst view
adding markers 968
critical paths 482
crossprobing 971
displaying net signal flow 954
Expand commands 980
filtering 979
finding objects 962
Go to Location command 966
selecting objects 955
tool tips (Physical Analyst) 960
using markers 967
zoom selected objects 943
physical constraints
design plan-based physical
synthesis 54
design-plan based logic synthesis 45
Xilinx output file (Legacy) 320
physical constraints (Design Planner -
Altera)
Altera guidelines 919
physical constraints (Design Planner
-Xilinx)
Xilinx guidelines 928
physical coordinates
marking 967
Physical Plus Flow
running 76, 80
Xilinx 66
physical synthesis
Altera 57
analyzing results 938
graph-based (Altera) 57
improve performance
(Altera) 1007, 1070
running place-and-route 1104
using design plan file 896
with back annotation 252
with design plan file 54
PICs 1013
pin assignment (Design Planner) 897
assigning clock pins 900
crossprobing 906
temporary assigns 902
pin assignment tool (Design
Planner) 893
pin assignments
converting to constraints 247
pin assignments (Design Planner)
temporary 902
pin loc constraint files
converting to SDC 247
pin locations
specifying (Xilinx) 1054
pin names, displaying 434
pins
expanding logic from 435, 980
properties 389
pipelining
adding attribute 582
definition 580
multipliers 580
prerequisites 580
whole design 581
place-and-route
creating implementation 229
customizing ISE option file 237
customizing option file 234
customizing Vivado option file 1122
placement constraint file 252
with back annotation 252
with physical synthesis 1104
place-and-route implementations 229
PLLs
port context 203
ports
false path constraint (Legacy) 316
properties 389
POS interface
using 275
post_route.dcp file 1128
post-synthesis constraints with adc 463
post-synthesis simulation, Xilinx 1071
preferences
crossprobing to place-and-route
file 397
displaying Hierarchy Browser 397
displaying labels 398
RTL and Technology views 397
sheet size (UI) 397
Index
1256 March 2014
preplace.srm file 939
preserving region resources
Design Plan Editor view 911
primitives
initial values 558
pin name display 434
pushing into with mouse stroke 402
viewing internal hierarchy 430
primitives (Synplify Premier)
breaking up large 930
probes
adding in source code 613
definition 613
retiming 590
process-level hierarchy 930
Product of Sums interface. See POS
interface
project command
archiving projects 214
copying projects 221
unarchiving projects 218
project file hierarchy 144
project files
adding files 140
adding source files 136
batch mode 812
creating 136
definition 136
deleting files from 140
opening 139
replacing files in 140
updating include paths 143
VHDL file order 139
VHDL library 138
project status report
remote access 348
projects
archiving 214
copying 221
files after importing from Quartus 772
importing from Quartus 769
restoring archives 218
properties
copying and pasting (Physical
Analyst) 961
displaying with tooltip 389
encrypted IP cells (Physical
Analyst) 969
finding objects with Tcl find -filter 282
orig_inst_of 392
reporting for collections 296
viewing for individual objects 389
prototypes
fast turnaround 1227
initial 1225
optimizing timing 1228
QoR 1228
prototyping 1217
converting ASIC designs 1220
guidelines 1221
using hyper source threading 729
Push/Pop mode
HDL Analyst 401
keyboard shortcut 403
using 401, 403
Q
QoR
prototypes 1228
qsf
importing 769
translating I/O constraints 318
qsf file
translated files for synthesis 772
qsf2sdc
translating constraints 318
qsf2syn.log file 771
Quartus
batch mode 1009
imported settings and constraints 773
importing design with Megacore IP 774
importing design with
megafunctions 775
importing LPMs 775
importing megafunctions 775
importing projects from 769
incremental flows 1108
integrated flow 1007
interactive flow 1008
supported constraints for import 773
supported project settings for
import 773
synthesis project files 772
using instantiated Clearbox netlist
files 748
Index
March 2014 1257
Quartus Fast Fit flow 1109
Quartus II
using synthesis results to run 1007
Quartus II Incremental Compilation
flow 1110
Quartus II Incremental Synthesis
running 1110
Quartus incremental compilation
flow 1108
QUARTUS_ROOTDIR variable
inferring Clearbox megafunctions 740
instantiating Clearbox 743
question mark wildcard, Find
command 413
R
radiation effects. See high reliability
RAM
local TMR 516
RAM inference 529
using attributes 531
ram_block primitive
Clearbox 738
RAMs 554
compiling with SYNCore 671
ECC 517
inferring block RAM 533
initializing 554
initializing values (Xilinx) 1048
mapping LUTRAMs 538
SYNCore 671
SYNCore, byte-enable 678
TMR 516
region clock buffers (BUFR) 1061
regions
retiming 591
regions (Design Planner)
preserving logic and memory
resources 911
replicating logic manually
replicating instances (Design
Planner) 916
register balancing. See retiming
register constraints, setting (Legacy) 306
register packing
See also syn_useioff attribute 1043
Altera 1001
Xilinx 1043
registers
false path constraint (Legacy) 316
INIT value 1046
Registers panel
using SCOPE 264
relative placement. See RLOCs
remote access
status reports 348
replication
controlling 600
reports
gated clock conversion 852
shift registers, Altera 561
resource sharing 1013
optimization technique 577
overriding option with syn_sharing 603
results example 603
using 602
resource usage 354
resource utilization. See resource usage
resynthesis
compile points 643
forcing with Resynthesize All 643
forcing with Update Compile Point
Timing Data 643
retiming
effect on attributes and constraints 588
example 586
overview 584
probes 590
regions 591
report 587
simulation behavior 590
return codes 813
RLOC_ORIGINs
specifying 1064
RLOCs 1062, 1064
specifying with synthesis
attribute 1064
specifying with xc attributes 1062
rom.info file 403
ROMs
Index
1258 March 2014
pipelining 580
SYNCore 684
viewing data table 403
Routing Congestion map
RTL
importing from Vivado 782
RTL view
See also HDL Analyst
analyzing clock trees 455
crossprobing collection objects 291
crossprobing description 421
crossprobing from 422
crossprobing from Text Editor 424
defined 387
description 386
filtering 433
finding objects with Find 410
finding objects with Hierarchy
Browser 408
flattening hierarchy 441
opening 388
sequential shift components 560
setting preferences 397
state machine implementation 608
RTL views
hierarchical subprojects 192
run_vivado.tcl
See alsoVivado, options file
run_vivado.tcl file 1121
running P&R
license release (synthesis) 1107
runtime
S
safe case 519
safe FSM 519
using Hamming Distance 3 521
using safe case 519
schematics
multisheet. See multisheet schematics
page size 397
SCOPE
adding attributes 174
adding probe insertion attribute 614
assigning Xilinx pin locations 1055
Attributes panel 264
case sensitivity for Verilog designs 281
Clocks panel 263
collections compared to Tcl script
window 289
Collections panel 263
Compile Points panel 264
creating compile-point constraint
file 654
defining compile points 651
Delay Paths panel 264
drag and drop 272
editing operations 273
Generated Clocks panel 263
I/O pad type 268
I/O Standards panel 264
Inputs/Outputs panel 264
multicycle paths 278
pipelining attribute 581
Registers panel 264
setting compile point constraints 655
setting constraints (FDC) 256
specifying constraints 263
specifying RLOCs 1062, 1064
state machine attributes 502
TCL View 264
SCOPE editor
using 256
scope of the document 31
SCOPE panels
entering and editing constraints 263
SCOPE TCL View
using 269
sdc
converting from Xilinx ucf 329
sdc constraints
manually converting UCF 325
search
browsing objects with the Find
command 409
browsing with the Hierarchy
Browser 408
Index
March 2014 1259
finding objects on current sheet 410
setting limit for results 412
setting scope 411
using the Find command in HDL
Analyst views 410
secure core flow
synthesis 798
See also search
Select Net Instances command (Physical
Analyst) 983
select RAM
initializing 1054
selecting objects (Physical Analyst) 955
Send Crossprobes when selecting
command 971
sequential shift components
Altshift_tap 559
mapping 559
SRL16 primitives 559
Verilog 564
VHDL 563
sequential shift components See shift
registers
set command
collections 297
set_option command 154
sfp file
creating 896
logic synthesis 45
sheet connectors
navigating with 396
sheet size
setting number of objects 397
shift register lookup table. See
sequential shift components
shift registers
inferring 559
Shift-F3 key
Message Viewer 357
Show Cell Interior option 430
Show Context command
different from Expand 432
using 432
signal flow (Physical Analyst) 954
displaying 954
Signal Flow command 954
signal pins (Physical Analyst)
displaying 951
signals
threading with hyper source. See hyper
source
simulation, effect of retiming 590
single-port RAMs
SYNCore parameters 674
site columns
properties (Physical Analyst) 960
sites (Physical Analyst)
properties 960
slack 458
setting margins 455
Slack Map
slack time display 452
slice_primitive command 931
Slow property 391
SmartGuide flow 1132
SoC 1217
SOPC Builder
importing embedded systems 760
source code
adding pipelining attribute 582
commenting with synthesis on/off 167
crossprobing from Tcl window 427
defining FSMs 500
fixing errors 113
opening automatically to
crossprobe 423
optimizing 576
specifying RLOCs 1062, 1064
source files
See also Verilog, VHDL.
adding comments 112
adding files 136
checking 110
column editing 112
copying examples from PDF 112
creating 100
crossprobing 424
editing 111
Index
1260 March 2014
mixed language 120
specifying default encoding style 166
specifying top level file for mixed
language projects 121
specifying top level in Project view 139
specifying top-level file 166
state machine attributes 502
using bookmarks 112
special characters
Tcl collections 295
SRLs See shift registers
STA 459
STA, generating custom timing
reports 459
STA, using analysis design constraints
(adc) 462
stability latches
ICG 864
stand-alone timing analyst. See STA
startup block (Xilinx) 1036
state machines
See also FSM Compiler, FSM Explorer,
FSM viewer, FSMs.
attributes 502
descriptions in log file 607
implementation 608
parameter and define comparison 501
statemachine.info file 449
Structural Verilog flow 127
sub-projects
creating 179
linking updates to top level 180
synchronizing device options with top
level 208
subprojects
block-based 178
compiling 190
differences between instance-based
and block-based 178
generating port context 203
instance-based 181
nested 187
subtractors
SYNCore 689
syn_allow_retiming
using for retiming 585
syn_allowed_resources
compile points 656
syn_black_box
instantiating LPMs (Altera) 566
syn_dspstyle attribute
inferring wide adders/subtractors 1038
syn_edif_bit_format attribute 1040
syn_edif_scalar_format attribute 1040
syn_encoding attribute 503
syn_enum_encoding directive
FSM encoding 504
syn_force_pad attribute
using 603, 1021
syn_forward_io_constraints
attribute 132
syn_hier attribute
Altera Quartus II Incremental
Compilation flow 1112
controlling flattening 596
preserving hierarchy 596
using with compile points 656
syn_highrel_ioconnector
uisng 513
syn_insert_buffer attribute
BUFGMUX 1060
syn_isclock
black box clock pins 498
syn_keep
inferring Altera shift registers 560
inferring Lattice PICs 1014
replicating redundant logic 593
syn_keep attribute
preserving nets 592
preserving shared registers 592
syn_keep directive
effect on buffering 600
syn_macro
specifying encrypted IP as white
box 716
white-boxing non-secure cores 798
syn_maxfan attribute
setting fanout limits 598
Xilinx buffers 601
syn_noarrayports attribute
use with alspin 1093
Index
1261 March 2014
syn_noprune directive
preserving instances 592
syn_pipeline attribute 582
syn_preserve
effect on buffering 600
preserving power-on for retiming 586
preserving registers with INIT
values 1046
syn_preserve directive
preserving FSMs from optimization 502
preserving logic 592
syn_probe attribute 613
inserting probes 613
preserving nets 592
syn_radhardlevel
distributed DWC 510
distributed TMR 506
syn_reference_clock constraint
(Legacy) 301
syn_replicate attribute
using buffering 601
syn_sharing directive
overriding default 603
syn_srlstyle attribute
altshift_tap 559
mapping sequential shift components
to registers 559
setting shift register style 559
syn_state_machine directive
using with value=0 608
SYN_TCL_HOOKS environment
variable 826
syn_tco attribute
adding in SCOPE 497
syn_tco directive 496
syn_tpd attribute
adding in SCOPE 497
syn_tpd directive 496
syn_tsu attribute
adding in SCOPE 497
syn_tsu directive 496
syn_use_carry_chain attribute
using 1013
syn_useioff
preventing flops from moving during
retiming 586
syn_useioff attribute
packing registers (Altera) 1001
packing registers (Xilinx) 1043
SYN_XILINX_GLOBAL_PLACE_OPT
environment variable 245
SYNCore
adders 689
counters 696
FIFO compiler 666
RAMs 671
RAMs, byte-enable 678
RAMs, dual-port parameters 675
RAMs, single-port parameters 674
ROMs 684
ROMs, parameters 688
subtractors 689
synenc encryption 728
synhooks
automating message filtering 361
synhooks.tcl file 826
Synopsys
FPGA product family 26
synplicity.ucf file
non-secure cores 797
relation to ncf file (Legacy) 320
secure cores 797
Synplify Premier
list of design flows 41
logic synthesis flows 41
Synplify Premier flows
Xilinx Physical Plus 66
Synplify Premier synthesis tool
overview 26
Synplify Pro synthesis tool
overview 26
synplify UNIX command 32
synplify_premier UNIX command 32
synplify_premier_dp UNIX command 32
synplify_pro UNIX command 32
SYNPLIFY_REMOTE_REPORT_LOCATIO
N 350
Index
March 2014 1262
synplify.ucf 330
synplify.vhd 1072
syntax
checking source files 110
syntax check 110
synthesis
Xilinx non-secure cores 798
Xilinx secure cores 798
synthesis check 110
synthesis_on/off
using 167
SystemDesigner
using with Xilinx IP 718
SystemVerilog keywords
context help 108
T
ta file 459
Tcl
max_parallel_jobs variable 821
tcl callbacks
customizing key assignments 827
Tcl commands
batch script 813
netlisting editing 1152
running 819
Tcl expand
using 280
Tcl expand command
usage tips 285
using in SCOPE 290
Tcl files 819
creating 821
for bottom-up synthesis 825
guidelines 130
naming conventions 131
recording from commands 820
synhooks.tcl 826
using variables 823
wildcards 131
Tcl find
batch mode 287
filtering results by property 282
search patterns 280
using 280
Tcl find command
annotating properties 282
case sensitivity 281
database differences 290
pattern matching 281
Tcl window vs SCOPE 289
usage tips 283
useful -filter examples 283
using in SCOPE 290
Tcl Script window
crossprobing 427
message viewer 356
Tcl script window
collections compared to SCOPE 289
Tcl scripts
See Tcl files.
TCL View 269
uisng 269
using SCOPE 264
-tclcmd 812
team design. See hierarchical projects,
hierarchical project management
flows
Technology view
See also HDL Analyst
critical paths 455
crossprobing 421, 422
crossprobing collection objects 291
crossprobing from source file 424
filtering 433
finding objects 412
finding objects with Find 410
finding objects with Hierarchy
Browser 408
flattening hierarchy 441
general description 386
opening 388
setting preferences 397
state machine implementation in 608
temporary assigns (Design Planner) 902
drag and drop 902
empty 902
Index
1263 March 2014
return assignment 902
text editor
built-in 111
external 116
using 111
Text Editor view
crossprobing 422
Text Editor window
colors 114
crossprobing 114
fonts 114
text files
crossprobing 424
The Synopsys FPGA Product Family 26
third-party vendor tools
invoking 1098
through constraints 275
AND lists 276
OR lists 275
time stamp, checking on files 141
time stamps
Xilinx partition flow 1138
TimeQuest
supported constraints for import 774
timing
after logic synthesis 940
prototypes 1228
timing analysis 452
timing analysis using STA 459
timing budgeting
compile points 637
timing constraints
translating qsf 772
Xilinx output file (Legacy) 320
timing constraints (Legacy) 301
timing exceptions, adding constraints
after synthesis 463
timing exceptions, modifying with
adc 463
timing failures 458
timing information commands 452
timing information in HDL views 453
timing information, critical paths 457
timing optimization 578
Timing Report View 474
using 474
timing report, stand-alone 459
timing reports
specifying format options 162
timing reports, custom 459
timing_applied.sdc file 772
timing_unapplied.sdc file 772
tips
memory usage 445
TMR
description 505
distributed 506
local. See local TMR 516
using 506
using for ECC 516
using for RAM 516
voter insertion examples 508
to constraints
specifying 275
tool tags
creating 1098
definition 1098
tool tips
tooltips (Physical Analyst)
copying information from 961
top level
specifying 166
top-down design flow
compile point advantages 624
top-down hierarchical develpment flow
sub-projects 179
top-down hierarchical synthesis flow 94
top-first hierarchical development
flow 90
transparent instances
flattening 441
lower-level logic on multiple sheets 395
triple modular redundancy. See TMR
U
UCF
Vivado support 1116
Index
March 2014 1264
UCF constraints 325
converting to sdc manually 325
input files 329
supported 331
translating for logic synthesis 326
unsupported 332
ucf file
using as input for logic design 326
ucf file (Legacy). See also synplicity.ucf
ucf2sdc 325
ucf2sdc.log file 330
UINISIM library
simulation 1072
unisim libraries
Virtex 2 with ISE 11 1033
UNISIM library 1033
UNIX commands
synplify 32
synplify_premier 32
synplify_premier_dp 32
synplify_pro 32
unsupported.ucf 330
up-to-date checking 337
copying job logs to log file 339
limitations 340
using 127
V
VCS-Analyst Integration tool 1167
using 1167
vendor-specific netlists 1096
verification
using VIF file 1156
Verilog
define statements 164
adding attributes and directives 171
adding probes 613
Altera LPM library 572
Altera LPM megafunction example 566
Altera PLLs 998
always block hierarchy 229
black boxes 490
black boxes, instantiating 490
case sensitivity for Tcl Find
command 281
checking source files 110
choosing a compiler 164
clock DLLs 1066
creating source files 100
crossprobing from HDL Analyst
view 422
defining FSMs 500
defining state machines with parameter
and define 501
extracting parameters 164
include paths, updating 143
initializing RAMs 554
instantiating LPMs as black boxes
(Altera) 566
macro library (Xilinx) 1033
Microsemi ACTgen macros 1028
RLOCs 1063
specifying compiler directives 164
specifying top-level module 166
structural, for instantiated
Clearbox 746
using library extensions 117
Verilog 2001
setting global option from the Project
view 164
setting option per file 164
Verilog library files
using library extensions 117
Verilog macro libraries
Lattice 1010
Microsemi 1027
Verilog model (.vmd) 636
VHDL
adding attributes and directives 170
adding probes 613
Altera LPM megafunction example 568
Altera PLLs 998
black boxes 492
black boxes, instantiating 492
case sensitivity for Tcl Find
comand 281
checking source file 110
clock DLLs 1066
constants 167
creating source files 100
crossprobing from HDL Analyst
view 422
Index
1265 March 2014
defining FSMs 501
extracting generics 167
file order in mixed designs 123
global signals in mixed designs 123
initializing RAMs with variable
declarations 557
initializing with signal declarations 555
instantiating LPMs as black boxes
(Altera) 566
LPM instantiation example 571
macro libraries, Microsemi 1027
macro library (Xilinx) 1033
prepared components method of
instantiation 571
process hierarchy 229
RLOCs 1063
specifying top-level entity 166
structural, for instantiated
Clearbox 746
VHDL files
adding library 138
adding third-party package library 138
order in project file 139
ordering automatically 139
VHDL macro libraries
Lattice 1011
vi text editor 116
VIF file
using 1156
vif2conformal.tcl script 1160
Virtex
clock buffers 1065
I/O buffers 1068
netlist 1096
PCI core 1040
virtual clock, setting (Legacy) 306
Vivado
environment variables 1117
flow 1115
netlists 1115
options file 1122, 1123
running 1118
running incrementally 1126
running place-and-route 1114
Vivado IP 779
generating 780
importing 779
importing netlists 779
importing RTL 782
Vivado IP Catalog 780
vqm
inferred Clearbox 741
instantiated Clearbox 743
instantiated Clearbox with netlist 748
W
warning messages
definition 111
warnings
feedback muxes 579
filtering 357
handling 366
sorting 357
Watch window 352
moving 353, 356
resizing 353, 356
white boxes
defined for ise2syn flow 809
EDK cores 809
using syn_macro on non-secure
cores 798
wide adders/subtractors
example 1039
inferring 1037
prerequisites for inference 1037
wildcards
effect of search scope 413
message filter 359
wildcards (Find)
examples 415
how they work 413
wildcards (Physical Analyst)
in Find command 964
X
xc_clockbuftype attribute
specifying 1065
xc_fast attribute
for critical paths 1033
Index
1266 March 2014
xc_loc attribute
assigning locations in SCOPE 1055
xc_map attribute
relative location 1062
xc_padtype attribute
specifying I/Os 1068
xc_rloc attribute
specifying relative location 1063
xc_uset attribute
grouping instances for relative
placement 1063
using to group instances 1063
xcf files
translating to sdc 329
xdc2fdc
debugging translation 793
xflow script 237
Xilinx
byte-enable RAM inference 552
byte-wide write enable inference 553
clock buffers 1065
converting PAD files 247
converting pin assignments to SDC 247
CoreGen 1040
design guidelines 1033
distributed RAM inference 542
forward-annotation 133
GSR 1036
I/O buffers 1068
I/O insertion, manual 1059
I/O locations 1054
including cores for synthesis 798
INIT property 1049
INIT property, VHDL 1052
IP cores 795, 1040
macros 1033
netlist 1096
non-secure core flow 798
packing registers 1043
partition flow 1131
place-and-route option file, ISE 237
place-and-route option file,
Vivado 1122
post-synthesis simulation 1071
secure core flow 798
shift registers 559
specifying pin location 1054
startup blocks 1036
synthesis constraint files (Legacy) 320
tips for optimizing 1032
using BUFR 1061
Xilinx differential I/O buffer
inference 1060
Xilinx projects
converting with ise2syn 800
xpartition.pxml file 1138
xtclsh flow 237
Z
zoom selected objects (Physical
Analyst) 943

Synopsys

Uploaded by

Copyright:

Available Formats

Synopsys

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Synopsys

Uploaded by

Copyright:

Available Formats

Synopsys FPGA Synthesis

Premier tools for FPGA synthesis.

(B.E.S.T.) algorithms, perform

(Behavior Extracting Synthesis Technology) in the RTL

IP cores generated with the Altera MegaWizard

Premier FPGA tool.

You might also like