Certify Partition Driven Synthesis: User Guide

Certify Partition Driven Synthesis User Guide
March 2011
http://solvnet.synopsys.com
Disclaimer of Warranty
Synopsys, Inc. makes no representations or warranties, either expressed or implied, by or with respect to anything in this manual, and shall not be liable for any implied warranties of merchantability or fitness for a particular purpose of for any indirect, special or consequential damages.
Copyright Notice
Copyright 2011 Synopsys, Inc. All Rights Reserved. Synopsys software products contain certain confidential information of Synopsys, Inc. Use of this copyright notice is precautionary and does not imply publication or disclosure. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form by any means without the prior written permission of Synopsys, Inc. While every precaution has been taken in the preparation of this book, Synopsys, Inc. assumes no responsibility for errors or omissions. This publication and the features described herein are subject to change without notice.
Trademarks
Registered Trademarks ()
Synopsys, AMPS, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, CHIPit, CoMET, Design Compiler, DesignWare, Formality, Galaxy Custom Designer, HAPS, HapsTrak, HDL Analyst, HSIM, HSPICE, Identify, Leda, MAST, METeor, ModelTools, NanoSim, OpenVera, PathMill, Physical Compiler, PrimeTime, SCOPE, Simply Better Results, SiVL, SNUG, SolvNet, Syndicated, Synplicity, the Synplicity logo, Synplify, Synplify Pro, Synthesis Constraints Optimization Environment, TetraMAX, UMRBus, VCS, Vera, and YIELDirector are registered trademarks of Synopsys, Inc.
Trademarks ()
AFGen, Apollo, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, LO Columbia-CE, Cosmos, CosmosLE, CosmosScope, CRITIC, DC Expert, DC Professional, DC Ultra, Design Analyzer, Design Vision, DesignerHDL, DesignPower, Direct Silicon Access, Discovery, Eclypse, Encore, EPIC,
2 Certify User Guide, March 2011
Galaxy, HANEX, HAPS, HapsTrak, HDL Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC Prototyping System, HSIM, HSIMplus, i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Magellan, Mars, Mars-Rail, Mars-Xtalk, Milkyway, ModelSource, Module Compiler, MultiPoint, Physical Analyst, Planet, Planet-PL, Polaris, Power Compiler, Raphael, Saturn, Scirocco, Scirocco-i, Star-RCXT, Star-SimXT, System Compiler, System Designer, Taurus, TotalRecall, TSUPREM-4, VCS Express, VCSi, VHDL Compiler, VirSim, and VMC are trademarks of Synopsys, Inc.
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.
Restricted Rights Legend

Government Users: Use, reproduction, release, modification, or disclosure of this commercial computer software, or of any related documentation of any kind, is restricted in accordance with FAR 12.212 and DFARS 227.7202, and further restricted by the Synopsys Software License and Maintenance Agreement. Synopsys, Inc., Synplicity Business Group, 700 East Middlefield Road, Mountain View, CA 94043, U. S. A. March 2011
Certify User Guide, March 2011
LO
Contents
Chapter 1: ASIC Prototyping Using FPGAs
What is Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 What is the Certify Prototyping Tool? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 The Synopsys FPGA Product Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 The FPGA Synthesis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Synopsys FPGA Tool Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 User Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Certify Tool Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 ASIC Compatible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Automatic Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Manual Partitioning Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Debugging Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 The Generic FPGA Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 HDL Design Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logic Optimization (Compilation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Technology Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 FPGA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Prototyping Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 2: Preparing the Input

Setting Up HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Certify User Guide March 2011 Copyright 2011 Synopsys, Inc. 5
Creating HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Checking HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Editing HDL Source Files with the Built-in Text Editor . . . . . . . . . . . . . . . . . . . . 45 Using an External Text Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Setting Editing Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Using Mixed Language Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Working with Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 When to Use Constraint Files over Source Code . . . . . . . . . . . . . . . . . . . . . . . . 54 Tcl Syntax Guidelines for Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Using a Text Editor for Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Using Synopsys Design Compiler Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Checking Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Generating Constraint Files for Forward Annotation . . . . . . . . . . . . . . . . . . . . . 60
Chapter 3: Setting up a Project

Setting Up Project Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Creating a Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Opening an Existing Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Making Changes to a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Setting Project View Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Creating Logical Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Setting Up Implementations and Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Working with Multiple Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Adding an Identify Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Creating Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Using Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Setting Implementation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Setting Partition/SLP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Setting Device Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Setting Optimization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Specifying Global Frequency and Constraint Files . . . . . . . . . . . . . . . . . . . . . . 85 Specifying Result Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Specifying Timing Report Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Setting Verilog and VHDL Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Setting Netlist Filtering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Preserving Top-Level I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 LO Entering Attributes and Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Specifying Attributes and Directives in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . 102 Specifying Attributes and Directives in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . 103 Specifying Attributes and Directives in a cdc File . . . . . . . . . . . . . . . . . . . . . . . 104
Copyright 2011 Synopsys, Inc. 6 Certify User Guide March 2011
Specifying Attributes Using the SCOPE Editor . . . . . . . . . . . . . . . . . . . . . . . . 106 Specifying Attributes in the Constraints File (sdc) . . . . . . . . . . . . . . . . . . . . . . 108 Adding Attributes and Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Specifying Attributes and Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Adding Attributes and Directives in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Adding Attributes and Directives in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Adding Attributes in the SCOPE Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Adding Attributes to a Tcl Constraint File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Searching Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Identifying the Files to Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Filtering the Files to Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Initiating the Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Search Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Archiving Files and Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Archive a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Un-Archive a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Copy a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Chapter 4: Fast Synthesis

About Fast Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Using Fast Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Fast Synthesis and Other Synthesis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Chapter 5: Partitioning a Design

Preparing to Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Files Needed for Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Preparing to Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Partitioning Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Manual Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Partitioning with QPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Running QPT on Boards with Undefined Traces . . . . . . . . . . . . . . . . . . . . . . . 156 Using a Different Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Performing Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Advanced Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Impact Analysis Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Replicating Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Replication Example Using the Impact Analysis Window . . . . . . . . . . . . . . . . 167
Replication Example Using the Drag and Drop . . . . . . . . . . . . . . . . . . . . . . . . 169 Listing Replicated Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Voltage Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 HAPS Voltage Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 I/O Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Bit Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Using the Bit Slice Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Bit Slice Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Bit Slicing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Fanin-driven Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Arranging the Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Arranging the Partition and RTL Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Changing the Default Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Partition Device View Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 ToolTip Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Viewing Instance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Design Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Chapter 6: Layout of the Certify Partition Board View

Automated Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Manual Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Enabling Layout Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Creating Empty Rows and Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Compaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Restoring the Automated Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Saving a Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Create a Custom Layout Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Chapter 7: Trace Assignment

Manual Trace Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Nets Display Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Filtering the List of Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Trace Display Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Scratchpad Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Trace Aliasing . . . . . . . . . . .LO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 .. HSTDM Trace Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Differential Trace Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Manual Trace Assignment for QPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Manually Assigning Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Multi-Terminal Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Automatic Trace Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Automatic Assignment of Black-Box Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Assigning Probes to Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Saving Pin Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Reserving Pins with the Reserve I/O Pads Option . . . . . . . . . . . . . . . . . . . . . . 225
Chapter 8: Time-Domain Multiplexing

High-Speed Time-Domain Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Automatic Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Manual Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Prioritizing HSTDM Over Non-HSTDM Assignments . . . . . . . . . . . . . . . . . . . . 237 Configuring the Board Definition Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Configuring the HAPS Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Clocking Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Enabling HSTDM Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Sample Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Output/Report Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 HSTDM (Circuit) Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Source- and System-Synchronous Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Virtex-5 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Certify Pin Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 CPM Assignment User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 CPM Assignment Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Module Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 CPM Net Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Black-Box Net Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Unqualified Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Automatic Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Manual Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Updating Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 CPM Fast Clock Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Creating Custom CPM Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Synchronous CPM Module Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Asynchronous CPM Module Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 CPM Modules or Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 CPM Block Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
CPM Directives and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 syn_asynchronous_cpm Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 syn_cpm_control Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 syn_cpm_srcontrol Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 syn_cpm_type Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 syn_cpm_system_clock Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 syn_implement Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 syn_preserve Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 syn_hier Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 CPM Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 CPM Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Additional Pin Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Global Routing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Chapter 9: HAPS Clock Synchronization

Clocking Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Clock Generation and Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Detailed Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Identify All Primary Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Identify Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Select a Base Clock Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Determine the Clock Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Create One or More CGMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Validate the CGM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Update the Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Add CGM HDL to Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Identify Global Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Partition the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Trace and CPM Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Clock Synchronization and Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Chapter 10: Source-Level Partitioning

Running SLP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Database File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 LO Mixed-project RTL File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Validating Partitioning Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 RTL-Based Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Gate-level Based Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Mixed-language Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Source-Level Partitioning Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Netlist Partitioning Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Pass 1 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Pass 2 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Chapter 11: Scripting

Capturing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Scripting Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Using Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Working with Tcl Scripts and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Using Tcl Commands and Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Setting Device Options in Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Using Tcl Variables for Multiple Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Automating Flows with synhooks.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Chapter 12: Netlist Editing

RTL-Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 RTL Flow Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 SLP Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Diagnosing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Netlist Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Obsolete Netlist Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Chapter 13: Analyzing Logic in HDL Analyst

Working in the Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Opening an RTL View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Viewing Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Selecting Objects in the RTL View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Working with Multisheet Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Moving Between Views in a Schematic Window . . . . . . . . . . . . . . . . . . . . . . . 329 Setting Schematic View Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Setting Preferences in the ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Managing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Exploring Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Traversing Design Hierarchy with the Hierarchy Browser . . . . . . . . . . . . . . . . 334
Exploring Object Hierarchy by Pushing/Popping . . . . . . . . . . . . . . . . . . . . . . . 335 Exploring Object Hierarchy of Transparent Instances . . . . . . . . . . . . . . . . . . . 340 Finding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Browsing to Find Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Using Find for Hierarchical and Restricted Searches . . . . . . . . . . . . . . . . . . . . 343 Using Wildcards with the Find Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Crossprobing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Crossprobing within an RTL View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Crossprobing from the RTL View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Crossprobing from the Text Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Crossprobing from the Tcl Script Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Crossprobing from the FSM Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Analyzing With the HDL Analyst Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Viewing Design Hierarchy and Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Filtering Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Expanding Pin and Net Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Expanding and Viewing Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Viewing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Flattening Schematic Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Minimizing Memory Usage While Analyzing Designs . . . . . . . . . . . . . . . . . . . . 375 Using the FSM Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Chapter 14: Instantiating and Inferring High-Level Objects

Defining Black Boxes for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Instantiating Black Boxes and I/Os in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Instantiating Black Boxes and I/Os in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Adding Black-Box Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Adding Other Black Box Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Defining State Machines for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Defining State Machines in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Defining State Machines in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Specifying FSMs with Attributes and Directives . . . . . . . . . . . . . . . . . . . . . . . . 396 Inferring RAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Inference Versus Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Basic Guidelines for Coding RAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Specifying RAM Implementation Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 LO Implementing Altera RAMs Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Implementing Xilinx RAMs Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Implementing Altera Stratix Multi-Port RAMs . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Inferring Altera Stratix III LUTRAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Inferring Xilinx Block RAMs Using Registered Addresses . . . . . . . . . . . . . . . . 412 Inferring Xilinx Block RAMs Using Registered Output . . . . . . . . . . . . . . . . . . . 415 Mapping Xilinx ROM to Block RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Initializing RAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Initializing RAMs in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Initializing RAMs in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Setting Xilinx RAM Initialization Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Inferring Shift Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Working with LPMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Instantiating Altera LPMs as Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 Instantiating LPMs Using VHDL Prepared Components . . . . . . . . . . . . . . . . . 441 Instantiating LPMs Using a Verilog Library (Altera) . . . . . . . . . . . . . . . . . . . . . 442 Translating .lib Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Chapter 15: Generating IP with SYNCore

Specifying FIFOs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Specifying SYNCore FIFO Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Specifying RAMs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Specifying Parameters for Single-Port RAM . . . . . . . . . . . . . . . . . . . . . . . . . . 472 Specifying Parameters for Dual-Port RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 Specifying Byte-Enable RAMs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 Port List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 Specifying Byte-Enable RAM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 Specifying ROMs with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 Port List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Specifying ROM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Specifying Adder/Subtractors with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Port List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 Specifying Adder/Subtractor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Specifying Counters with SYNCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 Port List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 Specifying Counter Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Chapter 16: Using DesignWare IP

DesignWare IP Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 Using DesignWare Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 Using DesignWare-Compatible Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 Verilog Library Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 VHDL Library Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 Available DesignWare-Compatible Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Supported Models by Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Supported Models Alphabetical List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Chapter 17: Specifying Design-Level Optimizations

Tips for Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 General Optimization Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 Optimizing for Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Optimizing for Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Preserving Objects from Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565 Using syn_keep for Preservation or Replication . . . . . . . . . . . . . . . . . . . . . . . 566 Controlling Hierarchy Flattening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 Preserving Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 Optimizing Fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 Setting Fanout Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 Controlling Buffering and Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 Sharing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 Inserting I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 Optimizing State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 Deciding when to Optimize State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 Running the FSM Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Running the FSM Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 Inserting Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 Specifying Probes in the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 Adding Probe Attributes Interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585 Working with Gated Clocks . . . .LO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 .. The Synplicity Approach to Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 Prerequisites for Gated Clock Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 Synthesizing a Gated Clock Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Using Gated Clocks for Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 Analyzing Gated Clock Conversion Reports . . . . . . . . . . . . . . . . . . . . . . . . . . 595 Working with Gated Clock Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 Restrictions on Using Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 Optimizing Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 Generated-Clock Optimization Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 Enabling Generated-Clock Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 Conditions for Generated-Clock Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 602 Edge-Detection Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Chapter 18: Specifying Constraints

Using the SCOPE UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 Creating a Constraint File Using the SCOPE Window . . . . . . . . . . . . . . . . . . . 606 Entering and Editing Constraints in the SCOPE Window . . . . . . . . . . . . . . . . . 608 Setting SCOPE Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611 Specifying Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 Entering Default Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 Setting Clock and Path Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 Defining Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614 Defining Input and Output Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 Specifying Standard I/O Pad Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 Specifying Xilinx Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 Specifying Timing Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622 Defining From/To/Through Points for Timing Exceptions . . . . . . . . . . . . . . . . . 623 Defining Multi-cycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 Defining False Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 Setting Clock Priority in Xilinx Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628 Using Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631 Comparing Methods for Defining Collections . . . . . . . . . . . . . . . . . . . . . . . . . . 631 Creating and Using Collections (SCOPE Window) . . . . . . . . . . . . . . . . . . . . . 632 Creating Collections (Tcl Commands) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635 Using the Tcl Find Command to Define Collections . . . . . . . . . . . . . . . . . . . . . 638 Using the Expand Tcl Command to Define Collections . . . . . . . . . . . . . . . . . . 640 Viewing and Manipulating Collections (Tcl Commands) . . . . . . . . . . . . . . . . . 641 Using Auto Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645 Translating Altera QSF Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647 Converting and Using Xilinx UCF Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 Using Xilinx UCF Constraints in a Logic Synthesis Design . . . . . . . . . . . . . . . 650
Support for UCF Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653 Using the Legacy UCF2SDC Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Chapter 19: Optimizing for Specific Targets

Optimizing Altera Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 Working with Altera PLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663 Packing I/O Cell Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664 Specifying Core Voltage in Stratix III Designs . . . . . . . . . . . . . . . . . . . . . . . . . 666 Using LPMs in Simulation Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667 Working with Quartus II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669 Optimizing Xilinx Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671 Designing for Xilinx Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671 Specifying Xilinx Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672 Specifying Global Sets/Resets and Startup Blocks . . . . . . . . . . . . . . . . . . . . . 674 Inferring Wide Adders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675 Instantiating CoreGen Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678 Instantiating Virtex PCI Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679 Packing Registers for I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 Specifying Xilinx Register INIT Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684 Inserting Xilinx I/Os and Specifying Pin Locations . . . . . . . . . . . . . . . . . . . . . . 686 Working with Xilinx Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693 Specifying RLOCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694 Specifying RLOCs and RLOC_ORIGINs with the synthesis Attribute . . . . . . . 696 Using Clock Buffers in Virtex Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 Working with Clock Skews in Xilinx Virtex-5 Physical Designs . . . . . . . . . . . . 698 Instantiating Special I/O Standard Buffers for Virtex . . . . . . . . . . . . . . . . . . . . 699 Reoptimizing With EDIF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Improving Xilinx Physical Synthesis Performance . . . . . . . . . . . . . . . . . . . . . . 701 Running Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 Working with Xilinx Place-and-Route Software . . . . . . . . . . . . . . . . . . . . . . . . 703
Chapter 20: Working with Vendor IP

Using Hyper Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 Using Hyper Source for Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 Using Hyper Source for IP Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 Threading Signals Through the Design Hierarchy of an IP . . . . . . . . . . . . . . . 707 Working with Altera IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711 LO Using Altera LPMs or Megafunctions in Synthesis . . . . . . . . . . . . . . . . . . . . . . 711 Implementing Megafunctions with Clearbox Models . . . . . . . . . . . . . . . . . . . . 715 Implementing Megafunctions with Grey Box Models . . . . . . . . . . . . . . . . . . . . 725 Including Altera MegaCore IP Using an IP Package . . . . . . . . . . . . . . . . . . . . 731
Importing Projects from Quartus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735 Importing Quartus Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736 Importing Quartus Designs with Megacore IPs . . . . . . . . . . . . . . . . . . . . . . . . 741 Importing Quartus Designs with Megafunctions/LPMs . . . . . . . . . . . . . . . . . . . 742 Troubleshooting Imported Quartus Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . 743 Working with Xilinx IP Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 Xilinx Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 Secure and Non-secure Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746 Including Xilinx Cores for Logic and Physical Synthesis . . . . . . . . . . . . . . . . . 748
Chapter 21: Analyzing the Log File

Checking Log Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 Viewing the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 Analyzing Results Using the Log File Reports . . . . . . . . . . . . . . . . . . . . . . . . . 753 Handling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753 Checking Results in the Message Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754 Filtering Messages in the Message Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 755 Filtering Messages from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 758 Automating Message Filtering with a Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . 759 Log File Message Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 Handling Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 Validating Logic Synthesis for Physical Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . 764
Chapter 22: Analyzing Timing

Analyzing Timing in Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768 Time Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769 System-Level Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770 Defining the SLP Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770 Timing Analysis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Chapter 23: Debugging Aids

Assigning Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 Assigning Probes to Internal Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 Notes on Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777 Multiplex Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778 Adding Probe Multiplexers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778 Adding Nets to Multiplexers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780 Updating the Post-Partition RTL View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Assigning Control Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782 Creating Your Own Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Chapter 24: Post-Synthesis Operations

Synthesizing with Synplify Premier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 Synthesizing SLP Projects in Certify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Checking the Results in Synplify Premier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789 Running the Identify Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Launching the Identify Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Chapter 25: Board Description Files

Defining Physical Device Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 Board-level Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795 Board Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 Board Description Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Using the Board Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Synopsys HAPS Board Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Vendor Board Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 Creating an Initial Single-Board File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800 Board Wizard Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 Board Description File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 Board Description File Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808 syn_partition Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808 syn_noprune Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809 syn_speedgrade Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810 syn_black_box Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810 Board Trace Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811 Board Trace Delay File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 Trace Delay File Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815 Board Routing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 Board Routing File Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 LO
Copyright 2011 Synopsys, Inc. 18
Certify User Guide March 2011
Appendix A: Board Description File Example Appendix B: Filename Extensions

Certify Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829 Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Appendix C: Project Conversion

Conversion Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 Loading the Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 Converting Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836 Referenced Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Appendix D: Top-down Conversion

Project Conversion in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841 Project Conversion Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
LO
CHAPTER 1
ASIC Prototyping Using FPGAs
What is Prototyping
Todays silicon process technologies have integrated the unique functions of a system into a single ASIC to create the System-on-Chip (SoC) revolution. Though SoC designs offer unprecedented integration that results in cost savings and higher performance, their complexity makes functional verification a monumental task. Verifying these complex SoC designs against events (OS boot, bit-error rates, protocol compliance) and subjective criteria (video and communications applications) has created a need for at-speed or nearspeed verification that only can be realized through hardware-based prototyping. For example, a change in the image or sound quality based on an algorithmic change in a design cannot be verified effectively using only software simulation technology.
What is the Certify Prototyping Tool?
What is the Certify Prototyping Tool?

The Certify prototyping tool is an electronic design automation (EDA) tool for ASIC, SoC, and system design teams that require hardware prototypes of their project early in the design phase. The Certify tool enables a functional ASIC prototype divided among multiple FPGAs from RTL code (either Verilog or VHDL or a combination of both) using embedded synthesis technology to optimize the final prototype performance. Unlike traditional ASIC prototyping techniques, the Certify tool enables prototype delivery before ASIC synthesis to allow a design team to recognize and correct problems earlier in the design flow. The Certify tool includes Quick Partitioning Technology (QPT) which allows an unpartitioned or partially partitioned design to be automatically partitioned among the available FPGAs using the tools bit slicing advanced feature. High performance functional prototypes can be used for applications implemented in an ASIC by a system-design or verification team. Applications include:
System software development and debugging Algorithm development and verification System-level protocol compatibility IP verification Verification of hardware/software codesign platforms Flexible debugging and probing
LO
About This Manual
About This Manual

This user guide is part of a document set that is intended for use with the other documents in the set. It concentrates on describing how to use the Synplify 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 Command Reference.
The user guide contains task-based information. For a breakdown of

how information is organized, see the individual chapter descriptions below.
Chapter 1, ASIC Prototyping Using FPGAs

This chapter, ASIC Prototyping Using FPGAs, provides overviews to help you get started using the Certify prototyping tool.
Chapter 2, Preparing the Input

Chapter 2, Preparing the Input, describes the procedures to set up the required input files for the project.
Chapter 3, Setting up a Project

Chapter 3, Setting up a Project, describes the procedures for setting up a Certify project.
Chapter 4, Fast Synthesis

Chapter 4, Fast Synthesis, describes how fast synthesis reduces compilation runtimes by reducing the number of optimizations performed.
Chapter 5, Partitioning a Design

Chapter 5, Partitioning a Design, provides basic tasks and tips for using the Certify prototyping tool to partition a design.
About This Manual
Chapter 6, Board View

Chapter 6, Layout of the Certify Partition Board View, presents an abstraction of the board for the purpose of interactive partitioning.
Chapter 7, Trace Assignment

Chapter 7, Trace Assignment, outlines criteria for assigning logical nets to the physical traces between FPGAs.
Chapter 8, Time-Domain Multiplexing

Chapter 8, Time-Domain Multiplexing, describes the CPM and HSTDM features for pin multiplexing.
Chapter 9, HAPS Clock Synchronization

Chapter 9, HAPS Clock Synchronization, describes converting clocks in a HAPS-based ASIC design into an implementation that functions correctly in a multi-FPGA environment.
Chapter 10, Source-Level Partitioning

Chapter 10, Source-Level Partitioning, describes how post-partitioned FPGAs are processed as individual projects.
Chapter 11, Scripting

Chapter 11, Scripting, describes how a set of Tcl commands can be applied to a design through a Tcl script file.
Chapter 12, Netlist Editing

Chapter 12, Netlist Editing, describes how to modify the HDL netlist to perform small changes to the design. LO Chapter 13, Analyzing Logic in the HDL Analyst Chapter 13, Analyzing Logic in HDL Analyst, describes how to analyze logic in the HDL Analyst.
About This Manual
Chapter 14, Instantiating and Inferring High-Level Objects,

Chapter 14, Instantiating and Inferring High-Level Objects, describes highlevel object optimizations.
Chapter 15, Generating IP with SYNCore

Chapter 15, Generating IP with SYNCore, describes how to use the SYNCore IP wizard to generate FIFO, RAM, ROM, adder/subtractor, and counter implementations.
Chapter 16, Using DesignWare IP

Chapter 16, Using DesignWare IP, describes how to include DesignWare models from the Synopsys foundation library or DesignWare-compatible models developed by Synplicity in your design.
Chapter 17, Specifying Design-Level Optimizations

Chapter 17, Specifying Design-Level Optimizations, describes optimizing your design using built-in tools and attributes.
Chapter 18, Specifying Constraints

Chapter 18, Specifying Constraints, describes how to specify constraints for your design.
Chapter 19, Optimizing for Specific Targets

Chapter 19, Optimizing for Specific Targets, covers techniques for optimizing your design for the supported vendor technologies.
Chapter 20, Working with Vendor IP

Chapter 20, Working with Vendor IP, describes how to work with IP from different sources
About This Manual
Chapter 21, Analyzing the Log File

Chapter 21, Analyzing the Log File, describes how to analyze the log files generated following compilation and after synthesis.
Chapter 22, Analyzing Timing

Chapter 22, Analyzing Timing, describes typical analysis tasks including time budgeting and system-level timing analysis.
Chapter 23, Debugging Aids

Chapter 23, Debugging Aids, describes the available debugging aids.
Chapter 24, Debugging Aids

Chapter 24, Post-Synthesis Operations, describes synthesizing with Synplify Premier and running the Identify debugger.
Chapter 25, Board Description File

Chapter 25, Board Description Files, describes how to use the board wizard to select or create a board description file, defines the directives used in board description files, and provides a template for this file.
Appendix A, Board Description File Example

Appendix A, Board Description File Example, includes a sample board description file for the tutorial design.
Appendix B, Filename Extensions

Appendix B, Filename Extensions lists the input and output filename extensions used by Certify.
LO Appendix C, Project Conversion, describes how to convert projects created with Certify releases prior to the C-2009.09 release.
Appendix C, Project Conversion
Introduction
Appendix D, Top-down Conversion

Appendix D, Top-down Conversion, describes how to convert existing projects that were developed using the top-down methodology to the SLP project flow.
Introduction
This introduction to the Certify software describes the following:
The Synopsys FPGA Product Family, on page 28 Getting Started, on page 32 User Interface Overview, on page 32
The Synopsys FPGA Product Family

The Synopsys family of synthesis tools is based on core logic synthesis technology, and share a common look and feel. The following figure shows the Synopsys Synplicity line of products. FPGA Implementation
FPGA Logic Synthesis
ESL Synthesis
DSP Synthesis
Confirma Verification
ASIC RTL Prototyping
Synplify
Synplify DSP
Certify
Synplify Pro
ASIC/ASSP Prototyping
HAPS
Physical Synthesis for FPGAs
Synplify Premier Design Planner
Physical Synthesis
Synplify Premier
RTL Debugger RTL Debugger
Identify
Identify Pro
The FPGA Synthesis Tools

This section briefly describes the FPGA syntheis tools Synplify, Synplify Pro, and Synplify Premier synthesis tools. See Synopsys FPGA Tool Features, on LO page 29 for a comparison table that lists the differences between them.
Synplify and Synplify Pro Software

Synplify and Synplify Pro are logic synthesis tools for FPGAs (Field Programmable Gate Arrays) and Complex PLDs (Programmable Logic Devices). For input, the software uses high-level designs written in Verilog and VHDL hardware description languages (HDLs). Using proprietary Behavior Extracting Synthesis Technology (B.E.S.T.) the tool converts the HDL into small, high-performance, design netlists that are optimized for popular technology vendors. Optionally, the software can write postsynthesis VHDL and Verilog netlists that you can use to verify functionality through simulation.
Synplify Premier Software

The Synplify Premier tool offers a push-button, graph-based physical synthesis approach improving overall device performance while simultaneously delivering tight correlation between pre-route timing estimates and final post place-and-route results.
Synopsys FPGA Tool Features

This table distinguishes between the Synplify Pro, Synplify, Synplify Premier, and Synplify Premier with Design Planner products. Synplify Performance
Behavior Extracting Synthesis Technology (BEST) Vendor-Generated Core/IP Support (certain technologies) FSM Compiler FSM Explorer Gated Clock Conversion Register Pipelining Register Retiming
Synplify Pro
Synplify Premier
Synplify Premier DP
x x
x x x x x x x
x x x x x x x
x x x x x
Synplify Code Analysis

SCOPE Spreadsheet HDL Analyst Timing Analyzer Point-to-point FSM Viewer Crossprobing Probe Point Creation
Synplify Pro
Synplify Premier
Synplify Premier DP
x Option
x x x x x x
x x x x x x
x x x x x x
Physical Design
Design Plan File Logic Assignment to Regions Area Estimation and Region Capacity Pin Assignment Physical Synthesis Optimizations Graph-based Physical Synthesis Island Timing Analyst Physical Analyst
x x x x x x x x x x x x x x x
Prototyping
Automatic translation of Synopsys DesignWare components
LO
Synplify Team Design

Mixed Language Design Modular Flow (certain technologies) MultiPoint Flow True Batch Mode (Floating licenses only) GUI Batch Mode (Floating licenses) Batch Mode Post-synthesis P&R Run Back-annotation of P&R Data Formal Verification Flow
Synplify Pro
Synplify Premier
Synplify Premier DP
x x x x x x x x
x x x x x x (Physical synthesis disabled)
x x x x x x x
(Physical synthesis disabled)
Identify Integration Back-annotation of P&R Data
Limited
x x
Design Environment
Technical Resource Center Text Editor View Log Watch Window Message Window Tcl Window Workspaces Multiple Implementations Vendor Technology/Family Support
x x
x x x x x x x
x x x x x x x
Limited
x x x x x x x
Limited
Getting Started
Getting Started
This section shows you how to get started with the Certify software. It does not supersede the information in the installation instructions about licensing and installation. 1. If you have not already done so, install the Certify software according to the installation instructions. 2. Start the software.
If you are working on a Windows platform, select

Programs->Synopsys->Certify version from the Start button.
If you are working on a Linux platform, type the following command

at the command line prompt: certify The command starts the 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 Chapter 2, User Interface Overview of the Reference Manual.
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 3, User Interface Commands of the Certify Reference Manual.
LO
Certify Tool Features

The Certify prototyping tool uses partition-driven synthesis directly from RTL source code to build ASIC prototypes based on multiple FPGAs. Automatic timing analysis is integral to the Certify tool and enables simultaneous partitioning and optimization of designs spanning multiple FPGAs without requiring changes to the RTL source code and without requiring the design to be divided into smaller blocks for synthesis.
ASIC Compatible
A unique fix gated clocks feature can be used to transfer the large number of gated clocks characteristic of ASIC designs to the dedicated clock resources of the FPGA. This feature relocates the gating logic from the clock inputs of sequential elements to the enable inputs which allows the clock input to be driven directly by the base clock.
Automatic Partitioning
The Quick Partitioning Technology (QPT) feature automatically partitions a design among the available FPGAs. This feature considers both area and pin requirements to reach a viable solution. Threshold levels can be user adjusted to control the amount of logic allocated to each FPGA. QPT can be used with both unpartitioned and partially partitioned designs. Running QPT on a board design with undefined traces determines if it is feasible to fit a design within the intended pin and area constraints before investing in the purchase or development of a board, and running QPT on a board with predefined traces produces a comprehensive signal-to-trace assignment report for detailed analysis.
Manual Partitioning Aids

During manual partitioning, the immediate updating of I/O pin and area utilization reduces the number of potential iterations between partitioning and layout. Impact analysis lets you perform what if scenarios before assigning any logic element or block to an FPGA.
Additional features are incorporated to ensure optimum partitioning. These features include:
Logic replication allows a device to be assigned to more than one FPGA

to reduce the amount of interconnect
Bit slicing allows a large device to be divided into a number of smaller

devices that can be repartitioned among multiple FPGAs
Certify Pin Multiplexer reduces pin count by multiplexing the nets on

traces between FPGAs
Feedthrough optimization and constant propagation reduce pin counts

by eliminating feedthroughs and by moving logic pins tied to VCC or ground internal to the FPGA.
Fanin-driven decomposition breaks up large primitives so that the

portion of the primitive being driven is relocated within the FPGA that drives it.
Debugging Aids
In addition to the Identify instrumentor and Identify debugger tools, several debugging aids are included in the Certify prototyping tool. These aids include:
Probes assigned to internal nets to allow internal signals to be

monitored as part of the I/O interface and can also be assigned to output ports at the top level of an FPGA design.
Multiplexed probes substantially reduce pin count when bringing

internal signals out to a devices I/O pins as probes. To enable CPM probes, multiplexers are compiled into the design and instantiated, and nets are then assigned to the multiplexers as probes. In addition, the Certify tool supports the Identify instrumentor/debugger.
LO
Input and Output

The Certify prototyping tool accepts any combination of RTL source code files written in Verilog and VHDL. Constraint files, created locally using SCOPE or a text editor or from a physical system, are also accepted. Pin location files from the physical system can be imported directly into the Certify tool. A Verilog file describing the FPGA board configuration is required for partitioning; a board wizard is available to assist in the selection (or creation) of this file. In terms of output files, the Certify tool can generate any of the following:
Log file that lists the status of operations including notes, warnings, and
errors as well as detailed timing and usage reports and critical path identification
Vendor-specific netlist file for each FPGA for use by the place and route
tool
Vendor-specific constraint file for each FPGA for use by the place and
route tool
Project directory for each FPGA

For information on the input and output files used by the Certify software, see Appendix B, Filename Extensions.
The Generic FPGA Design Flow

The following figure contains a generic design flow showing the typical steps a designer follows when implementing an FPGA. The shaded box shows the steps you can accomplish with Certify/Synplify Premier synthesis. This generic design flow complements the specific design flow used for the tutorial.
HDL Design Entry Logic Optimization Technology Mapping Placement Routing Synthesis
FPGA Configuration
The following sections describe each step more fully.
HDL Design Entry

The starting point for FPGA design is to specify the logic of the FPGA circuit to be implemented. You can do this by drawing a schematic, writing an HDL description, or specifying Boolean expressions. For the Certify flow, design entry is the step where you generate the input for the tool. The input must be Verilog or VHDL descriptions. The software provides you with an environment where you can write or edit HDL descriptions. LO
Logic Optimization (Compilation)

This is the first stage of synthesis, in which the software restructures the original network into a set of combinational functions. In the Certify flow, the combinational functions are represented as a Boolean network. At this point in the design process, you modify the initial logic design to optimize the area or speed of the final circuit, or both. The optimization is calculated from the netlist and is independent of the target technology. It includes operations like redundancy removal and common subexpression elimination.
Technology Mapping
Technology mapping is the second phase of optimization, in which the partitioned logic is optimized to a specific technology by the Synplify Premier tool. During this phase, the compiled design is transformed into a circuit of optimized FPGA logic blocks. Depending on your design priorities, you might want to focus on area optimization (minimizing the total number of blocks), delay optimization (minimizing the number of logic block stages in timecritical paths), or both. The Synplify Premier tool uses architecture-specific mapping techniques to map the logic design. It has built-in tools to analyze critical paths, crossprobe, and check the RTL view. The software generates netlists in formats appropriate for the place-and-route tools that follow.
Placement
Placement is the first step of the physical design process. During placement, the logic blocks are placed in an FPGA array. At this point, considerations like the total interconnect length become important. This is the point at which the synthesis software hands off control of the design to another tool.
Routing
Routing is the final step of the physical design process. At this stage, use the place-and-route tool to connect the placed logic blocks by assigning wire segments and choosing programmable switches.
Prototyping Design Flow
FPGA Configuration
In this design phase, you configure the final FPGA chip and implement it. You can use the results from an initial placement pass to further optimize your logic design using Synplify Premier.
Prototyping Design Flow

The Certify tool supports a complete design and verification environment that features the Identify product and automated HDL code translation. You can run the Identify tool set directly from the Certify graphical user interface. You can use the flow shown in the following figure for single FPGA prototypes. For partitioning and timing optimizations in multi-FPGA designs, use the Certify product.
LO
Getting Help
ASIC HDL Identify Instrumentor

Instrumentation
Certify
Optimized Netlist
Synplify Premier
Synthesized Netlist
FPGA Place-and-Route
Placed and Routed Netlist
Identify Debugger
JTAG
Prototype Board
Getting Help
Before contacting Synopsys support, (SolvNet) look through the documented information. You can access the information online from the Help menu, or refer to the corresponding manual. The following table shows you how the information is organized.
Getting Help
Finding Information
For help with...
How to... Tutorials Flow information Licensing Language and syntax Attributes and directives Tcl language Synthesis Tcl commands Using tool-specific features and attributes Error and warning messages
Refer to the...
User Guide and various application notes available on the Synplicity support web site SolvNet User Guide and various application notes available on the SolvNet web site INSTALL_README.pdf on the SolvNet download page Reference Manual Reference Manual Online help (Help->Tcl Help) Command Reference or type help followed by the command name in the Tcl window User Guide Click on the message ID code
Contacting Customer Support

If you have a problem, question, or enhancement request, use one of these methods to contact Synopsys Customer Support:
Support at www.solvnet.com Write to us at this address:

Synopsys, Inc. 700 East Middlefield Road Mountain View, CA 94043, USA
LO
CHAPTER 2
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 42 Using Mixed Language Source Files, on page 51 Working with Constraint Files, on page 54
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 64. 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 42 Checking HDL Source Files, on page 43 Editing HDL Source Files with the Built-in Text Editor, on page 45 Using an External Text Editor, on page 48 Setting Editing Window Preferences, on page 49
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 43 and Editing HDL Source Files with the Built-in Text Editor, on page 45). You can use Verilog or VHDL for your source files. The files have v (Verilog) or vhd (VHDL) file extensions, respectively. 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 51. 1. To create a new source file:
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. 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). LO
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 45 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 attributes 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 43.
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. An exclamation mark next to a file in the project list indicates that it has errors or warnings. The number of warnings is listed after the file name. If there are no errors, the following message is displayed at the bottom of the log file: Syntax check successful! 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. It puts an exclamation mark next to files in the project list that have errors or warnings, and lists the number of errors, warnings or notes found in each file. If there are no errors, the following message is displayed at the bottom of the log file: Synthesis check successful! 4. Review the errors by opening the syntax.log file when prompted and use Find to locate the error message (search for @E). Click on either the 5character error code or 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. Messages can be categorized as errors, warnings, or notes. Review all LO 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 48. 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 49.
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. To... Do...
Cut, copy, and paste; Select the command from the popup (hold down undo, or redo an action the right mouse button) or Edit menu. Go to a specific line Find text Press Ctrl-g or select Edit->Go To, type the line number, and click OK. Press Ctrl-f or select Edit ->Find. Type the text you want to find, and click OK.
To...
Replace text
Do...
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. Type enough characters to uniquely identify the keyword, and press Esc. Select the block, and press Tab. Select the block, and press Shift-Tab. Select the text, and then select Edit->Advanced ->Uppercase or press Ctrl-Shift-u. Select the text, and then select Edit->Advanced ->Lowercase or press Ctrl-u. Put the cursor at the beginning of the comment text, and select Edit->Advanced->Comment Code or press Alt-c. 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.
Complete a keyword Indent text to the right Indent text to the left Change to upper case Change to lower case Add block comments
Edit columns
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...
Insert a bookmark
Do...
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. LO The line number is highlighted to indicate that there is a bookmark at the beginning of that line.
To...
Delete a bookmark
Do...
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. 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. 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.
Delete all bookmarks
Navigate a file using bookmarks
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.
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 crossprobe 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 352 for details. 8. When you have fixed all the errors, select File->Save or click the Save icon to save the file.
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 45. 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 Linux platform for a text editor that creates its own window,
click the ... Browse button and select the external text editor executable.
LO From a Linux platform, for a text editor that does not create its own window, do not use the ... Browse button. Instead, type gnometerminal -x editorName. To use emacs for example, type gnometerminal -x emacs.
The software has been tested with the emacs and vi text editors. 3. Click OK.
Setting Editing Window Preferences

You can customize the fonts and colors used by the internal Synplicity editor in the Text Editing window. 1. Select Options->Editor Options and select Synplicity Editor. 2. From the File Type drop-down menu, select the type of file for which you want to set the preferences. The Text Editing window can be used to set preferences for source files, log files, Tcl files, constraint files, or other default files. The Editor Options form opens. 3. This table shows you how to set some common syntax options from the Editor Options form: To...
Set syntax color defaults
Do This on the Editor Options form...

Click Syntax coloring. On the Syntax Coloring form, check Use syntax coloring. Set the colors you want for keywords, comments, quotes, and default text by clicking Foreground and Background and selecting colors from the palette. Click OK. Click Syntax coloring. On the Syntax Coloring form, type the comment start character(s) in the lower part of the form. Type the comment end characters if necessary. Click OK.
Define comment characters
To...
Make the text editor case-sensitive Set fonts
Do This on the Editor Options form...

Click Syntax coloring On the Syntax Coloring form, check Case Sensitive. Click OK. Click Fonts. On the Font form, set the font and the size. Click OK. Specify tab size. Specify whether spaces or tabs are to be used to define tabs. Set the display of a tab character.
Set tabs
4. Click OK on the Editor Options form.
LO
Using Mixed Language Source Files

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. 1. Remember these restrictions and set up the mixed language design files accordingly:
You can not use defparams across languages. Verilog does not support unconstrained VHDL ports
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 68.
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 Implementation Options, on page 81.
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 139. LO
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 Implementation Options, on page 81.
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.
Working with Constraint Files

Constraint files are text files that are automatically generated by the SCOPE interface (see Specifying Timing Constraints, on page 612), 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 it is not the preferred method. This section contains information about
When to Use Constraint Files over Source Code, on page 54 Tcl Syntax Guidelines for Constraint Files, on page 55 Using a Text Editor for Constraint Files, on page 56 Checking Constraint Files, on page 60 Generating Constraint Files for Forward Annotation, on page 60
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. 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 attributes, directives can only be added to the source code, not to constraint files. See Adding Attributes and Directives, on page 110 for more information on adding directives to source code.
LO
Tcl Syntax Guidelines for Constraint Files

This section covers general guidelines for using Tcl for constraint files:
Tcl is case-sensitive. 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:]object_name Where cell is the name of the design entity, prefix is a prefix to identify objects with the same name, object_name is an instance path with the dot (.) separator. Prefix (Lower-case) i: p: b: n: Object
Instance names Port names (entire port) Bit slice of a port Net names
In VHDL modules, use the following syntax for instance, port, and net
names in VHDL modules: v:cell [.view] [prefix:]object_name 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 object_name 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[*]
Using a Text Editor for Constraint Files

This section shows you how to manually create a Tcl constraint file. The software automatically creates this file if you use the SCOPE interface to enter the constraints. The Tcl constraint file only contains general timing constraints. Black box constraints must be entered in the source code. For details of the Tcl commands, refer to the Reference Manual. For additional information, see When to Use Constraint Files over Source Code, on page 54. 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 Constraint 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 55. 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. To define...
Clock frequencies
Use...
define_clock. See Defining Clocks, on page 614
for additional information.
Clock frequency other than syn_reference_clock (attribute). See Defining Clocks, on page 614 for additional information the one implied by the signal on the clock pin LO Clock domains with asymmetric duty cycles
define_clock. See Defining Clocks, on page 614
for additional information
To define...
Edge-to-edge clock delays Speed up paths feeding into a register Speed up paths coming from a register Input delays from outside the FPGA Output delays from your FPGA Paths with multiple clock cycles False paths (certain technologies) Path delays
Use...
define_clock_delay. See Defining Clocks, on
page 614 for additional information
define_reg_input_delay. define_reg_output_delay. define_input_delay. See Defining Input and
Output Constraints, on page 619 for additional information Output Constraints, on page 619 for additional information Paths, on page 626 for additional information page 626 for additional information.
define_output_delay. See Defining Input and
define_multicycle_path. See Defining Multi-cycle
define_false_path. See Defining False Paths, on define_path_delay. See Defining
From/To/Through Points for Timing Exceptions, on page 623 for additional information
The following code excerpt shows some typical Tcl constraints: # Override the default frequency for clk_fast and set it to run # at 66.0 MHz. define_clock {clk_fast} -freq 66.0 # Set a default input delay of 4 ns define_input_delay -default 4.0 # Except for the "sel" signal, which has an input delay of 8 ns define_input_delay {sel} 8.0 # The outputs have an off-chip delay of 3.0 ns define_output_delay -default 3.0 # Get better results on the critical path going to register # "inst3.q[0]" (in the memory) by adding 3 ns with -improve define_reg_input_delay {inst3.q[0]} -improve 3.0
4. You can also add vendor-specific attributes in the constraint file using define_attribute. See Adding Attributes to a Tcl Constraint File, on page 116 for more information. 5. Save the file. 6. Add the file to the project as described in Making Changes to a Project, on page 68, and run synthesis.
Using Synopsys Design Compiler Constraints

The FPGA synthesis tools can read some native Design Compiler (SDC) constraint files for a supported set of clock definition, I/O delay, and timing exception constraints. To use these constraints for FPGA synthesis, do the following: 1. If you are importing constraints in the Design Compiler SDC format, do not use other constraints in the FPGA synthesis format. 2. Add the Design Compiler file to your project. 3. Run the constraint checker, as described in Checking Constraint Files, on page 60 and edit the constraint files as needed. 4. Edit your Design Compiler file if needed.
Make sure the object identifiers map as expected:

Synopsys Design Compiler Identifiers
(Wildcards are not supported)
FPGA Synthesis Identifiers c: r: n: p: i:
get_clocks
get_registers get_nets get_ports get_cells get_pins LO
t:
If you use different naming conventions than the default FPGA

assumptions, add the appropriate command to the beginning of your file. You must add it to the beginning of the file, so that it is read first. The following table lists the default FPGA naming convention and the corresponding Design Compiler rule. FPGA Hierarchy separator Register names Bus names Bus array separator . _reg [] [][] Design Compiler Rule set_hierarchy_separator { . } set_rtl_ff_names { _reg } bus_naming_style { %s[%d] } bus_dimension_separator_style { ][ }
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: Default Hierarchy separator Naming bit 5 of bus ABC Naming row 2 bit 3 of array ABC [2x16] A.B ABC[5] ABC [2] [3] You use
Slash: A/B Underscore Underscore
Add this to your file set_hierarchy_separator {/} bus_naming_style {%s_%d} bus_dimension_separator_style {_}
ABC[2_3]
The FPGA synthesis tool accepts the following native Design Compiler constraints, and uses them to run synthesis: all_clocks all_inputs all_outputs all_registers create_clock create_generated_clock set_false_path set_input_delay set_max_delay set_multicycle_path set_output_delay
Checking Constraint Files

For certain technologies, you can check your constraints and their syntax. Do the following: 1. Make sure your target is a technology that supports this feature. 2. Generate a constraint file. 3. Select Run->Constraint Check. This command generate a report that checks the syntax and applicability of the timing constraints in the sdc file(s) for your project. The report is written to the projectNname_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 a description of this file, see Constraint Checking Report, on page 278 of the Reference Manual.
Generating Constraint Files for Forward Annotation

You can create certain vendor-specific constraint files, where the synthesis constraints are mapped to the appropriate vendor constraints. 1. Set attributes to control forward annotation.
To forward-annotate I/O constraints (define_input_delay and

define_output_delay) to the ncf 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 multiplication properties you need. See Defining Other Clock Requirements, on page 618 for details. The synthesis software LO 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 618 for details. The synthesis software forward-annotates the PLL inputs. 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 acf file for Altera and the ncf file for Xilinx. See the Reference Manual for details about forward annotation.
LO
CHAPTER 3
Setting up a Project
Before you can compile, partition, and synthesize a design with Certify, you must first set up a project for your design. The following describe the procedures for setting up a Certify project:
Setting Up Project Files, on page 64 Setting Up Implementations and Workspaces, on page 76 Setting Implementation Options, on page 81 Adding Attributes and Directives, on page 110 Searching Files, on page 117 Archiving Files and Projects, on page 120
Setting Up Project Files

For a specific example on setting up a project file, refer to the Certify tutorial. This section describes the following:
Creating a Project File, on page 64 Opening an Existing Project File, on page 68 Making Changes to a Project, on page 68 Setting Project View Display Preferences, on page 69
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. 2. Click the Add File button, press F4, or select the Project->Add Source File command to open the Select Files to Add to Project dialog box. 3. Make sure that the Look in field at the top of the dialog box points to the correct directory. The available files are listed in the upper portion of the dialog box. If you do not see the desired 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 51.
LO
To add all of 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 simply 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 HDL files, select the appropriate library from the VHDL/Verilog lib drop-down menu. The library you select is applied to all VHDL/Verilog files when you click OK in the dialog box.
You also can drag and drop files or folders from an OS explorer
application into the Project view. This feature is available on both Windows and on Linux desktops running KDE. If you drag and drop a file into the Project view, it is immediately added to the project. If View Project Files in Type Folders is enabled (the default), the file is placed in the appropriate type directory. If no project is open in the Project view, a new project is created.
If you drag and drop a folder, the Add Files to Project dialog box is
displayed asking you to confirm the files listed in the lower portion of the dialog box to be added to the project. Click OK to accept all of the files. If you want to modify the list, you can select individual files and click Remove or you can click Remove All and specify a new filter or option. 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 option separates one type of file from another in the Project view by putting them in separate folders.
The implementation, named proto 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. Each implementation has its own synthesis and device options and its own project-related files.
4. Add any libraries you need, using the method described in the previous step to add the Verilog or VHDL library file. LO 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 on 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 toplevel 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 88. 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 Altera Designs, on page 662 and Optimizing Xilinx Designs, on page 671.
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. 5. 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. 6. Select File->Save, type a name for the project, and click Save. The Project window reflects your changes. 7. 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. 2. Use one of the following methods to open any project file: Open Project 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, doubleclick it from the list of recent projects. Otherwise, click the Existing Project button to open the Open dialog box and select the project.
File->Open Command
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.
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 64 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 LO 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. 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.
2. To organize different kinds of input files in separate folders, check View Project Files in Folders. 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 open more than one implementation in the same Project view, check Allow Multiple Projects to be Opened.
Project 1
Project 2
LO 5. 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. 6. 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.
Creating Logical Folders

Logical folders allow you to arrange files in various hierarchy groupings within the Project view. These folders can be specified with any name and at any level of hierarchy. For example, you can arbitrarily match your operating system file structure or HDL logic hierarchy. Logical folders are distinguished by their blue color.
Adding Logical Folders

Logical folders can be added to a project or to another logical folder. To use logical folders, you must enable View Project Files in Custom Folders in the Project View Options dialog box (select Options->Project View Options from the main menu). To add an empty logical folder: 1. Right-click on a project file or on an existing logical folder and select Add Folder from the popup menu to display the Create New Folder dialog box.
2. Enter a name for the logical folder. You can use any name for the folder, however do not use the character (/) because this is a hierarchy separator symbol. 3. Right-click on an existing file within the project and select Place in Folder; multiple files can be selected using the Ctrl or Shift key. Use the popup menu to either add the selected file to any of the existing logical folders or to a new, unnamed logical folder (if you select Add Folder, you are first prompted for a folder name).
The selected file or files are added to the specified folder. If View Project Files in Type Folders is enabled (the default), the files are placed in the appropriate type directories within the logical folder when there are multiple file types in the folder (for example, v files are added to a Verilog subdirectory). Note: You cannot add individual files to logical folders directly from the Add Files to Project dialog box; add the required files to the project and then use Place in Folder to move the files to the desired logical folder.
Operating System Hierarchies

LO To automatically place files into logical folders corresponding to the OS folder hierarachy:
1. Open the Add Files to Project dialog box and navigate to the directory containing the files to add to the logical folder and click the <- Add button. 2. If necessary, use the Remove -> button to remove any unwanted files from the list of files displayed. 3. Enable the Add files to Folders checkbox and click OK. By default, the logical folder name is the same name as the folder containing the files to be added to the project. However, you can modify how folders are displayed to include the path hierarchy.
Folder without path hierarchy
Folder with path hierarchy
To enable display of the folder path hierarchy, click on the Folders Option button on the Add Files to Project dialog box to display the Folder Options dialog box.
Enable the Use Parent Path radio button and, in the display area below, select the top level for the hierarchy.
Other Logical Folder Operations

The following describes how to remove files from logical folders, delete logical folders, and change the logical-folder hierarchy.
To remove a file from a logical folder, 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.
To delete a logical folder, highlight the folder, right-click, and either

select Delete from the popup menu or press the DEL key. When you delete a folder, you are prompted with the following choices:
Click Yes to delete the folder and the files contained in the folder from
the project.
Click No to delete only the folder; any files are relocated to the toplevel project directory.
To change the hierarchy of a logical folder: Drag and drop the folder within another logical folder to create a subfolder or drag the folder over the project to move the folder to the toplevel.
To remove the top-level hierarchy of a logical 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 logical folder directory is /Examples/Verilog/RTL and you want a single-level RTL hierarchy only, drag and drop RTL over the project. Then delete the /Examples/Verilog directory.
Other Logical Folder File Operations

Additionally, you can perform the following types of 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 View Project Files in Type Folders option in the dialog box. 2. To display files in alphabetical order instead of project order, check the LO Sort Files button in the Project view control panel. Click the down arrow key at the bottom of the panel to toggle the control panel on and off.
Control Panel Toggle
3. To change the order of files in the project, disable both the display of logical logical folders (uncheck Folders) and the sorting of files (uncheck Sort Files) and then drag and drop files to their desired positions in the list of files. 4. To change the file type, drag and drop the file to the new type folder. The software will prompt you for verification.
Setting Up Implementations and Workspaces

Workspaces and implementations are extensions of the project metaphor used in the Synopsys FPGA synthesis software. This section describes the following:
Working with Multiple Implementations, on page 76 Adding an Identify Implementation, on page 78 Creating Workspaces, on page 79 Using Workspaces, on page 80
Working with Multiple Implementations

The Certify tool lets you create multiple implementations of a design based on the same RTL and board design files. This capability lets you experiment with different options or settings for the same design. Implementations are revisions of your design within the context of the Certify software and do not replace external source code control software and processes. 1. To add an implementation, click the Add Implementation button or select Project->New Implementation to bring up the Select Flow dialog box.
LO
Note: If you are adding an Identify implementation (see Adding an Identify Implementation, on page 78), click the Identify Implementation checkbox in the lower left corner before clicking OK. 2. Click the OK button to close the dialog box and open the Add Implementation dialog box where you can set or change option settings or project configuration. When you click OK to accept the new values, another implementation appears in the project view. The new implementation has the same name as the previous implementation, but with a different number suffix. The following figure shows two implementations, proto_1 and proto_2, with the current (active) implementation highlighted.
The new implementation uses the same source code and board files, but with different device options and constraints. When creating a second implementation, some files are copied from the previous implementation: (i.e., the tlg log file, the srs RTL netlist file, and the designName_fsm.sdc file generated by FSM Explorer. The software maintains a repeatable history of the preparation runs. 3. With the new implementation highlighted, click Run Preparation to prepare the design using the new implementation values. The Project view shows all implementations with the active implementation highlighted. The corresponding output files generated for the active implementation are displayed in the Implementation Results view on the right, and the corresponding flow diagram is displayed in the Flow Graph view. Changing the active implementation changes the output file display and the flow graph.
Implementation Operations
The following operations can be performed on an implementation from the project view:
Rename 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.
Copy 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.
Delete 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.
Adding an Identify Implementation

The Certify tool allows an Identify implementation to be added to a project. Adding an Identify implementation allows a design to be instrumented for hardware debugging before the design is partitioned. The additional IICE sampling logic inserted by the Identify instrumentor can be assigned to a single FPGA or partitioned among multiple FPGAs. To add an Identify implementation to an existing project, either:
Click the Add Implementation button and, in the dialog box, check Identify
Implementation before clicking OK.
Select Project->New Identify Implementation from the menu.

Make any implementation option or configuration changes in the Add Identify Implementation dialog box and click OK. A new Identify implementation is added to the project view.
LO
Creating Workspaces
The Certify tool lets you group projects together into workspaces. A workspace is like a container for a number of projects. 1. To create a new workspace, select File->New Workspace or right-click in the Project view and select Build Workspace. 2. In the dialog box,
Select the project files (prj) of the projects you want to add to the
workspace.
Name the workspace and click OK.

The Project view displays the workspace and the associated projects under it. The workspace file is also a prj file.
3. To open more than one project in the same Project view, check Allow Multiple Projects to be Opened. After you set up the new project, you can see it in the Project view.
Project 1
Project 2
Using Workspaces
You can use your workspace to simplify your work flow. For example, you can set up dependencies between projects in the same workspace.The Synplify software does not support workspaces. 1. To add a project to a workspace, right-click the workspace and select Insert Project. Select the project file you want to add, and click OK. 2. To remove a project from a workspace, right-click on the project and select Remove Project from Workspace. 3. To synthesize a single project in a workspace, click Run. The software synthesizes the current project. 4. To run all the projects in a workspace, do the following:
If you have multiple implementations within a project, check that the

correct implementation is active. To make an implementation active, click on the implementation in the Project view.
Select the workspace in the Project view, right-click, and select Run all
Projects. The software synthesizes the active implementations of all the projects in the workspace.
LO
Setting 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 Entering and Editing Constraints in the SCOPE Window, on page 608. For information about overriding global settings with individual attributes or directives, see Adding Attributes and Directives, on page 110. This section discusses the following implementation options:
Setting Partition/SLP Options, on page 81, next Setting Device Options, on page 82 Setting Optimization Options, on page 84 Specifying Global Frequency and Constraint Files, on page 85 Specifying Result Options, on page 86 Specifying Timing Report Output, on page 88 Setting Verilog and VHDL Options, on page 88 Setting Netlist Filtering Options, on page 94
Setting Partition/SLP Options

Partition/SLP options include provisions for defining the board file, specifying SLP generation options, and identifying partitioning command script files.
Setting Device Options

Device options include the device mapping options (for example, I/O insertion and fanout control) and, in the absence of a board file, device selection including technology, part, speed grade, and package (device selection is automatically set when the board file is compiled). Device options can be set anytime before the design is synthesized (mapped). 1. Open the Implementation Options dialog box by clicking the Impl Options button or by selecting Project->Implementation Options, and click the Device tab at the top if it is not already selected. 2. 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. LO To set an option, type in the value or check the box to enable it.
For more information about the fix gated clock option, see Working with Gated Clocks, on page 587. For information on the reserve I/O pads
option, see Reserving Pins with the Reserve I/O Pads Option, on page 225. For details about other vendor-specific options, refer to the appropriate vendor chapter and technology family in the Reference Manual.
Altera Stratix Technology
Xilinx Virtex Technology
3. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
Setting Optimization Options

Optimization options are part of the global options you can set for the implementation. 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 left side of the Project view. 1. Open the Implementation Options dialog box by clicking the Impl Options button or by selecting Project->Implementation Options, and click the Options tab at the top. 2. Click the optimization options you want on the Options tab. Your choices vary, depending on the technology. If an option is not available for your technology, it is grayed out. Note: The Pipelining and Retiming option setting selections are forwarded to Synplify Premier synthesis tool for SLP project synthesis.
LO
For details about using these optimizations, refer to the following sections:
FSM Compiler FSM Explorer Resource Sharing Pipelining Retiming Reserving Pads Running the FSM Compiler, on page 577 Running the FSM Explorer, on page 581 Sharing Resources, on page 573 refer to the Synplify Premier documentation refer to the Synplify Premier documentation Reserving Pins with the Reserve I/O Pads Option, on page 225
The equivalent Tcl commands are set_option -symbolic_fsm_compiler or autosm, set_option -use_fsm_explorer, set_option -resource_sharing, set_option retiming, set_option -pipe, and set_option -reservepads. 3. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
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, open the Implementation Options dialog box by clicking the Impl Options button or selecting Project->Implementation Options, and click the Constraints tab. The equivalent Tcl set_option commands is -frequency frequencyValue. You can override the global frequency with local constraints, as described in Entering and Editing Constraints in the SCOPE Window, on page 608.
2. To specify constraint files for an implementation, do one of the following:
Select Project->Implementation Options->Constraints. Check the constraint

(sdc) files you want to use in the project.
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 Entering and Editing Constraints in the SCOPE Window, on page 608. 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. Either action removes the constraint file from the implementation, but does not delete the file. 4. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
Specifying Result Options LO

This section shows you how to specify criteria for the output of the synthesis run.
1. Open the Implementation Options dialog box by clicking the Implementation Options button or by selecting Project->Implementation Options and then clicking the Implementation Results tab at the top.
2. Specify the output files you want to generate.
Checking Write Mapped Verilog Netlist or Write Mapped VHDL Netlist creates
a post-mapped, gate-level Verilog or VHDL netlist file for each FPGA.
Checking Write Vendor Constraint File generates a vendor-specific

constraint file for forward-annotation. See the corresponding vendor appendix in the Reference Manual for more information. See Generating Constraint Files for Forward Annotation, on page 60 for more information. 3. Set the directory to where you want to write the results. Click Browse to bring up the Select Run Directory dialog box. 4. You might also want to set attributes to control name-mapping. For details, refer to the appropriate vendor chapter in the Reference Manual. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
Specifying Timing Report Output

You can determine how much information is reported in the timing report by setting the following options. 1. Select 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. 4. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
Setting Verilog and VHDL Options

When you set up the Verilog and/or 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.
LO
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, 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 is Verilog 2001.
2. Specify the top-level design file. You can leave this field blank if you have already made the top-level file the last source file in the project list. Note: You must specify the top-level module or entity with mixed-language designs. The equivalent Tcl command for scripting is set_option -top_module {Verilog_module | VHDL_entity | VHDL_entity.arch}. 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: Parameter extraction is not supported for mixed-language designs.
4. Type in the directive in Compiler Directives, using spaces to separate the statements. You can type in directives you would normally enter with ifdef and define statements in the code. For example, size=32 test_impl results in the software writing the following statements to the project file: set_option -hdl_define -set SIZE=32 TEST_IMPL LO 5. In the Include Path Order box, specify the search paths for the include commands in your project. Use the buttons in the upper right corner of the box to add, delete, or reorder the paths.
Delete file Move file up
Move file down
6. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
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. 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. 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 use by LO the HDL Analyst in displaying and debugging 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 directives you set here to encode the state machines and does not run the FSM compiler, which would override the compiler directives. Alternatively, you can define state machines with the syn_encoding attribute, as described in Defining State Machines in VHDL, on page 395. 3. To extract generics from the source code:
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: You cannot extract generics in mixed-language designs.
4. To push tristates across process/block boundaries, check that Push Tristates is enabled. For details, see Push Tristates Option, on page 137 in the Reference Manual. 5. Determine the interpretation of the synthesis_on and synthesis_off directives:
To make the compiler treat 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 Directive, on page 944 in the Reference Manual for more information. 6. Set other implementation options as needed (see Setting Implementation Options, on page 81 for a list of choices).
Setting Netlist Filtering Options

Netlist filtering includes the following optimization features including reducing I/O pin count and removing duplicate bus drivers as well as breaking up large modules or entities that cannot be partitioned into a single FPGA:
Feedthrough Optimization, on page 95 Constant Propagation, on page 95 Create Always/Process Level Hierarchy, on page 96 Optimize Netlist, on page 98 Remove Duplicate Drivers, on page 98
These features are controlled from the Prototyping Tools tab of the Implementation Options dialog box (or the Job Options dialog box by selecting the Optimize Design block in the Flow Graph window and clicking Properties in the popoup menu) and must be individually enabled before running Run Preparation (pressing F7) on the design.
To enable any of these individual options, make sure that the Enable Prototyping Tools checkbox is checked and then enable the individual netlist prototype options by clicking the corresponding checkbox (the Optimize Netlist option LO is enabled by default).
Note: By default, Certify inserts keepbuf symbols as placeholders to preserve top-level nets in the design (see Preserving Top-Level I/Os, on page 98).
Note: Model-based area estimation from a set option comand in the project file is enabled by default.
Feedthrough Optimization
Feedthrough optimization, when enabled, eliminates I/O pins associated with signals that pass through a design block without driving any logic or, as shown in the following figure, are unnecessarily routed through a block.
Block 1 Block 2 Block 3
Without Feedthrough Optimization (Block 2 requires two I/O pins)
Block 1
Block 2
Block 3
With Feedthrough Optimization (Block 2 requires one I/O pin)
Constant Propagation
Constant propagation eliminates the I/O pin count associated with tying a logic input signal high or low by making the connection internal to the instance rather than through the instance interface.
Instance
Instance
Without Constant Propagation
With Constant Propagation
Create Always/Process Level Hierarchy

Always/process-level hierarchy creates an additional level of hierarchy based on the always (Verilog) or process (VHDL) blocks in the source RTL design file. This feature allows large modules or entities that cannot be partitioned into a single FPGA to be broken up into a set of logical submodules that can be more easily partitioned among the available FPGAs. When netlist filtering is disabled (the default) or when the always/process-level hierarchy feature is selectively disabled, no additional level of hierarchy is created. To illustrate the always/process-level hierarchy feature, consider the flat module shown in the following figure of a design that was compiled without enabling this feature.
Although you can partition individual instances or gates at this level of the hierarchy, partitioning at this level has the following disadvantages:
the number of instances to be partitioned can be large LO the optimum assignment in terms of I/O usage may not be apparent
Enabling the always/process-level hierarchy feature and running the netlist filter on the design (pressing F7) adds the level of hierarchy shown in the figure below.
With the added level of hierarchy, the instances can be easily and quickly assigned to individual FPGAs. Note: The always/process-level hierarchy feature applies to the entire design. Creating an additional level of hierarchy may prove not to be useful on designs with a number of smaller blocks that can be easily partitioned among the available FPGAs.
Block Naming
When you enable the always/process-level hierarchy feature, the Certify software uses the following naming convention to identify the new hierarchical modules or entities:
If the always/process block is named in the RTL source, the module or

entity is named: designName_blockName
If the always/process block is not named in the RTL source, the module
or entity is named: designName_proc_1stAssignedOutputSignalName
Optimize Netlist
Removes redundant logic from the netlist. This option is enabled by default (i.e., redundant logic is automatically removed).
Remove Duplicate Drivers

Removes duplicate I/O bus drivers from the netlist.
Create MAC Hierarchy

The Create MAC Hierarchy check box is only available for Altera Stratix devices and, when checked, allows dedicated DSP MAC blocks to be configured as multipliers, multiplier adders, or multiplier accumulators. This optimization conveniently maps MAC configurations together into a single MAC block so that the block can be easily assigned. This option appears on the Prototyping Tools tab after a design using the Stratix technology is compiled.
Preserving Top-Level I/Os

The Certify tool attempts to minimize I/Os during partitioning in an attempt to create a workable partition. When it is necessary for a constant to be driven onto an FPGA output, the Certify prototyping tool must be instructed to preserve the top-level constant to make sure that it is not optimized away. Checking the Enable Prototyping Tools option on the Prototyping Tools tab causes Certify to automatically insert keepbuf symbols. These placeholder symbols preserve nets in the design and can be inferred from RTL code using a syn_keep directive. The keepbuf symbols are not synthesized to anything in the target FPGA technology. However, the keepbuf symbols must be assigned to an FPGA or a system black-box on the Certify board before the design partition is complete. By assigning the keepbuf symbols to the desired FPGAs, the LO constant outputs are driven as desired.
The following subsections illustrate the effects of the keepbuf symbols on toplevel constant ports in a simple design.
Two-FPGA Partition with Top-Level Constant Ports and Prototyping Tools Disabled
The following RTL view represents a two FPGA design with top-level constant ports and the Enable Prototyping Tools option disabled. As shown in the RTL view, neither the constant vector driving the const_out[3:0] port nor the const_out[3:0] port itself can be assigned to an FPGA for partitioning. As a result, neither FPGA drives the constant output port. The design assumes that the constant value is driven by circuitry outside the FPGAs, perhaps by tie downs on the board. Note that neither U1 nor U2 drives the const_out[3:0] port.
Two-FPGA Partition with Top-level Constant Ports and Prototyping Tools Enabled
The following RTL view represents a two FPGA design with top-level constant ports with the Enable Prototyping Tools option enabled. As shown in the RTL view, Certify automatically inserts the highlighted keepbuf symbols as placeholders to preserve nets in the design.
LO
Entering Attributes and Directives

Attributes and directives are pieces of information that you attach to design objects to control the way in which your design is analyzed, optimized, and mapped. Attributes control mapping optimizations and directives control compiler optimizations. Because of this difference, you can only specify directives in the source code or the compiler constraints file. This table describes the methods that are available to specify attributes and directives: Source VHDL Verilog .cdc Compiler Constraints File SCOPE Editor .sdc Constraints File Attributes
--Supported attributes* x x
Directives
x x Supported directives* ---
* See Specifying Attributes and Directives in a cdc File, on page 104
Note that it is better to specify attributes in the SCOPE editor or the sdc constraints file because you do not have to recompile the design first. For directives, you must compile the design for them to take effect. For further details, refer to the following:
Adding Attributes and Directives in VHDL, on page 111 Adding Attributes and Directives in Verilog, on page 112 Specifying Attributes and Directives in a cdc File, on page 104 Adding Attributes in the SCOPE Window, on page 113 Adding Attributes to a Tcl Constraint File, on page 116
Specifying Attributes and Directives in VHDL

You can use other methods to add attributes to objects, as listed in Entering Attributes and Directives, on page 101. However, you can specify directives only in the source code. There are two ways of defining attributes and directives 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 712 in 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 install_directory/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 object_name : object_kind 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 712 in the Reference Manual. LO 3. Add the source file to the project.
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 attribute_name : data_type ; attribute attribute_name of object_name : object_kind 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 Entering Attributes and Directives, on page 101. However, you can specify directives 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 directives must be specified exactly as presented in their syntax descriptions. For syntax details, see Verilog Attribute and Directive Syntax, on page 531 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 /* synthesis attribute_name = value */ /* synthesis directory_name = value */
Verilog Line Comment Syntax // synthesis attribute_name = value // synthesis directory_name = value
For details of the syntax rules, see Verilog Attribute and Directive Syntax, on page 531 in the Reference Manual. The following are examples: module fifo(out, in) /* synthesis syn_hier = "firm" */; 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 */;
Specifying Attributes and Directives in a cdc File

A cdc file provides a convenient way to specify supported attributes and directives without making changes to your HDL files. You can specify the following attributes and directives on views, entities, architectures, and modules:
syn_black_box Directive syn_noprune Directive syn_preserve Directive

syn_sharing Directive syn_dspstyle Attribute syn_multstyle Attribute syn_ramstyle Attribute syn_resources Attribute syn_romstyle Attribute (Altera), syn_romstyle Attribute (Xilinx) LO syn_srlstyle Attribute
Use this procedure to create a cdc file and specify attributes and directives:
1. Create a constraints file with a cdc extension that contains the Tcl directives you want. 2. Use the following syntax for the attributes and directives you want. Use the syntax that matches the HDL source code you are using.
VHDL Verilog
define_attribute {v:[libraryName.]entityName[(architectureName)]} {directive} {value} define_attribute {v:[libraryName.]moduleName} {directive} {value}
The following example sets the syn_black_box attribute on all architectures of the sub entity in the MyLib library: define_attribute {v:MyLib.sub]{syn_black_box}{1} You must specify the attribute or directive on a view (v:). The libraryName and architectureName arguments are optional. If you do not specify a library, Certify defaults to all design libraries. If you include an architecture, make sure to enclose it in parantheses. Note that Verilog objects are case-sensitive, but VHDL objects are not. See Compiler Design Constraint File Examples, on page 738 in the Reference Manual for examples. 3. Add the file to your project. The tool creates a new directory in the Project view.
4. Compile the design. 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 attributes or 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 Adding Attributes and Directives in VHDL, on page 111 or Adding Attributes and Directives in Verilog, on page 112). 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.
Drag the object to which you want to attach the attribute from the LO
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:<module_name> in Verilog, or v:<library>.<module_name> 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. If you manually type an attribute the software does not recognize, or select an incompatible attribute/object combination, the attribute cell is shaded in red. 6. Save the file.
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 736 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.
Specifying Attributes in the Constraints File (sdc)

When you use the SCOPE window (Adding Attributes in the SCOPE Window, on page 113), the attributes are automatically written to the sdc constraint file using the Tcl define_attribute syntax. The following procedure explains how to specify attributes directly LO the constraint file. For information about in editing constraints in the file, see Using a Text Editor for Constraint Files, on page 56.
1. In the sdc constraint file, enter the attribute and specify the value you want, using the define_attribute syntax. For example, define_attribute {object_name} attribute_name value Check the attribute descriptions in the Reference Manual for the exact syntax and values of the attribute. The following code excerpt provides an example of attributes defined in the sdc 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
Adding Attributes and Directives

Attributes and directives are pieces of information that you attach to design objects to control the way in which your design is analyzed, optimized, and mapped. For further details, refer to these subtopics:
Specifying Attributes and Directives, on page 110 Adding Attributes and Directives in VHDL, on page 111 Adding Attributes and Directives in Verilog, on page 112 Adding Attributes in the SCOPE Window, on page 113 Adding Attributes to a Tcl Constraint File, on page 116
Specifying Attributes and Directives

Attributes control mapping optimizations, and directives control compiler optimizations. Because of this difference, you must specify directives in the source code. However, attributes can be added to either a constraint file or to the source code.
HDL Source Code

Directives can only be specified in the source code. You can specify attributes in the source code, but if you do so, you must recompile the design whenever you change an attribute value which can be very time-consuming for large designs. Accordingly, the recommended method of specifying attributes is in a constraint file. For information about procedures to add attributes and directives, see the following:
Adding Attributes and Directives in VHDL, on page 111 Adding Attributes and Directives in Verilog, on page 112 Constraint File
LO Using a constraint (sdc) file is the preferred method for specifying attributes because it is more flexible; you do not have to recompile the design. You can add attributes to a constraint file using one of the ways described here:
Enter them...
In the SCOPE Attributes tab
Description
A graphical interface for generating or editing an sdc file Tcl constraint file (sdc)
Details
Adding Attributes in the SCOPE Window, on page 113 Attributes Panel, on page 351 of the Reference Manual Adding Attributes to a Tcl Constraint File, on page 116 Syntax for individual attributes is included in the descriptions of the attributes in the Reference Manual.
By manually editing the constraint file
Adding Attributes and Directives in VHDL

You can use other methods to add attributes to objects, as listed in Adding Attributes and Directives, on page 110. However, you can specify directives only in the Verilog or VHDL source code. There are two ways of defining attributes and directives in VHDL:
Using the predefined attributes package Declaring the attribute each time it is used
For details on VHDL attribute syntax, see VHDL Attribute and Directive Syntax, on page 712 in 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 certifyInstallationDir/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 object_name : object_kind 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 712 in the Reference Manual. 3. Add the source file to the project.
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 attribute_name : data_type ; attribute attribute_name of object_name : object_kind 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.
Adding Attributes and Directives in Verilog

You can use other methods to add attributes to objects, as described in Adding Attributes and Directives, on page 110. However, you can specify directives only in the Verilog or VHDL source code. LO
Verilog does not have predefined synthesis attributes and directives, so you must add them as comments. Note that the attribute or directive name is preceded by the keyword synthesis. For syntax details, see Verilog Attribute and Directive Syntax, on page 531 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 /* synthesis attribute_name = value */ /* synthesis directory_name = value */ Verilog Line Comment Syntax // synthesis attribute_name = value // synthesis directory_name = value
For details of the syntax rules, see Verilog Attribute and Directive Syntax, on page 531 in the Reference Manual. The following are examples: module fifo(out, in) /* synthesis syn_hier = "firm" */; 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 */;
Adding Attributes in the SCOPE Window

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 Adding Attributes and Directives in VHDL, on page 111 or Adding Attributes and Directives in Verilog, on page 112). 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.
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 LO technology you are using. If you selected the 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. If you manually type an attribute the software does not recognize, or select an incompatible attribute/object combination, the attribute cell is shaded in red. 6. Save the file. 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 736 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.
Adding Attributes to a Tcl Constraint File

When you add attributes through the SCOPE window (Adding Attributes in the SCOPE Window, on page 113, the attributes are automatically added to the constraint file using the Tcl define_attribute syntax. The following procedure explains how to add attributes manually to a Tcl constraint file. For information about editing the constraints in a constraint file, see Using a Text Editor for Constraint Files, on page 56. 1. In the constraint file, add the attribute and value you want, using the following define_attribute syntax. define_attribute {object_name} attribute_name value Check the descriptions of individual attributes in the Reference Manual for the exact values and syntax of the attribute. The following code excerpt shows some attributes set in a constraint file. Some of the attributes are specific to Xilinx designs: # 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
LO
Searching Files
Searching Files
A find-in-files feature is available to perform string searches within a specified set of files. Advantages to using this feature include:
Ability to restrict the set of files to be searched to a project or implementation.
Ability to crossprobe 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 is 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.
Searching Files
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 implementation 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.
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 subpattern.
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. LO Leaving the File filter field empty searches all files that meet the Find In criteria.
Searching Files
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.
Archiving Files and Projects

Use the archive utility to archive, extract (unarchive), or copy complete design projects to a single file. Archived files are in a proprietary format and saved to a file with a sar extension. This section provides a description of how to use the archive utility to:
Archive a Project Un-Archive a Project Copy a Project
Archive a Project
Use the archive utility to include 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. The archive utility automatically runs a syntax check on the active project 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. The archive wizard displays the name of the project to archive, the top-level directory where the project file is located (root directory), and other information. If you want to create a copy of a project without archiving the files, see Copy a Project, on page 128.
Using the Archive Wizard

Here are the steps to create an archive file with the archive wizard: 1. In the Project view, select Project->Archive Project to bring up the first page of the archive wizard. The Tcl command equivalent is project -archive. For a complete description of the project Tcl command options for archiving, see the project command description in the Certify Command Reference. LO
2. In the wizard, the following information is displayed:
Project Path and Filename the name of the design project to be archived Root Directory the top-level (root) directory for the project Destination File the name (and location) of the archive file; the name
defaults to the project name with a sar extension 3. In the Archive Style section, select the archive style as follows:
Create a fully self-contained copy archives all files in the project

including input and result files; selecting All Implementation archives the files for all implementations in the project, and selecting Active Implementation archives only the files for the active implementation (the implementation name displayed)
Local copy for internal network archives only project input files (no result
files or remotely referenced files outside of the root directory are included in the archive)
Customized file list archives only the files that you select. When you
select this style (and click Next), additional forms are displayed to
allow you to individually select the files to be included in the archive. To use this style, see Creating a Customized File List, on page 124. 4. After selecting the archive style, click Next> at the bottom of the form to display a summary of the files to be included in the archive file.
Review the list of files and verify the archive destination file. If the list and destination are correct, click the Archive button at the bottom of the form. If the list is not correct, click the <Back button to return to the first page of the wizard, select Customized file list, and see Creating a Customized File List, on page 124 to add or delete files. Note: The file summary displays all the files to be included in the archive and reports the full, uncompressed file size. The actual file size is smaller after the archiving operation as there is no duplication of files. LO
5. When you click Archive, the following prompt is displayed:
6. Click Done to create the archive file. If you want to send the archive file to another site, click FTP Archive File and see Sending Archive Files with FTP, on page 123.
Sending Archive Files with FTP

The archive wizard includes a facility for sending archive files to an FTP site (for example, you can send your design project to the Synopsys FTP site). When you click FTP Archive File in response to the prompt, the following form is displayed.
To complete the form: 1. Fill in your email address. At the Synopsys web site, this email address, plus a date and time stamp are prepended to the sar file name to uniquely identify your archive file.
2. Fill in the other details about the FTP site destination, including username and password if you are sending it to sites other than to Synopsys. 3. Click Transfer. This completes the archive transfer. The Status field in the dialog box displays the transfer results.
Creating a Customized File List

When you select Customized file list on the first page of the wizard (and click Next>), the following form is displayed to allow you to define the file set to be included in the archive file.
To create a custom file list:
Use the check boxes to include files in or exclude files from the archive. Click the Source Files radio button to include the HDL files or click the
LO SRS radio button to include all srs files (RTL schematics).
Use the Add Extra Files button to include additional files from outside of
the project.
When you are satisfied with the list of files to be included in the archive, click the Next> button to display the confirmation screen shown in step 4 of Using the Archive Wizard. Subsequently selecting the Archive button prompts to create the archive file or open an FTP transfer as described previously.
Un-Archive a Project
Use 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 description of the project Tcl command options for archiving, see the project command description in the Certify Command Reference.
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.
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 unchecked 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
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 Synplicity after un-archiving option. 6. Click Un-Archive. A message dialog box is displayed while the files are being extracted.
7. 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 120. 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, seesee the project command description in the Certify Command Reference. 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 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.
LO
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.
Click Next.
LO
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.
LO
CHAPTER 4
Fast Synthesis
The following describe how to use the Fast Synthesis feature in Certify:
About Fast Synthesis, on page 134 Using Fast Synthesis, on page 135 Fast Synthesis and Other Synthesis Options, on page 137
About Fast Synthesis
About Fast Synthesis

Fast synthesis is a feature available in the Certify software. It is a logic synthesis design flow that is specific to compilation. Fast synthesis reduces compilation runtimes by reducing the number of optimizations performed. As a result, using fast synthesis is a trade-off for performance over quality of results (QoR).
When to Use Fast Synthesis

Fast synthesis is best used in situations where quality of results (QoR) is not crucial, or when quick turnaround times are more important. Do not use this flow when performance is critical. The following list some situations where fast synthsis can be advantageous:
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 implementations in mind for your design. In such cases, fast synthesis could save you time working through different runs.
When you need a quick preliminary synthesis result to help get postsynthesis feedback.
When prototyping a design. Fast synthesis 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.
LO
Using Fast Synthesis

This section describes how to run Certify fast synthesis.
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 136.
Create Project Add Source Files Set Constraints Set Options Set Logic Mode Run Preparation Partition Certify Synplify Premier Fails Requirements SLP Generate
Synthesize Analyze Results
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 Certify project. 2. Add the source files to the project. 3. Set attributes and constraints for the design. 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.
Enable Fast Synthesis on the Options panel of the Implementation Options

dialog box. This option is off by default, and you must explicitly enable it.
Implementation Options->Options
Note that the Physical Synthesis option must be disabled in order to select the Fast Synthesis option. 6. Click the Run Preparation button to compile the design using fast synthesis. The Certify tool reduces the amount and number of logic optimizations performed which results in faster runtimes. 7. Partition the design among the available FPGAs. 8. Run SLP Generate to create the individual projects. 9. Launch Synplify Premier and synthesize each FPGA project. LO 10. Analyze the results, using the log file, the HDL Analyst schematic views, the Message window and the Log Watch window.
Fast Synthesis and Other Synthesis Options
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. If Fast Synthesis is intended for quick synthesis results and not for a fast board implementation, it is recommended that you do not run placeand-route on the resulting netlist, as you might get sub-optimal QOR and longer place-and-route run times.
Attributes Limitation
The Fast Synthesis flow does not support the following attributes:
syn_allow_retiming syn_maxfan syn_pipeline syn_replicate

When you run fast synthesis, other optimizations can be affected. Option
Auto Constrain FSM Explorer Resource Sharing Retiming Timing constraints
Usage with Fast Synthesis

Do not use this option with fast synthesis. You can use this option with fast synthesis. You can use this option with fast synthesis. If you enable Fast Synthesis, the tool does not perform any retiming optimizations. 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.
LO
CHAPTER 5
Partitioning a Design
The information in this chapter outlines basic techniques and procedures for partitioning a design with the Certify software. If you are a new Certify tool user, Synopsys recommends that you first work through the first Certify tutorial design available on the SolvNet web site at https://solvnet.synopsys.com/browse?bt=2&pd=Certify listed under Application Note. This chaptersection includes the following related topics:
Preparing to Partition, on page 140 Partitioning Your Design, on page 148 Impact Analysis, on page 162 Replicating Logic, on page 167 Voltage Regions, on page 171 Bit Slicing, on page 176 Fanin-driven Decomposition, on page 183 Arranging the Views, on page 187 ToolTip Probing, on page 194 Viewing Instance Properties, on page 195 Design Output, on page 196
Preparing to Partition
The following sections describe tasks performed prior to partitioning.
Files Needed for Partitioning

To partition a design, create and then add the following files to a Project:
One or more HDL logic design files describing your design. Design files
can be all Verilog, all VHDL, or a combination of Verilog and VHDL files.
A board description file (vb), which is written in Verilog for VHDL-based

designs as well as for Verilog-based designs.
Optionally, your project can contain one or more constraint files (sdc),
which you create using the SCOPE editor or a text editor.
LO
Before partitioning, complete the Project Management section in the project view:
Open your project by clicking the Open Project button in the Run Preparation section of the project view; if you are creating a new project, add the RTL design and board files to your project using the Add File button (see Creating a Project File, on page 64)
Set the implementation options for your project (see Setting Implementation Options, on page 81). Make sure that the board file to be included in your design is selected and enabled on the Partition/SLP panel.
Accept the implementation options. Click Run Preparation or select the implementation and click Run Preparation from the popup memu; the progress is reflected in the Flow Graph window.
Flow-Graph Project Compilation

When you click Run Preparation, the board and design files are compiled, n-filter is called to optimize the design, and properties are annotated in the design. When run preparation is successful, all of the boxes in the flow diagram will be green as shown in the previous figure. If you get a compilation error, the corresponding box will be red as shown in the figure below.
Debug the source files and rerun preparation until the log file no longer contains any errors. To view the log file, select View->View Log File. You can proceed with warnings or notes, but errors must be corrected. Note: If you are running Run Preparation on an Identify implementation, an additional box is added to the flow diagram to show the Identify compilation step.
Including Identify Sampling Logic

The additional IICE sampling logic inserted by the Identify instrumentor can be partitioned with the initial design logic. To include the sampling logic, the design must be instrumented, compiled, and saved in the Identify instrumentor and Run Preparation must be executed on the Identify implementation. To include an Identify implementation in your Certify project: LO 1. Open the Certify project. 2. Add an Identify implementation by either selecting Project->New Identify Implementation from the main menu or by highlighting the existing Certify
implementation and selecting New Identify Implementation from the popup menu with the right mouse button. 3. Set any additional options in the Add Identify Implementation dialog box; the device is defined by the board file and should not be changed. 4. Highlight the Identify implementation and either select Launch Identify Instrumentor from the popup menu with the right mouse button or click the Launch Identify Instrumentor icon in the top menu bar. 5. If you are prompted for the install path to the Identify instrumentor installation, enter the path in the Locate Identify Installation field, select the Locate Identify Installation radio button, click OK, and repeat step 4. Do not include the /bin subdirectory in the path.
6. In the Identify instrumentor, instrument and save your design as described in the accompanying Identify documentation and then close the Identify instrumentor. 7. In the Certify project window, make sure that the Identify implementation is selected (highlighted) and click Run Preparation.
The instrumented design can now be partitioned as described in Partitioning Your Design, on page 148. The additional IICE control and sampling logic is displayed in the RTL view.
Area Estimation
To estimate the area required by the design blocks, select Run->Estimate Area or press F9. Note that you can also select the Estimate Area for Partitioning block in the flow diagram and select Run from the popup menu. Estimating area creates an estimation file (est). The area specified is in design architecture units such as LUTs (for Xilinx) or LABs (for Altera Stratix), and not in ASIC gates. A separate log file (designName_est.srr) lists errors, warnings, and notes for the estimation process. To view this file in the GUI, select View->View Area Estimation File. Two methods for performing area estimation are supported model based and architecture-unit based. Model-based area estimation is faster (but less accurate) and is generally used to improve the performance for partitioning guidance. Architecture-unit based area estimation (the default) is more accurate (but slower) and is used when area estimates are critical. The area-estimation method is determined by the Estimate Area Effort setting according to the following table. Effort Level low medium Estimation Mode model based model based Description Uses n-filter to write estimation (est) file; provides fastest execution time Uses n-filter to write estimation file; improved estimation of registers over low effort with longer execution time Uses Certify mapper to write estimation file; requires longest execution time
high (default)
architecture-unit based
To effort level can be set in the user interface from either:
the Device tab of the Implementation Options dialog box select the desired
effort level from the Estimate Area Effort drop-down menu. LO
the Estimate Area for Partitioning block in the flow diagram highlight the
block, select Properties from the popup menu, and then select the desired effort level from the Estimate Area Effort drop-down menu.
To set the effort level from the Tcl command interface and perform area estimation, use the following command syntax: estimate_area -effort low | medium | high To set the effort level from the Tcl command interface without running area estimation, use the following set_option command: set_option -area_effort {low | medium | high}
Opening a Partition
To open a Partition: 1. Click the Load Database button. A dialog box is displayed to prompt you to load the prototyping files.
2. Click the Load All button in the dialog box. The status of the database files is listed in the display area a green check box indicates a successful load.
At a minimum, you must have a compiled board and netlist file to perform partitioning.
LO
3. Click the Close button in the dialog box. 4. Click the Open Partition icon ( ) on the toolbar or the Partition View button in the Partition Management section to open the partition file. When you open a partition file, the Certify software reduces the Certify Project view to an icon and, as shown in the following figure, displays:
An RTL view including the RTL Design view, connectivity matrix, and
Hierarchy Browser (pressing F3 toggles the connectivity matrix display; not shown in the following figure).
A Partition view including the Partition Device view, Partition Tree view,
and Partition Info view.
A floating Impact Analysis view (not shown in the following figure; select
View->Impact Analysis View when the partition view is active).
Partition Tree view Partition Info view Partition Device view
Partition view
RTL view
Hierarchy Browser
RTL Design view
Partitioning Your Design

With the Partition and RTL views in the Certify window, you can either manually partition your design or you can use the Certify tools Quick Partitioning Technology (QPT) feature to automatically partition your design among the available FPGA devices.
Manual Partitioning
To manually partition a design, follow these steps: 1. Assign logic by selecting instances from the RTL view, the Hierarchy Browser, or the Info view and dragging them to the FPGAs in the Partition Device view. Alternatively, you can use the Impact Analysis window to assign the selected instance or instances to a device (see Impact Analysis, on page 162) or you can use the Assign to menu selection with the right mouse button in the RTL view. 2. If your design contains black-box logic components that will not be mapped to an FPGA, drag and drop the black-box logic components to their board-level black boxes or use the Assign to menu. 3. Check for unassigned logic by selecting System Unassigned Bin in the Partition Tree view. Assign any unassigned logic by dragging the instance from the Partition Tree or Partition Info view to an FPGA in the Partition Device view or use the Impact Analysis window. 4. Use Save->Save Prototyping Files to save the partition file ( prt). By default, the partition file is automatically added to the project. Note: When manually partitioning a design, any inverters are automatically pushed into the input pins of their associated primitives. To improve or complete partitioning of your design, you can use one or more of the following features: LO
Filter the netlist (see Setting Netlist Filtering Options, on page 94) and
recompile your design
Replication (see Replicating Logic, on page 167) Bit slicing (see Bit Slicing, on page 176)
Partitioning with QPT

The QPT (Quick Partitioning Technology) feature can be used on both unpartitioned or partially-partitioned designs with either undefined or predefined traces. QPT is run from the Partition view after a design is successfully compiled (Run Preparation) and area estimated. The QPT configuration and flow are different for boards with undefined traces and for boards with predefined traces. User-defined area and trace constraints are used to drive the QPT algorithm. Beginning with an initial starting partition, QPT continues to iteratively improve the area and trace requirements and stops when all of the design elements have been assigned and the area and trace constraint goals are satisfied. When used with a board with undefined traces, QPT generates a Signal Connectivity and Board Suggestion Report. This report defines the individual device and device-to-device bus requirements. Running QPT on a board with undefined traces determines if it is feasible to fit a design within the intended I/O and area constraints before investing in the purchase or development of a board. When used with a board with predefined traces, QPT attempts to find a solution within the I/O, area, and trace constraints and generates a comprehenive Signal to Trace Assignment Report. This report defines:
Signal-to-trace assignments for each device including device to I/O and

device-to-device
Net bus requirements in terms of nets that can and cannot be used with
asynchronous CPM (Certify Pin Multiplexer) and the compatible traces required and available
Running QPT on Boards with Pre-defined Traces

QPT uses CPM to achieve a partitioning solution when the availability of board traces is limited; QPT starts with a user-defined CPM ratio and automatically continues to decrease this ratio until a solution cannot be
reached. QPT then uses the last successful CPM ratio and writes the CPM commands to the partition file and the trace assignments to the pin-assignment file. When running QPT on a design that uses CPM, only the end@seq net qualification criteria is considered. Any net that is considered CPM-capable within QPT is based on the end@seq criteria regardless of the Net Qualification Criteria selection in the CPM Assignment dialog box. When running QPT on a board with pre-defined traces, QPT can write CPM commands to the specified cpm file and trace-assignment commands to the specified tra file. If a board solution is reached, only the additional manual assignment of the CPM control signals is required, and the selected CPM ratio is reported in the Signal to Trace Assignment Report. If QPT cannot succesfully partition the design within the given pin, area, and trace constraints, the best-possible CPM solution is written to the specified cpm file and the best-possible trace solution is written to the trace-assignment file. The QPT flow for boards with pre-defined traces is shown in Figure 5-1, on page 152, and is outlined below: 1. Create your project using a board with pre-defined traces. For information on boards and board design, see Chapter 25, Board Description Files. 2. Define any additional asynchronous CPM modules required for your design (a set of asynchronous, default CPM modules is included in both Verilog and VHDL formats). For information on creating CPM modules, see Certify Pin Multiplexing, on page 252. 3. Run RTL Preparation and run area estimation. For designs with adequate area resources, model-based area estimation can be used to reduce the estimation time (see Area Estimation, on page 144). 4. Perform any desired pre-assignments. Saving these values allows you to reload the assignments if you must rerun QPT. Pre-assignments include:
System-level black boxes from within your design Modules containing block RAM memories LO Modules that you want located in a specific FPGA Top-level nets or reserved traces
5. Optionally reconfigure the default QPT settings (Setting the QPT Options, on page 153). 6. Run QPT. If partitioning is successful, QPT reports the CPM ratio that it used to reach the solution. If a partitioning solution cannot be reached, see Rerunning QPT, on page 153. 7. Run SLP Generation and then use Synplify Premier to map the individual FPGAs.
Start
Add Board File
Remove CPM Commands
Compile and Estimate Design
Delete Trace Assignments
Open Partition
Modify Board? N
Pre-assign Modules
Restore Saved Assignments
Pre-assign Nets, Reserve Traces
Save Partition & Pin Assignments
Change Area/ Trace Utilization or Increase CPM Ratio
Run QPT
Successful Solution? Y Assign CPM Control Signals
Run SLP Generation
LO Figure 5-1: QPT Flow with Pre-defined Board
Interpreting the Report

The QPT section of the log file provides a comprehensive report of QPT progress towards finding a partitioning solution and includes the final signalto-trace assignment list. When QPT is successful, this list is complete; when QPT is unable to completely partition a design, the list includes only the assignments that were completed.
Rerunning QPT
When QPT cannot completely partition a design, you can:
Increase the board capacity by adding connectors or daughter boards. Increase the QPT option settings for trace utilization and area bias (see
Setting the QPT Options, on page 153).
Increase the initial CPM ratio to a value greater than the starting ratio.
QPT starts with a default ratio of 8:1 and decreases the ratio until a partitioning solution cannot be reached. Asynchronous CPM ratios range from 2:1 to 20:1 in incremental steps and 32:1. Before you rerun QPT, restore any predefined conditions such as module and net assignments or reserved traces.
Setting the QPT Options

The QPT options for boards with predefined traces are set on the Set Quick Partitioning Technology Options dialog box. This dialog box is available from the Partition view by selecting Tools->Set Quick Partitioner Options when a pre-defined board is specified for the project.
CPM Ratio Trace Utilization Goal
Minimize Run Time
Utilization Goals (each FPGA)
Trace Utilization Goal

The Trace utilization goal entry sets the percentage of trace utilization available to QPT for boards with defined traces when CPM is included in the solution. The default goal is 100 percent with some additional overhead required for the CPM control signals (the starting CPM ratio is set by the value specified in the CPM Ratio field).
CPM Ratio
The CPM Ratio entry sets the starting asynchronous CPM ratio. When a solution is reached at the current ratio, the ratio is decreased, and QPT attempts to partition the design at the lower ratio. This cycle is repeated until a solution cannot be reached with the current ratio setting, and the previous CPM ratio is used. This final CPM ratio is reported in the partition (prt) file as well as in the log file. Note: QPT does not increase LO starting CPM ratio; if a solution cannot be the reached at the starting ratio, you must manually increase the ratio.
Minimize Run Time

The Minimize Run Time checkbox controls the amount of time that QPT spends attempting to reach a solution. When checked (the default), QPT gives up within a reasonable amount of time when a solution does not appear possible. Unchecking this box allows QPT to essentially run indefinitely to find a solution; this setting is normally only used when a solution is thought to be possible and run time is not critical such as allowing QPT to run overnight.
Allow Re-arrange Assignment

The Allow re-arrange assignment checkbox, when checked, allows instances already assigned to be moved by QPT. This option is available to the advanced user who wants to guide QPT through a starting manual solution or who wants to rerun QPT on a QPT-partitioned design for possible improvement. This option is disabled (unchecked) by default.
Utilization Goals
QPT uses area and I/O utilization goals to control automatic partitioning. These goals include RAM, DSP, DCM/PLL, and global buffer utilization as well as the normal area and I/O utilization goals. To adjust any utilization threshold for an individual FPGA, double-click on the corresponding entry and enter a new value. To utilization goals can also be set through individual board_constrain Tcl command options (see board_constrain, on page 33 of the command reference manual).
Pre-assignment
The manual pre-assigning of modules to FPGAs prior to running QPT is used when certain modules are required to be partitioned to a specific FPGA. Usually, pre-assignment is used when there are different FPGA devices available and speed or critical path is a consideration or when blocks of logic are required to be located in the same device. Note that when pre-assigning modules, the Allow re-arrange assignment option must not be checked.
Running QPT on Boards with Undefined Traces

The QPT (Quick Partitioning Technology) feature can be used on both unpartitioned or partially-partitioned designs with either undefined or predefined traces. When QPT is used with a board design with undefined traces, QPT determines if it is possible to fit the design within the intended pin and area constraints before investing in the purchase or development of a board. Running QPT on a board design with undefined traces generates a Signal Connectivity and Board Suggestion Report. This report defines the individual device and device-to-device bus requirements including:
number of compatible traces number of nets compatible with CPM number of nets that cannot use CPM
Because QPT operates on the area and pin utilization values specified, balancing and I/O pin optimization are not considered in the solution when used with a board design with undefined traces. After quick partitioning a design, balancing among the available FPGAs can be achieved by lowering the area and pin utilization values for one or more FPGAs and rerunning QPT. The QPT flow for boards with undefined traces is shown in Figure 5-2, on page 158, and is outlined below: 1. Create your project including a board description file. For information on board design with undefined traces, see Chapter 25, Board Description Files. 2. Add any user-defined CPM modules to your project. For information on creating CPM modules, see Certify Pin Multiplexing, on page 252. 3. Compile your design and run area estimation. For designs with adequate area resources, model-based area estimation can be used to reduce the estimation time (see Area Estimation, on page 144). 4. Extract any system-level black boxes from within your design. 5. Pre-assign any modules containing block RAM or ESB memories LO 6. Pre-assign any modules that you want located in a specific FPGA.
7. Optionally reconfigure the default QPT settings (Setting the QPT Options, on page 153). 8. Run QPT and check the log file:
If QPT reports that the design is larger than the board size, either
increase the area utilization goal or define a board with greater capacity.
If partitioning is successful, QPT reports the CPM ratio that it used to

reach the solution. If a partitioning solution cannot be reached, see Rerunning QPT, on page 153. 9. Run SLP Generation and then use Synplify Premier to map the individual FPGAs.
Add CPM Modules
Add Board File
Compile and Estimate Design
Open Partition
Pre-assign Modules
Save Partition Increase Area Utilization or Use Larger Board
Run QPT
Design Too Large? N Select/Define Board
Close .prt File
Figure 5-2: QPT Flow with Certify-defined Board
LO
Interpreting the Report

The QPT section of the log file for boards with undefined traces provides a Signal Connectivity and Board Suggestion Report. This report defines the bus requirements in terms of:
the number of compatible traces required for each device and between
each combination of devices
number of nets compatible with CPM available between devices number of available nets that cannot use CPM drivers required for extra nets Setting the Partitioning Thresholds
QPT is area biased and uses an 80 percent area default during partitioning which allows possible application of CPM when a design can be partitioned within the given area, but fails to meet the I/O constraints. The area utilization (the percentage that an FPGA is filled), the I/O utilization, and the other resource utilizations can be adjusted from the Set Quick Partitioning Technology Options dialog box (select Tools->Set Quick Partitioner Options from the Partition view) or set through individual board_constrain Tcl command options (see board_constrain, on page 33 of the command reference manual).
To adjust any of the utilization thresholds for an individual FPGA, doubleclick on the corresponding entry and enter a new value in the column. When you are satisfied with the utilization values, click OK to update the changes and exit the dialog box. Quick partition the design (select Tools->Run Quick Partitioning Technology from the Partition view.
Pre-assignment
The manual pre-assigning of modules to FPGAs prior to running QPT is used when certain modules are required to be partitioned to a specific FPGA. Usually, pre-assignment is used when there are different FPGA devices available and speed or critical path is a consideration or when blocks of logic are required to be located in the same device.
Limitations
The following limitations are placed on designs that can be automatically partitioned with QPT.
Black boxes in the logical netlist that correspond to physical black boxes
must be manually assigned; by default, QPT assigns all black boxes to FPGAs
Block RAM usage is not taken into account Timing and clock resources are not taken into account
LO
Using a Different Partition

Whenever you save a partition, it is automatically added to your project.
If your project already contains a partition file, the Certify software displays a dialog box asking if you want to replace the existing partition file in the current implementation. Select Yes to replace the current partition file or select No to continue to use the current partition file in the implementation (the new partition file is still added to the list of partition files for the project). If you later decide to use another partition file, select the file from the Partition Input tab of the Implementation Options dialog box.
Impact Analysis
Impact Analysis
Impact analysis lets you dynamically examine the area and pin count impact of assigning a block or blocks to various FPGAs on the board. Using impact analysis lets you make intelligent partitioning decisions in the shortest amount of time. This type of analysis is especially useful for design blocks with high pin counts. Impact analysis can be performed from the RTL view as well as from the unassigned components list in the Partition Tree or Partition Info views. Using the RTL view allows replication to be considered in the analysis, but limits the analysis to only the components that can be selected in the current RTL view. Using either of the Partition views allows analysis from anywhere in the hierarchy, but is limited to only unassigned components.
Performing Impact Analysis

Follow these steps to perform impact analysis. 1. After you successfully compile your design and estimate its area, open a new or existing partition. 2. If the Impact Analysis window is not displayed, select Tools->Impact Analysis or press Ctrl-i while the Partition view is active or select an instance in the RTL view, click the right mouse button, and select Impact Analysis from the popup menu. 3. Select an element or group of elements in the RTL view or Hierarchy Browser. When a selection is made, the Calculate button in the Impact Analysis window is enabled.
LO
Impact Analysis
4. In the Impact Analysis window, click Calculate to update the area and I/O information for the enabled FPGAs.
instance name
include in calculation
new current
device delta
new device current delta I/O pin usage
area usage
The table in the window is used for what if analysis and shows the area and pin count impact of assigning the selected block to each of the devices marked for inclusion in the calculation (Calc box checked). Note: The values displayed for each device are independent of the other devices and reflect only the impact on that device. In the table above, the U1 line defines the area and I/O pin usage if you were to assign the selected element or group of elements to FPGA U1, and the U2 line defines the area and pin usage if you were to assign the same selected element or group of elements to FPGA U2. In the above table, delta (the values in parentheses) is the change in area or pin count if you were to assign the selected element or group to that device. Note that no assignment is made until you select the device in the Device column and click the Assign button. 5. Assign the selected element or group by first highlighting the desired entry in the table by clicking on the instance name in the Device column and then clicking the Assign button. When the assignment is made, the area and pin count information is immediately updated in the Partition view to help you monitor the resources on the individual FPGAs. If an assignment causes the area or I/O usage to exceed its capacity, the corresponding table cell turns light red. Use impact analysis to experiment with partitioning. When you are satisfied with your initial assignments, save the partition file for that scenario, and repartition your design with different assignments to see if you can improve the partitioning. When you are done experimenting, use the partition that
Impact Analysis
best fits your designs resource requirements. If the current partition is not the one you want to use, refer to Using a Different Partition, on page 161 and select the partition that gives you the best results for your design. Note: The calculation time is proportional to the number of devices included in the calculation and the amount of logic already assigned and becomes more complex as you approach a final partition. When partitioning large, complex designs, it may be faster to assign logic to a device and examine the area and I/O usage in the Partition Info view.
Using the Impact Analysis Window

When using the Impact Analysis window:
You can assign elements or blocks without calculating the I/O and area
resource requirements. Simply select the element or block in the RTL view, Hierarchy Browser, or System Unassigned Bin, click on the target device in the Device column, and click Assign.
The Show insts button displays a dialog box that lists all of the elements
currently selected in the RTL view, Hierarchy Browser, or System Unassigned Bin.
The Calc checkboxes in the table determine if any devices are to be

excluded from the impact analysis calculation to reduce the analysis time (by default, all devices are included in the calculation). Usually, you will exclude a device from the calculation when its contents are near or at capacity or when it is not being considered for the current assignment.
To move an element from one device to another using the Impact

Analysis window:
select the element to be moved in the RTL view; use the ToolTip to
identify the current device assignment
select the Advanced tab and select the Move radio button select the destination device in the Device column and click Assign To replicate an elementLO another device using the Impact Analysis in
window:
Impact Analysis
select the element to be replicated in the RTL view; use the ToolTip to
identify the current device assignment
select the Advanced tab and select the Replicate radio button select the destination device in the Device column and click Assign
For more information on replicating devices, see Replication Example Using the Impact Analysis Window, on page 167.
Advanced Window
The Advanced window duplicates all of the functions of the Basic window and includes an Options area and a View Selection area.
Options Area
The Options area includes three radio mode buttons and a Decompose checkbox.
Assign Replicate Move Decompose
Selected element in RTL view is assigned to each device included in the calculation (default mode) Selected element in RTL view is replicated in each device included in the calculation Selected element in RTL view is moved to each device included in the calculation Decomposes selected instance (if qualified) during calculation
Note: When requesting a new calculation involving a replicate or move operation, the impact on the device where the logic is currently assigned is excluded from the calculation to improve the run time.
Impact Analysis
View Selection Area

The View Selection area lets you add or customize views by modifying the list of devices displayed in the Device column.
New View
Creates a new view. Views are named View_n beginning with View_0 and incremented with each new view added. Add devices to the view by dragging and dropping from the Partition Info or Partition Tree view. Creates a clone of the selected view. Cloned views are named by appending an _n suffix to the name of the active view. Add devices to the view by dragging and dropping from the Partition Info or Partition Tree view. Deletes the active view. Deletes the selected device from the active view.
Clone View
Delete View Delete Device
Impact Analysis Tcl Commands

A set of Tcl commands is available with impact analysis to return the requested calculation results on the specified instances for the indicated devices. Results can be displayed on the command line or written to a specified file for analysis. For command information and syntax, see impact_analysis, on page 109 of the command reference.
LO
Replicating Logic
Replicating Logic
When partitioning, the Certify tool lets you replicate logic across multiple FPGAs, provided the replicated logic is assigned to another FPGA.
Replication Example Using the Impact Analysis Window

The following example, which is based on the tutorial design, uses the Impact Analysis window to illustrate impact analysis with replication. For this example, assume that you have two FPGAs, U1 and U2. 1. If the Impact Analysis window is not displayed, select Impact Analysis View from the Partition view popup menu or select View->Impact Analysis View from the menu bar while the Partition view is active. 2. From the RTL view or Hierarchy Browser, select several submodules from within the top-level module.
3. In the Impact Analysis window, click Calculate to update the table with the area and pin count requirements for the selected blocks.
Replicating Logic
4. For this example, assign the submodules to FPGA U1 by clicking the first (U1) entry in the table. 5. Pop-up one level in the hierarchy and select the top-level module from the RTL view. 6. Display the Advanced tab of the Impact Analysis window by clicking the Advanced button and select the Replication radio button in the Options section (replication is off by default). 7. In the Impact Analysis window, click Calculate to update the table with the area and pin count resources required by the top-level block based on replicating any of its submodules that have been previously assigned to other FPGAs.
Note that both entries in the Area column are light red to indicate that either assignment would exceed the area limit. 8. On the Advanced tab, turn replication off by clicking the Assign radio button so that subsequent impact analysis calculations for area and pin count will exclude any submodules previously assigned to other FPGAs. 9. With the top-level block still selected, again click Calculate to update the table values. These new values reflect the impact analysis information for the top-level block if you were not going to replicate the submodules previously assigned to U1. As shown in the table, assigning the top-level block to U2 without replicating the submodules would reduce the area requirement to within device capacity, but would increase the pin count.
LO
Replicating Logic
Replication Example Using the Drag and Drop

The following example is based on the tutorial design and uses drag and drop to illustrate replication. For this example, assume that you have two FPGAs, U1 and U2. 1. From the RTL view or Hierarchy Browser, select several submodules from within the top-level module.
2. Drag and drop the selected submodules to device U1. 3. Pop-up one level in the hierarchy and select the top-level module from the RTL view. 4. Drag and drop the top-level module to device U2. An Instance Replication dialog box pops up asking if you want to replicate the instances assigned to U1.
Replicating Logic
If you click Yes (or Yes to All), the instances assigned to U1 are replicated in U2; if you click No (or No to All), the instances are not replicated. Note: The setting of the Replication radio button in the Impact Analysis window only affects assignments made in the window. You can perform drag and drop logic replication with the Replication radio button on or off.
Listing Replicated Assignments

You can display a list of the replicated assignments from the Partition view. Selecting Tools->Show replicated assignments from the menu displays the Replicated Assigments dialog box which lists all of the initial and replicated assignments for the design.
Replicated instance marked for unassign
From the dialog box, you can unassign a replicated instance by selecting the instance (or check mark) and clicking Unassign; the selected instance is deleted from its assigned device when you click OK. If you unassign either the original (initially assigned) or replicated instance, both instances are removed from the list. If you mistakenly mark an instance for unassignment, you can reassign the instance by clicking Assign before you click OK. LO
Voltage Regions
Voltage Regions
The voltages assigned to different regions of boards can vary depending on requirements of the connected daughter boards. When individual voltage regions exhibit different voltages, there is a potential for board connectivity errors when pins from different voltage regions are interconnected. Pin connectivity and the assignment of I/O standards can be difficult with large FPGAs; acquiring a list of all pins in a particular voltage region, all connected pins, or a list of the connected voltage regions can be equally difficult to obtain.
HAPS Voltage Regions

With HAPS boards, the voltages assigned to each voltage region are annotated by parameters set in the board file. These voltage region assignments are added to the haps-*.v files (HAPS-5n and later) to set voltages that correspond to the DIP switch settings on the board. The default is the same as the board default. example: #!verilog (-) // Voltage region configuration // binary value represents dip switch settings parameter V1a_cfg = 5'b0100_1; localparam V1a = ( V1a_cfg == 5'b1000_1 ? 3.3 : V1a_cfg == 5'b0100_1 ? 2.5 : V1a_cfg == 5'b0010_1 ? 1.8 : V1a_cfg == 5'b0001_1 ? 1.5 : V1a_cfg == 5'b0000_1 ? 1.2 : 0.0 ); The 5-bit binary value corresponds to the DIP switch settings. The extra voltage regions that can be driven externally are also set to their default values: // override these with the external voltage if used parameter V1ax = V1a; parameter V1cx = V1c; parameter V3ax = V3a; parameter V3cx = V3c;
Voltage Regions
All default assignments can be overridden in the board file with defparams: defparam V1a_cfg = 5'b1000_1; defparam V1ax = 1.8; During partitioning, the board netlist with the voltage region assignments is read and any connectivity conflicts are reported. These conflicts include one or more of the following:
different voltages in two, interconnected regions a voltage that does not match the allowed I/O standard on a daughter
board
a voltage that does not match the LVDS I/O standard required for
HSTDM
I/O Standards
I/O standards for each pin in each voltage region are selected based on the voltage for that region. The I/O standards are defined in $LIB/xilinx/x_io_tbl.txt and $LIB/altera/altera_io_tbl.txt. The definitions in these files include:
The default I/O standard for each technology (starting with Virtex-5) The default I/O standard for each voltage for each technology (starting
with Virtex-5) Note: Altera-based HAPS boards are currently unavailable. During partitioning, the board netlist is checked for daughter board I/O standard requirements and, if possible, compatible I/O standards for each pin are assigned. These I/O standards are forward annotated to both the synthesis and place-and-route tools.
LO
Voltage Regions
Example Voltage Region Report

The following is an example of a voltage-region report. Voltage Region Report: -----------------------------------------------------------(details of any conflicts should be shown above) region region @W:Has region region region region region region region region @W:Has region region region region mb.2.5v : FIXED at 2.50 V mb.V1c : USER SET at 1.20 V a CONFLICT based on connectivity to other pins mb.V1b : USER SET at 2.50 V mb.V2c : USER SET at 2.50 V mb.V2b : USER SET at 2.50 V mb.V1cx : USER SET at 1.20 V mb.V3c : USER SET at 2.50 V mb.V3b : USER SET at 2.50 V mb.V3cx : USER SET at 2.50 V mb.V3a : USER SET at 2.50 V a CONFLICT based on connectivity to other pins mb.V3ax : USER SET at 2.50 V mb.V2a : USER SET at 2.50 V mb.V1a : USER SET at 1.20 V mb.V1ax : USER SET at 2.90 V
Make sure to set up the voltage regions as described above -----------------------------------------------------------End Voltage Region Report
Example I/O Standards Report

The following is an example of an I/O standards report. IO Standards Report: ================================================== mb.uD mb.uD mb.uD . . . mb.uA mb.uA : bank : bank : bank 1: OK , notes: N5 2: OK , notes: N5 3: OK , notes: N5
: bank 22: CONFLICT , notes: N5 : bank 23: OK , notes: N5
Voltage Regions
mb.uA : bank 24: OK , notes: N5 mb.uA : bank 25: OK , notes: N5 . . . Key to notes and warnings: N1: IO standards assigned by user N2: IO standards assigned based on TDM use N3: IO standards assigned based on other pins in the IO Bank N4: IO standards assigned based IO standards required or set on connected pins N5: IO standards assigned based voltage regions The rules for allowable I/O standards on the same bank of pins are complex, and the use of a voltage that does not match the I./O standard may be permitted. Accordingly, all conflicts that cannot be resolved are reported, but are not required to be corrected. In addition to the report, an I/O standard constraint file is written for each FPGA. Conflicts are noted as comments, and pins of the same I/O bank appear together, with a comment identifying the I/O bank. These constraint files can be edited.
Example iostd.sdc File

# # IO Standards assignments for pins of mb.uA # Written on Wed Sep 17 12:46:58 2008 # ... # Pins in use in IO Bank 26 (40 pins total) in voltage region mb.V1ax (2.90 Volts): # Pins in this bank had CONFLICTS that may need to be resolved # pin arsti (AL12) has default IO Standard # pin ai[0] (AL11) has default IO Standard # pin ai[3] (AM11) has default IO Standard # pin ai[4] (AM12) has default IO Standard # pin ai[1] (AP10) has default IO Standard # pin ai[2] (AN11) has default IO Standard # pin ai[5] (AN10) has default IO Standard # pin ai[6] (AM9) has default IO Standard LO # pin ai[7] (AP12) has default IO Standard # Pins in use in IO Bank 27 (40 pins total) in voltage region mb.V2b (2.50 Volts):
Voltage Regions
# Pins in use in IO Bank 28 (40 pins total) in voltage region mb.V2a (2.50 Volts): define_io_standard {reg_array_5_[0]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[3]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[4]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[1]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[2]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[5]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[6]} syn_pad_type {LVCMOS_25} define_io_standard {reg_array_5_[7]} syn_pad_type {LVCMOS_25} ...
Bit Slicing
Bit Slicing
Bit slicing can be used when there is an imbalance of I/O pin requirements among FPGAs after initial partitioning due to the assignment of a large, bustype primitive to a single FPGA. Bit slicing allows you to break up larger primitives into some number of smaller primitives that can be more equally partitioned among the other FPGAs. The logical division of primitive outputs is defined by a slice_primitive command read from a ptf or tcl file. Bit slicing references this file and uses the netlist filter to control the logical division of the element into the user-defined number of primitives. A graphical user interface simplifies the editing of the netlist filter ptf files for bit slicing (existing tcl files can be used directly by the netlist filter or renamed with a ptf extension for viewing in the graphical user interface).
Using the Bit Slice Interface

To use the graphical interface to perform bit slicing, open a new or existing prototype tool file (ptf). Note: When bit slicing, close the active partition before opening the prototype tool file. If a partition is open, a message pops up reminding you to close the partition before running the netlist filter (pressing F7). The prototyping tool file tab for bit slicing is shown in the following figure.
LO
Bit Slicing
To use the Bit Slices tab, drag and drop the instance to be bit sliced from the RTL view onto the tab.
Slicing by Bits and Slices

To slice an instance by a specified number of bits per slice or by a specified number of slices: 1. Enter a Bits per Slice or Slices value by clicking the corresponding radio button and entering a value in the adjacent field. If you enter a Bits per Slice value, the Certify software allocates an instance for each group of bits with any remaining bits allocated to the last instance. When using a Slices value, the Certify software divides the bits equally among the specified number of instances with the last instance assigned any partial number. 2. Save the file (if this is a new prototyping tool file, you are prompted for a filename). Also, if Enable Prototyping Tools is not checked on the Prototyping Tools tab, you are asked if you want it enabled click YES. 3. Close the RTL view and redisplay the Project view. 4. Display the Implementation Options dialog box (click Impl Options or select Project->Implementation Options) and select the Prototyping Tools tab. Make sure that the prototyping tools file that you just created is checked in the Netlist Prototype Files section.
Bit Slicing
5. Run netlist filtering (press F7) on your design with the selected prototyping tool file and open the partition. The sections of the sliced element will be displayed and can now be individually partitioned.
Custom Slicing
A custom slice setting is available for defining slices of varying widths. To use the custom setting: 1. Click on the Custom radio button. The MSB/LSB table becomes highlighted. 2. Select the entry in the table. The Slice button becomes enabled. 3. Click the Slice button to display the Select New Slice MSB popup menu as shown below.
4. Either click OK to slice the number of bits into two or enter the starting MSB for the second (least significant) slice. 5. Continue to select entries in the table and click Slice to redisplay the Select New Slice MSB popup menu (see Slicing into Predefined Primitives, on page 180). 6. Save the file (if this is a new prototyping tool file, you are prompted for a filename). 7. Close the RTL view andLO redisplay the Project view.
Bit Slicing
8. Display the Implementation Options dialog box (click Impl Options or select Project->Implementation Options) and select the Prototyping Tools tab. Make sure that the prototyping tool file is checked. 9. Recompile your design with the prototyping tool file and open the partition. The sections of the sliced element can be individually partitioned.
Bit Slice Options

Bit slicing supports both global application of the bit slice definition to all same-type instances in the netlist and the ability to preserve the hierarchical view (the effects of bit slicing are only visible at the next level down in the hierarchy). To enable either (or both) of these options, check the corresponding box in the Options section.
Bit Slice Examples

The following examples illustrate two different cases of bit slicing a 96-bit bus XOR primitive. The figure below shows the primitive before bit slicing.
Slicing into Primitives of Equal Size

In this example, the Bits per Slice value is set to 36 as shown below.
Bit Slicing
The above setting divides the output of the y[95:0] primitive into three individual primitives. The first two primitives each contain the requested 36 bits; the last primitive contains the remaining 24 bits (y[95:72]). The RTL Device view for this bit slicing example is shown in below.
Slicing into Predefined Primitives

In this example, the Custom setting is used to slice the primitive into three individual primitives of predefined widths of 48, 32, and 16. When the Custom radio button is selected, the adjacent table is enabled. Clicking on the top (and only) entry enables the Slice button as shown below.
Clicking the Slice button prompts you to accept the displayed MSB for the new (next) slice or to enter another MSB for the slice. LO
Bit Slicing
For this example, click OK to create an initial bit slice of 48. Note that 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. Select the second entry in the table and click Slice. You are again prompted to accept the displayed MSB for the new slice or to enter another MSB for the slice. Enter 15 (the MSB for the third slice) and click OK. The table is updated as shown below.
You can merge two (or more) adjacent slice definitions in the table by selecting the entries with the Control key and clicking Join. Using this feature allows you to essentially undo an entry with an incorrect width. Save the ptf file, make sure that the filename is checked on the Prototyping Tools tab, and run the netlist filter (press F7) on the design. The RTL view for this bit slicing example is shown in the following figure.
Bit Slicing
Bit Slicing Guidelines

When using bit slicing, you can only divide large bus primitives of the following types: buf, inv, tristate, and, or, xor, mux, latch, flip-flop, equality, adder, adder/subtractor.
LO
Fanin-driven Decomposition
Use fanin-driven decomposition to break down MUXes or other large primitives to achieve better partitioning and reduce pin counts. Fanin-driven decomposition often can solve the problem of exceeding pin counts on FPGAs because when the primitives are decomposed, portions of the primitives are relocated inside the FPGAs with the source logic that drives them, thus reducing the pin count. When you push down in the hierarchy and partition your design at the primitive level, the Certify program prompts you to break up large primitives when assignment separates the primitive from the source logic that drives it. By clicking Yes on the Certify prompt to decompose the primitive, the Certify software automatically decomposes the primitive and redistributes those portions of the primitive to the FPGAs that include the driving source logic. To enable fanin-driven decomposition, select Options->Certify Preferences from an active Partition view to display the Preferences dialog box. When the dialog box appears, click the Assignments tab to display the form shown below. Click the Ask button under Apply Fanin Driven Decomposition to enable fanin-driven decomposition prompting.
To illustrate fanin-driven decomposition, assume that the sample, primitivelevel design shown in the following diagram is to be partitioned among three FPGAs with the assignments as noted by the dashed lines in the figure.
Assign to U1
Assign to U3
Assign to U2
To apply fanin-driven decomposition to the sample design: 1. Make sure that fanin-driven decomposition prompting is enabled on the Assignments tab of the Preferences dialog box. LO 2. Assign the indicated elements to U1 and to U2 as noted in the above figure.
3. Select the multiplexer and register and assign these elements to U3. When you make this assignment, you are prompted:
4. Select Yes or Yes to All to decompose the multiplexer element (if you select No or No to All, no decomposition occurs and the selected elements are assigned to the specified device). When you select Yes, the Certify software automatically decomposes the multiplexer so that a smaller MUX primitive is used in U3 and small MUX primitives are added to the logic driving the original multiplexer in the other FPGAs. Depending on the design, fanin-driven decomposition can result in reduced pin counts and improved partitioning. The following figure shows the post-partitioning RTL views of the three FPGAs using fanin-driven decomposition. In the sample design, fanin-driven decomposition results in a 25 percent reduction in I/O pin count.
U1
U2
U3
Note: Fanin-driven decomposition is only applied to instances with nine or more input and output pins. Instances with eight or fewer pins do not need to be decomposed, and no prompting occurs. In the above example, the original MUX primitive has nine pins.
LO
Arranging the Views
Arranging the Views

The size and location of the initial Certify window are determined by the window location values in the Certify initialization file (certify.ini) which normally are not changed. The window can be moved or resized using the standard window controls. To maximize the viewing area, the window normally is expanded to full screen by clicking the maximize button in the upper right corner of the window. You can do any of the following to rearrange or organize the views on your screen:
Arranging the Partition and RTL views Changing the default views Partition Device view properties
Arranging the Partition and RTL Views

The Partition and RTL views are available after a design has been compiled. These views are arranged within the Certify window by using one of the following Window menu commands:
Tile Horizontally arranges the views horizontally across the window (the
default)
Tile Vertically arranges the views vertically within the window Cascade overlaps (staggers) the views
If you intend to use a full-screen Certify window, expand the window before arranging the views.
Hiding/Displaying the Connectivity Matrix

By default, the connectivity matrix is displayed when the RTL view is first displayed. The connectivity matrix is toggled on and off by pressing the F3 key.
Arranging the Views
Hiding/Displaying the Tcl Script Window

By default, the Tcl Script window is not displayed when the Certify software is initially started. The Tcl Script window is toggled on and off by selecting View->Tcl Window or by pressing Ctrl-t when the Project view is active.
Opening/Closing the Impact Analysis Window

By default, the Impact Analysis window opens when a new or existing partition is opened. To close the window, click the close button in the upper left corner of the window. To open the Impact Analysis window, select View->Impact Analysis View when the Partition view is active. You can also display the Impact Analysis window by selected one or more components in the RTL view and selecting Perform Impact Analysis from the popup menu with the right mouse button.
Changing the Default Views

The default display of the Certify views and windows is set from the Preferences dialog box and remains in effect from session to session until explicitly changed. To access the dialog box, select Options->Certify Preferences from the Project or Partition view. The Preferences dialog box includes two tabs; a General tab and an Assignments tab.
LO
Arranging the Views
General Tab
The General tab controls the contents and display of the Partition and RTL views and also sets the undo limit for operations within the views.
In the Windows section, Tile Partition View with Analyst when opening, when checked (the default), includes a tiled RTL view when the partition is opened.
Arranging the Views
Assignments Tab
The Assignments tab of the Preferences dialog box includes user-interface, black-box trace assignments, and unassigned bin usage controls.
In the Warnings section:
Show partition assignment warnings when checked, displays warnings

related to assignment. In the Drag/Drop section:
Show fly lines when dragging when checked, displays interconnections to

other devices when dragging and dropping in the Partition view. For the Apply Fanin-Driven decomposition section, see Fanin-driven Decomposition, on page 183. For the Black Box Trace Assignments section, see Automatic Assignment of Black-Box Pins, on page 222.
LO
Arranging the Views
Changing the Partition Info View Columns

The columns displayed in the Partition Info view are controlled by both menu selection and the Select Columns dialog box. To change the partition info view column display, position the cursor anywhere within a row in the Partition Info view (except over a column heading) and click the right mouse button to display the following popup menu:
Auto-size columns Hide column n Sort column n Show Column
Adjusts column widths to fit text Hides the column containing the cursor Sorts the column containing the cursor; toggles between ascending and descending order Adds selected column to the Partition Info view; columns are added on the right. After adding a column, you may have to adjust the column and/or window widths. Opens the Select Columns dialog box to change the columns displayed. The Show All button enables (checks) all columns, and the Hide All button disables all columns. Clicking Cancel closes the dialog box without updating column selection. After selecting the columns to be displayed, you may have to adjust the column and/or window widths.
Show/Hide columns
Arranging the Views
Partition Device View Properties

Partition device view properties are available for both devices and buses.
Device Properties
Device properties are available by selecting the device in the Partition Device view, clicking the right mouse button, and selecting Properties to display the Properties dialog box.
This dialog box includes two tabs: Object Properties and Assignments. The Object Properties tab lists (read only) a series of device properties and their values. The Assignments tab lists the current block assignments for the selected device and the area for each assigned block in that device. You can delete individual block assignments using the Assignments tab by selecting the block to be unassigned, clicking the Unassign button, and then clicking OK. Note that if you incorrectly mark a block to be unassigned, you can reassign the block (before clicking OK) by clicking Assign. LO
Arranging the Views
Bus Trace Properties

Bus trace properties are available by selecting the bus trace and then clicking the right mouse button to display the Properties popup.
Bus Trace Colors

Bus traces are normally green. If the number of I/Os required by an assignment exceeds the capacity of the bus, the color of the bus trace changes from green to red. The Trace Alert column in the Impact Analysis window also indicates when an assignment exceeds the I/O trace capacity; selecting the Traces tab at the bottom of the window displays the I/O pin counts and capacities for each of the individual bus traces on the board.
ToolTip Probing
ToolTip Probing
While you are partitioning your design, ToolTips are available at specific locations that can be probed within a view. The following table outlines the location points for accessing this information and the ToolTip content. Item/View
Instance/RTL view
Content
Instance name and module/entity name in parentheses; area (estimated designs only) and, if assigned, the device assignment(s) Net name and, if multiple destinations, the number of connections (fanout) Hierarchical port name and source/destination signal name in parentheses Instance name and module/entity name in parentheses Net name and, if multiple destinations, the number of connections (fanout) Hierarchical port name Device with module type in parentheses, and the number of instances assigned to that device Area or I/O usage as a percentage with the actual and maximum possible values in parentheses Bus device origin/destination in parentheses and the bus trace capacity/number used in curly braces The full pathname of the partition (prt) file
Net/RTL view Port/RTL view Instance/Technology view Net/Technology view Port/Technology view Device/Partition Device view Gauge/Partition Device view Bus/Partition Device view Background/Partition Device view
LO
Viewing Instance Properties
Viewing Instance Properties

In addition to the ToolTip probes described in the previous section, the Certify tool provides a variety of read-only and value-set property dialog boxes that present more detailed information or set specific values on the selected instance. The following table describes the instance locations and property dialog box contents. The Property dialog box is displayed by first selecting the instance and then using the right mouse button to select Properties from the popup menu. Instance/View
FPGA device/all Partition views
Property Dialog Box Content

Reports I/O capacity and package, input/output net allocation and usage, area and RAM usage on Object Properties tab; reports current assignments and area allocation on Assignments tab Reports name, pins, type, and package on Object Properties tab; reports current assignments and area allocation on Assignments tab Name, capacity, usage, and origin/destination devices Hierarchical name, size, view, assignment, and number of connections; also indicates if the element is replicated and/or decomposed Name of net assigned to probe and if probe is assigned to a pin
Black box/all Partition views Board Trace/all Partition views Assigned instance/Partition Tree and Partition Info views Probe/Partition Tree and Partition Info views
Design Output
Design Output
When you click the Run Preparation button in the Certify Project view, the design and board files are compiled and the design is optimized. The results are written to the log file (see Viewing the Log File, on page 750). When you complete the partition management phase, individual files are written to describe the partition, trace assignments, and CPM assignments and a partitioned netlist (srp) file is generated. During SLP generation:
For each FPGA, vendor-specific output netlist and constraint files are
generated for use by the place and route tools (Write Vendor Constraint File must be checked on the Implementation Results panel).
Optionally, a Verilog or VHDL design file is generated describing the

contents of each FPGA (Write Mapped Verilog Netlist and/or Write Mapped VHDL Netlist must be checked on the Implementation Results panel).
A Verilog or VHDL source-level file and a project file for each FPGA are
created. These files are used with source-level partitioning to create individual projects for each FPGA. The files are in separate subdirectories under the synthesis_files directory in the implementation results window (see Chapter 10, Source-Level Partitioning).
LO
Design Output
The following table lists the output files generated for the specific vendor technologies: File
FPGA netlist FPGA constraint FPGA design FPGA HDL source
Xilinx Technology FPGA#.edf FPGA# .ncf FPGA#_timing.sdc FPGA# .vm FPGA# .vhm FPGA# .v FPGA# .vhd
Altera Technology FPGA# .vqm FPGA# .tcl FPGA#_timing.sdc FPGA# .vm FPGA# .vhm FPGA# .v FPGA# .vhd
Design Output
LO
CHAPTER 6
Layout of the Certify Partition Board View

The partition board view presents an abstraction of the board for the purpose of interactive partitioning. Feature device support on the board includes:
FPGAs Black boxes including PLLs and clock sources Sockets (if present) Traces (aggregated to show connections with common end points) Information gauges
Certify can perform an automatic placement of the devices on the board or the placement of devices can be performed manually. The routing of traces is always done automatically.
Automated Layout
The layout is done to facilitate manual partitioning and has no relationship to the physical board layout. FPGAs are placed on a grid in the middle of the board (with a maximum of 10 columns) in alphabetical order. Sockets are placed above the FPGAs. Black boxes are placed below the FPGAs in columns based on the connectivity to the FPGAs.
Automated Layout
Traces are routed to show connectivity while maximizing appearance. Space is made for the traces as necessary. There are two styles of trace routing:
direct connection in a column or row channel routing.

When a trace connects to devices that are all in the same row or column (and have uniform height or width), the trace connects through the row or column and runs beneath the devices. As shown in the following figure, a dot indicates a device connection, and an X indicates that the trace simply passes through.
LO
Manual Layout
Channel routing creates feeders in the horizontal channels separating the devices; these are connected by segments in the vertical channels.
Manual Layout
You can manually place devices. As is the case for automated placement, devices must be aligned on a grid and cannot overlap. You can place devices of various dimensions in the same row or column. However you cannot change device dimensions. Heres an example of a modified HAPS-54 board view (shown with layout editing enabled): The steps to create a manual placement include: 1. Enter manual editing mode 2. Create empty space (vacancies) 3. Drag devices to create the new layout (Certify re-routes traces as you move devices) 4. Remove unused rows or columns (optional) These steps are described in the following sections.
Manual Layout
Enabling Layout Editing

To enable manual layout, select Edit->Partition Board View->Enable Layout Editing. When manual layout editing is enabled, empty locations in the placement grid are shown as pale green rectangles. Also, clicking on a device shows a tracking rectangle (dashed line) around the perimeter, and all of the interconnected devices are highlighted to simplify placement.
Selected Device with Tracking Rectangle
Empty Locations
You can select multiple devices using a cursor box or the shift/control keys. The selection rectangle is extended horizontally and vertically to include all selected devices. When you place the cursor over a device or devices that can LO be moved, the cursor changes so a cross with outward facing arrows. Leftclick and drag the devices to the new grid location.
Manual Layout
Creating Empty Rows and Columns

Empty grid locations are required to relocate devices (you cannot move a device on top of another device). To create an empty grid location, either:
Use the menu commands Edit->Partition Board View->Add column to the right or
Edit->Partition Board View->Add row on bottom.
Drag the selected devices off an edge of the board view to create new
rows or columns (depending on the location and number of devices selected). A quick way to create ample room is to select all devices and then drag them off the left or right edge of the board. This operation doubles the number of columns. Once you have empty space, you can simply drag and drop the devices to the empty locations. The following figure shows devices relocated on an expanded matrix of six columns.
Compaction
When you close and re-open the Partition view, empty rows and columns are automatically removed. You can explicitly remove empty rows and columns using the Edit->Partition Board View->Compact command.
Manual Layout
Restoring the Automated Layout

You can restore the automatic placement by using the Edit->Partition Board View->Restore command.
Saving a Layout
As you move devices, their locations are recorded in the active Certify object. This means that if you close and re-open the Partition view, you will see your modified placement. If you save your partitioning (to a prt file), the custom layout is saved via board_layout -device commands. These commands contain the column (minX, left-to-right) and row (minY, top-to-bottom) locations of the devices (the max values are unused at present). If you subsequently reopen a design and load the prt file, the custom layout is restored.
Create a Custom Layout Library

Certify does not automatically manage a custom library of board layouts, but you can do this rather simply. To reuse a custom layout of a particular board with several designs: 1. Open a design that uses the desired board (such as a HAPS-52) 2. Open the Partition view and create the custom layout 3. Save partitioning commands to a partition in your custom library (such as haps52_custom.prt). 4. Edit the file to retain only the board_layout commands. 5. When beginning a new design, source the custom layout file. This information will then become part of your design. If you save partitioning for the design, the custom layout is preserved.
LO
CHAPTER 7
Trace Assignment
This chapter outlines criteria for assigning logical nets to the physical traces between FPGAs and black boxes including connectors. You assign nets either manually or automatically using the Trace Assignment window. Note: You can only assign nets on predefined boards. If you try to assign nets on a board without traces, no trace names appear in the Trace column of the trace assignments window. Assigning nets to traces is usually done after a design is successfully partitioned and after any probes are defined. Also, any CPM assignments must be performed before trace assignment. Prior to partitioning, the top-level nets can be pre-assigned or traces can be reserved on partially partitioned designs before using the Quick Partitioning Technology (QPT) to complete the partitioning of the design.To display the Trace Assignment window, select Trace Assignment in the Partition Management section of the project view or click the Open Trace Assignment icon in the menu bar. Note that you must have a netlist and board file loaded into the database to display the Trace Assignment window.
Manual Trace Assignment
The trace assignments window lists the logical nets and probes on the left and the physical traces from the board description file on the right. The upper area on the right is a scratch pad. A set of action buttons separates the list of physical traces from the scratch pad area.

Manual trace assignment is required for all nets connected to board-level black boxes, including connectors and routing chips, that do not meet the following conditions required for automatic assignment:
the name of the black-box port connected to the trace must have the
same name as the logical net
the net and trace must have identical end points

Note: By default, all black-box pins must be manually assigned. For inforLO mation on automatic black-box pin assignment, see Automatic Assignment of Black-Box Pins, on page 222.
Manual trace assignment is also used with QPT to pre-assign nets and to reserve traces before a design is completely partitioned and additionally can be used to assign global nets, buses, and probes when you want to control trace assignment. You normally perform manual trace assignment before automatic trace assignment. With manual trace assignment, you select a net in the Nets area on the left which filters the trace list so that only the legal traces for the selected net appear in the Trace area on the right. Assignment is made as follows: 1. Select an individual net or bus in the Nets area. The selected net or bus is highlighted and the list of eligible traces is displayed in the Trace area. 2. Select the trace targeted for assignment by highlighting the trace in the Trace area. A green check mark appears to the left of the selected trace, and the trace name is duplicated in the scratchpad area.
3. Click the Assign button to make the assignment. When you click Assign:
the trace is removed from the scratchpad area the Assignments column entries in both the Nets and Trace areas are
updated to Assigned.
Nets Display Area

The Nets display is divided into three columns from left to right as follows:
Nets lists the names of the nets or buses in alphabetical order. The
triangle in the header changes the sort order.
Connected Devices lists the nets and buses according to their number of
device connections. The triangle in the header changes the sort order.
Assignments populated with traces names as nets are assigned. The

triangle in the header changes the sort order.
In the Nets display column, buses are collapsed by default; clicking the + symbol expands the bus to its individual bits. Symbols to the right of the name indicate net/bus direction. Selecting a net or bus highlights the name, LO and multiple nets/buses can be selected using the control and shift keys.
In additon to filtering (see Filtering the List of Nets, on page 209), the following operations are supported within the Nets column:
Automatic highlighting a net or bus and clicking the Automatic button

or selecting Automatic Assignment from the drop-down menu automatically assigns the net or bus to a compatible trace or set of traces. The assignment is reflected in the Assignments column.
Reserve highlighting a net or bus and clicking the Reserve button or

selecting Reserve from the drop-down menu reserves the net for future assignment (a reserved net cannot be assigned). The word Reserved is displayed in the Assignments column.
Clear highlighting a net or bus and clicking the Clear button or

selecting Clear from the drop-down menu clears the trace assignment or removes the reserved status.
HSTDM highlighting a net or bus and clicking the HSTDM button or

selecting HSTDM from the drop-down menu changes the status of a reserved net or bus to HSTDM compatible. In the Assignments column, the following words are used to indicate assignment status:
assignment the actual trace assignment (e.g., A7_B[59] or BCLK) Assigned used with collapsed buses to indicate that all bits have been
assigned to traces
Mixed used with collapsed buses to indicate that the bus is only partiially assigned to traces
Reserved the net or bus is reserved (cannot be assigned to a trace until

cleared)
HSTDM the net or bus is HSTDM compatible
Filtering the List of Nets

When the desired net is not visible in the list of nets, you can scroll to the net or you can enter the net name in the filter field and then click the adjacent Apply net name filter icon to display only the net or nets that meet the filter criteria. Note that you do not have to enter the complete name string and that you can use the * and ? wildcards in the search string. The Reset all filters icon resets the display to the original list of nets.
In addition to filtering by name, the Show Status and Show Type filter selections provide filtering by net status (clear, assigned, reserved, or mixed) and by net type including HSTDM and CPM nets as well as assigned probes. The list of filtered nets is restored by clicking the Reset all filters icon.
Search Field
Apply net name filter
Reset all Filters
Width of Selected Net
Trace Display Area

The trace display area is divided into three columns from left to right as follows:
Trace lists the names of the individual or bus traces eligible for assignment to the selected net or nets. Selecting a trace displays the trace name in the scratchpad area. The triangle in the header changes the sort order.
Connected Devices lists the devices connected to a trace according to the

number of connections. The triangle in the header changes the sort order.
Assignments lists the assignment status of the traces

LO
Apply trace name filter Search Field
Reset all Filters
Trace type
In the Trace display column, buses are collapsed by default; clicking the + symbol expands the bus to its individual bits. Selecting an individual or bus traces adds a check mark to the left of the name and highlights the entry in the list of traces; the selected trace is redisplayed in the scratch pad area. Multiple nets/buses are selected using the control and shift keys. When the desired trace is not visible in the list of traces, you can scroll to the trace or you can enter the trace name in the filter field and then click the adjacent Apply trace name filter icon to display only the traces that meet the filter criteria. Note that you do not have to enter the complete name string and that you can use the * and ? wildcards in the search string. The Reset all filters icon resets the display to the original list of traces. In additon to filtering by trace name, you can filter the list of traces by trace status from the Show Status drop-down menu to show any combination of trace status.
When assigning nets to traces:
Nets marked as reserved in the Nets area are not eligible for trace assignment.
When assigning multiple nets to a trace bus and there are more nets
than traces, the unmatched nets remain unassigned, and a bus status of Assigned is indicated.
When assigning multiple nets to a trace bus and there are more traces
than nets, the net assignments are made, and a bus status of Mixed is indicated.
Nets can be assigned to more than one bus by selecting additional

traces/buses before clicking the Assign button in the scratchpad area.
Scratchpad Area
The scratchpad area, like the traces area, is divided into three columns from left to right as follows:
Trace lists the names of the individual or bus traces to be assigned to

the selected net or nets.
Connected Devices lists the devices connected to a trace according to the

number of connections.
Assignments lists the assignment status of the traces

Traces in the scratchpad area are assigned to the corresponding nets and the area is cleared when you click the Assign button. The following operations are available before clicking assign:
Click Remove the highlighted trace is removed from the scratchpad

area and returned to the traces area.
Click Reserve Trace all of the eligible (clear) traces in the scratchpad
area are marked Reserved.
Click Clear Trace all of the eligible (reserved) traces in the scratchpad
area are marked Clear. When you click the Assign button: LO Any traces in the scratchpad area are returned to the traces area; their status is updated to reflect any assignments.
The Assignments column in the Nets area is updated with the assignment
status.
Trace Aliasing
The renaming of board traces or trace aliasing is available for both off-theshelf HAPS and custom boards. This capability:
allows large trace buses to be logically broken down into smaller, more
easily recognized buses
simplifies trace identification in hierarchical designs when trace names

differ among modules Trace aliasing is defined in the HAPS board vb file by including syn_trace_attr attributes to define the bus trace structure. This attribute uses the following syntax: syn_trace_attr #(busWidth,priority) aliasedBus(busName[bitRange]); In the above syntax: busWidth the width of the aliased bus expressed as an integer. The value specified cannot be greater than the width of the original bus. priority the name priority when a bus has multiple names. A value of 1 is the lowest priority. Specifying a value less than 1 does not rename the bus, but makes the new bus name (aliasedBus) an alias. In the following example syn_trace_attr #(1,0) green(A1_A[1]); syn_trace_attr #(1,1) blue(A1_A[1]); syn_trace_attr #(1,10) bluegreen(A1_A[1]); the trace is named bluegreen, and blue and green are aliases. aliasedBus the new name for the bus. Note that aliasedBus is hierarchical if syn_trace_attr is assigned at the top level, the bus name is aliasedBusName; if the attribute is assigned within a hierarchy named mod1 (for example, a daughter card or connector), the bus name will be mod1.aliasedBusName. busName the original name of the bus in the board file. bitRange the range of bits in the original bus to be mapped to the new bus. The range specified must match busWidth.
To illustrate the use of the syn_trace_attr attribute to customize the names of specific traces, consider the following example that splits the A1 bus between devices mb.uA and mb.uB into three separate buses and renames the buses. syn_trace_attr #(50,1) mybusAtoB(A1_A[50:1]); syn_trace_attr #(50,1) mybusBtoA(A1_B[50:1]); syn_trace_attr #(5,1) mybusctrl(A1_B[55:51]); In the above example, portions of the A1_A[59:1] and A1_B[59:1] buses are aliased to mybusAtoB[49:0], mybusBtoA[49:0], and mybusctlr[4:0]. Note that in a hierarchical board file, every hierarchical net segment of the trace is a valid alias for the net. In the board file, the trace could be broken up into different segments such as:
the segment corresponding to the connection between an FPGA and a

connector
the segment corresponding to the cable attached between two different

connectors
the segment corresponding to the connection between a different FPGA

and the other end of the connector
HSTDM Trace Assignment

HSTDM nets are the outputs of HSTDM modules which are exclusively available with HAPS-5x and HAPS-6x series boards. To perform HSTDM net-totrace assignment, the HSTDM option must be enabled when the board file is loaded into the database. To set the HSTDM option:
Select the Enable High-Speed TDM checkbox on the Load Prototyping Files
dialog box.
Include the -hstdm option when loading the board with the board_load
command When assigning HSTDM nets to traces:
HSTDM nets can only be assigned to HSTDM 'p' traces. When an assignment is made, a check is made for an assigned clock within that bank.
If a clock is assigned, a warning is issued, but the assignment is LO

completed.
If the net is assigned to a clock 'p' trace, a warning is issued, but the
assignment is completed.
If a non-HSTDM net is assigned to a clock trace, a warning is issued,

but the assignment is completed.
Setting a trace to HSTDM automatically sets its corresponding paired

trace to HSTDM. Both the trace and its pair must to be explicitly unassigned.
Clearing an HSTDM trace automatically clears its pair. The return value,
however, only contains the specified trace and not the affected pair. Note: When HSTDM is enabled, any command that lists traces omits HSTDM 'N' traces from the list.
Differential Trace Assignment

Differential net-to-trace assignment is supported on both HAPS and custom boards. To perform differential net-to-trace assignment, the differential option must be enabled when loading the board file into the database. To set the differential option, either:
Select the Enable Differential I/O checkbox on the Load Prototyping Files dialog
box in the UI
Include the -diff option when loading the board with the load_board Tcl
command When the -diff option is enabled (and the -hstdm option is off), traces are placed in the differential state when both the p and n trace pair are connected to the same p and n trace pairs on two and only two devices. By default, traces that are placed in the differential state during board loading are configured for the LVDS25 I/O standard. Other differential standards can be supported by reconfiguring traces through the board_define_io_standard command. The differential I/O drivers and receivers are inserted when saving the partitioned netlist. For differential assignment, the differential nets must be identified by the user through the net_place command using the -diff argument. The differential traces are automatically identified during load_board command execution when the -diff option is enabled provided that the following qualifications are met:
the traces are differential-capable per the FPGA specification the traces are connected to two and to only two devices the N trace has the same connectivity as its P trace pair
When performing differential net-to-trace assignment:
Only differential P traces are displayed in the UI Only differential traces can be assigned to differential nets The status of differential nets/traces can be cleared at any time When one trace of a P-N pair is successfully assigned to the differential state, its trace pair is also assigned to the differential state N-trace to clear
Setting a diff-compatible P-trace to clear also sets its corresponding To set a differential-compatible trace to the differential state, neither the
P nor the N trace can be in the assigned state Note: When differential trace support is enabled, any command that lists traces (with the exception of the board_list -all_traces command) omits the differential 'N' traces from the list. HAPS board users can mix HSTDM and differential assignments by setting both the -hstdm and -diff options when loading the board. With both options set, HSTDM-compatible traces are automatically placed in the hstdm state. Once set, these traces can then be set to the diff state as required (you must also set the corresponding net to the diff state to support differential assignment). Also, with both options set, trace pairs that do not meet HSTDM qualifications, but meet differential qualifications, are placed in the diff state.
Manual Trace Assignment for QPT

Manual trace assignment is used prior to running QPT on an off-the-shelf or pre-defined board to pre-assign nets to traces or to reserve traces on a partially partitioned FPGA. To pre-assign a net: LO 1. With the Partition view active, select Trace Assignment in the Partition Management section of the project view or click the Open Trace Assignment icon in the menu bar to display the Trace Assignments window.
2. Select the net to be pre-assigned in the Nets area (top-level nets are indicated by driver/receiver symbols). The Traces column will be filtered to display only the legal traces for the selected net. If no partitioning has been done, only the top-level nets will be listed and all of the traces will be enabled. If partial partitioning has been done, the nets associated with the assigned logic are displayed with the top-level nets; selecting a net filters the traces column to display only the legal nets.
top-level nets
3. Click on the desired trace in the Traces area. The selected trace will be yellow and the QPT Preassign and QPT Ignore buttons will be enabled. 4. Click on the QPT Preassign button. You will be prompted to confirm the pre-assignment. When you click OK, the selected trace in the Traces column will become orange to indicate that it has been pre-assigned. To unassign a pre-assigned trace, select the trace in the Traces column and click QPT Unassign. 5. When all of the pre-assignments have been made, save the trace assignment (tra) file. 6. Run QPT. When you are satisfied with the partition, open the Trace Assignments window and save the tra file. Note: You must explicitly save the tra file in the Trace Assignments window to preserve the QPT trace assignments. Traces on partially assigned (semi-partitioned) FPGAs can be reserved. To reserve a trace: 1. With the Partition view active, select Tools->Trace Assignments from the menu to display the Trace Assignments window.
2. Either make sure that none of the nets is selected or click on the table heading of the semi-partitioned device. 3. Click on the trace to be reserved in the Traces column. The selected trace will be yellow with a gray stripe and the QPT Ignore button will be enabled. 4. Click on the QPT Ignore button. The selected trace in the Traces column will become red with a gray stripe to indicate that it is reserved. To release a reserved trace, select the trace in the Traces column and click QPT Restore. 5. When all of the reserved assignments have been made, save the trace assignment (tra) file. Note: The list of nets to be assigned to traces on a semi-partitioned FPGA will normally get smaller when additional modules, which form internal connections, are added to that FPGA. 6. Run QPT. When you are satisfied with the partition, complete the net-totrace assignments and save the tra file in the Trace Assignments window. Note: You must explicitly save the tra file in the Trace Assignments window to preserve the QPT trace assignments.
Manually Assigning Buses

Buses can be assigned either manually or automatically. Manual assignment allows individual bit assignment and lets you assign large bus nets to multiple smaller bus traces. To assign a bus net to a bus trace of the same width or larger, select the net and then select the trace from the Traces column as previously described. To view the individual assignments, double-click on the bus name in the Nets LO area column to expand the net bus or double-click on the bus name in the Traces column to expand the trace bus.
Multi-Terminal Nets
Multi-terminal nets are nets that originate from a single source within an FPGA and connect to two or more destination FPGAs as shown in the following figure.
FPGA2 FPGA1 FPGA1 FPGA2
FPGA3
FPGA3
Multi-Terminal Net
Multi-Terminal Trace
A multi-terminal net is defined as a net having more than two devices listed in the Connected Devices column and:
there is no multi-terminal trace interconnecting the FPGAs (or it is not

desirable to use a multi-treminal trace resource)
individual traces exist between the driving FPGA and each of the
receiving FPGAs To assign a multi-terminal net: 1. Select the multi-terminal net in the Nets area. Multi-terminal nets are noted by special icons on the left of the net name. A list of the eligible multi-terminal traces is displayed in the Trace column. 2. If you do not want to assign the multi-terminal net to any of the available multi-terminal traces, check the Use Muti-Term box at the top of the traces section.
When you check the box, the list of available traces is expanded to include all traces connected tothe driver, the adjacent Unconnected and Connected drop-down menus are enabled, and the FPGA location of the driver and the word MultiTerminal appear in the lower-right corner of the trace area. 3. Click on the Unconnected drop-down menu to display the FPGA trace assignment requirements.
In the figure above, two traces are required for the selected net, one from mb.uA to mb.uB and the other from mb.uA to mb.uD (the driver for this example is located in mb.uA). 4. Select a trace (or bus) in the Trace column that meets the Connected Devices requirement (using the above example, select a trace or bus connecting devices mb.uA and mb.uB). The selected trace appears in the scratchpad area showing the connected devices, the counts in the Unconnected and Connected drop-down menus are updated, but the Assign button remains disabled.
5. Select another trace in the Trace column that meets the next Connected Devices requirement (using the above example, select a trace or bus connecting devices mb.uA and mb.uD). The selected trace appears in the scratchpad area showing the connected devices, and the counts in the Unconnected and Connected drop-down menus are updated. LO 6. When the number of traces selected satisfies the multi-trace assignment (Unconnected menu reports 0), the Assign button is enabled.
Clicking the Assign button completes the assignment. The Assignments column in the Nets area is updated with the names of the assigned traces, and the scratchpad area is cleared.
Specifying Device Connectivity

The Select Devices checkbox (adjacent to the Use Multi-Term checkbox) is used when a specific device net is to be assigned to a particular trace. Checking Select Devices expands the scratchpad area to include an additional column for each destination device.
To complete the trace assignments, check a box in the FPGA device column. When at least one check box is checked in each colum, the Assign button is enabled; clicking the button completes the assignment. When more than one device is eligible, selection boxes appear under each eligible FPGA as shown in the first entry.
Automatic Trace Assignment

Nets can be automatically assigned to traces by the Certify software. Auto trace assignment is normally performed after all of the manual trace assignments have been made. To automatically assign nets to traces: 1. If necessary, display the Trace Assignment window by selecting Trace Assignment in the project view. 2. Select the nets to be auto-assigned from the list of nets dispalyed. Note that you can selected all nets; any nets that are already assigned and any nets that are revereved are ignored. 3. Click the Automatic button or select Automatic Assignment from the dropdown menu. The nets are automtically assigned to qualified traces
Automatic Assignment of Black-Box Pins

The net-to-trace assignment of board-level black boxes can be automated under either of the following conditions:
the set of logical black-box pin names matches a subset of the physical
black-box pin names
the logical net name and the physical black-box pin name match on an
individual basis The above conditions are enabled by check boxes in the Black Box Trace Assignments section on the Assignments tab of the Preferences dialog box (select Options->Certify Preferences and click on the Assignments tab).
LO
Pin-Name Matching
When the Pin name based box is checked, nets are assigned to traces when the logical and physical pin names match.
Logical Design Block1 net1 BlackBox1 A FPGA1 trace1 Physical Board BB1 A
BB2 * assume: Block1 assigned to FPGA1 BlackBox1 assigned to BB1 B
Referring to the above figure, net1 would be assigned to trace1 because both net1 and trace1 are connected to black-box pin A. Note that if net-name matching was selected, no assignment would be made because the logical net name (net1) and physical pin name (A) do not match.
When performing pin-name matching:
a complete match between the set of logical black-box pin names and
physical black-box pin names is required. If a logical black-box pin is missing from the physical black box or if it does not have the same name as the corresponding pin on the physical black box, no assignment for that black box is performed.
all of the physical black-box pins do not have to be assigned (i.e., the
logical pins can be a subset the physical pins).
the net and trace must have identical end points; the trace can have
additional end points (i.e., the trace end points can be a superset).
if Net name based is also checked, net-name matching (see below) is

performed before pin-name matching.
Net-Name Matching
When the Net name based box is checked, nets are assigned to traces when the logical net name matches the physical pin name.
Logical Design Block1 IN1 BlackBox1 A FPGA1 trace1 Physical Board BB1 IN1
BB2 * assume: Block1 assigned to FPGA1 BlackBox1 assigned to BB1 INn
Referring to the above figure, net IN1 would be assigned to trace1 because the trace connects to black-box pin IN1. Note that if pin-name matching was selected, no assignment would be made because the logical black-box pin name (A) and physical black-box pin name (IN1) do not match. LO When using net-name matching:
the net and trace must have identical end points; the trace can have
additional end points (i.e., the trace end points can be a superset).
if Pin name based is also checked, net-name matching is performed before

pin-name matching.
Assigning Probes to Traces

Probes are assigned exactly like nets and can be manually or automatically assigned. During automatic assignment, traces identified as probes in the board description file are assigned to probe pins. If there are not enough probe pins or no probe pins are defined in the board description file, probes are assigned to normal traces.
Saving Pin Assignments

The Certify software updates the pin assignment (tra) file whenever you use the Save Prototyping Commands dialog box (select File->Save Prototyping Files) after making an assignment. The default filename for this file is the partition filename with a tra extension.
Reserving Pins with the Reserve I/O Pads Option

When using the Reserve I/O pads option to reserve pins on predefined boards, the supported technologies reserve pins as outlined below. To enable this option, check the Reserve I/O pads box on the Options tab of the Implementation Options dailog box. Note: When the Reserve I/O pads option is not set, the Place and Route tool is free to assign pins to the unused traces. This random assignment can impact the operation of predefined boards if the pins are constrained to traces.
Altera Stratix
For the Altera Stratix technologies, pins connected to unused or partially used traces are treated as follows:
Pins with no assigned net, but connected to a partially or totally unused

trace, are reserved and treated as inputs
No action is taken on pins that are not connected to any trace Xilinx
For the Xilinx technology, pins connected to unused or partially used traces are treated as follows:
Pins with no assigned net, but connected to a partially or totally unused

trace, are reserved and treated as tristate outputs Note: The Xilinx P&R tool optimizes away the undriven tristates.
LO
CHAPTER 8
Time-Domain Multiplexing
Time-Domain Multiplexing is a technique in which different signals are transferred in a single channel to reducing the number of I/O pins required between FPGAs. The time domain is divided into several time-slots of fixed length, one for each channel. Certify supports two methodologies to reduce pin counts: Certify Pin Multiplexing or CPM and High-Speed Time Domain Multiplexing or HSTDM. The basic time-domain multiplexing concept used by CPM is shown below. Source FPGA Destination FPGA
Mux
Dmux
100MHz Clk
100MHz Clk
In the above figure, data at the source FPGA is loaded into the multiplexer in parallel and shifted out serially by the clock. At the destination FPGA, the serial data is shifted into the de-multiplexer by the same clock and then loaded in parallel to the output registers.
For the above configuration, a typical design frequency would be 10MHz (100ns) with a TDM frequency of 100MHz (10ns). Assuming a re-sampling rate of three samples per design cycle, the transmission rate for a HAPS board with 119 pin connectors would by 119 * 3 or 357 signals per design cycle. By contrast, the time-domain multiplexing technique used by HSTDM is shown in the following figure.
400MHz Clk
PLL
LVDS
LVDS
400MHz Clk
100MHz Clk
BUFR
BUFIO
100MHz Clk
100MHz Clk
Counter
+
Counter O S E R D E S I S E R D E S
REG
REG
M U X
REG
I/O PAD DLY
D E M U X
REG
LVDS
LVDS
Source FPGA
Destination FPGA
LO
In the above HSTDM figure:
The transmission frequency is raised to allow more signals to be transmitted over the same pin (i.e., an asynchronous 100MHz clock generated by an on-board HAPS PLL is distributed to all FPGAs; on each transmitting FPGA the frequency is stepped up to 400MHz via a PLL.
An input multiplexer and an output serializer/deserializer (OSERDES)

running off of both clock edges are used; the corresponding data is transmitted at 800MHz across an LVDS pin pair.
A source-synchronous clock scheme is used with the reference clock

(differential) transmitted along with the serial data (see Source- and System-Synchronous Circuits, on page 248).
The receiving FPGA uses the clock from the source FPGA passed into a
BUFIO and then to a BUFR that divides the clock frequency. The BUFIO-based clock is used by an input serializer/deserializer (ISERDES) that is clocked on both edges to convert the serial input stream to parallel data which is then de-multiplexed with the BUFRbased clock into the final output channels.
Small programmable delay elements are used at the receiving end to

align the data arrival with the clock setup and hold window. The delay values are the result of a training process (see HSTDM (Circuit) Training, on page 244). The reset signal is hijacked by disconnecting the user logic, inserting training logic in between, and reconnecting the user logic to the new reset generated by HSTDM. This is a requirement for using HSTDM. When the global reset is asserted (for example, while programming the FPGAs) and during training, the user design is held in reset.
Transmission pin blocks are in groups of up to 40 pins (20 pin-pairs).

Each pin block structure is source synchronous and is derived from the BUFIO clock structure that reaches the input serializer/deserializer.
Within each I/O pin block, there are four clock-capable pins (2 pinpairs) of which two pins are consumed as clocks for each data transmission direction. With normal one-way transmission, only one pin-pair is used within a pin block and the remaining clock-capable pins are available for data.
High-Speed Time-Domain Multiplexing

High-speed, time-domain multiplexing or HSTDM is available with Synopsys HAPS-5x and HAPS-6x boards. This technique makes use of the HSTDM clock-capable differential pin pairs between send and receive I/O banks to provide both faster multiplexing speeds and increased pin capacity over CPM. The following subsections outline the basic HSTDM flows for:
performing fully automatic HSTDM assignments (see Automatic Assignment, on page 230)
performing manual HSTDM assignments of critical nets/traces with

automatic HSTDM assignment follow up (see Manual Assignment, on page 232)
prioritizing HSTDM assignments over non-HSTDM assignments (see

Prioritizing HSTDM Over Non-HSTDM Assignments, on page 237)
Automatic Assignment
The automatic HSTDM flow is shown in the following figure.
RTL Preparation (HSTDM mode)
Partition Design
Define HSTDM Clock and Reset
Trace Assign Global Reset
SLP Generate
Load Project
LO
Use Run Preparation to compile the netlist and the board file with HSTDM mode enabled (see Enabling HSTDM Mode, on page 241).
Partition the Design

Partition your design. If you are using QPT:
QPT finds solution with HSTDM ratios (highest HSTDM ratio is 128) QPT does not write the CPM output file QPT writes pin assignments for signals that are not HSTDM-compatible Define the HSTDM Parameters
The external HSTDM clock and the global hijacked reset signal must be identified prior to performing HSTDM. Enter the following commands at the Tcl prompt: board_configure -global_reset {globalResetTrace} board_define_attribute {hsdtmClockTrace} syn_hstdm_clk_pin 100 Note that there are no UI equivalents to define these parameters and that the commands must be entered directly in the Tcl window (or through a Tcl script). Also note that a value of 1 is also accepted for the board_define_attribute command to define a 200MHz HSTDM clock for HAPS-5x legacy support.
Trace Assignment
Manual trace assignment of the global reset net for a design is required for automatic HSTDM. Generally, this net is the mb.RESET_n[1] trace on the HAPS board. The global reset net must release all FPGAs following HSTDM training. Note that you can use a custom reset signal provided that it is a global reset for the entire design.
SLP Project Generation

During SLP project generation, HSTDM cells (black boxes) are inserted automatically based on the number of inter-FPGA nets to traces available and HSTDM pin pairs are assigned to the inserted HSTDM cells. Multi-terminal nets, if present, are split into separate 2-terminal nets to create point-to-point connections.
Manual Assignment
The manual HSTDM assignment flow is shown in the following figure. In this flow, critical nets are manually assigned to HSTDM modules and traces, and HSTDM generate is then run to update the database. Manual assignment:
automatically completes any HSTDM assignments validates the manual HSTDM assignments
Partition Design
Define HSTDM Clock and Reset
HSTDM Manual Assignment
HSTDM Generate
hstdm.cpm hstdm.tra hstdm.prt Files
Load Project

QPT finds solution withLO HSTDM ratios (highest HSTDM ratio is 128) QPT does not write the CPM output file QPT writes pin assignments for signals that are not HSTDM-compatible
Define the HSTDM Parameters

The external HSTDM clock and the global hijacked reset signal must be identified prior to performing HSTDM. Enter the following commands at the Tcl prompt: board_configure -global_reset {globalResetPin} board_define_attribute {hsdtmClockTrace} syn_hstdm_clk_pin 100 Note that there are no UI equivalents to define these parameters and that the commands must be entered directly in the Tcl window (or through a Tcl script). Also note that a value of 1 is also accepted for the board_define_attribute command to define a 200MHz HSTDM clock for HAPS-5x legacy support.
HSTDM Module Assignment

To assign critical nets to HSTDM modules: 1. Open the CPM View. 2. Select the HSTDM module type from the CPM Type drop-down menu.
3. Select the nets to be assigned and click the --> button to make the assignment. When making HSTDM module assignments:
HSTDM modules are assigned consecutive names beginning with

CPM_0; once a module is assigned, removing its assignments does not allow the module name to be reassigned.
When assigning multiple nets in a single operation, the selected nets are
assigned to the same CPM module until the capacity of the module is
reached; the additional nets are then assigned to a subsequent module or modules.
Following an assignment operation, additional nets are assigned to a

subsequent HSTDM module even when the module from the previous assignment is not filled to capacity.
Nets can be assigned to an unfilled HSTDM module by selecting the net

or nets and then selecting the HSTDM module before clicking the assign (-->) arrow.
Nets can be unassigned from a HSTDM module by selecting the net

assignment on the module and then clicking the unassign (<--) arrow.
HSTDM Trace Assignment

To assign critical nets to HSTDM traces: 1. Open the Trace Assignment window. 2. Assign the HSTDM CPM nets to HSTDM-capable traces (i.e., traces shown in the trace UI in the HSTDM state). When manually assigning HSTDM CPM nets, be sure enough HSTDM traces are available for the HSTDM clock signals; if there are not enough HSTDM clocks available, an error results. Always check for warning messages when manually assigning HSTDM nets to traces. Traces are not considered to be HSTDM-capable when:
there are no suitable, clock-capable traces in the same I/O bank the trace is connected to an in-board level shifter the electrical properties of the trace make it unsuitable for HSTDM
A board_list Tcl command option is available to query individual traces for HSTDM compatibility using the following syntax: board_list -hstdm_compatibility_info_of traceName The command returns the pin status of traceName such as there are no suitable clock-capable traces in the same IO bank to indicate an incompatibility or HSTDM OK to indicate a compatible trace. LO
Run HSTDM Generate

HSTDM generate is run to perform automatic net/trace assignments (including auto-HSTDM) to create a design baseline that includes any constrained nets/traces. Running HSTDM generate also reserves clockcapable traces and several additional traces required during the HSTDM training sequence. To run HSTDM generate, right-click on the Do HSTDM Assignments block in the flow diagram and select Run from the popup menu or enter the following Tcl command: hstdm_generate Running HSTDM generate creates new *_hstdm.cpm, *_hstdm.tra, and *_hstdm.prt text files that allow you to confirm or edit the automatic HSTDM assignments. Trace assignments within an I/O bank are made in either the transmit or receive direction, and directions are not mixed. You must explicitly source these HSTDM files. If you are satisfied with this automatic output, no changes are necessary. If you require minor modifications, manually edit these files using a text editor. Note that SLP projects are not generated by HSTDM generate and that SLP generate must be explicity executed. If no other non-HSTDM assignments are required, SLP generation is now performed. Otherwise, make any non-HSTDM CPM/Trace assignments before SLP generation.
SLP Generate
The SLP generate step is entered directly after partitioning when auto HSTDM assignment is used exclusively for trace assignment and includes the HSTDM generate phase. When using manual assignment to define system-critical signals in combination with automatic assignment, only the HSTDM generate phase is run to produce the tra, cpm, and prt files for manual editing. When generating an SLP project, HSTDM cells (black boxes) are inserted automatically based on the number of inter-FPGA nets to traces available. Multi-terminal nets are split into separate 2-terminal nets to create point-topoint connections, and HSTDM pin pairs are assigned for the inserted HSTDM cells.
Post SLP Synthesis

If the srp file is opened immediately after SLP generation, the post-HSTDM inserted netlist is displayed, but the HSTDM cells appear as black-boxes. To replace the black-box cells with logic, the individual SLP projects must first be synthesized in Synplify Premier before the inserted logic can be viewed in the HDL-Analyst technology view. To view the post-HSTDM inserted netlist: 1. After partitioning your design, run SLP Generate. 2. Run synthesis for the individual SLP projects using Synplify Premier. 3. Open the technology view netlist (srm) file for the individual SLP projects to view the post-HSTDM inserted netlist.
LO
Prioritizing HSTDM Over Non-HSTDM Assignments

Prioritizing HSTDM assignments over non-HSTDM assignments involves constraining specific nets/traces prior to running HSTDM generate.
Partitioning
SLP Generate Constrain Traces HSTDM Generate SLP File Generation
.cpm
CPM Assignment hstdm.cpm hstdm.tra hstdm.prt Files
.tra
Trace Assignment
Load Project

QPT finds solution with HSTDM ratios QPT does not write the CPM output file QPT writes pin assignments for signals that do not use HSTDM
Define the HSTDM Parameters

The external HSTDM clock and the global hijacked reset signal must be identified prior to performing HSTDM. Enter the following commands at the Tcl prompt: board_configure -global_reset {globalResetPin} board_define_attribute {hsdtmClockTrace} syn_hstdm_clk_pin 100 Note that there are no UI equivalents to define these parameters and that the commands must be entered directly in the Tcl window (or through a Tcl script). Also note that a value of 1 is also accepted for the board_define_attribute command to define a 200MHz HSTDM clock for HAPS-5x legacy support.
Constrain Nets/Traces
If you are using manual HSTDM assignment (or a combination of manual and automatic assignment), you can restrict the design nets/traces that can be considered for HSTDM assignment in advance by defining the nets that are not eligible to be multiplexed. Additionally, you can reserve traces for any signals that are not to be used for HSTDM. Nets are disqualified from HSTDM (and CPM) assignment using the following option of the cpm_configure command: cpm_configure -disqualify_net {listofNets} Similarly, traces are reserved using the following option of the board_configure command: board_configure -reserve -trace {listofTraces} Nets and traces that are not to be considered for HSTDM are marked during this phase to allow HSTDM assignments to performed by HSTDM generate; the reserving of nets/traces for non-HSTDM assignment is done later. At this point, you can either:
perform full automatic HSTDM assignments by selecting HSTDM

generate
perform some manual HSTDM assignments and/or non-HSTDM assignLO

ments before automatic HSTDM clean-up using CPM/Trace assignment
Run HSTDM Generate

HSTDM generate is run to perform automatic net/trace assignments including auto-HSTDM to create a design baseline including any constrained nets/traces. To run HSTDM generate, right-click on the Do HSTDM Assignments block in the flow diagram and select Run from the popup menu or enter the following Tcl command: hstdm_generate Running HSTDM generate generates new *_hstdm.cpm, *_hstdm.tra, and *_hstdm.prt text files that allow the you to confirm or edit the automatic HSTDM assignments. You must explicitly source these HSTDM files. If you satisfied with this automatic output, no changes are necessary. If you require minor modifications, manually edit these files using a text editor. If no other non-HSTDM assignments are required, SLP generation is now performed. Otherwise, make any non-HSTDM CPM/trace assignments before running SLP generation.
Perform CPM/Trace Assignment

CPM/trace assignment is used to perform the following tasks:
Manual/automatic CPM assignment Manual assignment of critical nets to HSTDM modules Manual/automatic trace assignment of non-HSTDM traces Manual HSTDM trace assignment
If you are using manual HSTDM assignment (or a combination of manual and automatic assignment), manually assign HSTDM nets and qualified traces for your system-critical signals as outlined in the following sections. Note: You can also make any CPM assignments at this time.
Configuring the Board Definition Files

Before you can use HSTDM with a HAPS-5x series board, make sure to configure the $LIB/board/haps-5x.vb file for:
a global reset to act as the supervisor reset to all FPGAs a distributed, 100MHz (or 200MHz) clock to all FPGAs that will use
HSTDM The following reset and clock configuration parameters are basic definitions for the reset and clock: defparam mb.reset_cfg = 4'b0000 ; defparam mb.clk_cfg = 44'h1111_1000_000 ;
Configuring the HAPS Board

The following switch settings and connections can be used to configure your HAPS-5x series board for HSTDM using the on-board PLL and a 100MHz clock.
Configure the OSC DIP switches for a 100MHz onboard clock (M = 25,
N= 1; switches 4, 5, and 8 ON when using a 16MHz reference oscillator or M=24, N=1; switches 4 and 5 ON when using a 16.67MHz reference oscillator)
Connect the 100MHz oscillator output to the on-board PLL input Configure the SETUP DIP switches for single-ended PLL in closed-loop
mode (switch 3 = OFF, switches 7, 8, and 9 = ON)
Connect the PLL output to the configured GCLK input (i.e., GCLK[5])
HAPS-5x series boards require the connection of a 100MHz (or 200MHz ) common clock signal as the global clock for all FPGAs that use HSTDM. HAPS-6x series boards automatically select the 100MHz global clock. For specific information, see the corresponding HAPS mother board documentation. LO
Clocking Schemes
When using HSTDM, all HSTDM clocks are derived from the on-board 100MHz clock and are intended to be asynchronous with the design logic. If you also use the same 100MHz (or 200Mhz) base clock in your design, the paths between the design logic and the HSTDM interface can become incorrectly timed when the timing analysis tools (Synplify and ISE) consider the design and HSTDM clocks to be synchronous. These paths should be considered as false paths; the estimate_timing -budgets command correctly times the paths from the design to the HSTDM transmit interface and from the HSTDM receive interface to the user design and supplies time-budgeting information for the paths, overriding any false paths as necessary. When setting up the HSTDM clocks:
If possible, avoid using the 100MHz clock for your design logic. If you must use the 100MHz clock for your design logic, constrain each
of your design clocks (rather than letting them be automatically constrained based on the MMCM/PLL parameters or other methods), and make sure that the design clocks are always in a different clock group from the 100MHz clock. The following example shows a set of sdc file entries defining separate clocks and clock groups. # # Clocks # define_clock {clk} -name {clk} -freq 100 -clockgroup clkgroup_100MHz define_clock {n:clkv[0]} -name {clkv0} -freq 30 -clockgroup grp1 define_clock {n:clkv[1]} -name {clkv1} -freq 21.8181 -clockgroup grp2 define_clock {n:clkv[2]} -name {clkv2} -freq 20 -clockgroup grp1 define_clock {n:clkv[3]} -name {clkv3} -freq 10.9090 -clockgroup grp2 define_clock {n:clkv[4]} -name {clkv4} -freq 10 -clockgroup grp1
Enabling HSTDM Mode

High-speed, time-domain multiplexing is off by default; any multiplexing of pins is accomplished through standard CPM. When the HSTDM mode is enabled, all of the HAPS board HSTDM clock-capable pins are reserved for automatic HSTDM pin assignment.
Note: Once enabled, to use any of these reserved pins for other assignments (for example, CPM assignment), the pins must be explicitly cleared with a board_configure -clear -trace command. To enable HSTDM mode from the graphical interface, select Load Database in the Partition Management section to display the Load Prototyping Files dialog box and enable the Enable High-Speed TDM check box before loading the prototyping files with the Load All button.
To enable HSTDM mode from a Tcl command, include an -hstdm option with a load_board command: load_board -hstdm haps-5x.srs Note: Use the Tcl command to change the HSTDM mode setting after the board srs file is loaded from the UI.
LO
Sample Tcl Script

The following is an example Tcl script for running automatic HSTDM. # Load project and compile project -load proj.prj project -run rtl_prep # Load board in HSTDM mode load_board -hstdm haps-54.srs # Load compiled netlist load_netlist test.srs # Partition design manually logic_place -assign {F1} -device {mb.uA} logic_place -assign {F2} -device {mb.uB} # Trace assign fast clock(100Mhz) for HSTDM and reset. This # is same as the one defined in the board file. This trace # assignment is compulsory board_define_attribute {mb.RESET_n[1]} syn_hstdm_reset_pin 1 board_define_attribute {GCLK_OUT_a[1]} syn_hstdm_clk_pin 100 # Generate post partition netlist partition_save -database test.srp # Run SLP projects using 'slp_generate' which will insert # automatically HSTDM CPM slp_generate test.srp
Output/Report Files
Auto HSTDM insertion is summarized in the slpgen.srr file. The /synthesis_files/mb_device/mixed/mb_device_hstdmreport.txt file:
Lists all differential pairs used for HSTDM Gives a summary of the total number of HSTDM channels
The following is an example of an mb_device_hstdmreport.txt file: -------------------------------------------------------3: Pin pair AK30-AJ30: transmit data (ratio 8x), tap=8 Totals: Transmit: 608 bits transmitted over 70 LVDS pin pairs with 14 pin pairs used as clocks Receive: 0 bits received over 0 LVDS pin pairs with 0 pin pairs used as clocks End High Speed TDM report --------------------------------------------------------
HSTDM (Circuit) Training

When performing HSTDM, Certify uses a programmable delay element on the receiving side of the HSTDM data. Before actual design data is transmitted on an HSTDM channel, a known data pattern is transmitted to determine the range of programmable delay. Once this range is determined, the programmable delay element is set to the mid-value of the range. The process of setting this HSTDM delay is termed training.
Training occurs after power up and system reset is released. All design elements using system reset are reconnected to the hijacked
reset signal.
During training, known HSTDM training data is sent in place of design

data to set the data eye correctly.
Training is done on a per HSTDM channel basis. Until all HSTDM channels are trained, the hijacked reset is asserted to
hold the design in the reset state.
A single FPGA (called Root) collects all the training done signals from all
FPGAs on the board and then releases the reset for the design.
Training Status
Training status for the receivers in an FPGA can be verified by reading the LO I2C status register in each FPGA. During synthesis, the chip ID and the hstdm I2C slave address are reported in the chip fpga_hstdm_report.txt file. The following is an example of a HSTDM report file.
Each receive pin pair has four bytes of data: Address Pin_base + 00 Pin_base + 01 Pin_base + 01 Pin_base + 03 Value 4-bits pin training status; 4-bits bitslip value Idelay setting for start of eye Idelay setting for end of eye HSTDM ratio
Pin training status can have any of the following values:
0x0: not (yet) trained Training on this pin never started. If all pins are in this state, it
usually means that the clock is not connected. If the reset is not connected, uninitialized data (0xFF) would be present rather than 0. If there is an error in some pins, training is stopped, and the
remaining pins will be in this state. In this case, look at the error on the earlier pin.
0x1: training successful 0x8: centering step failed Unusual error message. Both the start and end of stable data were
found, but the data was incorrect or unstable in the middle of the eye.
0x9: never found unstable data In case the start (tap==0) is in the middle of a stable region, the
trainer increments idelay until it first encounters unstable data. If the region is not large enough, the trainer goes to the next eye. This error usually indicates there is no signal coming from the trainer which could indicate a pin assignment error or a disconnected clock on the trainer.
0xA: never found stable data After finding unstable data, the trainer increments the idelay tap
until it again finds unstable data followed by stable data. This error indicates possible noise or dissimilar clock periods for the trainer and receiver.
0xB: eye too small: less than 5 taps Unusual in production. During development, erroneous doubleincrementing the tap values was observed which resulted in the start and end of stable data being too close together. It is unlikely that we will be able to send data reliably. This could be from some other pin causing noise in the middle of the stable pin, but we've never seen this. To access the status of a pin pair for an FPGA, enter the following example commands in the supervisor interface (see I2C Registers and Commands, on page 247). wfpga a0 00 02 Write FPGA A0 is the chip ID for the FPGA. Address location 0 writes the upper address bytes of the address. In this case, the upper address byte is 0x02 which sets the pin base to 0x0200. LO In the following example command rfpga a0 00 04
Read FPGA A0 is the FPGA I2C slave address for the FPGA, and 00 specifies the lower address byte to be used for the read. 04 specifies four bytes to be read in order to access all of the status bytes for the receive pin pair. Repeat the I2C procedure above and verify that all channels on all FPGAs are trained.
I2C Registers and Commands

The following supervisor commands are used to read/write to FPGA. Note: Version 1.5 or later of the HAPS supervisory software is required to access the HSTDM training registers.
Read FPGA
The I2C command to read data from an FPGA has the following syntax: RFPGA fpgaAddress internalAddress numberBytes In the command syntax, fpgaAddress is the I2C address (A0-D0) that specifies the target FPGA for the read. InternalAddress is a 1-byte address specifying the starting internal address of the read. NumberBytes is the number of consecutive bytes to read. All output values are in HEX, concatenated on a single output line in silent mode, and as address:value pairs on separate lines in verbose mode. All parameters are in 2-digit HEX format.
Write FPGA
The I2C command to read data from an FPGA has the following syntax: WPFGA fpgaAddress internalAddress data1 [dataN ...] In the command syntax, fpgaAddress is the I2C address (A0-D0) that specifies the target FPGA for the write. InternalAddress is a 1-byte address specifying the starting internal address of the write. Data is the stream of byte values in hex written to consecutive addresses beginning with internalAddress. All output values are in HEX, concatenated on a single output line in silent mode, and as address:value pairs on separate lines in verbose mode. All parameters are in 2-digit HEX format.
Source- and System-Synchronous Circuits

System-synchronous circuitry in time-delay multiplexing is the traditional technique of providing a clock from a third device to both the transmitter and the receiver logic. Source-synchronous circuitry, as used in HSTDM, sources a clock along with the data. Specifically, the timing of unidirectional data signals is referenced to a clock (often called the strobe) sourced by the same device that generates those signals, and not to a system-synchronous global clock.
Clock
System-Synchronous Circuit
DATA Device 1 DATA Device 2
DATA DATA Device 3
Clock
Source-Synchronous Circuit
Device 1 TX
CLK1 DATA
Device 2 RX TX
CLK2 DATA
Device 3 RX
Advantages of Source-Synchronous Clocking

A fundamental reason that source-synchronous HSTDM clocking has proven advantageous stems from the fact that all of the circuits within a given semiconductor device experience roughly the same process-voltage-temperature (PVT) variation. In other words, the signal propagation delay experienced by the data through a device parallels the delay experienced by the clock through that same device. This fact allows higher speed operation as compared to the traditional technique of providing the clock from a third LO device to both the transmitter and receiver as with CPM. Large systems that take advantage of source-synchronous clocking can have the benefit of a higher tolerance of PVT variation of its individual components.
A limiting factor in achieving high performance is the sum of all of the delays applied to a signal before it reaches its destination. This signal delay is calculated by summing the logic and trace delays and then adding the setup- and hold-time delays combined with the signal integrity factors such as slew rate, attenuation, and crosstalk. The combination of all of these individual delays limits the system synchronous clocking method to an upper limit of between 100 and 200MHz depending on the trace delays on the board. With source-synchronous clocking, a much higher data rate is realized when a local clock is sent with the data to clock the receiving I/O registers. The higher speed allows more bits to reach their destination within the global synchronous system clock period and a higher pin multiplexing factor to be used.
Single-ended and Differential Signaling

In single-ended signaling, the transmitter generates a single voltage that the receiver compares with a fixed reference voltage, both relative to a common ground connection shared by both ends. Differential signaling is a method of transmitting information electrically by means of two complementary signals sent on two separate wires. Electrically, the two seesaw waveforms are replaced by a pair of wires labeled V+ and V-. When V+ is greater than V-, the signal is defined as positive, while when V+ is less than V-, the signal is defined as negative.
Virtex-5 Resources
The Virtex-5 resources supporting HSTDM include
Special Buffers, on page 249 I/O Resources, on page 250 Special Buffers
HSTDM takes advantage of two special Xilinx Virtex-5 buffers: BUFIO and BUFR. The BUFIO buffer:
drives a dedicated clock net within an I/O column, independent of the

global clock resources
can only be driven by clock capable I/Os located in the same clock
region
cannot drive logic resources (CLB, blockRAM, I/Odelay, etc.)

The BUFR buffer:
drives clock signals to a dedicated clock net within a clock region drives I/O logic and logic resources (CLB, blockRAM, etc.) in the existing
and adjacent clock regions; BUFRs can be driven by clock-capable pins or local interconnect.
is capable of generating divided clock outputs with respect to the clock

input; the divide values are integers between 1 and 8.
I/O Resources
The Virtex-5 device I/O resources or I/O tiles include the following:
Two IOBs Two ILOGICs (input serializers/deserializers) Two OLOGICs (output serializers/deserializers) Two I/O delay blocks
Each IOB contains Input, output, and 3-state select-I/O drivers configured to various I/O standards.
Differential I/O uses the two IOBs Single-ended I/O standards (LVCMOS, LVTTL, HSTL, SSTL, GTL, PCI) Differential I/O standards (LVDS, HT, LVPECL, BLVDS, and Differential
HSTL and SSTL) Each output serializer/deserializer module includes:
A dedicated serializer for data A 3-state control.

Both data and 3-state serializers can be configured in SDR or DDR mode. LO Data serialization can be up to 10:1 by cascading a second IOSERDES used in the IOB pair when using the default LVDS differential I/O standard.
Each input serializer/deserializer module includes:
Dedicated deserializer/serial-to-parallel converter supports both single

data rate (SDR) and double data rate (DDR) modes.
in SDR mode, the serial-to-parallel converter creates a 2-, 3-, 4-, 5-,
6-, 7-, or 8-bit wide parallel word.
in DDR mode, the serial-to-parallel converter creates a 4-, 6-, 8-, or

10-bit-wide parallel word.
Bitslip submodule allows designers to reorder the sequence of the

parallel data stream going into the FPGA
Dedicated support for strobe-based memory interfaces handles the

strobe-to-FPGA clock domain crossover entirely within the input serializer/deserializer Each I/O delay block includes:
a 64-tap, wraparound, delay element with a calibrated tap resolution

than can be applied to the combinational input path, registered input path, combinational output path, or registered output path
IODELAY allows incoming signals to be delayed on an individual

basis
IDELAY can be zero, fixed, or variable ODELAY is fixed. IODELAY is mixed (i.e., IDELAY fixed/ODELAY fixed or IDELAY
var/ODELAY fixed)
Certify Pin Multiplexing
Certify Pin Multiplexing

Certify Pin Multiplexer or CPM is a Certify tool feature that you use to reduce the number of I/O pins required between FPGAs. CPM applies a Time Domain Multiplexing (TDM) technique to reduce FPGA pin count. With CPM, pre-defined TDM modules are added to a design to provide the multiplexing capability. These modules include the requisite control logic and can operate either asynchronously or synchronously to the design. The following diagram shows the architecture for Synchronous CPM between two FPGAs.
SND
RCV
SND CTRL
SND
RCV
RCV CTRL
OFF-CHIP RCV CTRL
FPGA1
FPGA2
RCV
SND
RCV CTRL
RCV
SND
SND CTRL
OFF-CHIP SND CTRL
Asynchronous CPM example modules, in a range of ratios, are automatically compiled with the design (asynchronous CPM modules are used exclusively by QPT). Synchronous modules, which are based on clock domains, require much tighter net qualification. These modules must be explicitly added to the project and compiled with the design. The use of CPM may result in LO additional timing overhead and some area penalty.
V V
CPM Assignment User Interface
Before making any CPM assignments, a design must be fully partitioned. Netto-trace assignments should be done only after CPM assignment because the logical nets that cross FPGA boundaries will change. Synchronous and additional asynchronous module types can be created and made available by adding them to the project and compiling them with the design files.

The CPM Assignment user interface is accessible only after a design has been completely partitioned. To access the interface, click the CPM View button in the Project view or click the Open CPM icon in the menu bar. The user interface supports both synchronous and asynchronous CPM module types. The asynchronous CPM user interface lists the available nets between FPGAs within a domain that can be multiplexed, and the synchronous CPM user interface lists all of the qualified nets among the FPGAs that can be multiplexed based on clock-group information in the sdc file. Both interfaces allow automatic net assignment to multiple CPM modules of the same module type and manual net assignment to individual CPM modules. The set of assigned nets and corresponding CPM modules is referred to as the CPM group.
CPM Assignment Dialog Box

The nets are displayed by source FPGA and sorted by domain in the CPM nets display area. You select different source FPGAs from the tree view on the left side of the dialog box. The destination FPGA or FPGAs are displayed for each eligible net in the Nets section. The net qualification criteria is selected by the radio buttons along the top of the dialog box.
Module Types
The CPM Type field above the net display area lists the available CPM module types. With the asynchronous interface, the available modules range from 2 to 20 inputs in incremental steps and a 32-bit input. With the synchronous interface, the CPM modules are user-defined (see Synchronous CPM Module Types, on page 261).
LO
CPM Net Qualification

For the asynchronous interface, nets are qualified as usable if:
the net is not connected to a top-level design port the net is not connected to a system-level black box a register is available on the receiving side
For the synchronous interface, nets are qualified as usable based on the clock driving the net. The default net qualification criteria are:
The net exists at the board level and is connected only to FPGAs. Nets
connected to top-level ports or connectors do not qualify; nets connected to system-level black boxes can qualify if marked as sequential (see Black-Box Net Qualification, on page 256).
The net path must originate from a synchronous element (source FPGA)
and end at a synchronous element (the destination FPGAs). Synchronous elements include flip-flops, latches, synchronous memories, sequential instantiated technology primitives, and black boxes explicitly marked as sequential (see Black-Box Net Qualification, on page 256).
The synchronous elements at the start and ends of the path must be
clocked by the same base clock or a clock derived from the base clock. CPM is conservative when qualifying nets for the synchronous interface because, depending on the circuit functionality of the CPM module, improperly assigned nets will result in non-functioning logic. QPT, when using CPM information within its run, only supports end@seq net qualification criteria internally. Any net capable of using CPM within QPT is based on the end@seq qualification criteria regardless of the Net Qualification Criteria setting.
Black-Box Net Qualification

Synchronous CPM also supports net qualification for user-defined black boxes that are marked as sequential. Additionally, each of these black boxes must have a single clock and clock enable. Below is a Verilog example of a black box with the required attributes. Users must ensure the logical accuracy of the CPM-assigned nets associated with their black boxes. module bb (clk, data_in, data_out) /* synthesis syn_black_box */ /* synthesis syn_force_seq_prim="clk" */ ; input clk; input [8:0] data_in; output [8:0] data_out; endmodule
Unqualified Nets
Nets that do not meet the normal synchronous selection criteria can be assigned to asynchronous CPM groups.
LO
Automatic assignment is available with the asynchronous interface. With automatic assignment, all unassigned qualified nets for all clock groups are assigned to the selected (active) CPM module type. To automatically assign nets to CPM groups: 1. Select the CPM module type desired or the specified CPM ratio specified by QPT from the CPM Type drop-down list. 2. Click Auto Assign. Automatic assignment can be used after doing partial manual assignment to assign any remaining nets. Automatic assignment does not affect any existing assigned groups. Note: Automatic assignment only uses the selected CPM module type to create the CPM group. If multiple CPM module types are needed within the group, you must use manual assignment.
Manual Assignment
To manually assign nets to a CPM module: 1. Open the CPM Assignment window and in the Net Qualification Criteria section at the top of the window, click the End@Seq radio button to restrict net selection to only the nets that end at a sequential element (select Start and End @Seq if you are using synchronous CPM modules). 2. In the All Qualified FPGAs area at the left side of the window, click on the desired FPGA in the tree view.
Manual Assignment
Selecting an FPGA expands the CPM Assignment window to include a list of the eligible CPM nets.
3. Select the CPM module type desired from the CPM Type drop-down list. 4. Select one or more nets from the CPM nets display area. You can use the keyboard Shift and Control keys to select multiple nets. 5. Click the --> button in the center of the window to assign the selected nets to a CPM module on the right. As shown in the figure below, the nets are assigned to the CPM modules. The other fields show the area requirements for the module and the modules capacity and type.
When manually assigning nets to asynchronous CPM modules:
CPM modules are assigned consecutive names beginning with CPM_0;

once a module is assigned, removing its assignments does not allow the module name to be reassigned. LO
When assigning multiple nets in a single operation, the selected nets are
assigned to the same CPM module until the capacity of the module is
Manual Assignment
reached; the additional nets are then assigned to a subsequent module or modules.
Following an assignment operation, additional nets are assigned to a

subsequent CPM module even when the module from the previous assignment is not filled to capacity.
Nets can be assigned to an unfilled CPM module by selecting the net or

nets and then selecting the CPM module before clicking the assign (-->) arrow.
Nets can be unassigned from a CPM module by selecting the net assignment on the CPM module and then clicking the unassign (<--) arrow. Note: You cannot move a net directly from one module to another. To move a net, remove the net from its current module and add it to the new module.
To remove all the nets from a CPM module, select the module and click
<- to return the nets to the CPM nets display area. Note: The Certify software does not prevent the creation of modules with only a single net assignment. Review all of your module assignments and remove any single-net modules or assign additional nets to the module.
Updating Assignments
After completing all of the CPM net assignments, select File->Save Prototyping Files to display the Save Prototyping Command dialog box and then save the cpm file.
CPM Fast Clock Estimator
CPM Fast Clock Estimator

The CPM fast clock estimator estimates the CPM clock frequency after CPM insertion. To use this tool: 1. After CPM insertion, invoke the CPM fast clock estimator either from the UI by selecting Tools -> CPM Fast Clock Estimator and entering the name of the partitioned netlist file in the dialog box
or by entering the following Tcl command: estimate_cpm_clock_frequency partitionedNetlist Either action generates:
a log file (netlistName_cpm_clk_est.srr) that contains a range (min.

period - max period) for the CPM fast clock.
an sdc file (cpm_clocks.sdc) with the CPM clock net.

2. Select a frequency from within the range specified in the log file and enter the frequency in the sdc file. As a general rule-of-thumb, a CPM module requires n +1 fast CPM clock cycles (where n is the multiplexing ratio) for transferring data between FPGAs, and one additional clock cycle is required for asynchronous CPM operations. As an example, with a CPM ratio of 4 in a design running successfully at 10MHz without CPM, the CPM clock frequency would be set to a minimum of 50MHz. 3. Add the sdc file to your project and run estimate timing to generate time budgets. The input netlist used is the srp netlist after CPM insertion and SLP generation as this file includes all of the CPM and trace assignment information. LO
Creating Custom CPM Modules

CPM module descriptions consist of a number of specialized modules or entities. More than one CPM module type can be used within a design.
Synchronous CPM Module Types

Synchronous CPM module types can be user-defined or developed from one of the Certify-supplied examples in the examples/verilog/cpm or examples/vhdl/cpm directory. The following steps outline CPM flow with synchronous modules: 1. Define the synchronous CPM module or modules to be used in the design. 2. Add the HTL description file for each synchronous CPM module type to your project. 3. Specify the clock and clock group information in a constraint (sdc) file. 4. Use Run Preparation to compile your design with your user-defined CPM module and constraint file. 5. Partition your design and save the post-partition (srp) file. 6. Run estimate timing to extract the clock-related information using the following command syntax: estimte_timing -cpm partitionFile.srp 7. Load the timing-estimation (est) file into the database using the following command syntax: load_estimate_file -timing estimationFile.est 8. Open the CPM interface, select Start and End@Sequential Element as the net qualification criteria, and select Synchronous. 9. Perform CPM assignment using the synchronous CPM modules in the CPM Type pull-down list. 10. Save the CPM file and the post-partitioned netlist (srp) file. To view CPM module insertion, select HDL-Analyst->RTL->Partitioned RTL.
Asynchronous CPM Module Types

A range of asynchronous CPM module types from 2-input to 20-input in incremental steps and a 32-bit are included by default. Additional synchronous CPM module types must be user-defined. The RTL description file for any new asynchronous CPM module type must be added directly to the project before compiling the design. Note: To distinguish between Verilog and VHDL instantiated modules, a _v suffix is required for the module name specified with the syn_cpm_type directive when defining an asynchronous CPM module in Verilog.
LO
CPM Modules or Entities

Every CPM module type must include the following five CPM blocks (modules or entities) using the following syn_implement directive values:
cpmsnd sending block that performs TDM compression of nets cpmsnd_onchip_control internal control block connected to all cpmsnd
blocks
cpmrcv receiving block that performs TDM uncompression of nets cpmrcv_onchip_control internal control block connected to all cpmrcv
blocks
cpmrsc_offchip_control external control block connected to the

cpmsnd_onchip_control and cpmrcv_onchip_control blocks; intended for external clocks and control signals when a common off-chip control block is used with both the send and receive blocks Individual cpmsnd_offchip_control and cpmrcv_offchip_control external control blocks can be used in place of the cpmrsc_offchip_control block when the same off-chip control is not used by both the send and receive blocks. The CPM blocks are automatically inserted into the post-partitioned (premapped) RTL view when the CPM assignments are made (when you click OK).
The cpmrsc_offchip_control block (or individual cpmsnd_offchip_control and

cpmrcv_offchip_control blocks) is at the top level
The cpmsnd and cpmsnd_onchip_control blocks are inserted into the source
FPGAs
The cpmrcv and cpmrcv_onchip_control blocks are inserted into all destination FPGAs The CPM nets are inserted at the board level.
CPM Block Communications

The diagram below shows the relationships among the various CPM blocks. The following table defines the communications interface requirements for each block. The letter in parentheses following the port description shows the port location in the figure.
Send A SEND C H RECEIVE J Receive rcvData
D SEND ON-CHIP E
B sndData
RECEIVE ON-CHIP L
SEND/RECEIVE OFF-CHIP F SEND OFF-CHIP RECEIVE OFF-CHIP M
Table 8-1: CPM Block Communications Interface SEND (cpmsnd) can optionally have only one each of:
input port with syn_cpm_control input port with no attributes output port
sndIn (A) sndData (B) sndOut (C)
SEND ON-CHIP (cpmsnd_onchip_control) can optionally have only one each of:
input port with syn_cpm_system_clock input port with syn_cpm_srcontrol input port with no attributes output port with syn_cpm_srcontrol output port with no attributes LO
sndOnChipIn (E) sndOnChipOut (D)
Table 8-1: CPM Block Communications Interface RECEIVE (cpmrcv) can optionally have only one of:
input with syn_cpm_control input with no attributes output port
rcvInCtrl (G) rcvIn (H) rcvData (J)
RECEIVE ON-CHIP (cpmrcv_onchip_control) can optionally have only one of:

input port with syn_cpm_system_clock input port with syn_cpm_srcontrol input port with no attributes output port with syn_cpm_srcontrol output port with no attributes
rcvOnChipIn (L) rcvOnChipOut (K)
RECEIVE OFF-CHIP (cpmrcv_offchip_control)

only one output port no check for input ports
rcvOffChipOut (M)
SEND OFF-CHIP (cpmsnd_offchip_control)

only one output port
sndOffChipOut (F)
SEND/RECEIVE OFF-CHIP (cpmrsc_offchip_control)

[used for both send/receive off-chip modules] only one output port no check for input ports
sndOffChipOut
When defining the individual blocks, the widths of the following ports must match: sndIn = sndOnChipOut sndOnchipIn = sndOffChipOut sndOut = rcvIn sndData = rcvData rcvData >= 2 rcvInCtrl = rcvOnChipOut rcvOnchipIn = rcvOffChipOut
CPM Directives and Attributes

The following directives and attributes are used in the modules/entities that define a CPM module type:
syn_asynchronous_cpm syn_cpm_control syn_cpm_srcontrol syn_cpm_system_clock syn_cpm_type syn_implement syn_preserve syn_hier
syn_asynchronous_cpm Directive
The syn_asynchronous_cpm directive identifies a CPM block as being asynchronous. Each block that describes an asynchronous CPM module type must include this directive.
Data Type and Value:

Boolean: 1 (true)
Example:
module Async4_send_control (fast_clk, send_control, cpm_sync) /* synthesis syn_cpm_type="Async4_v" syn_implement="cpmsnd_onchip_control" syn_asynchronous_cpm=1 */;
syn_cpm_control Directive LO
The syn_cpm_control directive is used in the send and receive blocks to identify the input control signal within the block itself.

Boolean: 1 (true)
Example:
input [RON-1:0] c /* synthesis syn_cpm_control=1 */;
syn_cpm_srcontrol Directive
The syn_cpm_srcontrol directive is used in asynchronous send control and receive control blocks to identify the input/output control signal connection between on-chip control blocks.

Boolean: 1 (true)
Example:
input [RON-1:0] c /* synthesis syn_cpm_srcontrol=1 */;
syn_cpm_type Directive
The syn_cpm_type directive is used in all blocks to identify the name of the module type (the name that appears in the CPM Type field in the CPM Assignment menu).
Data Type and Values:

String: any value enclosed in quotes
Example:
/* synthesis syn_cpm_type="shftreg8" */; Note: The type name of the directive must be identical for all six blocks.
syn_cpm_system_clock Directive
The syn_cpm_system_clock directive is used in synchronous send and receive blocks to identify the clock signal within the block itself.

Boolean: 1 (true)
Example:
input clk /* synthesis syn_cpm_system_clock=1 */;
syn_implement Directive
The syn_implement directive identifies each of the blocks that make up a CPM module type.

String: predefined value enclosed in quotes; values are cpmsnd, cpmsnd_onchip_control, cpmsnd_offchip_control, cmprcv, cmprcv_onchip_control, cmprcv_offchip_control, and cpmrsc_offchip_control.
Example:
<module_declaration> /* synthesis syn_implement="cmpsnd" */;
syn_preserve Directive
The syn_preserve directive is used in all blocks to prevent any of the CPM logic from being optimized away.

Boolean: 1 (true) LO
Example:
<module_declaration> /* synthesis syn_preserve=1 */;
CPM Requirements
syn_hier Attribute
The syn_hier attribute is used in the send and receive blocks to preserve their design-unit interface.

String: predefined value hard enclosed in quotes
Example:
<module_declaration> /* synthesis syn_hier="hard" */;
CPM Requirements
The following requirements are imposed on CPM designs:
Verilog or VHDL RTL source code containing CPM blocks for the CPM
module type
The CPM module type and the top-level module or entity must be in the
same language (the Certify-supplied CPM module types in the examples/cpm directory are available in both VHDL and Verilog)
Special directives required for each CPM block definition Control signal buses must match among CPM blocks External or internal sources of CPM over-sampling clock and control
signals
CPM Design Considerations

Consider the following factors when using CPM:
Performance Area Additional pin count Global routing resources
Performance
Multi-FPGA partitioning generally results in a decrease in maximum frequency compared to a single FPGA prototype because the paths between FPGAs most often become the critical paths. This effect is multiplied when using CPM because paths must satisfy setup requirements within a fraction of the original clock period. If the CPM net is the critical path, the minimum system period is calculated by taking the worst-case, clock-to-setup path for each device and multiplying it by the amount of over-sampling being done by the CPM element. For this reason, using CPM on a critical path should be avoided. The speed decrease can be severe for CPM elements that multiplex a large number of nets together, but the benefit is that CPM allows easier creation of partitions and the ability to put more logic into each FPGA.
Area
The amount of logic added by CPM is dependent on the CPM module type and the number of CPM groups being created. The amount of logic compared to the size of an FPGA targeted for partitioning is normally relatively small.
LO
Additional Pin Count

Depending on the CPM module type and FPGA architecture, CPM may add several pins to the FPGA to connect externally supplied clocks and control signals from the cpmrsc_offchip_control block (or cpmsnd_offchip_control and cpmrcv_offchip_control blocks).
Global Routing Resources

Depending on the CPM module type and clock groups, one or more additional clocks may be added to an FPGA, requiring global clock routing resources. If FPGA global resources are not available, the clock signals will not be included in the global clock routing. Global control signals, if skew sensitive, may also require high-speed routing resources. If an FPGA uses multiple CPM module types, the resource requirements go up accordingly.
LO
CHAPTER 9
HAPS Clock Synchronization

Proper clock synchronization is essential in any ASIC design. Multi-FPGA designs increase the complexity of clock synchronization significantly. The remainder of this chapter proposes a standard flow for converting clocks in a HAPS-based ASIC design into an implementation that functions correctly in a multi-FPGA environment. The flow uses Certify-specific IP and utilizies design techniques to avoid potentially fatal problems such as hold time violations and clock synchronization errors that can be present with other clock generation schemes. The current Certify release provides a tool set and a standard flow for performing the complex clock conversion including support for differential clocks as found on the HAPS-6x series boards.
Clocking Problems
There are two potential problems that occur when synthesizing a clock network on a multi-FPGA design: Clock skew and uncertainty a common design methodology uses onboard PLLs to generate the required clocks. These clocks are then distributed as primary inputs to the FPGAs. The on-board traces and buffers create some uncertainty and clock skew between the related clocks due to the different paths taken to arrive at the FPGAs. If ignored, this skew can cause hold-time violations on short paths between these related clocks. Note that this skew can also cause setup violations, but this is usually not an issue in prototyping systems as clock skew is
Clock Generation and Synchronization
relatively small compared to the clock period, while the clock skew can be large compared to some on-chip paths. It is currently not possible to correctly forward annotate the skew and uncertainty to the backend place and route tools, which typically are used to resolve hold-time violations. To address this problem, on-chip PLLs are used for clock generation rather than on-board PLLs, since the skew and uncertainty of on-chip PLLs are well understood by the place and route tools. Using on-chip PLLs, however, introduces the second problem, clock synchronization. Clock synchronization when related clocks are regenerated locally on each chip, there is a potential clock-synchronization problem that does not show up in an ASIC design or anywhere where each clock is generated from a single source. The problem becomes apparent with divided clocks multiple copies of a divide-by-N clock that are derived from a base clock may not be identical (i.e., the divided clocks my not be aligned with the exact cycle of the clock as shown in the following figure).
Base Clock div2clk_A
div2clk_B
To address this issue, special IP for synchronizing these clocks on multiple-FPGAs has been developed and included with the Certify tool.

The process for clock generation and synchronization in a multi-FPGA design is outlined in the following steps and documented in detail in subsequent subsections. LO 1. Compile the design. 2. Identify all primary clocks.
3. Group clocks into one or more synchronous groups. Clocks can be in a single group or separated to model truly asynchronous behavior in the design. 4. Select a base-clock frequency for each clock group. The frequency of the base clock is limited by the FPGA PLL specifications and is selected to limit the number of divided clocks. Note that multiples of the base clock do not require synchronization. 5. Determine how the base clocks are to be generated and distributed on the board and then configure the board file appropriately for the selected clock configuration. 6. Create a Clock Generation Module (CGM) for each clock group. A CGM is a structural Verilog or VHDL netlist that contains: Clock generation logic to generate all clocks in the group from the base clock. An instance of the clock synchronizer IP. This instance includes, as input, the clocks that are not strict multiples of the base clock and an input sync signal, and as output, an output sync signal. 7. Validate the CGM in some way (e.g., take it through place and route to verify the PLL configuration. 8. Write a netlist-editing script to: Instantiate all CGM modules at the top level Disconnect the original ASIC drivers of each clock and reconnect the clock nets to the CGM module outputs Add the base clocks to the design as primary inputs Remove the disconnected ASIC clock logic 9. Add the CGM HDL and the netlist-editing script to the design, recompile the design, and run the netlist-editing scripts. 10. Partition the design. During partitioning, replicate the CGM modules onto each FPGA where the clocks are used. 11. Identify the global reset signal to enable the clock synchronizer IP to be inserted into the reset chain (step 13). 12. Complete trace-assignment and CPM/HSTDM insertion including all base clocks.
Detailed Flow
13. Insert the clock synchronizers into the chain/loop. Generate a new reset signal and insert it into the reset sequence.
Detailed Flow
The following subsections describe the individual clock generation and synchronization steps outlined in the previous section in greater detail.
Identify All Primary Clocks

The first step in the clock-generation process is to identify all of the primary (base) clocks present in the design database. These are the clocks to be synthesized on the FPGA prototype. Primary clocks can be identified directly from the clock report by selecting Run->Generate Clock Report in the UI or by entering a report_clocks Tcl command (see report_clocks, on page 175 of the command reference). Clocks originating from a base clock (derived clocks) are, by definition, synchronous to their base clock and are not considered to be a primary clock.
Identify Clock Groups

Clocks can be defined in groups of related clocks with the disjoint clock groups used to model truly asynchronous behavior within the design. Clock groups are identified in the clock report. Note: HSTDM and design logic clocks are always in different clock groups. Single clock groups may be required when special interfaces within a design require all hardware clocks to be stopped synchronously (SCI-ME, debug functionality, etc.). LO The clock synchronization logic may also limit the number of clocks that can be practically synchronized as each additional clock in a group potentially increases the amount of time required to achieve synchronization.
Detailed Flow
Select a Base Clock Frequency

The clock frequency is limited by the requirements of the on-chip PLL including: Minimum/maximum operating frequency The range of clocks that can be derived from the base clock (ratios, phases, duty cycles) The specified frequency must be slow enough to allow simple logic signals to reach neighboring FPGAs within a single clock cycle (the clock sync signal and, potentially, the reset signal require this clock). The frequency specified also affects both the time required for the clocks to reach synchronization and the speed of the clocks that can be synchronized. To specify a base clock frequency, use the Clocks tab in the SCOPE interface (see Clocks, on page 334 of the reference manual or the define_clock Tcl command (see define_clock, on page 982 of the reference manual).
Determine the Clock Configuration

Following clock definition, determine how the base clocks are to be generated and how they are to be distributed on the board: On-board PLL Off-board clock generator 100MHz reference clock on the HAPS-6 series boards Modify or regenerate the board file for the configuration desired.
Detailed Flow
Create One or More CGMs

For each clock group, create a structural Verilog or VHDL netlist that: Instantiates library components (MMCM/PLL, BUFG, etc.) to generate all of the clocks within each clock group. Instantiates a clock synchronization block; a sample synchronization block (clkgrp_sync.v) is included in the /lib/synip/pllsync/rtl directory Connects the necessary clocks (any divided clocks) to the clock synchronization block Creates the required training status signals for HSTDM Note: When defining CGM modules, be sure to include a syn_implement attribute with a value of cgm in the module definition to prevent the module from being removed during optimization. For example: module cgm2 (clk_ref,reset,clk_in,clk_div) /*synthesis syn_implement=cgm */ ; The following schematic diagram shows a top-level CGM inserted into an ASIC design to replace an existing PLL. A netlist editing command (create_cgm) creates the instance and connects the ports to the matching nets. Pushing down into the CGM reveals the clock synchronization IP block shown in the second schematic diagram.
LO
Detailed Flow
Validate the CGM

Validate the CGM as much as possible early in the development: Determine if the PLL/MMCM properties and connections are valid by running each defined CGM module through place and route where vendor tools can validate the configuration. Verify that the clocks generated are as expected: Generate a testbench to automatically simulate the CGM Include a text-based description of the clocks based on the PLL configuration
Update the Netlist

Create a netlist-editing script to: Instantiate all CGM modules at the top level Reroute the ASIC clocks; disconnect the original ASIC drivers of each clock and reconnect the clock nets to the CGM module outputs Add the base clocks to the design as primary inputs Remove the disconnected ASIC clock logic
Detailed Flow
In general, some manual intervention is often required here, since ASIC clocking differs widely, and, for example, control signals from the ASIC clock structures may need to be reconstructed from the FPGA clocking structures.
Add CGM HDL to Project

To add the CGM to your project: 1. Add the CGM HDL and the netlist-editing script to your project 2. Recompile the project 3. Run the netlist-editing scripts
Identify Global Reset

The clock synchronization block in the CGM uses a global reset signal to hold all of the CGMs in the reset state until synchronization occurs. This signal is identified by the -global_reset option of the board_configure command: board_configure -global_reset {traceName} The global reset signal for clock synchronization is the same global reset required by HSTDM. With HSTDM, the following command identifies the global reset: board_define_attribute {traceName} syn_hstdm_reset_pin 1 When a design includes both CGM and HSTDM, use the -global_reset option of the board_configure command to define the global reset for both features.

After adding the CGM to your project, the design srs netlist contains the original ASIC design, with ASIC clock generation logic and clock inputs replaced by one or more CGMs. During or after the normal partitioning step, LO replicate the CGM modules into each FPGA that contains logic that requires any of the generated clocks.
Detailed Flow
Trace and CPM Assignments

With the CGMs inserted and replicated, and the design partitioned, complete the trace assignments and any CPM/HSTDM assignment including assigning the base clock.
Clock Synchronization and Reset

The clock synchronizer circuits on each FPGA are connected in a Directed Acyclic Graph (DAG) configuration. A master synchronizer circuit is identified at the top of the DAG and all slaves synchronize themselves to the master synchronizer. Each directed edge in the DAG represents a trace used to synchronize a slave to another synchronizer at a higher level in the DAG. The average time required to synchronize an entire design is determined by both the maximum depth of the DAG and by the number and types of derived clocks being generated. Since the process of synchronizing involves resetting the PLLs to a new random state until all clocks are aligned, the total time is unknown, but an expected synchronization time is calculated and reported. Each synchronizer includes a syncin and syncout port. The master synchronizer uses syncin to release the global reset. The syncin and syncout signals are synchronized to the base clock and can use any standard routes that meet the clock frequency requirement. These signals are connected automatically similar to the insertion of the HSTDM control signals during hstdm_generate and slp_generate command execution. A reset_generate command generates the clock synchronization control signal and inserts this signal into the reset chain. This reset signal is hijacked and delayed until clock synchronization is complete. A new reset signal is then generated and all user logic originally connected to the original reset is relocated to the new post-clock sync reset. If HSTDM is also present, both HSTDM training and clock synchronization are inserted into the reset chain so that the design is held in a reset state until both tasks are completed successfully. Similar to hstdm_generate, the reserved traces are written to a prt file that is then added to the project.
Detailed Flow
LO
CHAPTER 10
Source-Level Partitioning
Source-level partitioning (SLP), which treats post-partitioned FPGAs as individual projects, is available in two functional modes according to the project target:
Database individual srs projects are created for mapping by the

Synplify Premier synthesis tool. This mode supports parallel mapping of each FPGA and physical floorplanning for the individual FPGAs.
RTL individual RTL projects are created as Verilog or VHDL for input to
a third-party simulator or the Identify Instrumentor. This mode allows changes to be made to individual FPGAs without impacting the entire design and supports a mixture of original RTL source code and machine-generated RTL for the top of each FPGA. Certify is configured to create an individual project file for each FPGA device. After partitioning and trace assignment, running SLP Generation creates a synthesis_files directory in the Results Directory view (the Show all files in the result directory check box on the Project View Options dialog box must be enabled to display this directory). Note: Top-down partitioning is no longer supported. To convert existing top-down designs to the SLP flow, see Appendix D, Top-down Conversion.
Running SLP Generation
Running SLP Generation

After partitioning your design, performing trace assignment, and optionally using CPM/HSTDM, you are ready to run source-level partitioning. From the project view: 1. Click the SLP Generation button to display the SLP Generation dialog box.
2. Make sure that the path to the post-partition result file is correct, select the SLP Generation Options, and click the Execute button.
Checking Generate SLP Mixed Projects creates individual project

directories for each FPGA with Verilog or VHDL RTL-based files, a project file, and an I/O location synthesis constraint file. These output files are synthesized by Synplify Premier and used for simulation and as input to the Identify Debugger.
Checking Generate SLP Database Projects creates individual project

directories for each FPGA with Verilog or VHDL RTL srs-based files, a project file, and an I/O location synthesis constraint file. These output files allow the Synopsys FPGA synthesis tools to map the post-compiled netlists without recompiling.
Database File Generation

LO The following figure shows the SLP directory structure partitioned into two FPGAs and targeted for database mapping (Generate SLP Database Projects checked).
Mixed-project RTL File Generation
synthesis_files Directory
U1
U2
common_files
U1.srs
U1_pinloc.sdc U1_srs.prj U1_timing.sdc
U2.srs
U2_pinloc.sdc U2_srs.prj U2_timing.sdc
map U1_srs.prj
map U2_srs.prj
U1.edf
U2.edf
The synthesis_files directory includes subdirectories for each device with each subdirectory containing a Project ( prj) file and an srs file. Clicking on a project file adds that project to the Project view.

After the successful partitioning of a design, changes to the original design may occur. Depending on the extent of the design change, you can implement an RTL change and update the netlist for that device as a separate project without repartitioning the design and without resynthesizing the other devices. To update a design without repartitioning, the design change must meet the following criteria:
The change cannot affect the devices boundaries; the change must be
completely internal to the device and cannot add, rename, or delete an I/O pin.
The change cannot cause the area resources of the device to be

exceeded.
The change must occur within a block that is fully assigned to a particular FPGA; partitioning must be done at the block level, not at the gate level. The synthesis_files directory includes subdirectories for each device with each subdirectory containing a Project (prj) file, a Verilog (v) or VHDL (vhd) file, an I/O location synthesis constraint (*_pinloc.sdc) file for that device, and a placeholder timing estimation (*_timing.sdc) file to contain the results from running the timing estimator. Clicking on a project file adds that project to the Project view; the project file automatically includes the top-level HDL source file (top.vp or top.vhp) for the design as a reference. The following figure shows the SLP directory structure for a design partitioned into two FPGAs and targeted for simulation or as input to the Identify Debugger (Generate SLP Mixed Projects checked).
synthesis_files Directory
U1
U2
common_files
U1_mixed.v
U1_pinloc.sdc U1_timing.sdc
U2_mixed.v
U2_pinloc.sdc U2_timing.sdc
U1_mixed.prj
U2_mixed.prj
synthesize U1_mixed.prj
synthesize U2_mixed.prj
U1.edf
U2.edf
Using the structure in the above figure as an example, if the source for a LO module instantiated in device U1 is changed (and the change fits the criteria previously described), the U1 project (U1_mixed.prj) can be resynthesized and a new EDIF netlist can be generated without repartitioning the design or resynthesizing U2.
Validating Partitioning Results

Simulation is used to validate the integrity of partitioning (RTL simulation) or the results of synthesis by the Synplify Premier mapper (gate-level simulation). Accordingly, the input files required by the simulator depend on which type of simulation is being performed.
RTL-Based Simulation
RTL-based simulation is used to validate the results of partitioning and is performed after completion of SLP generation. To generate the files required for RTL-based simulation, check Generate Mixed SLP Projects on the SLP Generation dialog box and run SLP generate. The following files are used for RTLbased simulation:
User-defined RTL source files. These files are the original Verilog or
VHDL RTL design files that define the modules or entities that are fully contained within an FPGA and are not partitioned.
An fpgaName_mixed.v or fpgaName_mixed.vhd file for each FPGA. These

files are the post-partitioned Verilog or VHDL RTL files located in the implementationName/synthesis_files directory under the individual FPGA names.
A topModule_mixed.vp or topEntity_mixed.vhp for the design. This file is a

top-level wrapper that instantiates the individual FPGAs and defines their connectivity. The file is located in the implementationName directory.
A modified_modules.v or modified_entities.vhd file that defines the interconnect and logic for any modules/entities that were split among multiple FPGAs as a result of partitioning. This file is located in the implementationName/synthesis_files/common_files directory.
Gate-level Based Simulation

Gate-level based simulation is used to validate the results of synthesis and is performed after SLP generation and after synthesis by the Synplify Premier mapper. To generate the files required for gate-level based simulation:
1. Check both Generate SLP Database Projects and Generate Mixed SLP Projects on the SLP Generation dialog box. 2. Run SLP generate to create:
an fpgaName_srs.v or fpgaName_srs.vhd file for each FPGA. These files

are the post-partitioned Verilog or VHDL RTL files located in the implementationName/synthesis_files directory under the individual FPGA names.
a topModule_mixed.vp or topEntity_mixed.vhp for the design. This file is

the top-level wrapper that instantiates the individual FPGAs and defines their connectivity. The file is located in the implementationName directory. Note: You must also check Generate Mixed SLP Projects on the SLP Generation dialog box to generate the topModule_mixed.vp or topEntity_mixed.vhp file. 3. Run synthesis on each srs project by selecting the project and then selecting Synthesize SLP Project from the popup menu. Running synthesis generates the fpgaName.vm (Verilog) or fpgaName.vhm (VHDL) files in the implementationName/synthesis_files/fpgaName/srs directory. Note: You must set the Write Mapped Verilog Netlist or Write Mapped VHDL Netlist output file option on the Implementation Results tab before synthesizing the srs projects. The option can be set in either Certify or Synplify Premier.
Mixed-language Simulation
When running simulation with post-partitioned VHDL RTL (Write Mapped VHDL Netlist checked), the following additional files may need to be compiled depending on the components and packages referenced in the fpgaName_mixed.vhd or fpgaName_srs.vhd files:
synplify.vhd and synattr.vhd (compiled into synplify library) LO certify.vhd (compiled into certify library) unisim_VCOMP.vhd and unisim_VPKG.vhd (compiled into unisim library)
Source-Level Partitioning Restrictions

The following restrictions apply when using Source Level Partitioning (SLP):
With mixed-language designs, using an entity with multiple archectures

is not supported when writing mixed projects with Verilog as the topmost design language. This restriction is due to a language limitation of Verilog not supporting multiple entity/architecture pairs. Possible workarounds include:
Write SRS SLP projects only Expose the mixed-project writer to only one entity/architecture pair.
This can be done by either not splitting views that contain entities with multiple views or by generating wrappers around each entity/architecure pair with a unique entity name.
If only a single architecture is used for synthesis, an additional

workaround is to insert synthesis off and synthesis on pragmas around the unused architectures such that only one architecture is compiled for each entity.
Global VHDL signals (signal declarations in a package) are not

supported in mixed-language SLP projects. Using these signal declarations within RTL code restricts SLP generation to only srs-based SLP projects (Generate SLP Database Projects selected).
When entities with ports that are elements of records are at the top of
the partitioned FPGAs, SLP VHDL and mixed-language generated RTL code is not properly constructed which results in a failure to compile SLP VHDL and mixed-language projects. When an entire record appears as a port, code generation is correct. To avoid this restriction, either use the srs SLP projects or avoid placing entities with record elements at the ports of an FPGA boundary.
When entities with ports of type character or string are at the top of the
partitioned FPGAs, SLP VHDL and mixed-language generated RTL code is not properly constructed which results in a failure to compile SLP VHDL and mixed-language projects. To avoid this restriction, either use the srs SLP projects or avoid placing entities with ports of type string or character at an FPGA boundary.
With mixed-language designs, using ports names that are reserved

words in the other language at the top of an FPGA can cause linking errors to occur when compiling a mixed-language SLP project. As a workaround, either avoid using reserved words in port names or avoid using mixed-language SLP projects when reserved words are used as top-level FPGA ports.
With VHDL designs, using an entity with the same name but with logical
differences and placed in different libraries can cause the partitioner to error out when Verilog SLP project writing is enabled. As a workaround, avoid using entities with the same name and different logic in different libraries or disable Verilog SLP project writing.
With mixed-language designs, using an entity with the same name as a

module can cause the partitioner to error out when SLP HDL project writing is enabled. As a workaround, avoid using entities and modules with the same name or disable HDL SLP project writing.
With Verilog designs, when the top-level project module has the same
name as a submodule but with different letter case, an error occurs when attempting to simulate the entire system in VHDL because both the top board (vhp) and a sub-entity have the same name in the VHDL namespace. To avoid this restriction, do not name a top module with the same name as a submodule when considering VHDL case insensitivity or do not simulate with VHDL.
When partitioning a VHDL design with signed division or remainder

operations, the partitioner errors out when attempting to write out Verilog SLP. Because signed division or remainder operations in Verilog are not modeled equivalently to VHDL, the Verilog SLP output must be disabled. Use mixed-language output when the source code must be used. For synthesizing FPGA designs, use the srs SLP project.
When compiling a Verilog SLP project, parameters are passed formally

which requires use of the Verilog 2001 standard. If your original project uses any Verilog 2001 reserved word as a port, net, or instance name, an illegal use of reserved word error occurs. To eliminate the error, simply rename the offending object in the original source codes.
Rotate right (rotr) and rotate left (rotl) primitives inferred by the compiler
cause the SLP flow in the partitioner to error out. As a workaround, either disable the SLP writers (turn off Write Post-Partitioned Verilog/VHDL LO Netlist) or use the SRS project created by Source Level Partitioning.
Enumerated data types are not supported.

Support for member port types in composite data type records is

limited; members with the following port types only are supported for composite data type records: std_logic, std_logic_vector, std_ulogic, and std_ulogic_vector.
Port types bit, bit_vector, boolean, integer (signed and unsigned), and
single- and multi-dimensional arrays are not supported as members in records. These types are, however, supported in SLP when not part of a record.
Multidimensional declarations on any of the supported port types (i.e.,

array of std_logic, array of std_logic_vector, etc.) are not supported.
Netlist Partitioning Flow

The netlist partitioning flow enables the use of a technology-mapped EDIF structural netlist from an external synthesis tool when prototyping a design. The netlist partitioning flow is a two-pass flow: mapping the design in the first pass using Synplify Premier and then partitioning the mapped design using Certify in the second pass. Using netlist partitioning includes the following advntages over the standard, SLP-based RTL partition flow:
faster and more accurate area estimation more optimized netlist

Using the netlist partitioning flow speeds up area estimation run times. Because designs are fully mapped, estimating the area is simply a computation of primitive-gate count. Area estimates are very accurate because they are derived from the mapped netlists. With the netlist partitoning flow, the Certify software calculates area resources from the results obtained during the first step (pass 1) as well as making use of the netlist optimizations performed during this step. In pass 1, the design is compiled and mapped by Synplify Premier (or other synthesis tool). During this pass, the flow can be sped up by identifying large modules and compiling them in parallel followed by a mapping step using the compile-point synthesis flow. The mapped EDIF netlist, the output of the first pass, is used as input to the Certify partitioning step in the second pass. The next few sections provide a brief description of the various steps in the two-pass flow followed by a flow diagram of each pass.
Pass 1 Flow
The pass 1 flow is performed by Synplify Premier outside of Certify. The major pass 1 steps are:
Key-in the board resources corresponding to the Certify environment

into the sdc file LO Identify large modules required for SLP-bottom-up compilation
Key-in Board Resources

Because the entire design is being mapped to a single FPGA, the mapper overmaps the design by first using the available resources on the single FPGA and then mapping the remaining logic onto LUTs. To realize accurate area requirements during pass 1, multiply the available FPGA resources by the number of FPGAs defined in Certify and then enter these values into a constraint file using a syn_allowed_resources attribute. A typical attribute entry for a single FPGA with 672 blockRAMs and 192 DSPs targeted for a Certify configuration with four FPGAs would be: define_global_attribute {syn_allowed_resources} {blockrams=2688,dsps=768} Refer to the resource utilization report in the log file for actual resource usage.
Creating SRS Files for Large Modules

The following steps describe how to create srs files for large modules using bottom-up compilation techniques: 1. Identify large modules in the design. 2. Create a new implementation for each large module to be compiled using the bottom-up methodology. 3. Define each module as a top module within its implementation and then compile the module to create a moduleName.srs file for the module in its implementation directory. 4. Create wrapper files from the RTL (v or vhd) files corresponding to the large modules identified in step 1:
In Verilog, create an empty module with the same name that contains
the same interface as the module.
In VHDL, create an empty architecture with the port map

corresponding to the module. 5. Include the srs files and the wrapper files in the top-level project (top.prj). Also include any remaining RTL files that are not identified as large modules in the top.prj file. Indicate the top module in the project file. 6. Do not insert any IO buffers (i.e., set_option -disable_IO_insertion 1).
7. Compile the top.prj design. The output of this step is the top.srs. Note: A module is identified as large based on your design knowledge. The bottom-up methodology allows you to compile each large module in parallel using multiple Synplify Pro, Synplify Premier, or Certify licenses.
Map the Design

Before mapping a design, it is important to note that the user-defined, toplevel timing constraints must be removed from the constraint file (i.e., the constraint file must consist of only the large design modules and the resource allocations). For information on setting up your synthesis environment, see the Synplify Premier user guide.
LO
Design Files (VHDL/Verilog)
Yes
Large Modules?
No
Compile Large Modules Create Wrapper Files .srs and .v/.vhd
.v/.vhd
Add toTop-level Project File (top.prj) Compile
Map the Design
Technology-Dependent Structural Verilog Netlist (vm/vhm)
Figure 10-1: Flow Diagram Pass 1
Pass 2 Flow
During the second pass, the EDIF design from the synthesis tool is brought into Certify where it goes through all of the normal Certify steps. The primary difference is more accurate area estimates and improved netlist optimization as a result of using the netlist from the synthesis tool.. The advantages of using the netlist file include:
Smaller netlist as a result of the mapper optimizations performed during

pass 1.
Elimination of the area-estimation step (it is only necessary to sum the

resource requirements from the post-map netlist). There are three steps in the second pass:
Area estimation Normal Certify partitioning flow which includes partitioning, CPM
assignment, trace assignment, and SLP-based mapping.
Area Estimation
The pass 2 flow eliminates the area-estimation step. A quick_area_estimate command is included in the library.tcl file and executed by nfilter to generate an area-estimate file based on the post-map netlist. Nfilter uses the mappedgate count to arrive at an estimate of the area for the various modules. The Tcl command syntax is: quick_area_estimate 1
Certify-based Normal Steps

At this point in the flow, a structural Verilog netlist exists which is now used to run the normal design-partitioning steps. Mapping of the partitioned design is done using the SLP flow. To use the SLP flow, add the library.srs file to the corresponding FPGA project before mapping your design. The time required to compile is now considerably less because the input to the compile step is the structural netlist (the vm or vhm file from pass 1). Although in pass 1 the RTL is mapped to the Verilog netlist through the technology library, you mustLO create an edf netlist suitable for place-and route and for use later in the down-stream flow.
Verilog/VHDL Netlist (v/vhd)
Yes
Can Large Instance be Partitioned into Single FPGA?
Define Large Library Instance Include library.tcl in .prj File
No
Compile and Estimate Area design.est design.srs library.srs Partition Design .srp .srs/.sdc/.prj per FPGA
Map Design
Source-Level Partitioning
Individual Netlists for Each FPGA
Figure 10-2: Flow Diagram Pass 2
LO
C H A P T E R 11
Scripting
Scripting allows a set of Tcl commands to be applied to a design through a Tcl script file. All of the normal UI functions have equivalent Tcl commands. In practice, a design is implemented through its various phases (i.e., partitioning, trace assignment) using the standard UI with the corresponding Tcl commands captured in a script file during each phase. These scripts are subsequently run to replay the design at each phase where changes can be made either through the UI or by modifying the commands directly in the Tcl files.
Capturing Commands
Capturing Tcl command equivalents to a Tcl script file is enabled by entering the following command in the Tcl window: recording -on When enabled, the Tcl equivalents of the UI commands are collected until recording is disabled (recording -off). These Tcl commands are then saved to a file using the command: recording -save filename.tcl This Tcl script file can then be entered from the UI (Run->Run Tcl Script) or from the command line in batch mode (run filename.tcl) to replay that portion of the design operation. For information on batch mode, see Using Batch Mode, on page 305.
Capturing Commands
Scripting Operations
In practice, Tcl scripts are individually or collectively created to perform the following operations:
Loading the database defines the project and compiles the files Partitioning adds logical blocks to the available devices Trace Assignment assigns logical nets to physical traces CPM/HSTDM multiplexes signals to reduce device pin count SLP synthesizes the individual devices
Invoking Certify in Shell Mode

Scripts and the Certify scripting commands are run from the Certify shell. Note that because Certify uses the Synplify Premier mappers to perform SLP project synthesis, you must set the SYNPLIFY_PATH environment variable to point to the Synplify Premier installation directory to invoke the Synplify Premier executable. To invoke Certify in shell mode, enter the following at the command prompt: certifyInstallDirectory/bin/certify shell Certify opens in the shell mode and displays the shell prompt (%).
Loading the Database

To start using Certify, load your project using the following command: % project load projectName.prj This command loads the project and sets the Certify-related options for the current session. To compile the netlist and board files for the project, enter the following command at the prompt: % project run rtl_prep This command is equivalentLO clicking Run Preparation in the GUI and generto ates the design and board srs netlist files. Before you can start partitioning, you must load these files into the design database using the following commands:
Capturing Commands
% load_board boardName.srs % load_netlist designName.srs All subsequent Certify operations are performed on this database.
Area Estimation
To estimate the area for your design, enter: %estimate_area -out projectName.est The above command uses the default (high) area estimation effort; to change the area estimation effort, include one of the following commands ahead of the estimate_area command: set_option -area_effort medium set_option -area_effort low After area estimation is run, load the area estimation file into the database using the command: %load_estimate_file -area projectName.est
Partitioning
Certify supports three basic partitioning commands:
logic_place updates the database logic_list lists the states of instances in the database logic_save saves the partitioning (prt) file
To display a list of command options for one of the above commands, enter the command name without any options (e.g., entering logic_place at the command prompt lists all of the available options for the logic_place command). To check which instances have not been assigned, use the -clear option for the logic_list command: %logic_list cleared A complete list of all unassigned (cleared) instances is generated. To partition the instances, use the following command syntax: logic_place -assign {instanceName} -device deviceName
Capturing Commands
For example, entering logic_place -assign {Decode Dmux} -device mb.uA assigns unassigned instance DECODE Dmux to device mb.uA.
Example Script
The following is an example script for manually partitioning the first tutorial design (commchip.v) showing the equivalent Tcl commands. The first three commands load the database. load_board {C:\DesignsII\proto\commboard.srs} load_netlist {C:\DesignsII\proto\proj_1.srs} load_estimate_file -area {C:\DesignsII\proto\proj_1.est} logic_place -assign {CLOCK_GEN} -device {clock} logic_place -assign {DESIGN.CTL1} -device {U1} logic_place -assign {DESIGN.RCV0} -device {U1} logic_place -assign {DESIGN.RCV1} -device {U1} logic_place -assign {DESIGN.RCV2} -device {U1} logic_place -assign {DESIGN.RCV3} -device {U1} logic_place -assign {DESIGN.SA1} -device {U1} logic_place -assign {DESIGN.MEM1} -device {RAM} logic_place -assign {DESIGN.RA1} -device {U2} logic_place -assign {DESIGN.SND0} -device {U2} logic_place -assign {DESIGN.SND1} -device {U2} logic_place -assign {DESIGN.SND2} -device {U2} logic_place -assign {DESIGN.SND3} -device {U2} logic_place -replicate {DESIGN.CTL1} -device {U2} logic_save {C:/DesignsII/proto/proj_1.prt} project -save proj_1.prj The script assigns devices to their respective FPGAs and saves the partition file as proj_1.prt.
CPM
Four basic CPM commands are supported:
cpm_place updates the database cpm_configure sets qualification criteria and connects internal fast clock LO cpm_list lists CPM-releated information (e.g., qualified nets, net properties, etc.)
cpm_save saves the CPM file

Capturing Commands
For example , enter the following command to qualify nets that end at a sequential element: %cpm_configure -qualify_type 2 Then, to list all of the qualified, unassigned nets that end at a sequential element, enter: %cpm_list nets To perform CPM assignment on a qualified net, use the following syntax: %cpm_place -assign {output_seq_logic_large_temp[1399:0]} Other CPM commands can be found in cpm.tcl with explanations. Either type the commands or source the cpm.tcl file by typing source cpm.tcl on the command line. The cpm.tcl script performs all CPM operations and saves the CPM results in the projectName.cpm file.
Trace Assignment
Trace assignment commands are divided between board commands and net commands:
board_configure use to configure the trace board_list used for getting information on trace net_place used for net-trace assignments net_list used for getting information on nets net_save saves the trace assignment (tra) file
To assign trace to net DATA[11] type-in following command %net_place -assign {Data[11]} -trace {SMAP[32]} To unassign the net LONGK[4] type-in following command %net_place -clear {Data[11]} -trace {SMAP[32]} Other trace commands can be found in trace.tcl with explanations. Either type the commands or source the trace.tcl file by typing source cpm.tcl at command line. The trace.tcl script performs all trace operations and saves the trace results in the projectName.tra file.
Capturing Commands
Synthesis
After trace assignment to generate a partitioned netlist inclusive of CPM and trace assignments type following command %partition_save -database top.srp To generate SLP project type following command %slp_generate top.srp database All SLP projects can be synthesized using command %project_launch -all
Command Descriptions
Complete command descriptions of the Tcl commands are located in the Certify Command Reference.
LO
Using Batch Mode
Using Batch Mode

Batch mode is a command-line mode in which you run scripts from the command line. Batch scripts are in Tcl format. For more information about Tcl scripts, see Working with Tcl Scripts and Commands, on page 306 or the Reference Manual. The following procedure uses a Tcl batch script for running synthesis. 1. Create a Tcl batch script. See Setting Device Options in Tcl Scripts, on page 307 for details. 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 where the files are located and type the following: certify.exe -tcl Tcl_script.tcl The software runs synthesis in batch mode. Note that the Certify GUI is displayed when the command is invoked. To hide the GUI, use the following command syntax: pathtoCertify/certify.exe -tcl pathtoTclScript.tcl -batch -hideui 4. Check for errors.
For source file errors, check the standard output for messages. On
Linux systems, this is generally the monitor; on Windows systems, it is the stdout.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
For synthesis run errors, check the projectFileName.srr log file.

Working with Tcl Scripts and Commands

The software uses extensions to the popular Tcl (Tool Command Language) scripting language to control synthesis and to define constraints. See the following for more information:
Using Tcl Commands and Scripts, next Setting Device Options in Tcl Scripts, on page 307 Using Tcl Variables for Multiple Runs, on page 307
You can also use synhooks Tcl scripts, as described in Automating Flows with synhooks.tcl, on page 309.
Using Tcl Commands and Scripts

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 Certify Command Reference for detailed information about

the Tcl synthesis commands.
Type help * in the Tcl window for a list of all the Tcl synthesis
commands.
Type help commandName in the Tcl window to see the syntax for an
individual command. When creating a Tcl script:
Check character case (Tcl commands are case-sensitive). Start all comments with a hash mark (#). Always use a forward slash (/) in directory and pathnames, even on the
Windows platform. To run a Tcl script, either enter source Tcl_scriptfile in the Tcl script window or select Run->Run Tcl Script, select the Tcl file, and click Open. LO The software runs the selected script by executing each Tcl command in sequence. For more information about Tcl scripts, refer to the following sections.
Setting Device Options in Tcl Scripts

To set device options with a Tcl script, use the set_option Tcl command. The following table is an alphabetical list of the device mapping options on the Device tab mapped to the equivalent Tcl commands. Because the options are technology-based, all the options will not apply to your design. All commands begin with set_option, followed by the syntax in the column as shown. Check the Certify Reference Manual for the most comprehensive list of options for your vendor and technology. Table 11-1: Device Options and equivalent Tcl Commands Device Option
Altera Models Annotated Properties for Analyst Disable I/O Insertion Disable Sequential Optimizations Enable Advanced LUT Combining Fanout Guide Fix Gated Clocks Fix Generated Clocks Update Compile Point Timing Data Use Xilinx Xflow (Xilinx) Verification Mode
Tcl Command (set_option...) -syn_altera_model {1|0} -run_prop_extract {0|1} -block {1|0} -no_sequential_opt {1|0} -enable_prepacking {0|1} -maxfan fanout_value -fixgatedclocks {0|1|2|3} -fixgeneratedclocks {0|1|2|3} -update_models_cp {0|1} -par_use_xflow {0|1} -verification_mode {0|1}
Using Tcl Variables for Multiple Runs

To create a single script for multiple synthesis runs with different criteria, you need to create a Tcl variable for the different settings you want to try. For example, you might want to try different frequencies.
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:
Set of frequencies to try
Foreach loop
set try_freq { 20.0 24.0 Tcl commands that set the 28.0 frequency, create log files for each 32.0 run, and run synthesis 36.0 40.0 ) foreach frequency $try_freq { set_option -frequency $frequency project -log_file $frequency.srr project -run}
LO
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 can use callbacks to send yourself email when a job is done (see Automating Message Filtering with a Tcl Script, on page 759), or to automatically 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 Synopsys FPGA install_dir/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 Tcl synhooks Utility, on page 405 in the Reference Manual. Design Phase Project Setup Callbacks
Settings defaults for projects Creating projects Opening projects
Tcl Callback Function
proc syn_on_set_project_template proc syn_on_new_project proc syn_on_open_project

Design Phase
Closing projects
Tcl Callback Function proc syn_on_close_project
Application Callbacks
Starting the application after opening a project Exiting the application
proc syn_on_start_application proc syn_on_exit_application
Run Callbacks
Starting a run. See Example: proc syn_on_start_run, on page 311. Ending a run
proc syn_on_start_run
proc syn_on_end_run
Key Assignment Callbacks

Setting an operation for CtrlF8. See Example: proc syn_on_press_ctrl_f8, on page 311. Setting an operation for CtrlF9 Setting an operation for CtrlF11
proc syn_on_press_ctrl_f8
proc syn_on_press_ctrl_f9 proc syn_on_press_ctrl_f11
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.
LO
Example: proc syn_on_start_run

The following code example gets selected files from the project browser at the start of a run: 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] } }
LO
CHAPTER 12
Netlist Editing
Netlist editing capabilities are useful for:
Implementing engineering change orders (ECOs) Rerouting a fast clock from an external source to an internal (DCM)
source
Inserting IP blocks in a partitioned netlist Inserting IP blocks in an RTL netlist (srs file)
With netlist editing, you do not have to modify the HDL to perform small changes to the netlist. Netlist editing includes the ability 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. There are two entry points in the Certify tool flow where netlist editing can be used:
RTL level Partitioned-netlist level

At the RTL level, you can add other RTL views (srs files) or primitives to the RTL view of the design to be synthesized. At the partitioned-netlist level, you must create a new project, add the srp netlist, and then edit the netlist. Netlist editing support at both the RTL and partitioned-netlist levels can only be used within the following flows:
top-down, board-level mapping (i.e., pressing the Run button) .srs-based SLP flow
RTL-Level Flow
The remainder of this section includes the following information:
RTL-Level Flow, below Netlist Editing Commands, on page 318
RTL-Level Flow
Netlist editing commands are written to a tcl file; you must include this file in your project using Add Prototype file on the Prototyping Tools tab of the Implementation Options dialog box. Nfilter reads these commands and performs the 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 data base (i.e., ip.srs or ip.srl file) with the existing netlist from where the new netlist will be created. 2. Create and compile the project with the IP or modules you want to insert into the main design to generate the ip.srs or ip.srl file. 3. Apply the netlist editing commands in the tcl file. 4. Run nfilter 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; nfilter does not understand the Verilog database, and you must load the syn file available 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 nfilter and then run the mapper.
RTL Flow Examples
LO
The following example add an RTL (srs) IP block and/or library primitives to a projects RTL View (srs).
RTL-Level Flow
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" Sample tcl file contents: #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]} 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
SLP Considerations
Using the RTL-level flow with source-level partitioning includes additional considerations based on the visibility or exposure of the edits to the machinegenerated portion of the mixed SLP projects. There are three unique design cases when editing a netlist within an SLP flow:
editing machine-generated code for logic that crosses device boundaries editing machine-generated code for logic within a hierarchy editing RTL code for logic within a single device
When using database SLP projects, the results of the netlist edits are incorporated in all cases.
RTL-Level Flow
Crossing Device Boundaries

When a module/entity that contains the target of the netlist edit spans more than a single device and the module/entity is instantiated directly by the top level of the design hierarchy, the SLP writer observes these connections and machine generates the interconnect for the top of the FPGAs. For this design case, the netlist editing file only needs to be applied to the top-level netlist. The following steps outline this basic flow. 1. Compile the project and open the top-level netlist (srs) file. 2. Create the netlist editing Tcl file using the netlist editing commands (see Netlist Editing Commands, on page 318). 3. Add the netlist editing script to the project. Use a source command in the Tcl window (e.g., source myscript.tcl) or manually add the editing commands directly to the project file. 4. Run the partitioner (Run->Partitioner) to apply the netlist edits and to generate the SLP projects. 5. Open the top-level netlist file and check the results of the edit. If necessary, edit the script and repeat the above steps.
Hierarchy
When a module/entity that contains the target of the netlist edit spans more than a single device and the module/entity is instantiated in a hierarchical level below the top level of the design, the SLP writer observes these connections and machine generates the interconnect for the top of the FPGAs. For these design cases, because the logic that instantiates the hierarchical module is machine generated, the netlist editing file only needs to be applied to the top-level netlist as in the case of crossing device boundaries.
Single Device Editing

With single-device editing, the logic block to be edited is fully contained within a single FPGA and the netlist edits are applied to the original srs file. Because the mixed SLP project references the original RTL code, the interconnect is not honored and a netlist editing script must also be applied to the LO mixed FPGA project. The following steps outline this basic flow.
RTL-Level Flow
1. Compile the project and open the top-level netlist (srs) file. 2. Create the netlist editing Tcl file using the netlist editing commands (see Netlist Editing Commands, on page 318). 3. Add the netlist editing script to the project. Use a source command in the Tcl window (e.g., source myscript.tcl) or manually add the editing commands directly to the project file. 4. Run the partitioner (Run->Partitioner) to apply the netlist edits and to generate the SLP projects. 5. Open the top-level srs netlist file, push down into the hierarchy, and check the results of the edit. 6. Check the mixed-project assignment for the device containing the logic block (the device project processes the original RTL for the logic block; the interconnect is not honored). 7. Open and compile the mixed-project assignment for the device containing the logic block. 8. Open the srs file for the mixed project. Since the original RTL was processed for the logic block, the interconnect is not honored in the mixed project. 9. Copy the top-level netlist editing script to the mixed-project and add the script to the mixed project by either adding the script contents directly to the project file or by sourcing the script with the following command: source tclFilename.tcl 10. Apply the netlist edits by compiling the design. Note that the design must be compiled with the Certify tool and cannot be compiled with Synplify Premier.
Diagnosing Problems
Problems can occur when adding entries to the tcl files. Syntax errors are usually reported, but incorrect connections may not be detected until much later in the design flow. The syntax error Could not find pin "pathName.pinName" in module "modName"
Netlist Editing Commands
indicates an incorrect path or pin name. Check that the path/pin names and letter case are correct.

Netlist editing commands typically apply to the current view. Note that all path names used in netlist editing commands are relative to the module of the current view and that the current view must be unique (if the view is not unique, a modification in the current view affects all modules of the same view). The supported netlist commands are listed in the table below. Complete syntax and command description are included in the Certify Command Reference.
connect_net create_cgm create_port disconnect_connector insert_buffer pop_feedthroughs remove_instance reset_generate tie_net copy_view create_instance create_process_hierarchy disconnect_net load_database propagate_constants remove_net set_property tie_pin create_cell create_net define_current_view get_net optimize_netlist remove_buffer remove_port swap_instance
LO
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 qualifiers 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 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 of 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
Obsolete Netlist Editing Commands

The following netlist editing commands are no longer supported. These commands were used previously to reconfigure clock paths to use the internal clock resources of an FPGA and were inserted directly into the partition file in text mode. ndisconnect -pin {t:hierInstanceName.pinName} nconnect -add -pin {t:hierInstanceName.pinName} -net {n:hierNetName} ndelete -port {p:portName} -inst {i:instName} ndelete -inst {i:instName}
LO
CHAPTER 13
Analyzing Logic in HDL Analyst

This chapter describes how to analyze logic in the HDL Analyst and FSM Viewer. See the following for detailed procedures:
Working in the Schematic View, on page 322 Exploring Design Hierarchy, on page 334 Finding Objects, on page 341 Crossprobing, on page 349 Analyzing With the HDL Analyst Tool, on page 357 Using the FSM Viewer, on page 376
For information about analyzing timing, see Chapter 22, Analyzing Timing.
Working in the Schematic View

The HDL Analyst includes the RTL view, which is a schematic view used to graphically analyze your design. The RTL view is available after a design is compiled following the Run Preparation stage. The RTL view displays your design as a high-level, technology-independent schematic. At this high level of abstraction, the design is represented with technology-independent components such as variable-width adders, registers, large muxes, state machines, and so on. This view corresponds to the srs netlist file generated by the software in the Synplicity proprietary format. For a detailed description, see Chapter 2 of the Reference Manual. This section describes basic procedures you use in the RTL view. The information is organized into these topics:
Opening an RTL View, on page 323 Viewing Object Properties, on page 323 Viewing Object Properties, on page 323 Selecting Objects in the RTL View, on page 326 Working with Multisheet Schematics, on page 327 Moving Between Views in a Schematic Window, on page 329 Setting Schematic View Preferences, on page 329 Setting Preferences in the ini File, on page 331 Managing Windows, on page 332
For information on specific tasks like analyzing critical paths, see the following sections:
Exploring Object Hierarchy by Pushing/Popping, on page 335 Exploring Object Hierarchy of Transparent Instances, on page 340 Browsing to Find Objects, on page 341 Crossprobing, on page 349 Analyzing With the HDL Analyst Tool, on page 357 LO
Opening an RTL View

The RTL view is available only after a design has been compiled. To open a hierarchical RTL view, do one of the following:
Select HDL Analyst->RTL->Hierarchical View. Click the RTL View icon ( ) (a plus sign inside a circle). Double-click the srs file in the Result Directory window.
To open a flattened RTL view, select HDL Analyst->RTL->Flattened View. The RTL view has 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 the window contains the name of the view, the kind of view, hierarchical level, and the number of sheets in the schematic. See Hierarchy Browser, on page 47 in the Reference Manual for a description of the Hierarchy Browser.
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.
Set this field to the pin name to see pin properties
3. To flag objects by property, do the following in an open RTL view:
Set the properties you want to see by selecting Options->HDL Analyst

Options->Visual Properties, and selecting the properties from the pulldown list.
LO
Close the HDL Analyst Options dialog box. Enable View->Visual Properties. If you do not enable this, the software
does not display the property flags in the schematics. The HDL Analyst annotates all objects in the current view that have the specified property with a rectangular flag that contains the property name and value. The software uses different colors for different properties, so you can enable and view many properties at the same time.
Example: Slow and New Properties

You can view objects with the slow property when you are analyzing your critical path. All objects with this property do not meet the timing criteria. The following figure shows a filtered view of a critical path, with slow instances flagged in blue.
Slow property
When you are working with filtered views, you can use the New property to quickly identify 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. This can be useful when you are debugging your design. The following figure expands one of the pins from the previous filtered view. The new instance added to the view has two flags: new and slow.
Selecting Objects in the RTL View

For mouse selection, standard object selection rules apply: In selection mode, the pointer is shaped like a crosshair. To select...
Single objects Multiple objects
Do this...
Click on the object in the RTL schematic or click the object name in the Hierarchy Browser. 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 341. Use Find to select the objects you want. See Using Find for Hierarchical and Restricted Searches, on page 343. Use Edit->Find to select the objects (see Browsing With the Find Command, on page 342), or use the Hierarchy Browser, which lists objectsLO type. by
Objects by type (instances, ports, nets)
To select...
All objects of a certain type (instances, ports, nets) No objects (deselect all currently selected objects)
Do this...
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. 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.
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 349 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.
Working with Multisheet Schematics

The title bar of the RTL 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 unfiltered 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...
Next sheet or previous sheet
Use one of these methods...

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). ) or Previous Sheet ( ) Click the icons: Next 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. 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. 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. 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. Filter the schematic as described in Filtering Schematics, on page 361. 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.
A specific sheet number
Lower-level logic of a transparent instance on separate sheets All objects of a certain type
Selected items only A net across sheets
LO
Sheet Connector Symbol
Connected sheet numbers
Sheet connector with multisheet popup menu
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.
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 view from the user interface. This is easier than editing the ini file. However, to set colors, you must modify the ini file directly, as described in Setting Preferences in the ini File, on page 331.
1. Select Options->HDL Analyst Options. For a description of all the options on this form, see HDL Analyst Options Command, on page 220 in the Reference Manual. 2. The following table details some common operations: To...
Display the Hierarchy Browser Control crossprobing from an object to a P&R text file Determine the number of objects displayed on a sheet. Determine the number of objects displayed on a sheet in a filtered view.
Do this...
Enable Show Hierarchy Browser (General tab). Enable Enhanced Text Crossprobing. (General tab) Set the value with Maximum Instances on the Sheet Size tab. Increase the value to display more objects per sheet. 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.
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.
Show Cell Interior off
Show Cell Interior on
LO
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.
Show Symbol Name Show Conn Name Show Pin Name
Show Port Name
Show
For a more detailed information about some of these options, see Schematic Display, on page 295 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.
Setting Preferences in the ini File

You can customize the colors used in the RTL view schematics. 1. Edit the certify.ini file. On Windows platforms, the file is in the Application Data\Synplicity directory under your account in C:\Documents and Settings. On UNIX workstations, it is in the .synplicity directory in your home directory ($HOME/.synplicity).
2. Adjust the RGB (red, green, blue) values in the [Schematics] section. To Change...
The default color for nets, ports, and nonpartitioned, unselected instances The highlight (selected) color for nets, ports, and non-partitioned instances The color for unselected partitioned instances The highlight (selected) color for partitioned instances The color for unselected replicated instances The highlight (selected) color for replicated instances The window background color
Adjust... SSC_DEFAULT_LINE SSC_HILIT SCC_OTHER SCC_HILIT_OTHER SCC_DUP SCC_DUP_HILIT SSC_BACKGROUND
Managing Windows
As you work on a project, you open different windows. For example, you might have two RTL views 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 329. 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. LO 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.
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 357. The topics include:
Traversing Design Hierarchy with the Hierarchy Browser, on page 334 Exploring Object Hierarchy by Pushing/Popping, on page 335 Exploring Object Hierarchy of Transparent Instances, on page 340
Traversing Design Hierarchy with the Hierarchy Browser

The Hierarchy Browser is the list of objects on the left side of the RTL view. 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 335 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.
LO
Click to expand and see lower-level hierarchy
Click to collapse list
Refer to Hierarchy Browser Symbols, on page 48 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 334. 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 361, Expanding Pin and Net Logic, on page 363, and Expanding and Viewing Connections, on page 367 for details about filtering and expansion. See the following sections for information about pushing down and popping up in hierarchical design objects:
Pushing into Objects, on page 336, next Popping up a Hierarchical Level, on page 339
Pushing into Objects

In the schematic view, 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).
Hierarchical object
Press right mouse button and draw downward to push into an object
Inferred ROMs and state machines.

The remaining steps show you how to use the icon or command to push into an object.
LO
2. Enable Push/Pop mode by doing one of the following:
Select View->Push/Pop Hierarchy. Right-click in the view and check Push/Pop Hierarchy from the popup
menu.
Click the Push/Pop Hierarchy icon (

pointing up and down).
) in the toolbar (two arrows
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.
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 graphically view the transitions. For more information, see Using the FSM Viewer, on page 376. If you push into a state machine from the Technology view, you see the underlying logic.
LO
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.
Press the right mouse button and draw an upward stroke to pop up a level
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 336for 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.
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 335). Pushing
User control You initiate the operation through the command or icon. Context lost; the lowerlevel logic is shown in a separate view
Transparent Instance
You have no direct control; the transparent instance is automatically generated by some commands that result in a filtered view. Context maintained; lower-level logic is displayed inside a hollow yellow box at the hierarchical level of the parent.
Design context
LO
Finding Objects
Finding Objects
In the schematic view, you can use the Hierarchy Browser or the Find command to find objects, as explained in these sections:
Browsing to Find Objects, on page 341 Using Find for Hierarchical and Restricted Searches, on page 343 Using Wildcards with the Find Command, on page 346
For information about the Tcl Find command, which you use to locate objects, and create collections, see Using the Tcl Find Command to Define Collections, on page 638.
Browsing to Find Objects

You can always zoom in to find an object in the RTL 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
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.
Expand Instances and select an object on a lower hierarchical level.
Schematic pushes down to the correct level to show 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 LO 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.
Finding Objects
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 schematics or use the Hierarchy Browser (see Browsing to Find Objects, on page 341). 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. 1. If needed, restrict the range of the search by filtering the view, hiding instances, or both. See Viewing Design Hierarchy and Context, on page 358 and Filtering Schematics, on page 361 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. 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. 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 open the Object Query dialog box, right click in the RTL 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.
Finding Objects
3. 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. 4. 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 Search Range on Wildcard Searches, on page 346 for details. Current Level Only or Current Level & Below are useful for searching filtered schematics or critical path schematics. 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. LO
Finding Objects
5. 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. 6. 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 346 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.
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.
Find all instances three levels down Narrow search to find instances that begin with i_ Narrow search to find instances that begin with un2 after the second hierarchy separator
*.*.* i_*.*.* i_*.*.un2*
7. 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 101 of the Reference Manual.
Finding Objects
Using Wildcards with the Find Command

Use the following wildcards when you search the schematics:
* ? . 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: \.
Effect of Search Range on Wildcard Searches

The asterisk and question mark do not cross hierarchical boundaries. However, the scope of the search determines the starting points for the searches, and this might make it appear as if the wildcards cross hierarchical boundaries in some cases. 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 hierarchical 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.
Entire Design
Current Level and Below

3A1
2A
Current Level
2B
3A2
3B1
3B2
3B3
See Wildcard Search Examples, on page 348 for examples. LO
Finding Objects
How a Wildcard Search Works

1. The starting point of a wildcard search depends on the range set for the search. 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. Starts at the current hierarchical level and searches that level only. A search started at 2A only covers 2A. 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.
Current Level Current Level and Below
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 (like *.*) are repeated at each level included in the scope. See Effect of Search Range on Wildcard Searches, on page 346 and Wildcard Search Examples, on page 348 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.
Finding Objects
Wildcard Search Examples

The figure shows a design with three hierarchical levels, and the table shows the results of some searches on this design.
2A
2B
3A1
3A2
3B1
3B2
3B3
Scope
Entire Design
Pattern Starting Point

* *.* 3A1 2B
Finds Matches in...

1, 2A, 2B, 3A1, 3A2, 3B1, 3B2, and 3B3 (* at all levels) 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. 1 only (no hierarchical boundary crossing) 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
* *.*
1 2B
LO
Crossprobing
Scope
Current Level and Below
Pattern Starting Point

* *.* 2A 1
Finds Matches in...

2A only (no hierarchical boundary crossing) 2A and 2B (*.* from 1) 3A1, 3A2, 3B1, 3B2, and 3B3 (*.* from 2A and 2B) No matches from 1, because the dot is specified. 3B1, 3B2, and 3B3 (*.* from 2B) No matches (no hierarchy below 3A2) 3A1, 3A2, 3B1, 3B2, and 3B3 (*.*.* from 1) Search ends because there is no hierarchy two levels below 2A and 2B.
*.* *.* *.*.*
2B 3A2 1
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 view. 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, 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 compilation. This section describes how to crossprobe from different views. It includes the following:
Crossprobing within an RTL View, on page 350 Crossprobing from the RTL View, on page 350 Crossprobing from the Text Editor Window, on page 352 Crossprobing from the Tcl Script Window, on page 355
Crossprobing from the FSM Viewer, on page 355

Crossprobing
Crossprobing within an RTL View

Selecting an object name in the Hierarchy Browser highlights the object in the schematic, and vice versa. Selected Object
Instance in schematic (single-click) Net in schematic Port in schematic Logic icon in Hierarchy Browser Net icon in Hierarchy Browser Port icon in Hierarchy Browser
Highlighted Object
Module icon in Hierarchy Browser Net icon in Hierarchy Browser Port icon in Hierarchy Browser Instance in schematic Net in schematic Port in schematic
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 View LO

To crossprobe from an RTL view to other open views, select the object by clicking on it.
Crossprobing
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 and Text Editor (source code) views.
RTL View
Text Editor
To crossprobe from the RTL view to the source file when the source file is not open, double-click on the object in the RTL view. Double-clicking automatically opens the appropriate source code file and highlights the appropriate code. For example, if you double-click an object in an RTL view, the HDL Analyst tool automatically opens an editor window with the source code and highlights the code that contains the selected object. The following table summarizes the crossprobing capability from the RTL view.
Crossprobing
From
RTL
To
Source code
Procedure
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. The FSM view must be open. The state machine must be coded with a onehot encoding style. Click the FSM to highlight and crossprobe.
RTL
FSM Viewer
Crossprobing from the Text Editor Window

To crossprobe from a source code window or from the log file to an RTL 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 353 for a practical example of how to use crossprobing. 1. Open the RTL or FSM 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. 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.
LO
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 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 RTL view. You can use the same technique to crossprobe from other text files like placeand-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 and the RTL view. 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 Linux platforms, 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 view.
Crossprobing
Text Editor
RTL View
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.
LO
Crossprobing
3. To isolate and view only the selected objects, do this in the RTL 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 open the Messages window and then double-click the warning or error. The software opens the relevant source code file and highlights the corresponding code.
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 or source code window. To crossprobe from the FSM Viewer, do the following: 1. Open the view to which you want to crossprobe: RTL view or the source code file.
Crossprobing
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 view does 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.
LO
Analyzing With the HDL Analyst Tool

The HDL Analyst tool is a graphical productivity tool that helps you visualize your design. The tool displays RTL-level schematics that let you graphically analyze your design. The RTL view uses BEST (Behavior Extracting Synthesis Technology) to keep a high-level of abstraction and to make 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. To analyze information, compare the current view with the information in the RTL view, the log file, the FSM view, and the source code. Use techniques such as crossprobing, flattening, and filtering. See the following for more information about analysis techniques.
Viewing Design Hierarchy and Context, on page 358 Filtering Schematics, on page 361 Expanding Pin and Net Logic, on page 363 Expanding and Viewing Connections, on page 367 Viewing Connectivity, on page 369 Flattening Schematic Hierarchy, on page 370 Minimizing Memory Usage While Analyzing Designs, on page 375
For additional information about navigating the HDL Analyst views or using other techniques like crossprobing, see the following:
Working in the Schematic View, on page 322 Exploring Design Hierarchy, on page 334 Finding Objects, on page 341 Crossprobing, on page 349
Viewing Design Hierarchy and Context

Because most large designs are hierarchical, the synthesis software provides tools that help you view hierarchy details or put the details in context. Alternatively, 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. 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 361) 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)
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. LO
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 similar to 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 unnecessary hierarchy focuses analysis and saves time in large designs.
H indicates a hidden instance
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 and dissolve the selected instance with the Dissolve Instances command, or you can flatten the design. You cannot use these methods to view the internal logic of a hidden instance.
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 335 for details. 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 370 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. 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 370 for details about dissolving instances.
Flattening the entire design
Flattening an instance by dissolving
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. LO
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: Filter Schematic Command
Loads part of the design; better memory usage Combine filtering with Push/Pop mode, and history buttons (Back and Forward) to move freely between hierarchical levels
Flatten Commands
Loads entire design 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.
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) ( ). 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 hierarchical 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 288 and Transparent and Opaque Display of Hierarchical Instances, on page 293 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 358, step 4.
Filtered view
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 LO
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
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:
Trace paths, build up logic See Expanding Pin and Net Logic, on page 363 and Expanding and Viewing Connections, on page 367 Select objects and filter again See Finding Objects, on page 341 See Flattening Schematic Hierarchy, on page 370. You can hide transparent or opaque instances. See Crossprobing from the RTL View, on page 350
Filter further Find objects Flatten, or hide and flatten
Crossprobe from filtered view
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 361 and Viewing Connectivity, on page 369 of the Reference Manual.
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 367.
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 361 and Flattening Schematic Hierarchy, on page 370 for details. 1. To expand logic from a pin hierarchically across boundaries, use the following commands. To...
See all cells connected to a pin See all cells that are connected to a pin, up to the next register See internal cells connected to a pin
Do this (HDL Analyst->Hierarchical/Popup menu)...

Select a pin and select Expand. See Expanding Filtered Logic Example, on page 365. Select a pin and select Expand to Register/Port. See Expanding Filtered Logic to Register/Port Example, on page 366. 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 366.
The software expands the logic as specified, working on the current level and below or working up the hierarchy, crossing hierarchical boundaries 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 page 200 of the Reference Manual. 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 rightclick 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.
LO
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...
Select the driver of a net Trace the driver, across sheets if needed Select all instances on a net
Do this...
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 367). Select a net and select Go to Net Driver. The software shows a view that includes the net driver. Select a net and select Select Net Instances. You see a filtered view of all instances connected to the selected net.
Expanding Filtered Logic Example
Expanding Filtered Logic to Register/Port Example
Expanding Inwards Example
LO
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 363. You can also use the Timing Analyst to generate a schematic for a path between objects, as described in Analyzing Timing in Schematic Views, on page 768. 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 314 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.
2. To view connections from all pins of a selected instance, right-click and select Isolate Paths from the popup menu.
Starting Point Filtered view The Filtered View Traces Paths (Forward and Back) From All Pins of the Selected Instance... 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.
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.
LO
Viewing Connectivity
The RTL view includes an associated connectivity matrix that shows the number of interconnections among the design modules. This information is typically used during manual partitioning to visualize which elements could be assigned to the same physical device to reduce the amount of I/O interconnect between FPGAs.
Toggling the Connectivity Matrix

The connectivity matrix is enabled by default. The matrix is toggled on or off from the RTL view by selecting View->Connectivity View or by pressing F3.
Column Order
Based on the number of interconnections, the order of module entries in any column can be arranged in ascending or descending order by positioning the cursor over the column heading to be sorted (the cursor changes to a down arrow) and double-clicking to alternately display the connections in descending and ascending order.
Hidden Nets
Hidden nets only appear on multi-sheet schematics and indicate the number of connections between the currently displayed schematic sheet and the other schematic sheets. Note that a net that also has a connections on the current sheet is not counted in the hidden net total. In the simplified schematic below, there are six hidden nets (S_DATA_INDEX[7:2]).
[0]
[7:0] [1]
S_DATA_INDEX[7:0]
Connectivity Matrix Popup Menu

The connectivity matrix popup menu allows you to filter (limit) the number of modules in the matrix based on the number of interconnects. To use the popup, right click anywhere within the matrix and select Set Connection Filter to display the Connectivity Matrix Filter dialog box.
Use the slide to set the threshold; the Connection Threshold and Object Count are dynamically updated. When satisfied with the values, click OK to update the matrix. To return to the full matrix, right click in the matrix and select Filter Off. To display only the module or modules with the largest amount of interconnect, right click in the matrix and select Filter Max.
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 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 RTL view of an entire design down to logic cells, select HDL Analyst->RTL->Flattened View. This flattens the design to generic logic cells. The software flattens the top-level design and displays it in a new LO 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 361) 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 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. 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.
Opaque hierarchical instance is unaffected.
Flatten Schematic flattens unhidden transparent instance.
Hidden transparent instance is not flattened.
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.
LO
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 Current Schematic command described in step 2, which only flattens transparent 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. Starting View
Filtered
Software Generates a...

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 358. Use the Back button to return to the undissolved view. 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.
Unfiltered
The following figure illustrates this.

Dissolved logic for prgmcntr shown nested when started from filtered view
Dissolved logic for prgmcntr shown flattened in context when you start from an unfiltered view
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. LO
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 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 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 370 for details. For more information on the Expand Paths and Isolate Paths commands, see RTL View Popup Menu Commands, on page 252 of the Reference Manual.
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.
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 577 and Running the FSM Explorer, on page 581, respectively. 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.
LO
2. The following table summarizes basic viewing operations. To view...

From and to states, and conditions for each transition The correspondence between the states and the FSM registers in the RTL view Just the transition diagram without the table
Do...
Click the Transitions tab at the bottom of the table. Click the RTL Encoding tab.
Select View->FSM table or click the FSM Table icon. You might have to scroll to the right to see it.
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.
States and Conditions
RTL Encoding
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.
CountCont state filtered by input transitions
CountCont state filtered by output transitions
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 LO 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 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
LO
CHAPTER 14
Instantiating and Inferring High-Level Objects

This chapter covers techniques for optimizing your design using built-in tools or attributes. For vendor-specific optimizations, see Chapter 19, Optimizing for Specific Targets. This chapter describes the following:
Defining Black Boxes for Synthesis, on page 382 Defining State Machines for Synthesis, on page 393 Inferring RAMs, on page 398 Initializing RAMs, on page 421 Inferring Shift Registers, on page 431
Working with LPMs, on page 436
Defining Black Boxes for Synthesis

Board-level black boxes are non-FPGA devices that reside on the board like FPGAs and provide a mechanism to add third party or custom devices to your design. Board-level black boxes can include predefined devices such as a RAM, preprogrammed FPGA or IP blocks, and routing chips. An internal-logic black box is essentially any predefined or undefined block of logic within an FPGA. Internal 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. The Certify tool supports both board-level and internal-logic black boxes. Board-level black boxes are defined with the following attributes (see Chapter 25, Board Description Files): /* synthesis syn_black_box */ /* synthesis syn_partition="black_box=nameofBlackBox" */ Internal logic black boxes are defined within the RTL source module description with a syn_black_box attribute. Because an internal logic black box is an integral part of the FPGA, area resources for the black-box portion of the FPGA can be defined by including a syn_resources attribute in the black-box description. This attribute can be used with both the Xilinx and Altera technologies to define area usage in terms of LUTs and registers. When reporting area usage (Partition Info view, RTL hierarchy, or impact analysis), the value displayed is the larger of the LUTs or registers value. The remainder of this section discusses the following topics:
Instantiating Black Boxes and I/Os in Verilog, on page 383 Instantiating Black Boxes and I/Os in VHDL, on page 384 Adding Black-Box Timing Constraints, on page 387 Adding Other Black Box Attributes, on page 392
For information about using black boxes with the Fix Gated Clocks option, see Working with Gated Clocks, on page 587. LO
Instantiating Black Boxes and I/Os in Verilog

Verilog black boxes for macros and I/Os come from two sources: commonlyused or vendor-specific components that are predefined in Verilog macro libraries, and black boxes that are defined in another input source like a schematic. The following process shows you how to instantiate both types as black boxes. 1. To instantiate a predefined Verilog module as a black box:
Select the library file with the macro you need from the
certify_install_dir/lib/vendor directory. Files are named family.v. Most vendor architectures provide macro libraries that predefine the black boxes for primitives and macros. Note: For all Xilinx device families, the macro library file is named unisim.v.
Add the file to your project.

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 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. 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 directive just before the semicolon in the module
declaration.
Specify the external pad pin with the black_box_pad_pin directive.

These examples show the directives attached to different pads: module vendors_input pad(out, in) /* synthesis syn_black_box */; output out; input in /* synthesis black_box_pad_pin=1 */; ... module vendors_output pad(out, in) /* synthesis syn_black_box */; output out /* synthesis black_box_pad_pin=1 */; input in ; ...
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 4. If needed, add timing constraints, as described in Adding Black-Box Timing Constraints, on page 387. 5. After synthesis, merge the black-box netlist and the synthesis results file using the method specified by the vendor.
Instantiating Black Boxes and I/Os in VHDL

VHDL black boxes for macros and I/Os come from two sources: commonlyused or vendor-specific components that are predefined in VHDL macro libraries, or black boxes that are defined in another input source like a schematic. The following process shows you how to instantiate both types as LO black boxes. 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
certify_install_dir/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; Note: All supported Xilinx device families use a unified macro library file named unisim.vhd; include the following lines in your VHDL RTL: library unisim; use unisim.vcomponents.all 2. To create a black box for a component from another input source:
Create a component declaration for the black box. Declare syn_black_box as a boolean attribute. Set the attribute to be true.
library IEEE; use ieee.std_logic_1164.all; 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, ENB: in bit); end component; attribute syn_black_box : boolean; attribute syn_black_box of bbox: component is true; ...
Instantiate the black box and connect the ports.

begin my_bbox: my_bbox port map ( Q => q, D => data, C => clk, ENB => en, 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 that has been 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. library IEEE; use ieee.std_logic_1164.all; ... component mybuf port(O: out bit; I: in bit); end component; attribute black_box_pad_pin : string; 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 387, Using Gated Clocks for Black Boxes, on page 594, and Adding Other Black Box Attributes, on page 392. LO
Adding Black-Box Timing Constraints

When a design includes a black box, the Certify tool has no information about timing characteristics inside the black box. You must ensure that you characterize black-box timing correctly, because it can critically affect the overall timing of the design. Without timing models on black boxes, Certify cannot write out time-budgeting I/O constraints for nets that cross FPGA boundaries, and the default system clock cannot be used to write the offset constraints for the FPGA. Black-box timing constraints are defined by the syn_tsu, syn_tco, and syn_tpd directives. These directives specify the data-to-clock setup time (syn_tsu), the clock-to-output hold time (syn_tco) and, for combinational logic, the propagation delay through the black box (syn_tpd) as shown in the following figure. There are additional attributes for black box pins and black boxes with gated clocks; see Adding Other Black Box Attributes, on page 392 and Using Gated Clocks for Black Boxes, on page 594.
Black Box D syn_tsu clk syn_tco Q
syn_tpd
Timing Constraints for Internal-logic Black Boxes

To characterize the timing for internal-logic black boxes, you attach timing constraints to the instances that have been defined as black boxes. These black-box timing constraints are specified in a constraint file created using the Attributes panel of the SCOPE spreadsheet or a text editor. Using a constraint file allows the constraints to be applied without altering the source code. As an alternative to constraint files, the timing-constraint directives can be added directly to the RTL source code. To add timing constraints to a constraint file for an internal-logic black box: 1. Define the instance as a black box as described in Instantiating Black Boxes and I/Os in Verilog, on page 383 or Instantiating Black Boxes and I/Os in VHDL, on page 384. 2. Open the SCOPE spreadsheet and select the Attributes panel. 3. Select the name of the black-box module or component declaration in the Object column from the pull-down list. Prefix the name with v: to apply the constraint to the view. 4. Enter the timing constraint directive name in the Attribute column. Note that you cannot select timing constraint directives from the pull-down list. To define...
Setup delay (relative to the clock) for input pins Clock-to-output delay through the black box Combinational-only propagation delay through the black box
Directive
Value Syntax
syn_tsun bundle -> [!]clock = value syn_tcon [!]clock -> bundle = value syn_tpdn bundle -> bundle = value
Enter the value using the syntax shown in the above table. In the syntax, bundle is a collection of buses and scalar signals. Note that each directive includes a numerical suffix (n) to allow the directive to specify more than one delay value for the black box. LO
To add timing constraints directly to the RTL code for a module or component declaration of an internal-logic black box: 1. Define the instance as a black box as described in Instantiating Black Boxes and I/Os in Verilog, on page 383 or Instantiating Black Boxes and I/Os in VHDL, on page 384. 2. Determine the type and number of constraints for the timing information you want to specify: To define...
Directive
Value Syntax
Note that each directive includes a numerical suffix (n) to allow the directive to specify more than one delay value for the black box. For each directive, there are ten predeclared constraints in the attributes package, from directive_name1 to directive_name10. In VHDL, you must use the predefined attributes package to use the predeclared constraints. If you need more constraints, declare them by using the next available number in the sequence; for example: attribute syn_tc11 : string; attribute syn_tc12 : string; 3. In VHDL, use the following syntax for the constraints:
Include the predefined attributes package:

library ieee, synplify; use ieee.std_logic_1164.all use synplify.attributes.all;
Define the constraints using the syntax in the previous table.

The following is an example of the using the directives in VHDL: architecture top of top is component rcf16x4z port( ad0, ad1, ad2, ad3 : in std_logic; di0, di1, di2, di3 : in std_logic; wren, tri : in std_logic; clk : 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 -> clk = 1.2"; attribute syn_tsu2 of rcf16x4z : component is "wren,di0,di1,di2,di3 -> clk = 1.0"; 4. In Verilog, add the directives as comments, as shown in the following example: 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; input [3:0] d; input [3:0] addr; input we; input clk; endmodule
LO
Timing Constraints for Board-level Black Boxes

To characterize the timing for board-level black boxes, attach timing constraints to the instances that have been defined as black boxes. These black-box timing constraints can only be added from the Attributes panel of the SCOPE editor. Note: The port names specified on the Attributes panel of the SCOPE spreadsheet must match the pin names of the instance assigned to the black box; the black box port names and module name in the board description file are not used in the constraint. To add timing constraints for a board-level black box: 1. Define the instance as a black box as described in Instantiating Black Boxes and I/Os in Verilog, on page 383 or Instantiating Black Boxes and I/Os in VHDL, on page 384. 2. Open the SCOPE spreadsheet and select the Attributes panel. 3. Select the name of the black-box module or component declaration in the Object column from the pull-down list. Prefix the name with v: to apply the constraint to the view. 4. Enter the timing constraint directive name in the Attribute column. Note that you cannot select timing constraint directives from the pull-down list. To define...
Directive
Value Syntax
5. Enter the value using the syntax shown in the above table. In the syntax, bundle is a collection of buses and scalar signals. Note that each directive includes a numerical suffix (n) to allow the directive to specify more than one delay value for the black box.
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. The Fix gated clocks function can be applied to user-defined black boxes by adding directives to the black box to identify which inputs to the black box are clocks and which inputs to the black box are to be used as clock enables. For more information, see Using Gated Clocks for Black Boxes, on page 594.
Black Box Clk Clk buffer Pad syn_isclock black_box_pad_pin black_box_tri_pins
1. To specify that a clock pin on the black box has access to global clock routing resources, use syn_isclock. In Xilinx, the software inserts a BUFG. 2. To specify that the software need not insert a pad for a black box pin, use the black_box_pad_pin directive (pad buffers are automatically inserted for 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 a black_box_tri_pins directive. 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
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 393 Defining State Machines in VHDL, on page 395 Specifying FSMs with Attributes and Directives, on page 396
For information about the attributes used to define state machines, see Running the FSM Compiler, on page 577.
Defining State Machines in Verilog

The synthesis software recognizes and automatically extracts state machines from the Verilog source code if you follow these coding guidelines. The software attaches the syn_state_machine attribute to each extracted FSM. For alternative ways to define state machines, see Defining State Machines in VHDL, on page 395 and Specifying FSMs with Attributes and Directives, on page 396.
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 statement 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.
Use explicit state values for states using parameter or define statements. 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 statements: 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 whereas parameter definitions are local. Local definitions make it easier to reuse certain state names in multiple FSM designs. For example, you might want to reuse common state names like RESET, IDLE, READY, READ, WRITE, ERROR and DONE. If you use `define to assign state names, you cannot reuse a state name because the name has already been taken in the global name space. To use the names multiple times, you have to ùndef state names between modules and redefine them with `define state names in the new FSM modules. This method makes it difficult to probe the internal values of FSM state buses from a testbench and compare them to the state names.
LO
Defining State Machines in VHDL

The synthesis software recognizes and automatically extracts state machines from the VHDL source code if you follow coding guidelines. For alternative ways to define state machines, see Defining State Machines in Verilog, on page 393 and Specifying FSMs with Attributes and Directives, on page 396. 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 IFTHEN-ELSE statements, but CASE statements are preferable.
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 automatically with the FSM Compiler (see Optimizing State Machines, on page 576), or you can manually specify attributes to define the state machines. You attach the attributes to the state registers. For detailed information about the attributes and their syntax, see the Reference Manual. The following steps show you how to use attributes to define FSMs for extraction. For alternative ways to define state machines, see Defining State Machines in Verilog, on page 393 and Defining State Machines in VHDL, on page 395. 1. To determine how state machines are extracted, set attributes in the source code as shown in the following table: To...
Specify a state machine for extraction and optimization Prevent state machines from being extracted and optimized Prevent the state machine from being optimized away
Attribute syn_state_machine=1 syn_state_machine=0 syn_preserve=1
For information about how to add attributes, see Adding Attributes and Directives, on page 110. 2. To determine the encoding style used 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 this setting. The different values for this attribute are briefly described here:
LO
Situation: If...
Area is important Speed is important Recovery from an invalid state is important
syn_encoding Value sequential onehot safe, with another style. For example: /* synthesis syn_encoding = "safe, onehot" */
Explanation
One of the smallest encoding styles. Usually the fastest style and suited to most FPGA styles. Forces the state machine to reset. For example, where an alpha particle hit in a hostile operating environment causes a spontaneous register change, you can use safe to reset the state machine. Default encoding. 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. Fastest style, because each state variable has one bit set, and only one bit of the state register changes at a time.
There are <5 states Large output decoder follows the FSM
sequential sequential or gray
There are a large number of flipflops
onehot
3. If you are using VHDL, you have two choices for defining encoding:
Use syn_encoding as described above, and enable the FSM compiler. 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 this method for user-defined FSM encoding. For example: attribute syn_enum_encoding of state_type : type is "001 010 101";
Inferring RAMs
Inferring RAMs
There are two methods of handling RAMs: instantiation and inference. The software can automatically infer RAMs if they are structured correctly in your source code. For details, see the following sections:
Inference Versus Instantiation, on page 398 Basic Guidelines for Coding RAMs, on page 399 Specifying RAM Implementation Styles, on page 404 Implementing Altera RAMs Automatically, on page 405 Implementing Xilinx RAMs Automatically, on page 408 Implementing Altera Stratix Multi-Port RAMs, on page 410 Inferring Altera Stratix III LUTRAMs, on page 411 Inferring Xilinx Block RAMs Using Registered Addresses, on page 412 Inferring Xilinx Block RAMs Using Registered Output, on page 415 Setting Xilinx RAM Initialization Values, on page 425 Mapping Xilinx ROM to Block RAM, on page 420
For information about generating RAMs with SYNCore, see Specifying RAMs with SYNCore, on page 469.
Inference Versus Instantiation

There are two methods to handle RAMs: instantiation and inference. Many FPGA families provide technology-specific RAMs that you can instantiate in your HDL source code. The software supports instantiation, but you can also set up your source code so that it infers the RAMs. The following table sums up the pros and cons of the two approaches. Inference in Synthesis Advantages LO Portable coding style Automatic timing-driven synthesis No additional tool dependencies
Instantiation Advantages Most efficient use of the RAM primitives of a specific technology Supports all kinds of RAMs
Inferring RAMs
Inference in Synthesis Limitations Glue logic to implement the RAM might result in a sub-optimal implementation. Can only infer synchronous RAMs No support for address wrapping No support for RAM enables, except for write enable Pin name limitations means some pins are always active or inactive
Instantiation Limitations Source code is not portable because it is technology-dependent. Limited or no access to timing and area data if the RAM is a black box. Inter-tool access issues, if the RAM is a black box created with another tool.
Basic Guidelines for Coding RAMs

Read through the limitations before you start. See Inference Versus Instantiation, on page 398 for information. The following steps describe general rules for coding RAMs so that the compiler infers them; to ensure that they are mapped to the vendor-specific implementation you want, see Specifying RAM Implementation Styles, on page 404, Implementing Altera RAMs Automatically, on page 405, and Implementing Xilinx RAMs Automatically, on page 408. 1. Make sure that the RAM meets minimum size and address width requirements for your technology. The software implements RAMs that are smaller than the minimum as registers. 2. Structure the assignment to a VHDL signal/Verilog register as follows:
To infer a RAM, structure the code as an indexed array or a case

structure. Code it as a two-dimensional array (VHDL) or memory (Verilog) with writes to one process.
Control the structure with a clock edge and a write enable.

The software extracts RAMs even if write enables are tied to true (VCC), if you have complex write enables coded in nested IF statements, or if you have RAMs with synchronous resets. 3. For a single-port RAM, make the address for indexing the write-to the same as the address for the read-from. The following code and figure illustrate how the software infers a single-port RAM.
Inferring RAMs
library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_signed.all; entity ramtest is port (q : out std_logic_vector(3 downto 0); d : in std_logic_vector(3 downto 0); addr : in std_logic_vector(2 downto 0); we : in std_logic; clk : in std_logic); end ramtest; architecture rtl of ramtest is type mem_type is array (7 downto 0) of std_logic_vector (3 downto 0); signal mem : mem_type; begin q <= mem(conv_integer(addr)); process (clk) begin if rising_edge(clk) then if (we = '1') then mem(conv_integer(addr)) <= d; end if; end if; end process; end rtl;
LO
Inferring RAMs
For technology-specific details, see Implementing Altera RAMs Automatically, on page 405 and Implementing Xilinx RAMs Automatically, on page 408. 4. For a dual-port RAM, make the write-to and read-from addresses different. The following figure and code example illustrate how the software infers a dual-port RAM.
module ram16x8(z, raddr, d, waddr, we, clk); output [7:0] z; input [7:0] d; input [3:0] raddr, waddr; input we; input clk; reg [7:0] z; reg [7:0] mem0, mem1, mem2, mem3, mem4, mem5, mem6, mem7; reg [7:0] mem8, mem9, mem10, mem11, mem12, mem13, mem14, mem15; always @(mem0 or mem1 or mem2 or mem3 or mem4 or mem5 or mem6 or mem7 or mem8 or mem9 or mem10 or mem11 or mem12 or mem13 or mem14 or mem15 or raddr) begin case (raddr[3:0]) 4'b0000: z = mem0; 4'b0001: z = mem1; 4'b0010: z = mem2; 4'b0011: z = mem3; 4'b0100: z = mem4; 4'b0101: z = mem5; 4'b0110: z = mem6; 4'b0111: z = mem7; 4'b1000: z = mem8; 4'b1001: z = mem9; 4'b1010: z = mem10;
Inferring RAMs
4'b1011: 4'b1100: 4'b1101: 4'b1110: 4'b1111: endcase end
z z z z z
= = = = =
mem11; mem12; mem13; mem14; mem15;
always @(posedge clk) begin if(we) begin case (waddr[3:0]) 4'b0000: mem0 = d; 4'b0001: mem1 = d; 4'b0010: mem2 = d; 4'b0011: mem3 = d; 4'b0100: mem4 = d; 4'b0101: mem5 = d; 4'b0110: mem6 = d; 4'b0111: mem7 = d; 4'b1000: mem8 = d; 4'b1001: mem9 = d; 4'b1010: mem10 = d; 4'b1011: mem11 = d; 4'b1100: mem12 = d; 4'b1101: mem13 = d; 4'b1110: mem14 = d; 4'b1111: mem15 = d; endcase end end endmodule For technology-specific details, see Implementing Altera RAMs Automatically, on page 405 and Implementing Xilinx RAMs Automatically, on page 408. 5. To infer multi-port RAMs or nrams (certain technologies only), do the following:
Target a technology that supports multi-port RAMs. Register the read address. Add the syn_ramstyle attribute with a value of no_rw_check. If you do not
do this, the compiler errors out. LO Make sure that the writes are to one process. If the writes are to multiple processes, use the syn_ramstyle attribute to specify a RAM.
Inferring RAMs
6. For RAMs where inference is not the best solution, use either one of these approaches:
Implement them as regular logic using the syn_ramstyle attribute with

a value of registers. You might want to do this if you have to conserve RAM resources.
Instantiate RAMs using the black box methodology. Use this method
in cases where RAM is implemented in two cells instead of one because the RAM address range spans the word limit of the primitive and the software does not currently support address wrapping. If the address range is 8 to 23 and the RAM primitive is 16 words deep, the software implements the RAM as two cells, even though the address range is only 16 words deep. Refer to the list of limitations in Inference Versus Instantiation, on page 398 and the vendor-specific information referred to in the previous step to determine whether you should instantiate RAMs. 7. Synthesize your design. The compiler infers one of the following RAMs from the source code. You can view them in the RTL view:
RAM1 RAM2 NRAM RAM Resettable RAM Multi-port RAM
If the number of words in the RAM primitive is less than the required address range, the compiler generates two RAMs instead of one, leaving any extra addresses unused. Once the compiler has inferred the RAMs, the mapper implements the inferred RAMs in the technology you specified. For details of how to map the RAM inferred by the compiler to the implementation you want, see Specifying RAM Implementation Styles, on page 404, Implementing Altera RAMs Automatically, on page 405, and Implementing Xilinx RAMs Automatically, on page 408.
Inferring RAMs
Specifying RAM Implementation Styles

You can manually influence how RAMs are implemented with the syn_ramstyle attribute, as described in the following procedure. The valid values vary slightly, depending on the technology you use. Check the Reference Manual for the values that apply to the technology you choose. If you would rather set up your design so that the software automatically maps the RAMs to the components you want, see Implementing Altera RAMs Automatically, on page 405 and Implementing Xilinx RAMs Automatically, on page 408 for some vendor-specific details. 1. If you do not want to use RAM resources, attach the syn_ramstyle attribute with a value of registers to the RAM instance name or to the signal driven by the RAM. Use this value for small RAMs. The software implements the RAMs according to the technology. They can be implemented as registers or LPMs. 2. To use the dedicated memory resources on the FPGA (Altera technologies), do the following:
Set syn_ramstyle to block_ram. Specify mapping to TriMatrix memories by setting syn_ramstyle to

M512, M4K, or M-RAM.
If you do not want glue logic created, register the RAM output. For
Altera designs, you can set syn_ramstyle to no_rw_check. 3. To implement RAMs using dedicated Block SelectRAM+ in Xilinx Virtex technologies, do the following. To use distributed memory, see the next step.
Set syn_ramstyle to block_ram. Register the read address, because the technology is fully
synchronous.
If you do not want to generate glue logic for dual-port RAMs, either
register the RAM output or set syn_ramstyle to no_rw_check. Use this attribute value only if you do not care about a read/write check. 4. To implement RAMs using distributed memory in Xilinx technologies, LO set syn_ramstyle to select_ram. Set syn_ramstyle explicitly, because by default the software first implements block RAM, and select RAM only if it cannot implement block RAM.
Inferring RAMs
Implementing Altera RAMs Automatically

The following procedure shows you how to implement various Altera RAMs automatically. You can always override the automatic implementation by specifying the syn_ramstyle attribute, as described in Specifying RAM Implementation Styles, on page 404 or instantiate LPMs instead of using RAMs. 1. Follow the guidelines described for RAM inference by the compiler (Basic Guidelines for Coding RAMs, on page 399). The Altera mapper does not implement any RAMs that are not first inferred by the compiler. 2. To implement Stratix block RAM, follow these guidelines:
If you are a Verilog user, avoid using blocking statements when you
model the RAMs because not all blocking assignments are mapped to block RAM.
Synchronize the read and write addresses by registering either the

read address or output. RAMs with asynchronous read and write are mapped to logic.
Use syn_ramstyle with a value of no_rw_check to disable the creation of

glue logic in dual-port mode.
Make sure the Altera Quartus tool is installed for best results with
Stratix devices. When Quartus is installed, the synthesis software takes advantages of the Stratix RAMs and MACs and writes out Stratix primitives that you can view in the Technology view. If you do not install Quartus, the synthesis software infers LPMs. During synthesis, the mapper maps Altera Stratix RAM to ALTSYNCRAM in the following modes:
Single-port Dual-port One address bus One address bus (where old data cannot be obtained in single-port mode), or Two buses: one each for read and write. Two buses: one for read/write and one for read only
Bidirectional
3. To implement Stratix single-port RAMs, ensure the following:
The read and write addresses share a single address. There is only one data input.
Inferring RAMs
There is only RAM output. Either the read address or the output is registered. For multiple clocks, both the read address and the output must be
registered. The mapper maps the RAM to the dedicated memory resource, ALTSYNCRAM, which is fully synchronous. It is mapped in SINGLE_PORT mode, and all ports are registered. The ALTSYNCRAM implementation is determined by the Quartus place-and-route tool.
4. To implement Stratix dual-port RAMs, make sure of the following:
The code is written so that the hardware exactly matches the RTL
behavior. For example, if your code allows simultaneous reads and writes to the same address, it can result in a mismatch between the RTL and hardware behaviors. In such a case, the mapper does not map the RAM inferred by the compiler to the dedicated ALTSYNCRAM resources and you get a warning message.
The design has different read and write addresses. There is only one data input. There is only RAM output. Either the read address or the output is registered. The read and write addresses can have different clocks. However if you register the read, write, and output, at least two of them must share a clock. registered.
For multiple clocks, both the read address and the output must be
LO The mapper maps the RAM to ALTSYNCRAM in DUAL_PORT mode, which is fully synchronous. The actual ALTSYNCRAM implementation is determined by the Quartus place-and-route tool.
Inferring RAMs
The following figure shows one dual-port RAM implementation:
5. To implement Stratix dual-port RAMs in bidirectional mode, make sure of the following:
The code must be written so that there are no mismatches between

the hardware and RTL behaviors.
The design has different read and write addresses. There are two read
addresses.
There is only one data input. There are two RAM outputs. Either the read address or the output is registered. The read and write addresses can have different clocks. However if you register the read, write, and output, at least two of them must share a clock. registered.
For multiple clocks, both the read address and the output must be
The mapper maps the RAM to ALTSYNCRAM in BIDIR_DUAL_PORT mode, which is fully synchronous. The actual ALTSYNCRAM implementation is determined by the Quartus place-and-route tool. 6. To implement Stratix multi-ports RAMs automatically, see Implementing Altera Stratix Multi-Port RAMs, on page 410.
Inferring RAMs
Implementing Xilinx RAMs Automatically

The following procedure shows you how to implement various Xilinx RAMs automatically. You can always override the automatic implementation by specifying the syn_ramstyle attribute, as described in Specifying RAM Implementation Styles, on page 404. 1. Follow the guidelines described for RAM inference by the compiler (Basic Guidelines for Coding RAMs, on page 399). The Xilinx mapper does not implement any RAMs that are not first inferred by the compiler. 2. To automatically implement distributed RAM, make sure the write operation is synchronous and the read operation is asynchronous. The Xilinx mapper implements RAMs inferred by the compiler as asynchronous RAMs, using the CLB resources. 3. To implement block SelectRAM+, do the following:
Make the write port synchronous. The read port can be

asynchronous.
Register the read address (see Inferring Xilinx Block RAMs Using
Registered Addresses, on page 412).
Make sure the RAM is a minimum of 2K bits.

The Xilinx mapper automatically implements RAMs inferred by the compiler as Block SelectRAM+, using the dedicated memory resources on the FPGA. The enable pin is tied to active and the reset pin is tied to inactive. 4. To implement single-port block RAM automatically, do the following:
Register the output. (see Inferring Xilinx Block RAMs Using

Registered Output, on page 415).
Make the read and write addresses the same. Make sure that the read and write clocks are the same. Make sure the read and write enables are the same.
The Xilinx mapper automatically implements RAMs inferred by the compiler as single-port LO Block SelectRAM+, using the dedicated memory resources on the FPGA. The enable signal has the highest priority. Where applicable, the tool uses the parity bus to infer data bus widths.
Inferring RAMs
The mapper also uses the Write modes in some Xilinx architectures, as described in the next step. 5. To implement dual-port block RAM automatically, do the following:
Register the output. (see Inferring Xilinx Block RAMs Using

Registered Output, on page 415).
Your design can have different read and write addresses, multiple
clocks, and different read and write enables. The Xilinx mapper implements RAMs inferred by the compiler as dualport block SelectRAM+, using the dedicated memory resources on the FPGA. The dual-port RAM has only one write port. The software automatically inserts glue logic for address collision and recovery, unless you specify otherwise with the syn_ramstyle attribute. The mapper also implements the Write modes available with certain Xilinx architectures to indicate the output value when the write enable is active. The RAM implementations are shown here: Write Mode Writefirst (data_in goes to data_out) Xilinx Architecture
Virtex-II, Virtex-II Pro, Virtex-4, Virtex-5, Spartan-3 Virtex, Virtex-E
RAM Implementation
Block SelectRAM+ (single-port or dual-port) Distributed RAM Block SelectRAM+ (single-port or dual-port) Distributed RAM Block SelectRAM+ (single-port) Distributed RAM Distributed RAM Block SelectRAM+ (single-port) Distributed RAM Distributed RAM
Readfirst (memory goes to data_out)
Virtex-II, Virtex-II Pro, Virtex-4, Spartan-3 Virtex, Virtex-E
Nochange (data_out is unchanged)
Virtex-II, Virtex-II Pro, Virtex-4, Spartan-3 Virtex, Virtex-E
Inferring RAMs
6. To implement true dual-port block (multi-port) RAM automatically, make sure the design meets the following conditions:
The compiler has inferred multi-port RAMs (nrams). See Basic

Guidelines for Coding RAMs, on page 399 for details.
The inferred nram has two writes and one read. The read shares an
address with only one of the write ports, or two inferred RAMs share the same write addresses, clocks, and enables, but have different read addresses. In the latter case, the mapper pairs the RAMs together and maps them to true dual-port RAM. The Xilinx mapper implements RAMs inferred by the compiler as true dual-port block SelectRAM+, using the dedicated memory resources on the FPGA. The dual-port RAM has one read port and multiple write ports. Each write port has its own write clock, write enable, data in, and write address.
Implementing Altera Stratix Multi-Port RAMs

The software can infer true multi-port RAMs, where both ports are used to read and write simultaneously. Implementing Stratix ALTSYNCRAM components is a two-step process: first the synthesis compiler infers the RAM primitive, and then the mapper maps the primitive to ALTSYNCRAM. 1. Make sure the compiler infers an nram, by following the guidelines in Basic Guidelines for Coding RAMs, on page 399. For multi-port RAMs, the compiler infers an nram primitive, where n is the number of write ports. You can view this in the RTL view. 2. To map the nram automatically to ALTSYNCRAM, ensure that it follows these guidelines:
The nram has two writes and one read. The read shares an address
with only one of the write ports.
Make sure there are only two clocks, one for each port. You cannot have more than two write ports; nram primitives with
more than two ports are mapped to logic.
The read address is registered. LO If the output is registered, the mapper retimes and infers block RAM.
Inferring RAMs
The software maps nram primitives as follows: Primitive Description

Two write ports, one read port. The read shares an address with only one of the write ports Two nrams each with two write addresses and one read address, which share the same write addresses, clocks, and enables, but different read addresses > Two write ports > Two clocks
Mapping
ALTSYNCRAM in bidir mode
Paired together and mapped to ALTSYNCRAM
Logic Logic
After synthesis, the software writes out the following for the place-androute tool: defparam mem_1_1_Z.lpm_type = "altsyncram";
Inferring Altera Stratix III LUTRAMs

The Altera Stratix III technology has 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. 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.
Inferring RAMs
For Verilog code examples that implement LUTRAM, see Stratix III LUTRAM Verilog Examples, on page 502 in the Reference Manual. 4. Synthesize your design. The software maps the memory, and reports resource utilization in the log file. For 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:
Inferring Xilinx Block RAMs Using Registered Addresses

There are two ways to infer block RAMs in Xilinx Virtex designs: using registered addresses and using registered output. For information about the latter, see Inferring Xilinx Block RAMs Using Registered Output, on page 415. The following procedure shows you how to set up your code with an explicit read address register. The software does not currently infer block RAMs for Virtex designs automatically; you have to use an attribute. It inserts bypass logic to resolve a read/write behavior difference between the RTL and post-synthesis gate-level simulations. It inserts the glue logic because it does not know the output at the read port when the read address and the write address access the same memory location. 1. Use instantiation instead of inference in the following cases where the LO software currently does not infer the RAMs:
RAMs with enable signals, RAM resets, or initialization settings.

Inferring RAMs
Inaccessible pins: read enable pins are always active, and reset pins
are always inactive.
Dual-port RAMs with read/write on a port.

2. For single-port RAM, do the following:
Make sure the read and write clocks are the same. Make sure the read and write addresses are the same. Make sure the enable signals are the same. Use only write enable
signals.
Register the address, as shown in the following code:

always @(posedge clk) if(we) mem[addr] = din; always @(posedge clk) addr_reg = addr; assign dout = mem[addr_reg]
To forward-annotate initialization values, use the Xilinx INIT property,

as described in Setting Xilinx RAM Initialization Values, on page 425. 3. For dual-port RAM, do the following:
Register the address as shown in this code:
Inferring RAMs
always @(posedge clk) if(we) mem[waddr] = din; always @(posedge clk) raddr_reg = raddr; assign dout = mem[raddr_reg]
+ Glue logic to resolve read/write discrepancies
To forward-annotate initialization values, see Setting Xilinx RAM

Initialization Values, on page 425. 4. To prevent the insertion of glue logic, add the syn_ramstyle="no_rw_check" attribute. By default, the software inserts glue logic when the read and write addresses access the same memory location, because it does not know the output of the read port. The glue logic prevents a mismatch between the RTL and post-synthesis simulation results. See Specifying RAM Implementation Styles, on page 404 or the Reference Manual for more information about this attribute. 5. To infer Virtex block RAM, add the syn_ramstyle="block_ram" attribute to the register signal in your source code, or to the output signal of the RAM in the SCOPE window. See Specifying RAM Implementation Styles, on page 404 or the Reference Manual for more information about this attribute. 6. Run synthesis. The software implements the circuit using Xilinx RAMB4_S<n>_-S<n> primitives. The Xilinx dual-port block RAM is implemented with one LO write port.
Inferring RAMs
Inferring Xilinx Block RAMs Using Registered Output

For Virtex-II and Virtex-II Pro designs, you can code block RAMs with registered output as described here, or with registered addresses (see Inferring Xilinx Block RAMs Using Registered Addresses, on page 412). For information about forward-annotating initialization values, see Setting Xilinx RAM Initialization Values, on page 425. This information is organized into these subtopics:
Advantages of Using Registered Output, on page 415 Block RAM Mapping for Virtex-II Write Modes, on page 415 Xilinx Single-Port Example with Registered Output, on page 417 Xilinx Single-Output Dual-Port Example with Registered Output, on page 419
Advantages of Using Registered Output

The registered output method allows you to use reset and enable lines as well as the different write modes in Virtex architectures. The following table shows the advantages of using registered output instead of registered addresses: Registered Read Address
Read and write clocks must be the same No enable, reset supported
Registered Output
Can have different clocks Supports enable and reset signals
Block RAM Mapping for Virtex-II Write Modes

The following table summarizes how the software implements Block RAM for the write modes in different Virtex families when you register the outputs. See Xilinx Single-Port Example with Registered Output, on page 417 and Xilinx Single-Output Dual-Port Example with Registered Output, on page 419 for examples.
Inferring RAMs
Virtex
Virtex-E
Virtex-II
Virtex-II Pro
WRITEFIRST Mode
With enable and reset, enable takes precedence With enable and reset, reset takes precedence Without enable Without reset Without enable or reset SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP SP
READFIRST Mode
With enable and reset, enable takes precedence With enable and reset, reset takes precedence Without enable Without reset Without enable or reset Select RAM Select RAM Select RAM Select RAM Select RAM Select RAM Select RAM Select RAM Select RAM Select RAM SP SP SP SP SP SP SP SP SP SP
NOCHANGE Mode
With enable and reset, enable takes precedence With enable and reset, reset takes precedence Without enable Without reset Without enable or reset DP DP DP DP DP DP DP DP DP DP SP SP SP SP SP SP SP SP SP SP
SP: Single-port block RAM LO DP: Single-output, dual-port block RAM
Inferring RAMs
Xilinx Single-Port Example with Registered Output

This example shows the single-port 257x9 RAM with reset and enable extracted from the following code, where the output is registered. To forwardannotate initialization values, use the Xilinx INIT property as described in Setting Xilinx RAM Initialization Values, on page 425.
Inferring RAMs
library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity ramtest is port( do : out std_logic_vector(8 downto 0); addr : in std_logic_vector(8 downto 0); di : in std_logic_vector(8 downto 0); en,clk,we,rst : in std_logic); end ramtest; architecture beh of ramtest is type memtype is array (256 downto 0) of std_logic_vector(8 downto 0); signal mem : memtype; attribute syn_ramstyle : string; attribute syn_ramstyle of mem : signal is "block_ram"; begin process(clk) begin if clk'event and clk='1' then if(en='1') then if (rst='1') then do <= "000000000"; elsif (we='1') then do <= di; else do <= mem(CONV_INTEGER(addr)); end if; end if; end if; end process; process(clk) begin if clk'event and clk='1' then if (en='1' and we='1') then mem(CONV_INTEGER(addr)) <= di; end if; end if; end process; end beh; LO
Inferring RAMs
Xilinx Single-Output Dual-Port Example with Registered Output

For Virtex and Virtex-II Pro designs, the software maps components to singleoutput dual-port block RAMs when the RAMs are coded with different read and write addresses, different read and write clocks, and different enable signals. To forward-annotate initialization values, see Setting Xilinx RAM Initialization Values, on page 425. In the following example, the read port has no enable, and the component is mapped to single-output dual-port block RAM: always@(posedge clk_r) if(rst == 1) data_out = 0; else data_out = mem[addr_out]; always @(posedge clk_w) if (we) mem[addr_in] = data_in;
Inferring RAMs
Mapping Xilinx ROM to Block RAM

For Xilinx Virtex architectures, the software can map ROM into block RAM, provided you follow the guidelines in this procedure. 1. Place a dff register in front of the ROM, or place one of the following after the ROM: Asynchronous dff, dffe dffr, dffre dffs, dffse dffpatr, dffpatre sdffr, sdffre sdffs, sdffse sdffpatr, sdffpatre Synchronous
where dffe is an enabled flip-flop, dffre is an enabled flip-flop with asynchronous reset, dffse is an enabled flip-flop with asynchronous set, and dffpatre is an enabled, vectored flip-flop with asynchronous reset pattern. 2. Ensure that the registers and ROMs are within the same hierarchy. 3. Ensure that the number of outputs of the candidate ROM is 64 or fewer. 4. Make sure that at least half the addresses possess assigned values. For example, in a ROM with ten address bits (1024 unique addresses), at least 512 of those unique addresses must be assigned values. 5. Specify the syn_romstyle attribute with the value set to block_rom. 6. Synthesize the design. The software maps the ROM into block RAM.
LO
Initializing RAMs
Initializing RAMs
You can specify startup values for RAMs and pass them on to the place-androute tools. See the following for ways to set the initial values:
Initializing RAMs in Verilog, on page 421 Initializing RAMs in VHDL, on page 422 Setting Xilinx RAM Initialization Values, on page 425
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 the 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). For Xilinx RAMs, you can alternatively initialize RAMs using the INIT property, as described in Specifying the INIT Property for Xilinx RAMs (Verilog), on page 426 and Specifying the INIT Property with Attributes, on page 429. 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 466 in 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 | $readmemh ("fileName", memoryName) ; Use $readmemb for a binary file and $readmemh for a hex file. For descriptions of the syntax, see Initial Values in Verilog, on page 463 in the Reference Manual.
Initializing RAMs
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 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] me_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 425.
Initializing RAMs in VHDL

There are two ways to initialize RAMs in the VHDL code: with signal declarations or with variable declarations. For Xilinx RAMs, you can also initialize RAMs using the INIT property (see Specifying the INIT Property for Xilinx RAMs (VHDL), on page 428 and Specifying the INIT Property with Attributes, on page 429).
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 424 and Specifying the INIT Property for Xilinx RAMs (VHDL), on page 428. library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; LO
Initializing RAMs
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; 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)
Initializing RAMs
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 VHDL Rams with Variable Declarations

The following example shows a RAM that is initialized with variable declarations. For alternative methods, see Initializing VHDL Rams with Signal Declarations, on page 422 and Initializing RAMs with $readmemb and $readmemh, on page 425. library ieee; use ieee.std_logic_1164.all; 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 if rising_edge(clk) then LO out1 <= mem(to_integer(raddr1)); if (we1 = '1') then
Initializing RAMs
mem(to_integer(waddr1)) := data_a; end if; end if; end process WRITE1_RAM; end rtl;
Setting Xilinx RAM Initialization Values

In addition to the methods described in Initializing RAMs in Verilog, on page 421 and Initializing RAMs in VHDL, on page 422, you can forwardannotate RAM initialization values using the Xilinx INIT property. If you are using Verilog, you can also initialize the RAM using the $readmemb and $readmemh system tasks. See the following:
Initializing RAMs with $readmemb and $readmemh, on page 425 Specifying the INIT Property for Xilinx RAMs (Verilog), on page 426 Specifying the INIT Property for Xilinx RAMs (VHDL), on page 428 Specifying the INIT Property with Attributes, on page 429
Note the following differences between the 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.
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 466 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 | $readmemh ("fileName", memoryName) ; Use $readmemb for a binary file and $readmemh for a hex file. For details about the syntax, see Initial Values in Verilog, on page 463 in the Reference Manual.
Initializing RAMs
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 426
Using Global Comments to Specify Initialization Values for Xilinx RAMs,

on page 427
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; name xx value
Is the name of the RAM. Indicates the part of the RAM you are initializing. It can be any hex number from 00 to FF. Sets the initialization value in hex.
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 "; LO defparam pkt_len_ram_lo.INIT_01= "00270026002500240023002200210020001f001e001d001c001b001a00190018;
Initializing RAMs
defparam pkt_len_ram_lo.INIT_02= "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.
Using Global Comments to Specify Initialization Values for Xilinx RAMs

1. Add the INIT property.
Attach the INIT property to the instance as shown:

RAM Block RAM
/* synthesis INIT = "value" */ /* synthesis INIT_xx = "value" */
Define the INIT_xx=value property as follows:

xx
value Indicate the part of the RAM you are initializing with a number from 00 to FF. 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.
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.
Initializing RAMs
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 .CLK .RST .EN .WE .ADDR .DI .DO ) pkt_len_ram_lo ( (clock), (1'b0), (1'b1), (we), (address), (data), (q)
/* synthesis INIT_00="00170016001500140013001200110010000f000e000d000c000b000a00090008" INIT_01="00270026002500240023002200210020001f001e001d001c001b001a00190018" INIT_02="00370036003500340033003200310030002f002e002d002c002b002a00290028" ... INIT_0F="0107010601050104010301020101010000ff00fe00fd00fc00fb00fa00f900f8" */; When you synthesize the design, the software forward-annotates the RAM initialization information to the Xilinx place-and-route software.
Specifying the INIT Property for Xilinx RAMs (VHDL)

1. Add the INIT property.
Attach the INIT property to the label as shown:

RAM Block RAM
attribute INIT of object : label is "value"; attribute INIT_xx of object : label is "value";
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";: LO
Initializing RAMs
3. For Virtex block RAM, specify 16 different INIT statements.
Define the INIT_xx=value property as follows:

xx
value Indicate the part of the RAM you are initializing with a number from 00 to FF. 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.
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.
End the initialization data with a semicolon.

When you synthesize the design, the software forward-annotates the RAM initialization information to the Xilinx place-and-route software.
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) orINIT_xx = value (Block RAM) property in SCOPE. Alternatively you can edit the sdc file using define_attribute statements. xx
value Indicates the part of the RAM you are initializing with a number from 00 to FF. 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.
Initializing RAMs
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. When you synthesize the design, the software forward-annotates the 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 Xilinx place-and-route software.
LO
Inferring Shift Registers

The software infers shift registers for Xilinx Virtex and Altera Stratix architectures. Use the following procedure. 1. Set up the HDL code for the sequential shift components. See Shift Register Examples, on page 433 for examples. Note the following for Xilinx shift registers:
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. 2. If needed, set the implementation style with the syn_srlstyle attribute. If you do not want the components automatically mapped to shift registers, set the value to registers. syn_srlstyle Value registers select_srl no_extractff_srl altshift_tap Implemented as...
registers Xilinx SRL16 primitives Xilinx SRL16 primitives without output flip-flops Altera Altshift_tap components
You can set the value globally or on individual modules or registers.
3. For Altera shift registers, use attributes to control how the registers are packed: To...
Prevent a register from being packed into shift registers Prevent two registers from being packed into the same shift registers
Attach... syn_noprune to the register. You can also use syn_srlstyle with a value of registers. syn_keep between the two registers. The algorithm slices the chain vertically, and packs the two registers into separate shift registers. syn_srlstyle with different group names for the registers you want to separate (syn_srlstyle= altshift_tap, group_name)
Specify that two registers be packed in different shift registers
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 attribute values you set. 5. Check the results in the log file and the technology file. The log file LO reports the shift registers and the number of registers packed in them.
Shift Register Examples Altera Shift Register (VHDL)

library ieee; use ieee.std_logic_1164.all; 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); tap6 : out std_logic_vector(31 downto 0); tap5 : out std_logic_vector(31 downto 0); tap4 : out std_logic_vector(31 downto 0); tap3 : out std_logic_vector(31 downto 0); tap2 : 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; dout tap7 tap6 tap5 tap4 tap3 tap2 tap1 <= <= <= <= <= <= <= <= q(31); q(27); q(23); q(19); q(15); q(11); q(7); 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 assign assign assign assign assign assign assign dout tap7 tap6 tap5 tap4 tap3 tap2 tap1 = = = = = = = = q[63]; q[55]; q[47]; q[39]; q[31]; q[23]; q[15]; q[7];
always @(posedge clk) if (shift) begin q[0] <= din; for (n=0; n<63; n=n+1) begin 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 LO 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;
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
Working with LPMs

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. Black Box Method
Applies to any LPM Synthesis LPM timing support Synthesis procedure Yes No More coding
Verilog Library/VHDL Prepared Component Method

No Yes Simple
See the following for more information about instantiating LPMs:
Instantiating Altera LPMs as Black Boxes, on page 437 Instantiating LPMs Using VHDL Prepared Components, on page 441 Instantiating LPMs Using a Verilog Library (Altera), on page 442
LO
Working with LPMs
Instantiating Altera LPMs as Black Boxes

The method described here uses either Verilog or VHDL LPMs in the Alteraprescribed megafunction format. Alternatively, you can use the methods described in Instantiating LPMs Using a Verilog Library (Altera), on page 442 or Instantiating LPMs Using VHDL Prepared Components, on page 441. For information about using Clearbox in Stratix designs, see Implementing Megafunctions with Clearbox Models, on page 715. 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 437 and LPM Megafunction Example (VHDL), on page 439. 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 437 and LPM Megafunction Example (VHDL), on page 439. 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.
Working with LPMs
module mylpm ( data, wren, wraddress, rdaddress, clock, q)/* synthesis syn_black_box */; input input input input input output [7:0] data; wren; [4:0] wraddress; [4:0] rdaddress; clock; [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", altsyncram_component.outdata_aclr_b = "NONE", altsyncram_component.read_during_write_mode_mixed_ports = "DONT_CARE", LO altsyncram_component.ram_block_type = "AUTO", altsyncram_component.intended_device_family = "Stratix"; endmodule
Working with LPMs
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; outdata_aclr_b : STRING; read_during_write_mode_mixed_ports ram_block_type : STRING; intended_device_family : STRING );
: STRING;
Working with LPMs
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" ) PORT MAP ( wren_a => wren, clock0 => clock, address_a => wraddress, address_b => rdaddress, data_a => data, q_b => sub_wire0 ); LO END SYN;
Working with LPMs
Instantiating LPMs Using VHDL Prepared 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 437), or Instantiating LPMs Using a Verilog Library (Altera), on page 442 (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 install_dir\lib\vhd directory. The Altera LPM prepared components are in lpm. 2. Instantiate the prepared component. For Altera LPMs, see Altera LPMs, on page 1016 in the Reference Manual. 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. This is an example of an LPM instantiated at a higher level: library ieee, lpm; use ieee.std_logic_1164.all; 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:
Working with LPMs
library lpm; use lpm.lpm_components.all; library ieee; use ieee.std_logic_1164.all; 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;
Instantiating LPMs Using a Verilog Library (Altera)

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 437 and Instantiating LPMs Using VHDL Prepared Components, on page 441. 1. Add the Verilog library file install_dir/lib/altera/altera_lpm.v to your project. The following shows the code for LPM_RAM_DP.
LO
Working with LPMs
module lpm_ram_dp (q, data, wraddress, rdaddress, rdclock, wrclock, rdclken, wrclken, rden, wren) /*synthesis syn_black_box*/; parameter parameter parameter parameter parameter parameter parameter parameter parameter parameter lpm_type = "lpm_ram_dp"; lpm_width = 1; lpm_widthad = 1; numwords = 1<<lpm_widthad; lpm_indata = "REGISTERED"; lpm_outdata = "REGISTERED"; lpm_rdaddress_control = "REGISTERED"; lpm_wraddress_control = "REGISTERED"; lpm_file = "UNUSED"; 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; 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 667.
Translating .lib Files
Translating .lib Files

Standard cells from a number of ASIC vendor libraries can be embedded in the RTL source code. By including the vendor technology (lib) file in the project, the logical information for the cell primitive is automatically extracted from the vendor file and instantiated as a module in the source code file.
LO
CHAPTER 15
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 446 Specifying RAMs with SYNCore, on page 469 Specifying Byte-Enable RAMs with SYNCore, on page 485 Specifying ROMs with SYNCore, on page 496 Specifying Adder/Subtractors with SYNCore, on page 507 Specifying Counters with SYNCore, on page 526
Specifying FIFOs with SYNCore

The SYNCore IP Wizard helps you generate Verilog code for your FIFO implementations. The following procedure shows you how to generate Verilog code for a FIFO you specify, 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.
In the window that opens, select sfifo_model and click Ok. This opens
the first screen of the wizard. LO
2. Specify the parameters you need in the five pages of the wizard. For details, refer to Specifying SYNCore FIFO Parameters, on page 449. 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. 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 synchronous 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 input input input Clk, [15:0] DataIn, WrEn, RdEn,
output Full, output Empty, output [15:0] DataOut ); fifo_a32 <instanceName>( .Clock(Clock) ,.Din(Din) ,.Write_enable(Write_enable) ,.Read_enable(Read_enable) ,.Dout(Dout) ,.Full(Full) ,.Empty(Empty) ) endmodule
template
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.
LO
module top ( input input input input Clk, [15:0] DataIn, WrEn, RdEn,
output Full, output Empty, output [15:0] DataOut ); fifo_a32 busfifo( .Clock(Clk) ,.Din(DataIn) ,.Write_enable(WrEn) ,.Read_enable(RdEn) ,.Dout(DataOut) ,.Full(Full) ,.Empty(Empty) ) endmodule 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 and timing diagrams, see Functional Description, on page 475. 1. Start the SYNCore wizard, as described in Specifying FIFOs with SYNCore, on page 446.
2. Do the following on page 1 of the FIFO wizard:
In Component Name, specify a name for the FIFO. Do not use spaces. 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 446. 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 463 in the Reference Manual for details.

LO
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. Select one of the four mutually exclusive configurations for
Programmable Empty on page 5. See Programmable Empty, on page 465 for details. You can now generate the FIFO and add it to the design, as described in Specifying FIFOs with SYNCore, on page 446.
Functional Description
The SYNCore synchronous FIFO compiler offers an IP wizard that generates Verilog code for your FIFO implementation. This section describes the following:
Synchronous FIFOs, on page 451 FIFO Read and Write Operations, on page 452 FIFO Ports, on page 454 FIFO Parameters, on page 456 FIFO Status Flags, on page 459 FIFO Programmable Flags, on page 462
Synchronous FIFOs
A FIFO is a First-In-First-Out memory queue. Different control logic manages the read and write operations. A FIFO also has various handshake signals for interfacing with external user modules. The SYNCore FIFO compiler generates synchronous FIFOs with symmetric ports and one clock controlling both the read and write operations. The FIFO is symmetric because the read and write ports have the same width. When the Write_enable signal is active and the FIFO has empty locations, data is written into FIFO memory on the rising edge of the clock. A Full status flag indicates that the FIFO is full and that no more write operations can be performed. See FIFO Write Operation, on page 452 for details.
When the FIFO has valid data and Read_enable is active, data is read from the FIFO memory and presented at the outputs. The FIFO Empty status flag indicates that the FIFO is empty and that no more read operations can be performed. See FIFO Read Operation, on page 453 for details. The FIFO is not corrupted by an invalid request: for example, if a read request is made while the FIFO is empty or a write request is received when the FIFO is full. Invalid requests do not corrupt the data, but they cause the corresponding read or write request to be ignored and the Overflow or Underflow flags to be asserted. You can monitor these status flags for invalid requests. These and other flags are described in FIFO Status Flags, on page 459 and FIFO Programmable Flags, on page 462. At any point in time, Data count reflects the available data inside the FIFO. In addition, you can use the Programmable Full and Programmable Empty status flags for user-defined thresholds.
FIFO Read and Write Operations

This section describes FIFO behavior with read and write operations.
FIFO Write Operation

When write enable is asserted and the FIFO is not full, data is added to the FIFO from the input bus (Din) and write acknowledge (Write_ack) is asserted. If the FIFO is continuously written without being read, it will fill with data. The status outputs are asserted when the number of entries in the FIFO is greater than or equal to the corresponding threshold, and should be monitored to avoid overflowing the FIFO. When the FIFO is full, any attempted write operation fails and the overflow flag is asserted. The following figure illustrates the write operation. Write acknowledge (Write_ack) is asserted on the next rising clock edge after a valid write operation. When Full is asserted, there can be no more legal write operations. This example shows that asserting Write_enable when Full is high causes the assertion of Overflow. LO
Clock Write_enable Din Write_ack Overflow Full

D D D D D D D D D D D
FIFO Read Operation

When read enable is asserted and the FIFO is not empty, the next data word in the FIFO is driven on the output bus (Dout) and a read valid is asserted. If the FIFO is continuously read without being written, the FIFO will empty. The status outputs are asserted when the number of entries in the FIFO are less than or equal to the corresponding threshold, and should be monitored to avoid underflowing the FIFO. When the FIFO is empty, all read operations fail and the underflow flag is asserted. If read and write operation occur simultaneously during the empty state, the write operation will be valid and empty, and is de-asserted at the next rising clock edge. There cannot be a legal read operation from an empty FIFO, so the underflow flag is asserted. The following figure illustrates a typical read operation. If the FIFO is not empty, Read_ack is asserted at the rising clock edge after Read_enable is asserted and the data on Dout is valid. When Empty is asserted, no more read operations can be performed. In this case, initiating a read causes the assertion of Underflow on the next rising clock edge, as shown in this figure.
Clock Read_enable Dout
D D D D D D
Read_ack
Underflow Empty
FIFO Ports
The following figure shows the FIFO ports.
Port Name
Almost_empty
Description
Almost empty flag output (active high). Asserted when the FIFO is almost empty and only one more read can be performed. Can be active high or active low. Almost full flag output (active high). Asserted when only one more write can be performed into the FIFO. Can be active high or active low. Asynchronous reset input. Resets all internal counters and FIFO flag outputs. Clock input for write and read. Data is written/read on the rising edge. Data word count output. Indicates the number of words in the FIFO in theLO read clock domain. Data input word to the FIFO. Data output word from the FIFO.
Almost_full
AReset Clock Data_cnt Din [width:0] Dout [width:0]
Port Name
Empty
Description
FIFO empty output (active high). Asserted when the FIFO is empty and no additional reads can be performed. Can be active high or active low. FIFO full output (active high). Asserted when the FIFO is full and no additional writes can be performed. Can be active high or active low. FIFO overflow output flag (active high). Asserted when the FIFO is full and the previous write was rejected. Can be active high or active low. Programmable empty output flag (active high). Asserted when the words in the FIFO exceed or equal the programmable empty assert threshold. De-asserted when the number of words is more than the programmable full negate threshold. Can be active high or active low. Programmable FIFO empty threshold input. User-programmable threshold value for the assertion of the Prog_empty flag. Set during reset. Programmable FIFO empty threshold assert input. Userprogrammable threshold value for the assertion of the Prog_empty flag. Set during reset. Programmable FIFO empty threshold negate input. User programmable threshold value for the de-assertion of the Prog_full flag. Set during reset. Programmable full output flag (active high). Asserted when the words in the FIFO exceed or equal the programmable full assert threshold. De-asserted when the number of words is less than the programmable full negate threshold. Can be active high or active low. Programmable FIFO full threshold input. User-programmable threshold value for the assertion of the Prog_full flag. Set during reset. Programmable FIFO full threshold assert input. Userprogrammable threshold value for the assertion of the Prog_full flag. Set during reset. Programmable FIFO full threshold negate input. Userprogrammable threshold value for the de-assertion of the Prog_full flag. Set during reset.
Full
Overflow
Prog_empty
Prog_empty_ thresh Prog_empty_ thresh_assert Prog_empty_ thresh_negate Prog_full
Prog_full_thresh
Prog_full_thresh_ assert Prog_full_thresh_ negate
Port Name
Read_ack Read_enable Underflow Write_ack Write_enable
Description
Read acknowledge output (active high). Asserted when valid data is read from the FIFO. Can be active high or active low. Read enable output (active high). If the FIFO is not empty, data is read from the FIFO on the next rising edge of the read clock. FIFO underflow output flag (active high). Asserted when the FIFO is empty and the previous read was rejected. Write Acknowledge output (active high). Asserted when there is a valid write into the FIFO. Can be active high or active low. Write enable input (active high). If the FIFO is not full, data is written into the FIFO on the next rising edge.
FIFO Parameters
Parameter
AEMPTY_FLAG_SENSE
Description
FIFO almost empty flag sense 0 Active Low 1 Active High FIFO almost full flag sense 0 Active Low 1 Active High FIFO depth FIFO empty flag sense 0 Active Low 1 Active High FIFO full flag sense 0 Active LowOVERFLOW_ 1 Active High FIFO overflow flag sense 0 Active Low 1 Active High
AFULL_FLAG_SENSE
DEPTH EMPTY_FLAG_SENSE
FULL_FLAG_SENSE
OVERFLOW_FLAG_SENSE
LO
Parameter
PEMPTY_FLAG_SENSE
Description
FIFO programmable empty flag sense 0 Active Low 1 Active High FIFO programmable full flag sense 0 Active Low 1 Active High Programmable empty assert threshold for
PGM_EMPTY_TYPE=2
PFULL_FLAG_SENSE
PGM_EMPTY_ATHRESH PGM_EMPTY_NTHRESH PGM_EMPTY_THRESH PGM_EMPTY_TYPE
Programmable empty negate threshold for

PGM_EMPTY_TYPE=2
Programmable empty threshold for

PGM_EMPTY_TYPE=1
Programmable empty type. See Programmable Empty, on page 465 for details. 1 Programmable empty with single threshold constant 2 Programmable empty with multiple threshold constant 3 Programmable empty with single threshold input 4 Programmable empty with multiple threshold input Programmable full assert threshold for
PGM_FULL_TYPE=2
PGM_FULL_ATHRESH PGM_FULL_NTHRESH PGM_FULL_THRESH PGM_FULL_TYPE
Programmable full negate threshold for

PGM_FULL_TYPE=2
Programmable full threshold for PGM_FULL_TYPE=1 Programmable full type. See Programmable Full, on page 463 for details. 1 Programmable full with single threshold constant 2 Programmable full with multiple threshold constant 3 Programmable full with single threshold input 4 Programmable full with multiple threshold input FIFO read acknowledge flag sense 0 Active Low 1 Active High
RACK_FLAG_SENSE
Parameter
UNDERFLOW_FLAG_ SENSE
Description
FIFO underflow flag sense 0 Active Low 1 Active High FIFO write acknowledge flag sense 0 Active Low 1 Active High FIFO data input and data output width
WACK_FLAG_SENSE
WIDTH
LO
FIFO Status Flags

You can set the following status flags for FIFO read and write operations.
Full/Almost Full Flags, on page 459 Empty/Almost Empty Flags, on page 460 Handshaking Flags, on page 460 Programmable full and empty flags, which are described in Programmable Full, on page 463 and Programmable Empty, on page 465.
Full/Almost Full Flags

These flags indicate the status of the FIFO memory queue for write operations: Full
Indicates that the FIFO memory queue is full and no more writes can be performed until data is read. Full is synchronous with the clock (Clock). If a write is initiated when Full is asserted, the write does not succeed and the overflow flag is asserted. The almost full flag (Almost_full) indicates that there is one location left and the FIFO will be full after one more write operation. Almost full is synchronous to Clock. This flag is guaranteed to be asserted when the FIFO has one remaining location for a write operation.
Almost_full
The following figure displays the behavior of these flags. In this example, asserting Wriite_enable when Almost_full is high causes the assertion of Full on the next rising clock edge.
Clock Write_enable Din Write_ack Full Almost_full
D D D D D D D D D D D
Empty/Almost Empty Flags

These flags indicate the status of the FIFO memory queue for read operations: Empty
Indicates that the memory queue for the FIFO is empty and no more reads can be performed until data is written. The output is active high and is synchronous to the clock. If a read is initiated when the empty flag is true, the underflow flag is asserted. Indicates that the FIFO will be empty after one more read operation. Almost_empty is active high and is synchronous to the clock. The flag is guaranteed to be asserted when the FIFO has one remaining location for a read operation.
Almost_ empty
The following figure illustrates the behavior of the FIFO with one word remaining.
Clock Read_en
Read_ack
Empty Almost_empty
Handshaking Flags
You can specify optional Read_ack, Write_ack, Overflow, and Underflow handshaking flags for the FIFO.
LO
Clock Write_en Read_en Din Write_ack
Read_ack
Dout Full Empty Overflow Underflow
D D D D D D D D
Read_ack
Asserted at the completion of each successful read operation. It indicates that the data on the Dout bus is valid. It is an optional port that is synchronous with Clock and can be configured as active high or active low. Read_ack is deasserted when the FIFO is underflowing, which indicates that the data on the Dout bus is invalid. Read_ack is asserted at the next rising clock edge after read enable. Read_enable is asserted when the FIFO is not empty.
Write_ack
Asserted at the completion of each successful write operation. It indicates that the data on the Din port has been stored in the FIFO. It is synchronous with the clock, and can be configured as active high or active low. Write_ack is deasserted for a write to a full FIFO, as illustrated in the figure. Write_ack is deasserted one clock cycle after Full is asserted to indicate that the last write operation was valid and no other write operations can be performed. Indicates that a write operation was unsuccessful because the FIFO was full. In the figure, Full is asserted to indicate that no more writes can be performed. Because the write enable is still asserted and the FIFO is full, the next cycle causes Overflow to be asserted. Note that Write_ack is not asserted when FIFO is overflowing. When the write enable is deasserted, Overflow deasserts on the next clock cycle. Indicates that a read operation was unsuccessful, because the read was attempted on an empty FIFO. In the figure, Empty is asserted to indicate that no more reads can be performed. As the read enable is still asserted and the FIFO is empty, the next cycle causes Underflow to be asserted. Note that Read_ack is not asserted when FIFO is underflowing. When the read enable is deasserted, the Underflow flag deasserts on the next clock cycle.
Overflow
Underflow
FIFO Programmable Flags

The FIFO supports completely programmable full and empty flags to indicate when the FIFO reaches a predetermined user-defined fill level. See the following: Prog_full Prog_empty
Indicates that the FIFO has reached a user-defined full threshold. See Programmable Full, on page 463 for more information. Indicates that the FIFO has reached a user-defined empty threshold. See Programmable Empty, on page 465 for more information.
Both flags support various implementation options. You can do the following:
Set a constant value Set dedicated input ports so that the thresholds can change dynamically
in the circuit
Use hysteresis, so that each flag has different assert and negative values
LO
Programmable Full
The Prog_full flag (programmable full) is asserted when the number of entries in the FIFO is greater than or equal to a user-defined assert threshold. If the number of words in the FIFO is less than the negate threshold, the flag is deasserted. The following is the valid range of threshold values:
Assert threshold value Negate threshold value
Depth / 2 to Max of Depth
For multiple threshold types, the assert value should always be larger than the negate value in multiple threshold types.
Depth / 2 to Max of Depth
Prog_full has four threshold types:
Programmable Full with Single Threshold Constant, on page 463 Programmable Full with Multiple Threshold Constants, on page 464 Programmable Full with Single Threshold Input, on page 464 Programmable Full with Multiple Threshold Inputs, on page 465
Programmable Full with Single Threshold Constant

PGM_FULL_TYPE = 1 This option lets you set a single constant value for the threshold. It requires significantly fewer resources when the FIFO is generated. This figure illustrates the behavior of Prog_full when configured as a single threshold constant with a value of 6.
Clock Write_en Write_ack Data_cnt
0 1 2 3 4 5 6 5 4
Prog_full
Programmable Full with Multiple Threshold Constants

PGM_FULL_TYPE = 2 The programmable full flag is asserted when the number of words in the FIFO is greater than or equal to the full threshold assert value. If the number of FIFO words drops to less than the full threshold negate value, the programmable full flag is de-asserted. Note that the negate value must be set to a value less than the assert value. The following figure illustrates the behavior of Prog_full configured as multiple threshold constants with an assert value of 6 and a negate value of 4.
0 1 2 3 4 5 6 5 4 3 2
Prog_full
Programmable Full with Single Threshold Input

PGM_FULL_TYPE = 3 This option lets you specify the threshold value through an input port (Prog_full_thresh) during the reset state, instead of using constants. The following figure illustrates the behavior of Prog_full configured as a single threshold input with a value of 6.
0 1 2 3 4 5 6 5 4
Prog_full
LO
Programmable Full with Multiple Threshold Inputs

PGM_FULL_TYPE = 4 This option lets you specify the assert and negate threshold values dynamically during the reset stage using the Prog_full_thresh_assert and Prog_full_thresh_negate input ports. You must set the negate value to a value less than the assert value. The programmable full flag is asserted when the number of words in the FIFO is greater than or equal to the Prog_full_thresh_assert value. If the number of FIFO words goes below Prog_full_thresh_negate value, the programmable full flag is deasserted. The following figure illustrates the behavior of Prog_full configured as multiple threshold inputs with an assert value of 6 and a negate value of 4.
0 1 2 3 4 5 6 5 4 3 2
Prog_full
Programmable Empty
The programmable empty flag (Prog_empty) is asserted when the number of entries in the FIFO is less than or equal to a user-defined assert threshold. If the number of words in the FIFO is greater than the negate threshold, the flag is deasserted. The following is the valid range of threshold values:
Assert threshold value Negate threshold value
1 to Max of Depth / 2
For multiple threshold types, the assert value should always be lower than the negate value in multiple threshold types.
1 to Max of Depth / 2
There are four threshold types you can specify:

Programmable Empty with Single Threshold Constant, on page 466 Programmable Empty with Multiple Threshold Constants, on page 466 Programmable Empty with Single Threshold Input, on page 467 Programmable Empty with Multiple Threshold Inputs, on page 467
Programmable Empty with Single Threshold Constant

PGM_EMPTY_TYPE = 1 This option lets you specify an empty threshold value with a single constant. This approach requires significantly fewer resources when the FIFO is generated. The following figure illustrates the behavior of Prog_empty configured as a single threshold constant with a value of 3.
Clock Read_en Data_cnt

0 1 2 3 4 5 6 5 4 3 2
Prog_empty
Programmable Empty with Multiple Threshold Constants

PGM_EMPTY_TYPE = 2 This option lets you specify constants for the empty threshold assert value and empty threshold negate value. The programmable empty flag asserts and deasserts in the range set by the assert and negate values. The assert value must be set to a value less than the negate value. When the number of words in the FIFO is less than or equal to the empty threshold assert value, the Prog_empty flag is asserted. When the number of words in FIFO is greater than the empty threshold negate value, Prog_empty is deasserted. The following figure illustrates the behavior of Prog_empty when configured as multiple threshold constants with an assert value of 3 and a negate value of 5. LO

0 1 2 3 4 5 6 7 8 7 6 5 4 3 2
Prog_empty
Programmable Empty with Single Threshold Input

PGM_EMPTY_TYPE = 3 This option lets you specify the threshold value dynamically during the reset state with the Prog_empty_thresh input port, instead of with a constant. The Prog_empty flag asserts when the number of FIFO words is equal to or less than the Prog_empty_thresh value and deasserts when the number of FIFO words is more than the Prog_empty_thresh value. The following figure illustrates the behavior of Prog_empty when configured as a single threshold input with a value of 3.

0 1 2 3 4 5 6 5 4 3 2
Prog_empty
Programmable Empty with Multiple Threshold Inputs

PGM_EMPTY_TYPE = 4 This option lets you specify the assert and negate threshold values dynamically during the reset stage using the Prog_empty_thresh_assert and Prog_empty_thresh_negate input ports instead of constants. The programmable empty flag asserts and deasserts according to the range set by the assert and negate values. The assert value must be set to a value less than the negate value.
When the number of FIFO words is less than or equal to the empty threshold assert value, Prog_empty is asserted. If the number of FIFO words is greater than the empty threshold negate value, the flag is deasserted. The following figure illustrates the behavior of Prog_empty configured as multiple threshold inputs, with an assert value of 3 and a negate value of 5.

0 1 2 3 4 5 6 7 8 7 6 5 4 3 2
Prog_empty
LO
Specifying RAMs with SYNCore

The SYNCore IP wizard helps you generate Verilog code for your RAM implementation requirements. The following procedure shows you how to generate Verilog code for a RAM you specify, using the SYNCore IP wizard. Note: The SYNCore RAM model uses Verilog 2001. When adding a RAM 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.
In the window that opens, select ram_model and click Ok. This opens
the first screen of the wizard.
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 472.
For details about the parameters for a dual-port RAM, see Specifying
Parameters for Dual-Port RAM, on page 473. 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 synchronous resets, and where all edges (clock, enable, and reset) are considered positive. 3. After you have specified all the parameters you need, click the Generate 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. LO SYNCore also generates a testbench for the RAM. The testbench covers a limited set of vectors. 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 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 figure shows a template file (in red text) inserted into a top-level module. module top ( input input input input ClkA, [7:0] AddrA, [15:0] DataInA, WrEnA,
output [15:0] DataOutA ); myram2 <InstanceName> ( .PortAClk(PortAClk) , .PortAAddr(PortAAddr) , .PortADataIn(PortADataIn) , .PortAWriteEnable(PortAWriteEnable) , .PortADataOut(PortADataOut) ); endmodule
template
definitions in the top-level module as shown in the example below. You can also assign a unique name to each instantiation. module top ( input input input input ClkA, [7:0] AddrA, [15:0] DataInA, WrEnA,
output [15:0] DataOutA );
myram2 decoderram( .PortAClk(ClkA) , .PortAAddr(AddrA) , .PortADataIn(DataInA) , .PortAWriteEnable(WrEnA) , .PortADataOut(DataOutA) ); endmodule
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. 1. Start the SYNCore RAM wizard, as described in Specifying RAMs with SYNCore, on page 469. 2. Do the following on page 1 of the RAM wizard:
In Component Name, specify a name for the memory. Do not use LO

spaces.
In Directory, specify a directory where you want the output files to be

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. 3. Do the following on page 2 of the RAM wizard:
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 469. 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 473. For read/write timing diagrams, see Read/Write Timing Sequences, on page 482 of the Reference 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 Specifying Parameters for Single-Port RAM, on page 472. 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
For the corresponding read/write timing diagrams, see Read/Write Timing Sequences, on page 482 of the Reference Manual. 1. Start the SYNCore RAM wizard, as described in Specifying RAMs with SYNCore, on page 469. 2. Do the following on page 1 of the RAM wizard:
In Component Name, specify a name for the memory. Do not use

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.

For a single clock... For separate clocks for each of the ports... Enable Single Clock. Enable Separate Clocks For Each Port.
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:
One read & one write Two reads & one write Two reads & two writes Enable Read Only Access. Enable Read and Write Access. Specify a setting for Use Write Enable.
Enable Read and Write Access. Specify a setting for Use Write Enable. LO Specify a read access option for Port A.
Specify a setting for Register Read Address.

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:
One read & one write Two reads & one write Two reads & two writes Enable Write Only Access. Set Use Write Enable to the setting you want. Enable Read Only Access. Specify a setting for Register Read Address. Enable Read and Write Access. Specify a setting for Use Write Enable. Specify a setting for Register Read Address. Set Synchronous Reset to the setting you want. Note that Register Outputs is always enabled. Select a read access option for Port B.
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 Specifying RAMs with SYNCore, on page 469, and add it to your design.
The SYNCore RAM Compiler generates Verilog code for your RAM implementation. This section describes the following:
Single-Port Memories, on page 476 Dual-Port Memories, on page 477 Read/Write Timing Sequences, on page 482
Single-Port Memories
For single-port RAM, it is only necessary to configure Port A. The following diagrams show the read-write timing for single-port memories. See Specifying RAMs with SYNCore, on page 469 in the User Guide for a procedure.
Single-Port Read
ADDR
00
01
02
03
CLK
QOUT
XX
F0
F1
F2
F3
MEM1
F1
MEM0
F0
MEM3
F3
MEM2
F2
MEM4
F4
LO
Single-Port Write
DATA
7A FC 7F FF
WREN
ADDR
00
01
02
CLK
QOUT
XX
F0
7A
7F
FF
MEM1
F1
7A
MEM0
F0
MEM3
F3
MEM2
F2
7F
FF
MEM4
F4
Dual-Port Memories
SYNCore dual-port memory includes the following common configurations:
One read access and one write access Two read accesses and one write access Two read accesses and two write accesses
The following diagrams show the read-write timing for dual-port memories. See Specifying RAMs with SYNCore, on page 469 in the User Guide for a procedure to specify a dual-port RAM with SYNCore.
Dual-Port Single Read

RADDR
00 03 02 01
CLK
QOUT
XX
F0
F3
F2
F1
MEM1
F1
MEM0
F0
MEM3
F3
MEM2
F2
MEM4
F4
LO
Dual-Port Single Write

DATA
7A FC 7F FF
WREN
WADDR
00
01
02
RADDR
00
03
02
CLK
QOUT
XX
F0
7A
7F
FF
MEM1
F1
7A
MEM0
F0
MEM3
F3
MEM2
F2
7F
FF
MEM4
F4
Dual-Port Read
ADDR_A
00 01 02 03
ADDR_B
00
03
02
01
CLK
QOUT_A
XX
F0
F1
F2
F3
QOUT_B
XX
F0
F3
F2
F1
MEM1
F1
MEM0
F0
MEM3
F3
MEM2
F2
MEM4
F4
LO
Dual-Port Write
DATA_A
7A FC 7F FF
WREN_A
ADDR_A
00
01
02
DATA_B
04
4A
4F
F4
WREN_B
ADDR_B CLK
00
03
02
QOUT_A
XX
F0
7A
7F
FF
QOUT_B
XX
F0
04
F3
XX
MEM1
F1
7A
MEM0
F0
7A
MEM3
F3
MEM2
F2
7F
FF
MEM4
F4
Read/Write Timing Sequences

The waveforms in this section describe the behavior of the RAM when both read and write are enabled and the address is the same operation. The waveforms show the behavior when each of the read-write sequences is enabled. The waveforms are merged with the simple waveforms shown in the previous sections. See the following:
Read Before Write, on page 482 Write Before Read, on page 483 No Read on Write, on page 484 Read Before Write
CLK
ADDR
00
01
02
03
04
DATA
FA
FB
FC
FD
FE
WEN
QOUT
A0
A1
A2
FC
A3
FD
A4
FE
MEM0
A0
MEM1
A1
MEM2
A2
FC
MEM3
A3
FD
MEM4
LO
A4
FE
Write Before Read

CLK
ADDR
00
01
02
03
04
DATA
FA
FB
FC
FD
FE
WEN
QOUT
A0
A1
FC
FD
FE
MEM0
A0
MEM1
A1
MEM2
A2
FC
MEM3
A3
FD
MEM4
A4
FE
No Read on Write
CLK
ADDR
00
01
02
03
04
DATA
FA
FB
FC
FD
FE
WEN
QOUT
A0
A1
MEM0
A0
MEM1
A1
MEM2
A2
FC
MEM3
A3
FD
MEM4
A4
FE
LO
Specifying Byte-Enable RAMs with SYNCore

The SYNCore IP wizard helps you generate SystemVerilog code for your byteenable 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. 1. Start the wizard.
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.
2. Specify the parameters you need in the wizard. For details about the parameters, see Specifying Byte-Enable RAM Parameters, on page 489. The BYTE ENABLE RAM symbol on the left reflects any parameters you set. 3. After you have specified all the parameters you need, click the Generate 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 component. 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. LO Use the Add File command to add the Verilog design file that was generated (the filename entered on page 1 of the wizard) and the
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 output [31:0] DataOut ) 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) );
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 ClkA WenA AddrA ResetA
Input Input Input Input
Type
Description
Clock input for Port A Write enable for Port A; present when Port A is in write mode Memory access address for Port A Reset for memory and all registers in core; present with registered read data when Reset is enabled; active low (cannot be changed) Write data to memory for Port A; present when Port A is in write mode Read data output for Port A; present when Port A is in read or read/write mode Clock input for Port B; present in dualport mode Write enable for Port B; present in dualport mode when Port B is in write mode Memory access address for Port B; present in dual-port mode 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) Write data to memory for Port B; present in dual-port mode when Port B is in write mode Read data output for Port B; present in dual-port mode when Port B is in read or LOread/write mode
WrDataA RdDataA ClkB WenB AddrB ResetB
Input Output Input Input Input Input
WrDataB
Input
RdDataB
Output
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 descriptions of each parameter, refer to SYNCore Byte Enable RAM Wizard, on page 3-107 in the reference manual. 1. Start the SYNCore byte-enable RAM wizard as described in Specifying Byte-Enable RAMs with SYNCore, on page 485. 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 parameters that you set. 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 userdefined 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 485. For read/write timing diagrams, see Read/Write Timing Sequences, on page 482 of the reference manual.
The SYNCore byte-enable RAM compiler generates SystemVerilog code describing byte-enabled RAMs. The data width of each byte is calculated by dividing the total data width by the write enable width. The byte-enable RAM compiler supports both single- and dual-port configurations. This section describes the following: LO
Functional Overview, on page Write Operation, on page

Read Operation, on page Parameter List, on page Overview

The SYNCore byte-enable RAM component supports bit/byte-enable RAM implementations using blockRAM and distributed memory. For each configuration, design optimizations are made for optimum use of core resources. The timing diagram that follow illustrate the supported signals for byte-enable RAM configurations. Byte-enable RAM can be configured in both single- and dual-port configurations. In the dual-port configuration, each port is controlled by different clock, enable, and control signals. User configuration controls include selecting the enable level, reset type, and register type for the read data outputs and address inputs. Reset applies only to the output read data registers; default value of read data on reset can be changed by user while generating core. Reset option is inactive when output read data is not registered.
Read/Write Timing Sequences

The waveforms in this section describe the behavior of the byte-enable RAM for both read and write operations.
Read Operation
On each active edge of the clock when there is a change in address, data is valid on the same clock or next clock (depending on latency parameter values for read address and read data ports). Active reset ignores any change in input address, and data and output data are initialized to user-defined values set by parameters RST_RDATA_A and RST_RDATA_B for port A and port B, respectively. The following waveform shows the read sequence of the byte-enable RAM component with read data registered in single-port mode.
As shown in the above waveform, output read data changes on the same clock following the input address changed. When the address changes from 'h00 to 'h01, read data changes to 50 on the same clock, and data will be valid on the next clock edge. The following waveform shows the read sequence with both the read data and address registered in single-port mode.
As shown in the above waveform, output read data changes on the next clock LO edge after the input address changes. When the address changes from 'h00 to 'h01, read data changes to 50 on the next clock, and data is valid on the next clock edge.
Note: The read sequence for dual-port mode is the same as single port; read/write conflicts occurring due to accessing the same location from both ports are the users responsibility.
Write Operation
The following waveform shows a write sequence with read-afterwrite in singleport mode.
On each active edge of the clock when there is a change in address with an active enable, data is written into memory on the same clock. When enable is not active, any change in address or data is ignored. Active reset ignores any change in input address and data. The width of the write enable is controlled by the WE_WIDTH parameter. Input data is symmetrically divided and controlled by each write enable. For example, with a data width of 32 and a write enable width of 4, each bit of the write enable controls 8 bits of data (32/4=8). The byte-enable RAM compiler will error for wrong combination data width and write enable values. The above waveform shows a write sequence with all possible values for write enable followed by a read:
Value for parameter WE_WIDTH is 2 and DATA_WIDTH is 8 so each

write enable controls 4 bits of input data.
WenA value changes from 1 to 2, 2 to 0, and 0 to 3 which toggles all

possible combinations of write enable. The first sequence of address, write enable changes to perform a write sequence and the data patterns written to memory are 00, aa, ff. The read data pattern reflects the current content of memory before the write. The second address sequence is a read (WenA is always zero). As shown in the read pattern, only the respective bits of data are written according to the write enable value. Note: The write sequence for dual-port mode is the same as single port; conflicts occurring due to writing the same location from both ports are the users responsibility.
Parameter List
The following table lists the file entries corresponding to the byte-enable RAM wizard parameters. Name
ADDR_WIDTH DATA_WIDTH
Description
Bit/byte enable RAM address width Data width for input and output data, common to both Port A and Port B Write enable width, common to both Port A and Port B Selects single/dual port configuration Port A/B reset type selection Default data value for LO Port A/B on active reset
Default Value
2 8
Range
multiples of 2 2 to 256
WE_WIDTH
CONFIG_PORT RST_TYPE_A/B RST_RDATA_A/B
1 (single port) 1 (synchronous) All 1s
0 = dual-port 1 = single-port 0 = no reset 1 = synchronous decimal value
WEN_SENSE_A/B RADDR_LTNCY_A/B
Port A/B write enable sense Optional read address register select Port A/B Optional read data register select Port A/B
1 (active high) 1
0 = active low 1 = active high 0 = no latency 1 = one cycle latency 0 = no latency 1 = one cycle latency
RDATA_LTNCY_A/B
Specifying ROMs with SYNCore

The SYNCore IP wizard helps you generate Verilog code for your ROM implementation requirements. The following procedure shows you how to generate Verilog code for a ROM you define using the SYNCore IP wizard. Note: The SYNCore ROM model uses Verilog 2001. When adding a ROM 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.

In the window that opens, select rom_model and click Ok to open page
1 of the wizard.
LO
2. Specify the parameters you need in the wizard. For details about the parameters, see Specifying ROM Parameters, on page 500. The ROM symbol on the left reflects any parameters you set. 3. After you have specified all the parameters you need, click the Generate 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
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 ROM, and paste them into your top-level module. The following figure shows a template file (in red text) inserted into a toplevel 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
LO
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) );
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 ClkA EnA AddrA ResetA DataA ClkB EnB
Input Input Input Input Output Input Input
Type
Description
Clock input for Port A Enable input for Port A Read address for Port A Reset or interface disable pin for Port A Read data output for Port A Clock input for Port B Enable input for Port B
AddrB ResetB DataB
Input Input Output
Read address for Port B Reset or interface disable pin for Port B Read data output for Port B
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. 1. Start the SYNCore ROM wizard, as described in Specifying ROMs with SYNCore, on page 496. 2. Do the following on page 1 of the ROM wizard:
In Component Name, specify a name for the memory. Do not use

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 singleport 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 LO 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). 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 496 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 page 482 of the Reference Manual.
The SYNCore ROM Compiler generates Verilog code for your ROM implementation. This section describes the following:
Overview, on page 501 Single-Port Read Operation, on page 502 Dual-Port Read Operation, on page 503 Parameter List, on page 504 Clock Latency, on page 505
Overview
The SYNCore ROM component supports ROM implementations using block ROM or logic memory. For each configuration, design optimizations are made for optimum usage of core resources. Both single- and dual-port memory configurations are supported. Single-port ROM allows read access to memory
through a single port, and dual-port ROM allows read access to memory through two ports. The following figure illustrates the supported signals for both configurations.
In the single-port (Port A) configuration, signals are synchronized to ClkA; ResetA can be synchronous or asynchronous depending on parameter selection. The read address (AddrA) and/or data output (DataA) can be registered to increase memory performance and improve timing. Both the read address and data output are subject to clock latency based on the ROM configuration (see Clock Latency, on page 505). In the dual-port configuration, all Port A signals are synchronized to ClkA, and all PortB signals are synchronized to ClkB. ResetA and ResetB can be synchronous or asynchronous depending on parameter selection, and both data outputs can be registered and are subject to the same clock latencies. Registering the data output is recommended. Note: When the data output is unregistered, the data is immediately set to its prefined reset value concurrent with an active reset signal.
Single-Port Read Operation

For single-port ROM, it is only necessary to configure Port A (see Specifying LO ROMs with SYNCore, on page 496 in the User Guide). The following diagram shows the read timing for a single-port ROM.
On every active edge of the clock when there is a change in address with an active enable, data will be valid on the same clock or next clock (depending on latency parameter values). When enable is inactive, any address change is ignored, and the data port maintains the last active read value. An active reset ignores any change in input address and forces the output data to its predefined initialization value. The following waveform shows the functional behavior of control signals in single-port mode.
When reset is active, the output data holds the initialization value (i.e., 255). When reset goes inactive (and enable is active), data is read form the addressed location of ROM. Reset has priority over enable and always sets the output to the predefined initialization value. When both enable and reset are inactive, the output holds its previous read value. Note: In the above timing diagram, reset is synchronous. Clock latency varies according to the implementation and parameters as described in Clock Latency, on page 505.
Dual-Port Read Operation

Dual-port ROMs allow read access to memory through two ports. For dualport ROM, both port A and port B must be configured (see Specifying ROMs with SYNCore, on page 496 in the User Guide). The following diagram shows the read timing for a dual-port ROM.
When either reset is active, the corresponding output data holds the initialization value (i.e., 255). When a reset goes inactive (and its enable is active), data is read form the addressed location of ROM. Reset has priority over enable and always sets the output to the predefined initialization value. When both enable and reset are inactive, the output holds its previous read value. Note: In the above timing diagram, reset is synchronous. Clock latency varies according to the implementation and parameters as described in Clock Latency, on page 505.
Parameter List
The following table lists the file entries corresponding to the ROM wizard parameters. Name
ADD_WIDTH
Description
ROM address width value. Default value is 10 Read Data width, common to both Port A and Port B Parameter to select Single/Dual configuration Port A reset type selection (synchronous, asynchronous) Port B reset type selection (synchronous, asynchronous) Default data value for Port A on active Reset LO
Default Value
10
Range
--
DATA_WIDTH
2 to 256
CONFIG_PORT
dual (Dual Port)
dual (Dual), single (Single)
RST_TYPE_A
1 - asynchronous
1( asyn), 0 (sync)
RST_TYPE_B
1 - asynchronous
1 (asyn), 0 (sync)
RST_DATA_A
1 for all data bits
0 2^DATA_WIDTH - 1
RST_DATA_B
Default data value for Port A on active Reset Port A enable sense
1 for all data bits
0 2^DATA_WIDTH - 1
EN_SENSE_A EN_SENSE_B ADDR_LTNCY_A
1 active high
0 - active low, 1- active high 0 - active low, 1- active high 1(reg), 0(no reg)
Port B enable sense 1 active high Optional address register select Port A Optional address register select Port B Optional data register select Port A Optional data register select Port B Initial values file name
1- address registered
ADDR_LTNCY_B
1- address registered
1(reg), 0(no reg)
DATA_LTNCY_A
1- data registered
1(reg), 0(no reg)
DATA_LTNCY_B
1- data registered
1(reg), 0(no reg)
INIT_FILE
init.txt
--
Clock Latency
Clock latency varies with both the implementation and latency parameter values according to the following table. Note that the table reflects the values for Port A the same values apply for Port B in dual-port configurations. Implementation Type/Target block_rom (Xilinx) block_rom (Altera) Parameter Value
DATA_LTNCY_A = 0 ADDR_LTNCY_A = 1 DATA_LTNCY_A = 1 ADDR_LTNCY_A = 0 DATA_LTNCY_A = 1 ADDR_LTNCY_A = 1
Latency
1 ClkA cycle 1 ClkA cycle 2 ClkA cycles
logic (Xilinx) logic (Altera)
DATA_LTNCY_A = 0 ADDR_LTNCY_A = 0 DATA_LTNCY_A = 0 ADDR_LTNCY_A = 1 DATA_LTNCY_A = 1 ADDR_LTNCY_A = 0 DATA_LTNCY_A = 1 ADDR_LTNCY_A = 1
0 ClkA cycles 1 ClkA cycle 1 ClkA cycle 2 ClkA cycles
LO
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 that you define 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. 1. Start the wizard.

n the window that opens, select addnsub_model and click Ok to open

page1 of the wizard.
2. Specify the parameters you need in the wizard. For details about the parameters, see Specifying Adder/Subtractor Parameters, on page 512. The ADDnSUB symbol on the left reflects any parameters you set. 3. After you have specified all the parameters you need, click the Generate 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. 4. 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. 5. Edit the adder/subtractor files if necessary. 6. Add the adder/subtractor you generated to your design. LO Use the Add File command to add the Verilog design file that was 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
located in the same output files directory. Copy the lines that define the adder/subtractor and paste them into your top-level module. The following figure shows a template file (in red text) inserted into a toplevel module.
template
module top ( output [15 : 0] Out, input Clk, input [15 : 0] A, input CEA, input RSTA, input [15 : 0] B, input CEB, 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 conditionsunder which the port is available.
LO
Port Name PortA
Description
Data input for adder/subtractor Parameterized width and pipeline stages Data input for adder/subtractor Parameterized width and pipeline stages Primary clock input; clocks all registers in the unit Reset input for port A pipeline registers (active high) Reset input for port B pipeline registers (active high) Selection port for dynamic operation
Required/Optional
Always present
PortB
Not present if adder/subtractor is configured as a constant adder/subtractor Always present Not present if pipeline stage for port A is 0 Not present if pipeline stage for port B is 0 or for constant adder/subtractor Not present if adder/subtractor configured as standalone adder or subtractor Not present if output pipeline stage is 0 Not present if pipeline stage for port A is 0 Not present if pipeline stage for port B is 0 or for constant adder/subtractor Always present Not present if output pipeline stage is 0 Always present
PortClk PortRstA PortRstB
PortADDnSUB
PortRstOut PortCEA PortCEB
Reset input for output register (active high) Clock enable for port A pipeline registers (active high) Clock enable for port B pipeline registers (active high) Carry input for adder/subtractor Clock enable for output register (active high) Data output
PortCarryIn PortCEOut PortOut
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. 1. Start the SYNCore adder/subtractor wizard as described in Specifying Adder/Subtractors with SYNCore, on page 507. 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. 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. 5. In the Configure Port B section:
If you are configuring port B as a constant port, check Constant Value

Input and enter the constant value in the Constant Value/Port B Width LO field.
If you are configuring port B as a dynamic port, check Enable Port B

and enter the port width in the Constant Value/Port B Width field.
If you are defining a synchronous adder/subtractor, check Register

Input B and then check Clock Enable for Register B and/or Reset for Register B. 6. 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. 7. In the Configure Reset type for all Reset Signal section, click Synchronous Reset or Asynchronous Reset as appropriate. Note: As you enter the page 2 parameters, the ADDnSUB symbol dynamically updates to reflect the parameters you set. 8. Generate the adder/subtractor by clicking the Generate button as described in Specifying Adder/Subtractors with SYNCore, on page 507 and add it to your design. All output files are in the directory you specified on page 1 of the wizard.
The SYNCore adder/subtractor compiler generates Verilog code for a parametrizable, pipelined adder/subtractor. This section describes the functionality of this block in detail. The adder/subtractor has a single clock that controls the entire pipeline stages (if used) of the adder/subtractor. As its name implies, this block just adds/subtracts the inputs and provides the output result. One of the inputs can be configured as a constant. The data inputs and outputs of the adder/subtractor can be pipelined; the pipeline stages can be 0 or 1, and can be configured individually. The individual pipeline stage registers include their own reset and enable ports. The reset to all of the pipeline registers can be configured either as synchronous or asynchronous using the RESET_TYPE parameter. The reset type of the pipeline registers cannot be configured individually.
Pipeline Stage A
Pipeline Stage Out PortA
PortOut PortB Pipeline Stage B PortCarryIn
SYNCore adder/subtracor has ADD_N_SUB parameter, which can take three values ADD, SUB, or DYNAMIC. Based on this parameter value, the adder/subtractor can be configured as follows.
Adder Subtractor Dynamic Adder and Subtractor Adder

Based on the parameter CONSTANT_PORT, the adder can be configure in two ways. CONSTANT_PORT='0' adder with two input ports (port A and port B) CONSTANT_PORT='1' adder with one constant port
LO
Adder with Two Input Ports (Port A and Port B)

In this mode, port A and port B values are added. Optional pipeline stages can also be inserted at port A, port B or at both port A and port B. Optionally, pipeline stages can also be added at the output port. Depending on pipeline stages, a number of the adder configurations are given below. Adder with No Pipeline Stages In this mode, the port A and port B inputs are added. The adder is purely combinational, and the output changes immediately with respect to the inputs.
Parameters:
PORTA_PIPELINE_STAGE= 0
Adder with Pipeline Stages at Input Only In this mode, the port A and port B inputs are pipelined and added. Because there is no pipeline stage at the output, the result is valid at each rising edge of the clock.
Parameters:
PORTA_PIPELINE_STAGE= 1 PORTB_PIPELINE_STAGE= 1 PORTOUT_PIPELINE_STAGE= 0
Adder with Pipeline Stages at Input and Output In this mode, the port A and port B inputs are pipelined and added, and the result is pipelined. The result is valid only on the second rising edge of the clock.
Parameters:
Adder with a Port Constant

In this mode, port A is added with a constant value (the constant value can be passed though the parameter CONSTANT_VALUE). Optional pipeline stages can also be inserted at port A, Optionally, pipeline stages can also be added at the output port. Depending on the pipeline stages, a number of the adder configurations are given below (here CONSTANT_VALUE=3) Adder with No Pipeline Stages In this mode, input port A is added with a constant value. The adder is purely combinational, and the output changes immediately with respect to the input.
Parameters:
PORTA_PIPELINE_STAGE= 0 PORTOUT_PIPELINE_STAGE= 0
Adder with Pipeline Stage at Input Only In this mode, input port A is pipelined and added with a constant value. Because there is no pipeline stage at the output, the result is valid at each rising edge of the clock.
Parameters:
LO PORTA_PIPELINE_STAGE= 1 PORTOUT_PIPELINE_STAGE= 0
Adder with Pipeline Stages at Input and Output In this mode, input port A is pipelined and added with a constant value, and the result is pipelined. The result is valid only on the second rising edge of the clock.
Parameters:
Subtractor
Based on the parameter CONSTANT_PORT, the subtractor can be configure in two ways. CONSTANT_PORT='0' subtractor with two input ports (port A and port B) CONSTANT_PORT='1' subtractor with one constant port
Subtractor with Two Input Ports (Port A and Port B)

In this mode, port B is subtracted from port A. Optional pipeline stages can also be inserted at port A, port B, or both ports. Optionally, pipeline stages can also be added at the output port. Depending on the pipeline stages, a number of the subtractor configurations are given below. Subtractor with No Pipeline Stages In this mode, input port B is subtracted from port A, and the subtractor is purely combinational. The output changes immediately with respect to the inputs.
Parameters:
Subtractor with Pipeline Stages at Input Only In this mode, input port B and input PortA are pipelined and then subtracted. Because there is no pipeline stage at the output, the result is valid at each rising edge of the clock.
Parameters:
Subtractor with Pipeline Stages at Input and Output In this mode, input PortA and PortB are pipelined and then subtracted, and the result is pipelined. The result is valid only at the second rising edge of the clock.
Parameters:
PORTA_PIPELINE_STAGE= 1 PORTB_PIPELINE_STAGE= 1 PORTOUT_PIPELINE_STAGE= 1 LO
Subtractor with a Port Constant

In this mode, a constant value is subtracted from port A (the constant value can be passed though the parameter CONSTANT_VALUE). Optional pipeline stages can also be inserted at port A, Optionally, pipeline stages can also be added at the output port. Depending on pipeline stages, a number of the subtractor configurations are given below (here CONSTANT_VALUE=1). Subtractor with No Pipeline Stages In this mode, a constant value is subtracted from port A. The subtractor is purely combinational, and the output changes immediately with respect to the input.
Parameters:
Subtractor with Pipeline Stages at Input Only In this mode, a constant value is subtracted from pipelined input port A. Because there is no pipeline stage at the output, the output is valid at each rising edge of the clock.
Parameters:
Subtractor with Pipeline Stages at Input and Output In this mode, a constant value is subtracted from pipelined port A, and the output is pipelined. The result is valid only at the second rising edge of the clock.
Parameters:
Dynamic Adder/Subtractor
In dynamic adder/subtractor mode, port PortADDnSUB controls adder/subtractor operation. PortADDnSUB='0' adder operation PortADDnSUB='1' subtractor operation Based on the parameter CONSTANT_PORT the dynamic adder/subtractor can be configured in one of two ways: CONSTANT_PORT='0' dynamic adder/subtractor with two input ports CONSTANT_PORT='1' dynamic adder/subtractorwith one constant port
LO
Dynamic Adder/Subtractor with Two Input Ports (Port A and Port B)

In this mode, the addition and subtraction is dynamic based on the value of input port PortADDnSUB. Optional pipeline stages can also be inserted at Port A, Port B, or both Port A and Port B. Optionally, pipeline stages can also be added at the output port. Depending on pipeline stages, some of the dynamic adder/subtractor configurations are given below. Dynamic Adder/Subtractor with No Pipeline Registers In this mode, the dynamic adder/subtractor is a purely combinational, and output changes immediately with respect to the inputs.
Parameters:
Dynamic Adder/Subtractor with Pipeline Stages at Input Only In this mode, input port A and port B are pipelined and then added/subtracted based on the value of port PortADDnSUB. Becasuse there is no pipeline stage at the output port, the result immediately changes with respect to the PortADDnSUB signal.
Parameters:
Dynamic Adder/Subtractor with Pipeline Stages at Input and Output In this mode, input port A and port B are pipelined and then added/subtracted based on the value of port PortADDnSUB. Because the output port is pipelined, the result is valid only on the second rising edge of the clock.
Parameters:
Dynamic Adder/Subtractor with a Port Constant

In this mode, a constant value is either added or subtracted from port A based on input port value PortADDnSUB (the constant value can be passed though the parameter CONSTANT_VALUE). Optional pipeline stages can also be inserted at port A, Optionally, pipeline stages can also be added at the output port. Depending on the pipeline stages, a number of the dynamic adder/subtractor configurations are given below (here CONSTANT_VALUE=1). LO Dynamic Adder/Subtractor with No Pipeline Registers In this mode, dynamic adder/subtractor is a purely combinational, and the output change immediately with respect to the input.
Parameters:
Dynamic Adder/Subtractor with Pipeline Stages at Input Only In this mode, a constant value is either added or subtracted from the pipelined version of port A based on the value of port PortADDnSUB. Because there is no pipeline stage on the output port, the result changes immediately with respect to the PortADDnSUB signal.
Parameters:
Dynamic Adder/Subtractor with Pipeline Stages at Input and Output In this mode, a constant value is either added or subtracted from the pipelined version of port A based on the value of port PortADDnSUB. Because the output port is pipelined, the result is valid only on the second rising edge of the clock.
Parameters:
Dynamic Adder/Subtractor with Carry Input

The following waveform shows the behavior of the dynamic adder/subtractor with a carry input (the carry input is assumed to be 0).
LO
Dynamic Adder/Subtractor with Complete Control Signals

The following waveform shows the complete signal set for the dynamic adder/subtractor. The enable and reset signals are always present in all of the previous cases.
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 that you define using the SYNCore IP wizard. Note: The SYNCore counter model use 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. 1. Start the wizard.

n the window that opens, select counter_model and click Ok to open

page1 of the wizard.
LO
2. Specify the parameters you need in the wizard. For details about the parameters, see Specifying Counter Parameters, on page 530. The COUNTER symbol on the left reflects any parameters you set. 3. After you have specified all the parameters you need, click the Generate 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. 4. The SYNCore wizard also generates a testbench for your counter. The testbench covers a limited set of vectors. You can now close the wizard. 5. Edit the counter files if necessary. 6. Add the counter you generated to your design.
Use the Add File command to add the Verilog design file that was 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
located in the same output files directory. Copy the lines that define 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
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.
LO
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 conditionsunder which the port is available.
Port Name PortCE PortClk PortLoad
Description
Count Enable input pin with size one (active high) Primary clock input
Required/Optional
Always present Always present
Load Enable input which Not present for parameter loads the counter (active high). LOAD=0 Load value primary input (active high) Reset input which resets the counter (active high) Primary input which determines the counter mode. 0 = Up counter 1 = Down counter Counter primary output Not present for parameter Always present Present only for
MODE="Dynamic"
PortLoadValue PortRST PortUp_nDown
LOAD=0 and LOAD=1
PortCount
Always present
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 variableload 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. LO
1. Start the SYNCore counter wizard, as described in Specifying Counters with SYNCore, on page 526. 2. Enter the following on page 1 of the wizard:
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. Paramaters section.
Enter the width and depth of the counter in the Configure the Counter 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.
The SYNCore counter compiler generates Verilog code for your up, down, and dynamic (up/down ) counter implementation. This section describes the following:
Overview, on page 532 UP Counter Operation, on page 533 Down Counter Operation, on page 533 Dynamic Counter Operation, on page 534
Overview
The SYNCore counter component supports up, down, and dynamic (up/down) counter implementations using DSP blocks or logic elements. For each configuration, design optimizations are made for optimum use of core resources. As its name implies, the COUNTER block counts up (increments) or down (decrements) by a step value and provides an output result. You can load a constant or a variable as an intermediate value or base for the counter. Reset to the counter on the PortRST input is active high and can be can be configured either as synchronous or asynchronous using the RESET_TYPE parameter. Count enable on the PortCE input must be value high to enable the counter to increment or decrement.
LO
Note: Altera Stratix II and Stratix III DSP blocks have registers with asynchronous resets only. Xilinx Virtex4 and Virtex5 DSP blocks have registers with synchronous resets only. Please configure the multiplier accordingly while targeting to these technologies for effective utilization of the DSP blocks.
UP Counter Operation
In this mode, the counter is incremented by the step value defined by the STEP parameter. When reset is asserted (when PostRST is active high), the counter output is reset to 0. After the assertion of PortCE, the counter starts counting upwards coincident with the rising edge of the clock. The following waveform is with a constant STEP value of 5 and no load value.
Parameters:
MODE= Up LOAD= 0
Note: Counter core can be configured to use a constant or dynamic load value in Up Counter mode (for the counter to load the PortLoadValue, PortCE must be active). This functionality is explained in Dynamic Counter Operation, on page 534.
Down Counter Operation

In this mode, the counter is decremented by the step value defined by the STEP parameter. When reset is asserted (when PostRST is active high), the counter output is reset to 0. After the assertion of PortCE, the counter starts counting downwards coincident with the rising edge of the clock. The following waveform is with a constant STEP value of 5 and no load value.
Parameters:
MODE= Down LOAD= 0
Note: Counter core can be configured to use a constant or dynamic load value in Down Counter mode (for the counter to load the PortLoadValue, PortCE must be active). This functionality is explained in Dynamic Counter Operation, on page 534.
Dynamic Counter Operation

In this mode, the counter is incremented or decremented by the step value defined by the STEP parameter; the count direction (up or down) is controlled by the PortUp_nDown input (1 = up, 0 = down).
Dynamic Up/Down Counters with Constant Load Value*

On de-assertion of PortRST, the counter starts counting up or down based on the PortUp_nDown input value. The following waveform is with STEP value of 5 and a LOAD_VALUE of 80. When PortLoad is asserted, the counter loads the constant load value on the next active edge of clock and resumes counting in the specified direction.
Parameters:
MODE= Dynamic LOAD= 1 LO
Note: *For counter to load the PortLoadValue, PortCE must be active.
Dynamic Up/Down Counters with Dynamic Load Value*

On de-assertion of PortRST, the counter starts counting up or down based on the PortUp_nDown input value. The following waveform is with STEP value of 5 and a LOAD_VALUE of 80. When PortLoad is asserted, the counter loads the constant load value on the next active edge of clock and resumes counting in the specified direction. In this mode, the counter counts up or down based on the PortUp_nDown input value. On the assertion of PortLoad, the counter loads a new PortLoadValue and resumes up/down counting on the next active clock edge. In this example, a variable PortLoadValue of 8 is used with a counter STEP value of 5.
Parameters:
MODE= Dynamic LOAD= 2
Note: * For counter to load the PortLoadValue, PortCE should be active.
LO
CHAPTER 16
Using DesignWare IP
DesignWare IP Sources
The Certify tool can implement DesignWare IP in FPGA designs from two distinct sources:
Synopsys DesignWare foundation library building blocks DesignWare-compatible models originally developed by Synplicity, Inc.
The Synopsys foundation library is licensed separately from Synopsys; the DesignWare-compatible library is a standard feature of the Synplify Premier and Certify tools. Either library can be used as the source of the DesignWare IP, but components from the two libraries cannot be intermixed.
Using DesignWare Building Blocks

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.
Install the Synopsys DesignWare foundation library included in the

Synopsys Design Compiler download; a separate license is required.
Set the path to the DesignWare foundation library by either:

Using DesignWare Building Blocks
specifying the path to the library using the dc_root installPath Tcl
command
selecting the Implementation Options dialog box and using either the
Verilog or VHDL tab to enter the path to the library in the Design Compiler Installation Location [$SYNOPSYS=]: field
Note: 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.
Enable using the DesignWare foundation library by: checking the Use DesignWare Foundation Library checkbox on either the
Verilog or VHDL tab
entering either of the following Tcl commands

set_option -dw_foundation 1 set_option -dw_library {dw_foundation}
If low-power building blocks are to be used in place of standard DesignWare building blocks, enable using the DesignWare minPower library by:
checking 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 not enabled).
entering either of the following Tcl commands

set_option -dw_minpower 1 set_option -dw_library {dw_minpower} LO Note that the above commands do not automatically enable the DesignWare foundation library, and that the foundation library must be explicitly enabled to use the minPower library.
Using DesignWare-Compatible Models
Set the response to being unable to locate a DesignWare foundation

library license according to your design criteria. Checking Stop Synthesis if no DesignWare license found or entering the following Tcl command set_option -dw_stop_on_nolic 1 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 defaults) allows synthesis to continue by black boxing each building block in the RTL. Note: The DesignWare feature license can use the multiprocessing capability of the Certify tool when multiple processor cores and licenses are available. To set the number of licenses, open the Options->Configure Synplify Launch dialog box and set the Maximum number of parallel jobs value to the desired number of licenses. You can also set the number of licenses with a set_option max_parallel_jobs Tcl command. The normal ratio of license use is one DesignWare license for every two synthesis licenses.

The Certify tool can replace Synopsys DesignWare foundation library building blocks instantiated in your VHDL or Verilog source code with corresponding DesignWare-compatible models originally developed by Synplicity, Inc. For a list of the available DesignWare-compatible models, see Available DesignWare-Compatible Models, on page 546 of the Reference Manual. For information on how to instantiate the supported DesignWare-compatible models in your source code, see:
Verilog Library Models, on page 540 VHDL Library Models, on page 541
Note: For a comparison list of Synopsys DesignWare foundation library building blocks, see http://www.synopsys.com/dw/buildingblock.php.
Verilog Library Models

This section describes the following:
Instantiating and Compiling Verilog Models, on page 540 Inferring Verilog Functions, on page 541 Instantiating and Compiling Verilog Models
To instantiate DesignWare-compatible models in your Verilog code, enable access to the Verilog model library (dw_verilog.v) by: 1. Opening the Implementation Options dialog box in the Project view. 2. Going to either the Options tab and enabling the Compile with Designware Library (dw_verilog.v) switch or to the Verilog tab and enabling Use Synplicity Legacy DesignWare Library. Either action causes the dw_verilog.v model file to be referenced during compilation. You can also enable access to the DesignWare-compatible library using the following Tcl command: set_option -enable_designware 1 3. Before you compile your project, enable the V2001 switch by doing one of the following:
Check the Verilog 2001 check box on the Verilog tab of the Implementation
Options dialog box.
Adding the following command in the #add_file options section of your

project file: set_option -vlog_std v2001. The dw_verilog.v file uses Verilog 2001 constructs, so you must enable this option before compiling your design. 4. Compile and synthesize your design as usual. The DesignWare-compatible models duplicate the functionality of the their corresponding Synopsys DesignWare foundation library building blocks, but not their exact implementation. When there is no DesignWare-compatible model corresponding to a DesignWare building block in your source code, you get an error message indicating that an unsupported building block has been encountered, and your design cannot be LO compiled (see Unsupported DesignWare Foundation Library Building Blocks, on page 543; for a list of DesignWare-compatible models, see
Available DesignWare-Compatible Models, on page 546 of the Reference Manual).
Inferring Verilog Functions

You can infer Verilog functions for a subset of the DesignWare-compatible models. For a list of the models supporting function inferencing, see Available DesignWare-Compatible Models, on page 546 of the Reference Manual. To use function inferencing, add the directory containing the DesignWarecompatible functions (dw_functions) to your include path, as described in the following procedure. You can either use the GUI method described in step 1 or the command line method described in step 2. Note: Function inferencing is only supported in Verilog-based designs. 1. To set up function inferencing from the GUI, do the following:
Open the Implementation Options dialog box in the Project view. Go to the Verilog tab and type the following path in the Include Path
Order field: install_dir/lib/designware/dw_functions 2. To set up function inferencing from the command line, add the following line to your project file: set_option -include_path "install_dir/lib/designware/dw_functions" 3. Synthesize the design.
VHDL Library Models

For VHDL designs, this section provides setup information so that the Certify tool can use DesignWare-compatible models in place of DesignWare foundation library building blocks in your VHDL source code.
Instantiating VHDL Models, on page 542 Creating and Editing VHDL Component Libraries, on page 543
Instantiating VHDL Models

DesignWare foundation library building blocks in VHDL-based code are replaced by corresponding Verilog-based, DesignWare-compatible models to create a mixed HDL design. To include the Verilog DesignWare-compatible model library in your project: 1. Open the Implementation Options dialog box in the Project view, go to the Options tab, and enable the Compile with Designware Library (dw_verilog.v) switch or enter the following Tcl command: set_option -enable_designware 1 2. Specify the top module: set_option -top_module "module_name" You must specify the top module for mixed HDL designs. 3. Before you compile your mixed HDL project, enable the V2001 switch by doing one of the following:
Check the Verilog 2001 check box on the Verilog tab of the Implementation
Options dialog box.
Adding the following command in the #add_file options section of your

project file: set_option -vlog_std v2001. The dw_verilog.v file uses Verilog 2001 constructs, so you must enable this option before compiling your design. 4. Compile and synthesize your design as usual. The DesignWare-compatible models duplicate the functionality of the their corresponding Synopsys DesignWare foundation library building blocks, but not their exact implementation. When there is no DesignWare-compatible model corresponding to a DesignWare building block in your source code, you get an error message indicating that an unsupported building block has been encountered, and your design cannot be compiled (see Unsupported DesignWare Foundation Library Building Blocks, on page 543; for a list of compatible models, see Available DesignWare-Compatible Models, on page 546 of the Reference Manual). LO
Unsupported DesignWare Foundation Library Building Blocks

When a DesignWare foundation library building block does not have a corresponding DesignWare-compatible model, you can either:
Use the Synopsys DesignWare foundation library. Using this library is

recommended as the full set of building blocks, synchronized with the customers companion ASIC flow, is available.
Model the unsupported building block as outlined below. For a list of

supported DesignWare-compatible models, see Available DesignWareCompatible Models, on page 546 of the Reference Manual. To replace an unsupported DesignWare foundation library building block, you must create your own model and then add the model file to your project. If you are creating a Verilog replacement model, simply add your model to your project file and then recompile your design. For example, the command add_file -verilog "my_DW_model" instructs the Synplify Premier tool to use your Verilog version of the model. The model name in my_DW_model must be the same name as the DesignWare foundation library building block that you are replacing. If you are creating a VHDL replacement model, your must add the model and corresponding VHDL library to your project as described in the following subsection.
Creating and Editing VHDL Component Libraries

The following procedure shows you how to create and edit a VHDL library for a DesignWare-compatible model. 1. To create and add a new library, use the following command syntax: add_file -library newlib add_file -vhdl -lib newlib dw_name.vhd For example, the following commands define a new library my_lib and compile the dw02_comp.vhd model into this library: add_file -library my_lib add_file vhdl lib my_lib dw02_comp.vhd 2. To add a new set of DesignWare model objects, such as entities and or architectures to an existing library, use this command syntax:
add_file -vhdl -lib exisiting_lib "new_object" The following command appends information for the new DW_square model to the DW01 library: add_file vhdl lib DW01 "DW_square.vhd" 3. To add a missing DesignWare-compatible model declaration to an existing package, do the following:
First add the missing component declaration to the library using this
command syntax: add_file -vhdl -lib library_name "component_pkg.vhd" The following example adds the missing DW_square model to the dw01_comp.vhd library: add_file -vhdl -lib DW01 "DW_square.vhd"
Add the component declaration to the vhd package by adding a line

like the following to the project file. This example adds the component declaration for DW_square in dw01_comp.vhd package. The DW01_components package is declared in the file by name (dw01_comp_add.vhd). add_file -vhdl -lib DW01 "DW01_comp_add.vhd" 4. To replace a model declaration in the existing package with a new declaration, add a line similar to the following: add_file vhdl lib DW01 "DW01_comp_replace.vhd" The example shows a new declaration for a DesignWare model, DW01_comp_replace.vhd, in the DW01 library. For a list of supported DesignWare-compatible models, see Available DesignWare-Compatible Models, on page 546 of the Reference Manual. 5. To replace an existing entity or architecture component in a library with a model you define, do the following:
Write your code for the model, and give the model the same name as
the model you want to replace. For example, if you want to replace an existing model called DW_square, name your custom design model LO DW_square.vhd.
Add a statement like the following to the project file to override the
existing model definition:
add_file -vhdl -lib DW02 DW_square.vhd Your DW_square model overwrites the existing model in the DW02 library. 6. If your design references libraries or packages that are not included, create a dummy package and add it to your project file. Creating a dummy package ensures that the compiler ignores the referenced package and that you do not get a compiler error because the tool cannot find a library.
Available DesignWare-Compatible Models

DesignWare-compatible models have been created for a majority of the standard DesignWare foundation library building blocks. The DesignWarecompatible models duplicate the functionality of the their corresponding DesignWare building blocks, but not their exact implementation. DesignWare users are urged to adopt the DesignWare foundation library building blocks to take advantage of the expanded component library and on-going component development, and the fully synchronized component support for the ASIC flow. The following sections list supported DesignWare-compatible models either by function or alphabetically:
Supported Models by Function, on page 546 Supported Models Alphabetical List, on page 553
For information about instantiating and inferring DesignWare-compatible models in your source code, see Verilog Library Models, on page 540 or VHDL Library Models, on page 541 in the User Guide. Note: For a comparison list of Synopsys DesignWare foundation library building blocks, see http://www.synopsys.com/dw/buildingblock.php.
Supported Models by Function

This section arranges DesignWare foundation library building blocks for which there is a corresponding FPGA-compatible model by function. These models are available only for the Synplify Premier and Synplify Premier with Design Planner tools. To see the list of supported models arranged alphabetically, see Supported Models Alphabetical List, on page 553. Information is grouped by functions, under the headings listed below. Note: Models marked with a double asterisk (**) support Verilog funcLO tion inferencing.
Data Integrity, on page 547

Combinational, on page 547 Sequential, on page 548 Register, on page 548 FIFO and Controllers, on page 548 Memories, on page 549 Arithmetic, on page 550 Floating Point, on page 552 Test, on page 552 Data Path, on page 553
Data Integrity
DW_8b10b_dec DW_8b10b_enc DW_crc_p DW_ecc DW04_crc32 DW04_par_gen 8b/10b Decoder 8b/10b Encoder Universal Parallel CRC Generator/Checker Error Checking and Correction 32-Bit CRC Polynomial Generator/Checker Parity Generator and Checker
Combinational
DW_lzd **DW01_binenc **DW01_bsh **DW01_decode DW01_mux_any **DW01_prienc Leading Zeros Detector Binary Encoder Barrel Shifter Decoder Universal Multiplexor Priority Encoder
** Function inferencing supported
Sequential
DW03_bictr_dcnto DW03_bictr_decode DW03_bictr_scnto DW03_cntr_gray DW03_lfsr_dcnto DW03_lfsr_load DW03_lfsr_scnto DW03_lfsr_updn DW03_updn_ctr Up/down Binary Counter Up/down Binary Counter Up/down Binary Counter Gray Code Counter LFSR Counter with Dynamic Count-to Flag LFSR Counter with Loadable Input LFSR Counter with Static Count-to Flag LFSR Up/Down Counter Up/down Counter
Register
DW03_pipe_reg DW03_reg_s_pl DW03_shftreg DW04_shad_reg DW04_sync Pipeline Register Register with Synchronous Enable Reset Shift Register Shadow and Multibit Register Variable Input Synchronizer
FIFO and Controllers

DW_asymfifo_s1_df DW_asymfifo_s1_sf DW_asymfifo_s2_sf DW_asymfifoctl_s1_df DW_asymfifoctl_s1_sf Asymmetric I/O Synchronous (Single Clock) FIFO with Dynamic Flags Asymmetric I/O Synchronous (Single Clock) FIFO with Static Flags Asymmetric I/O Synchronous (Dual Clock) FIFO with Static Flags Asymmetric I/O Synchronous (Single Clock) FIFO Controller with Dynamic Flags Asymmetric I/O Synchronous (Single Clock) FIFO LO Controller with Static Flags
DW_asymfifoctl_s2_sf DW_fifo_s1_df DW_fifo_s1_sf DW_fifoctl_s1_df DW_fifoctl_s1_sf DW_fifo_s2_sf DW_fifoctl_s2_sf DW_stack DW_stackctl
Asymmetric I/O Synchronous (Dual Clock) FIFO Controller with Static Flags Synchronous (Single Clock) FIFO with Dynamic Flags Synchronous (Single Clock) FIFO with Static Flags Synchronous (Single Clock) FIFO Controller with Dynamic Flags Synchronous (Single Clock) FIFO Controller with Static Flags Synchronous (Dual Clock) FIFO with Static Flags Asymmetric Synchronous (Dual Clock) FIFO with Static Flags Synchronous (Single Clock) Stack Synchronous (Single Clock) Stack Controller
Memories
DW_ram_rw_a_dff DW_ram_rw_a_lat DW_ram_r_w_a_dff DW_ram_r_w_a_lat DW_ram_2r_w_a_dff DW_ram_2r_w_a_lat DW_ram_rw_s_dff DW_ram_rw_s_lat DW_ram_r_w_s_dff Asynchronous Single-Port RAM (Flip-Flop Based) Asynchronous Single-Port RAM (Latch-Based) Asynchronous Dual-Port RAM (Flip-Flop Based) Asynchronous Dual-Port RAM (Latch-Based) Asynchronous Three-Port RAM (Flip-Flop Based) Asynchronous Three-Port RAM (Latch-Based) Synchronous Single-Port, Read/Write RAM (Flip-Flop Based) Synchronous Single-Port, Read/Write RAM (Latch-Based) Synchronous Write-Port, Asynchronous Read-Port RAM (Flip-Flop Based)
DW_ram_r_w_s_lat DW_ram_2r_w_s_dff DW_ram_2r_w_s_lat
Synchronous Write-Port, Asynchronous Read-Port RAM (Latch-Based) Synchronous Write-Port, Asynchronous Dual Read-Port RAM (Flip-Flop Based) Synchronous Write-Port, Asynchronous Dual Read-Port RAM (Latch-Based)
Arithmetic
DW_addsub_dx DW_bin2gray DW_cmp_dx DW_cntr_gray **DW_div DW_div_pipe DW_div_rem DW_div_seq DW_gray2bin DW_inc_gray DW_inv_sqrt DW_lbsh **DW_minmax DW_mult_dx DW_mult_pipe DW_norm DW_norm_rnd DW_piped_mac DW_prod_sum_pipe DW_rash Duplex Adder-Subtractor with Saturation and Rounding Binary to Gray Converter Duplex Comparator Gray Code Converter Combinational Divider/Remainder/Modulus Stallable Pipelined Divider Combinational Integer Divider with Quotient and Remainder Sequential Divider Gray to Binary Converter Gray Incrementor Reciprocal of Square-Root Barrel Shifter with Preferred Left Direction Minimum/Maximum Value Duplex Multiplier Pipelined multiplier Normalization for Fractional Input Normalization and Rounding Pipelined Multiplier-Accumulator
LO Pipelined Multiplier-Adder
Arithmetic Shifter with Preferred Right Direction
DW_rbsh **DW_shifter **DW_sqrt DW_sqrt_pipe **DW_square DW_squarep **DW_ver_mod **DW_vhd_mod **DW01_absval DW01_add DW01_addsub **DW01_ash DW01_cmp2 DW01_cmp6 DW01_csa DW01_dec DW01_inc DW01_incdec DW01_satrnd DW01_sub **DW02_divide DW02_cos **DW02_mac **DW02_mult DW02_multp DW02_mult_2_stage DW02_mult_3_stage
Barrel Shifter with Preferred Right Direction Combined Arithmetic and Barrel Shifter Combinational Square Root Stallable Pipelined Square Root Integer Square Partial Product Integer Squarer Combinational Modulus for Verilog LRM Combinational Modulus for VHDL LRM Absolute Value Adder Adder Subtractor Arithmetic Shifter 2-Function Comparator 6-Function Comparator Carry Save Adder Decrementer Incrementer Incrementer/Decrementer Arithmetic Saturation and Rounding Logic Subtractor Combinational Divider Combinational Cosine Multiplier/Accumulator Multiplier Partial Product Multiplier Two-Stage Pipelined Multiplier Three-Stage Pipelined Multiplier
DW02_mult_4_stage DW02_mult_5_stage DW02_mult_6_stage DW02_prod_sum DW02_prod_sum1 **DW02_rem DW02_sin DW02_sincos **DW02_sqrt **DW02_sum DW02_tree
Four-Stage Pipelined Multiplier Five-Stage Pipelined Multiplier Six-Stage Pipelined Multiplier Generalized Sum of Products Multiplier-Adder Combinational Remainder Combinational Sine Combinational Sine-Cosine Combinational Square Root Vector Adder Wallace Tree Compressor
Floating Point
DW_fp_addsub DW_fp_div DW_fp_flt2i DW_fp_i2flt DW_fp_mult Floating Point Adder/Subtractor Floating Point Divider Floating Point to Integer Converter Integer to Floating Point Converter Floating Point Multiplier
*Precision format can only be parameterized to either IEEE single- or double-precision
Test
DW_bc_1 DW_bc_2 DW_bc_3 DW_bc_4 DW_bc_5 DW_bc_7
Boundary Scan Cell Type BC_1 Boundary Scan Cell Type BC_2 Boundary Scan Cell Type BC_3 Boundary Scan Cell Type BC_4 LO Boundary Scan Cell Type BC_5 Boundary Scan Cell Type BC_7
DW_bc_8 DW_bc_9 DW_bc_10 DW_tap
Boundary Scan Cell Type BC_8 Boundary Scan Cell Type BC_9 Boundary Scan Cell Type BC_10 Tap Controller
Data Path
**DWF_dp_absval **DWF_dp_blend **DWF_dp_count_ones **DWF_dp_rnd **DWF_dp_rndsat **DWF_dp_sat **DWF_dp_sign_select **DWF_dp_simd_add **DWF_dp_simd_addc **DWF_dp_simd_mult Returns the absolute value (magnitude) of an argument Implements an alpha blender or linear interpolator Counts ones in argument Performs arithmetic rounding Performs arithmetic rounding and saturation Performs arithmetic saturation Performs sign selection / conditional two's complement Configurable SIMD adder Configurable SIMD adder with carry Configurable SIMD multiplier
**Function inferencing supported
Supported Models Alphabetical List

The following is an alphabetical list of the DesignWare foundation library building blocks for which there is a corresponding DesignWare-compatible model. DesignWare-compatible model support is available only with the Synplify Premier and Synplify Premier with Design Planner tools. To view the models sorted by functions, see Supported Models by Function, on page 546. Note: Models marked with a double asterisk (**) support Verilog function inferencing.
Function
DW_8b10b_dec DW_8b10b_enc DW_addsub_dx DW_asymfifo_s1_df DW_asymfifo_s1_sf DW_asymfifo_s2_sf DW_asymfifoctl_s1_df DW_asymfifoctl_s1_sf DW_asymfifoctl_s2_sf DW_bc_1 DW_bc_2 DW_bc_3 DW_bc_4 DW_bc_5 DW_bc_7 DW_bc_8 DW_bc_9 DW_bc_10 DW_bin2gray DW_cmp_dx DW_cntr_gray DW_crc_p
Name
8b/10b Decoder 8b/10b Encoder Duplex Adder-Subtractor with Saturation and Rounding Asymmetric I/O Synchronous (Single Clock) FIFO with Dynamic Flags Asymmetric I/O Synchronous (Single Clock) FIFO with Static Flags Asymmetric I/O Synchronous (Dual Clock) FIFO with Static Flags Asymmetric I/O Synchronous (Single Clock) FIFO Controller with Dynamic Flags Asymmetric I/O Synchronous (Single Clock) FIFO Controller with Static Flags Asymmetric I/O Synchronous (Dual Clock) FIFO Controller with Static Flags Boundary Scan Cell Type BC_1 Boundary Scan Cell Type BC_2 Boundary Scan Cell Type BC_3 Boundary Scan Cell Type BC_4 Boundary Scan Cell Type BC_5 Boundary Scan Cell Type BC_7 Boundary Scan Cell Type BC_8 Boundary Scan Cell Type BC_9 Boundary Scan Cell Type BC_10 Binary to Gray Converter Duplex Comparator Gray Code Converter Universal Parallel CRC Generator/Checker
LO
Function
**DW_div DW_div_pipe DW_div_rem DW_div_seq DW_ecc DW_fifo_s1_df DW_fifo_s1_sf DW_fifo_s2_sf DW_fifoctl_s1_df DW_fifoctl_s1_sf DW_fifoctl_s2_sf DW_fp_addsub DW_fp_div DW_fp_flt2i DW_fp_i2flt DW_fp_mult DW_gray2bin DW_inc_gray DW_inv_sqrt DW_lbsh DW_lzd **DW_minmax DW_mult_dx DW_mult_pipe
Name
Combinational Divider/Remainder/Modulus Stallable Pipelined Divider Combinational Integer Divider with Quotient and Remainder Sequential Divider Error Checking and Correction Synchronous (Single Clock) FIFO with Dynamic Flags Synchronous (Single Clock) FIFO with Static Flags Synchronous (Dual Clock) FIFO with Static Flags Synchronous (Single Clock) FIFO Controller with Dynamic Flags Synchronous (Single Clock) FIFO Controller with Static Flags Asymmetric Synchronous (Dual Clock) FIFO with Static Flags Floating Point Adder/Subtractor Floating Point Divider Floating Point to Integer Converter Integer to Floating Point Converter Floating Point Multiplier Gray to Binary Converter Gray Incrementor Reciprocal of Square-Root Barrel Shifter with Preferred Left Direction Leading Zeros Detector Minimum/Maximum Value Duplex Multiplier Pipelined Multiplier
Function
DW_norm DW_norm_rnd DW_piped_mac DW_prod_sum_pipe DW_ram_2r_w_a_dff DW_ram_2r_w_a_lat DW_ram_2r_w_s_dff DW_ram_2r_w_s_lat DW_ram_r_w_a_dff DW_ram_r_w_a_lat DW_ram_r_w_s_dff DW_ram_r_w_s_lat DW_ram_rw_a_dff DW_ram_rw_a_lat DW_ram_rw_s_dff DW_ram_rw_s_lat DW_rash DW_rbsh **DW_shifter **DW_sqrt DW_sqrt_pipe **DW_square
Name
Normalization for Fractional Input Normalization and Rounding Pipelined Multiplier-Accumulator Pipelined Multiplier-Adder Asynchronous Three-Port RAM (Flip-Flop Based) Asynchronous Three-Port RAM (Latch-Based) Synchronous Write-Port, Asynchronous Dual Read-Port RAM (Flip-Flop Based) Synchronous Write-Port, Asynchronous Dual Read-Port RAM (Latch-Based) Asynchronous Dual-Port RAM (Flip-Flop Based) Asynchronous Dual-Port RAM (Latch-Based) Synchronous Write-Port, Asynchronous Read-Port RAM (Flip-Flop Based) Synchronous Write-Port, Asynchronous Read-Port RAM (Latch-Based) Asynchronous Single-Port RAM (Flip-Flop Based) Asynchronous Single-Port RAM (Latch-Based) Synchronous Single-Port, Read/Write RAM (Flip-Flop Based) Synchronous Single-Port, Read/Write RAM (LatchBased) Arithmetic Shifter with Preferred Right Direction Barrel Shifter with Preferred Right Direction Combined Arithmetic and Barrel Shifter Combinational Square Root Stallable Pipelined Square Root LO Integer Square
Function
DW_squarep DW_stack DW_stackctl DW_tap **DW_ver_mod **DW_vhd_mod **DWF_dp_absval **DWF_dp_blend **DWF_dp_count_ones **DWF_dp_rnd **DWF_dp_rndsat **DWF_dp_sat **DWF_dp_sign_select **DWF_dp_simd_add **DWF_dp_simd_addc **DWF_dp_simd_mult **DW01_absval DW01_add DW01_addsub **DW01_ash **DW01_binenc **DW01_bsh DW01_cmp2 DW01_cmp6 DW01_csa DW01_dec
Name
Partial Product Integer Squarer Synchronous (Single Clock) Stack Synchronous (Single Clock) Stack Controller Tap Controller Combinational Modulus for Verilog LRM Combinational Modulus for VHDL LRM Returns the absolute value (magnitude) of an argument Implements an alpha blender or linear interpolator Counts ones in argument Performs arithmetic rounding Performs arithmetic rounding and saturation Performs arithmetic saturation Performs sign selection / conditional two's complement Configurable SIMD adder Configurable SIMD adder with carry Configurable SIMD multiplier Absolute Value Adder Adder Subtractor Arithmetic Shifter Binary Encoder Barrel Shifter 2-Function Comparator 6-Function Comparator Carry Save Adder Decrementer
Function
**DW01_decode DW01_inc DW01_incdec DW01_mux_any **DW01_prienc DW01_satrnd DW01_sub DW02_cos **DW02_divide **DW02_mac **DW02_mult DW02_mult_2_stage DW02_mult_3_stage DW02_mult_4_stage DW02_mult_5_stage DW02_mult_6_stage DW02_multp DW02_prod_sum DW02_prod_sum1 **DW02_rem DW02_sin DW02_sincos **DW02_sqrt **DW02_sum DW02_tree DW03_bictr_dcnto
Name
Decoder Incrementer Incrementer/Decrementer Universal Multiplexor Priority Encoder Arithmetic Saturation and Rounding Logic Subtractor Combinational Cosine Combinational Divider Multiplier/Accumulator Multiplier Two-Stage Pipelined Multiplier Three-Stage Pipelined Multiplier Four-Stage Pipelined Multiplier Five-Stage Pipelined Multiplier Six-Stage Pipelined Multiplier Partial Product Multiplier Generalized Sum of Products Multiplier-Adder Combinational Remainder Combinational Sine Combinational Sine-Cosine Combinational Square Root Vector Adder Wallace Tree Compressor Up/down Binary Counter
LO
Function
DW03_bictr_decode DW03_bictr_scnto DW03_cntr_gray DW03_lfsr_dcnto DW03_lfsr_load DW03_lfsr_scnto DW03_lfsr_updn DW03_pipe_reg DW03_reg_s_pl DW03_shftreg DW03_updn_ctr DW04_crc32 DW04_par_gen DW04_shad_reg DW04_sync
Name
Up/down Binary Counter Up/down Binary Counter Gray Code Counter LFSR Counter with Dynamic Count-to Flag LFSR Counter with Loadable Input LFSR Counter with Static Count-to Flag LFSR Up/Down Counter Pipeline Register Register with Synchronous Enable Reset Shift Register Up/down Counter 32-Bit CRC Polynomial Generator/Checker Parity Generator and Checker Shadow and Multibit Register Variable Input Synchronizer
LO
CHAPTER 17
Specifying Design-Level Optimizations

This chapter covers techniques for optimizing your design using built-in tools or attributes. For vendor-specific optimizations, see Chapter 19, Optimizing for Specific Targets. It describes the following:
Tips for Optimization, on page 562 Preserving Objects from Optimization, on page 565 Optimizing Fanout, on page 569 Sharing Resources, on page 573 Inserting I/Os, on page 575
Optimizing State Machines, on page 576 Inserting Probes, on page 584 Working with Gated Clocks, on page 587 Optimizing Generated Clocks, on page 600
Tips for Optimization

The software automatically makes efficient tradeoffs 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 562 Optimizing for Area, on page 563 Optimizing for Timing, on page 564
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 563. For timing optimization, see Optimizing for Timing, on page 564.
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

attribute 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 attribute to firm.
For accurate results with timing-driven synthesis, explicitly define clock LO

frequencies with a constraint, instead of using a global clock frequency.
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 performance 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 564. General optimization tips are in General Optimization Tips, on page 562.
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 570 for more information.
Check 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. See Sharing Resources, on page 573 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 396.
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 396.
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.
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 563. General optimization tips are in General Optimization Tips, on page 562.
Use realistic design constraints, about 10 - 15% of the real goal. Over
constraining your design can be counter-productive because you can get poor implementations. Use clock, false path, and multi-cycle path constraints to make the constraints realistic.
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 570 for information about setting limits.
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 saw warnings about feedback muxes being created for signals
when you compiled 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. LO
Preserving Objects from Optimization

Synthesis can collapse or remove nets during optimization. If you want to retain a net for simulation, probing, or for a different synthesis implementation, 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 attributes and their syntax, see the Reference Manual. To Preserve...
Nets
Attach... syn_keep on wire or reg (Verilog), or signal (VHDL). syn_probe on wire or reg (Verilog), or signal (VHDL) syn_keep on input wire or signal of shared registers
Result
Keeps net for simulation, a different synthesis implementation, or for passing to the place-and-route tool. Preserves internal net for probing. Preserves duplicate driver cells, prevents sharing. See Using syn_keep for Preservation or Replication, on page 566 for details on the effects of applying syn_keep to different objects. Preserves logic of constant-driven registers, keeps registers for simulation, prevents sharing Prevents the output port or internal signal that holds the value of the state register from being optimized Keeps instance for analysis, preserves instances with unused outputs
Nets for probing Shared registers
Sequential components FSMs
syn_preserve on reg or module (Verilog), signal or architecture (VHDL) syn_preserve on reg or module (Verilog), signal (VHDL) syn_noprune on module or component (Verilog), architecture or instance (VHDL)
Instantiated components
See the following for more information:
Using syn_keep for Preservation or Replication, on page 566 Controlling Hierarchy Flattening, on page 568 Preserving Hierarchy, on page 569
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.
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 wire wire wire in1a in1b in2a in2b /*synthesis syn_keep /*synthesisLO syn_keep /*synthesis syn_keep /*synthesis syn_keep = = = = 1*/; 1*/; 1*/; 1 */;
assign in1a assign in1b assign in2a assign in2b assign out1 assign out2 endmodule
= = = = = =
ina ; inb ; ina; inb; in1a & in1b; in2a & in2b;
Setting syn_keep on the input wires ensures that the second AND gate is preserved:
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.
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 569. 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. 2. Set the attribute value: To...
Flatten all levels below, but not the current level Remove the current level of hierarchy without affecting the lower levels Remove the current level of hierarchy and the lower levels Flatten the current level (if needed for optimization)
Value... flatten remove flatten, remove soft
The software flattens the design as directed. If there is a lower-level syn_hier attribute, it takes precedence over a higher-level one. LO
Optimizing Fanout
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 568. 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. 2. Set the attribute value: To...
Preserve the interface but allow cell packing across the boundary Preserve the interface with no exceptions Preserve the interface and contents with no exceptions (Altera only) Flatten lower levels but preserve the interface of the specified design unit
Value... firm hard macro flatten, firm
The software flattens the design as directed. If there is a lower-level syn_hier attribute, it takes precedence over a higher-level one.
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 570 Controlling Buffering and Replication, on page 571
Optimizing Fanout
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 technologies. 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 571 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. 2. 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 nonprimitive instances. These limits override the more global limits for that object. However, these limits still function as soft limits, and are replicated or buffered, as described in Controlling Buffering and Replication, on page 571. Attribute specified on... Module or view Non-primitive instance Clock nets or asynchronous control nets Effect Soft limit for the module; overrides the global setting. Soft limit; overrides global and module settings LO Soft limit.
Optimizing Fanout
3. 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 571. 4. 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 operations; for example, it does not respect an implicit buffer created as a result of syn_direct_enable. 5. 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 570) 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 which 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.
Optimizing Fanout
The following table summarizes the behavior. Replicates When... syn_replicate is 1 Creates Buffers When... syn_replicate is 0. 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
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 boundaries 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.
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
Sharing Resources
Sharing Resources
One of the ways you can optimize area is to use resource sharing. 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. 1. Specify resource sharing globally for the whole design with one of the methods below. Enable the option to improve area; disable it to improve timing.
Select Project->Implementation Options->Options, and enable or disable

Resource Sharing. Alternatively, enable Resource Sharing in the Project view.
Apply the syn_sharing directive to the top-level module or architecture

in the source code. See syn_sharing Directive, on page 899 of the Reference Manual for syntax examples.
Verilog module top(out, in, clk_in) /* synthesis syn_sharing = "on" */; VHDL
architecture rtl of top is attribute syn_sharing : string; attribute syn_sharing of rtl : architecture is "off";
You cannot specify syn_sharing from the SCOPE interface, because it is a compiler directive. 2. To specify resource sharing on an individual basis, or to override the global setting, specify the syn_sharing attribute for the lower-level module/architecture, using the syntax described in the previous step.
Sharing Resources
Multiple adders with syn_sharing off.
Shared adder resource with syn_sharing on.
LO
Inserting I/Os
Inserting I/Os
You can control I/O insertion globally, or on a port-by-port basis. To control the insertion of I/O pads at the top level of the design, use the Disable I/O Insertion option as follows: 1. Select Project->Implementation Options and click the Device panel. 2. 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. 3. 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. 4. For the most control, enable the option and then manually instantiate the I/O pads for specific pins, as needed.
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 576 Running the FSM Compiler, on page 577 Running the FSM Explorer, on page 581
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 396. 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 LO 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.
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 376.
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 581. 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 578 Running the FSM Compiler on Individual FSMs, on page 579
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 396. 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 have specified encoding styles, it automatically selects the encoding style based on the number of states. Number of States
Up to 4 5-40 > 40
Encoding Style sequential onehot gray
In the log file, the FSM Compiler writes a report that includes a description of each state machine extracted and the set of reachable states for each state machine.
LO
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 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 376.
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.
Verilog VHDL
reg [3:0] curstate /* synthesis syn_state_machine=0 */ ; signal curstate : state_type; attribute syn_state_machine : boolean; attribute syn_state_machine of curstate : signal is false;v
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 396. 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 LO synthesized, the FSM Compiler extracts these registers with the default encoding styles according to the number of states.
Verilog VHDL
reg [3:0] curstate /* synthesis syn_state_machine=1 */ ; signal curstate : state_type; attribute syn_state_machine : boolean; attribute syn_state_machine of curstate : signal is true;
For state machines with specific encoding styles, set the encoding
style with the syn_encoding attribute, as described in Specifying FSMs with Attributes and Directives, on page 396. 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. For information about the FSM viewer, see Using the FSM Viewer, on page 376.
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.
Verilog VHDL
reg [3:0] curstate /* synthesis state_machine */ ; signal curstate : state_type; attribute syn_state_machine : boolean; attribute syn_state_machine of curstate : signal is true;
Use syn_encoding if you want to set a specific encoding style.
Verilog VHDL
reg [3:0] curstate /* synthesis syn_encoding="gray"*/ ; signal curstate : state_type; attribute syn_encoding : string; attribute syn_encoding of curstate : signal is "gray";
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 Attributes and Directives, on page 396 for details. 2. Enable the FSM Explorer by checking the FSM Explorer box on the Options tab of the Implementation Options dialog box. 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.
LO
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) 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 376.
Inserting Probes
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 585. 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; LO attribute syn_probe of alu_tmp : signal is true; --other code;
Inserting Probes
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 property syn_probe, value 1, to net pc[0] Adding property syn_probe, value 1, to net pc[1] Adding property syn_probe, value 1, to net pc[2] Adding property syn_probe, value 1, to net pc[3] .... @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] @N|Added probe pc_keep_probe_2[1] on pc_keep[1] in eight_bit_uc @N|Also padding probe pc_keep_probe_2[1] @N|Added probe pc_keep_probe_3[2] on pc_keep[2] in eight_bit_uc
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 584. 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.
Inserting Probes
3. Do the following to add the attribute:
Drag the net into a SCOPE cell. 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.
Adding property syn_probe, value 1, to net pc[0] Adding property syn_probe, value 1, to net pc[1] Adding property syn_probe, value 1, to net pc[2] Adding property syn_probe, value 1, to net pc[3] .... @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] @N|Added probe pc_keep_probe_2[1] on pc_keep[1] in eight_bit_uc @N|Also padding probe pc_keep_probe_2[1] @N|Added probe pc_keep_probe_3[2] on pc_keep[2] in eight_bit_uc
LO
Working with Gated Clocks

This section first describes the gated clock solution, which is available for certain Altera and Xilinx technology families. The information is organized into these sections:
The Synplicity Approach to Gated Clocks, on page 587 Prerequisites for Gated Clock Conversion, on page 590 Synthesizing a Gated Clock Design, on page 592 Using Gated Clocks for Black Boxes, on page 594 Analyzing Gated Clock Conversion Reports, on page 595 Restrictions on Using Gated Clocks, on page 598
The Synplicity Approach to Gated Clocks

ASIC designs typically gate clocks to conserve power, with custom clock trees defined for each individual tree. FPGA design has dedicated resources for low-skew clock nets. If an FPGA design implements a large number of customized clock trees on some other routing resource, it can result in clock skew and timing problems. If you use the dedicated FPGA global clock trees instead, you free up routing resources and expedite 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 holdtime violations based on minimum delays are unnecessary. The solution is to separate the gating from the clock inputs, and combine individual clocks trees on the dedicated FPGA global clock trees. 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 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. See the following figure for examples of eliminating gated clocks.
LO
d a b clk
d a b clk
Gated Clock
Fixed Gated Clock
d a b clk en
d
D Q
clk
EN
EN
a b en Fixed Gated Clock
Gated Clock
d en1 clk en2 Gated Clock
d clk en1 en2
EN
Fixed Gated Clock
Prerequisites for Gated Clock Conversion

For a gated clock to be converted successfully, the design must meet these requirements: Condition
Combinational logic only Single base clock
Description
The gated-clock logic must consist only of combinational logic. A derived clock that is the output of a register is not converted. 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 (sdc) file. This example defines the clk input as the base clock:
define_clock -name {clk} -freq 10.000 -clockgroup default_clkgroup
Supported primitives
The sequential primitive clocked by the gated clock must be supported by the Certify tool (Certify supports 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 black box. See Using Gated Clocks for Black Boxes, on page 594. See Correct Logic Format, on page 590 for an example of the correct logic format.
Correct logic format
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.
LO
The correct logic format requirements are illustrated with the simple gates shown in the following figures. When the software synthesizes a design with the Fix Gated Cock 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. 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. 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.
OR gate gclks[2]
Exclusive-OR gate
gclks[3]
din[1:3] gate[1:3] clk
[1:3] [1:3] [3]
[3] D
[3]
[1:3]
dout[1:3]
gclks[3]
dout_1[3]
[2] D Q [2]
[1] [2]
Before Gated Clock Conversion dout_1[2]

[1] [1]
gclks[2]
[1] [2]
gclks[1]
dout_1[1]
din[1:3] gate[1:3] clk
[1:3] [1:3] [3]
[3] D
[3]
[1:3]
dout[1:3]
gclks[3]
dout_1[3]
[2] D CE Q [2]
After Gated Clock Conversion The clock enables for the AND and OR gates are converted, but the clock enable for the exclusive OR remains the same.
[1] [2]
dout_1[2]
[1] D CE Q [1]
un15_ce
[1] [2]
dout_1[1] ce[1]
Synthesizing a Gated Clock Design

The Fix Gated Clocks option described here is only available for some Altera and Xilinx technology families. 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 590 for details. 2. If the gated clock drives a black box, specify the clock and the associated clock enable signal with the following directives: syn_force_seq_prim, syn_isclock, and syn_gatedclk_en. See Using Gated Clocks for Black Boxes, on page 594 for details. 3. Make sure the clock net has a constraint specified in an sdc file for the current implementation. If you do not specify an explicit constraint on the clock net or set a LO global frequency constraint, enabling Fix Gated Clocks as described in the next step will not have any effect. 4. Enable the Fixed Gated Clocks option.
Select Project->Implementation Options.
On the Device tab, set the value of Fixed Gated Clocks according to the
kind of report you want to generate in the log file (see the following table). Value Effect
1 2 3 0 Does not report any gated clock conversions. Only reports sequential elements that could not be converted. The default. Reports the conversion status of all sequential elements. Disables the option.
5. Synthesize the design. The Fix Gated Clocks option works on 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 598 for additional information. 6. Check the results in the Gated Clock Report section of the log file. See Analyzing Gated Clock Conversion Reports, on page 595 for an example of this report.
Using Gated Clocks for Black Boxes

To fix gated clocks that drive black boxes, you must identify the clock and clock enable signal inputs to the black box. Use the syn_force_seq_prim, syn_isclock, and syn_gatedclk_clock_en directives to do this. Refer to the Reference Manual for information about these directives. You assume responsibility for their functionality. The following is an example 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 /* synthesis syn_isclock = 1 */ LO /* synthesis syn_gatedclk_clock_en="ena" */; input data_in,ena; output data_out; endmodule
VHDL
library synplify; use synplify.attributes.all; entity bbe is port ( clk : in std_logic; en : in std_logic; data_in : in std_logic; data_out : out std_logic); attribute attribute attribute attribute end bbe; architecture behave of bbe is attribute attribute attribute attribute begin end behave; syn_black_box : boolean; syn_force_seq_prim : string; syn_black_box of behave : architecture is true; syn_force_seq_prim of behave : architecture is "clk"; syn_isclock : boolean; syn_isclock of clk : signal is true; syn_gatedclk_clock_en : string; syn_gatedclk_clock_en of clk : signal is "en";
Analyzing Gated Clock Conversion Reports

The value of the Fix Gated Clocks option determines how the conversions in the log file are reported: Value Effect
1 2 3 0 Does not report any gated clock conversions. Only reports sequential elements that could not be converted. The default. Reports the conversion status of all sequential elements. See example, below. Disables the option.
For elements that could not be converted, the conversion also lists why the conversion did not occur.
Example
When Fix Gated Clocks is set to 3 (all sequential elements reported), the report for the logic shown in Correct Logic Format, on page 590 would look like this: ================= Gated clock report ================= The following instances have been converted Seq Inst Clock ------------------dout_1[2] clk_c dout_1[1] clk_c =================== The following instances have NOT been converted Seq Inst Clock Reason for not converting ------------------------------------------------------dout_1[3] G_8 Gating structure not compatible =======================================================
Working with Gated Clock Error Messages

The following table describes the gated clock conversion error messages that are reported in the Gated Clock Report section of the log file. The following terms are used in the descriptions:
user clock the clock defined in the SDC file by the user clock driver the driver to the clock pin of the sequential element
Error Message Added MUX in data path Explanation
The software added a MUX to the gated clock path because the sequential element did not have an equivalent gate with enable. The software encountered a primitive in the gating logic that cannot be handled by gated clock conversion. The software cannot find a syn_gatedclk_data_in and/or LO syn_gatedclk_data_out property on the sequential instance.
Cannot convert primitive instance of the type Cannot find gated clock property
Error Message Enable pin not found Found combination loop involving the gating logic Found unsupported combinational gate in gating logic Gated clock does not have declared clock, add/enable clock constraint in SDC file Gated clock either has NO DRIVER or has MULTIPLE DRIVERS
Explanation
There is no enable pin on an equivalent sequential element with enable. There is a combinational loop in the gating logic, which prevented gated clock conversion. There is an instance in the gating logic that could not be handled currently by gated clock conversion. The user-defined clock signal is not defined in the SDC file, and this causes the gated clock conversion to fail. The gated clock conversion code cannot determine which clock to use because of one of the following: There is no user clock driving the sequential element through the gating logic. There are multiple user-defined clocks driving the gating logic. The gating logic that corresponds to the sequential element could not be reduced to a form where it satisfies the following three rules needed for gated clock conversion: For certain combinations of the gating signals, the gated clock signal must be capable of being disabled For the remaining combinations of the gating signals, the gated clock signal equals either the clock signal or its inverted value Finally, all gated clock signal transitions can only result from the clock signal transitions, and no enable signal transition can result in a gated clock signal transition The sequential gate does not have a clock pin. The library cell has been marked as non sequential, with the property syn_force_seq_prim set to zero. There are multiple user-defined clocks in the gating logic. There is no gating logic (this message is no longer displayed in the gated clock report).
Gating structure creates Improper gating logic
Instance has no clock pin Library cell is not marked as sequential Multiple declared clocks found No gating logic found
Error Message Not in chip Property dontfixgatedclock found The width of the input not equal to the width of the output
Explanation
The clock driver is in another FPGA, not in the FPGA in which the sequential element is present. There is a syn_dontfixgatedclock on a sequential instance, which prevented gated clock conversion. There is an input/output data width mismatch on the sequential element. This prevents the software from using a MUX-based feedback loop to enable gated clock conversion. The sequential element does not have an equivalent gate with enable. The software is unable to determine the reason why gated clock conversion is failing. Contact Synplicity Support. There is a user-asserted syn_keep on one of the gates in the gating logic or one of the nets found in the gating logic. This prevented gated clock conversion.
Unknown reason
User asserted syn_keep found on gated clock logic
Restrictions on Using Gated Clocks

Currently, the Fix Gated Clocks option has the following restrictions:
If the syn_keep attribute is assigned to a net, the Fix Gated Clocks option
does not preserve this net during optimization. Refer to the third example in The Synplicity Approach to Gated Clocks, on page 587.
The Fix Gated Clocks option cannot be implemented for inferred counters
in Altera technologies.
Gated clock conversion is not performed across compile-point boundaries.
The Fix Gated Clocks option cannot be implemented by the Synplify

Premier tool if the gates associated with the gated clock are assigned to different Synplify Premier design plan regions. See the following figure. The Fix Gated Clocks option can be applied if all gates associated with the gated clock are assigned to the same Synplify Premier design plan region. Also, the flip-flops can be assigned to any Synplify Premier LO region.
Rgn1
Rgn2
d en1 clk en2 Gated Clock
Cannot Implement Fixed Gated Clock
Optimizing Generated Clocks

The Certify tool includes an option for generated clocks which, when enabled, replaces the generated-clock logic 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.
Generated-Clock Optimization Example

The following code segment is used to illustrate generated-clock optimization: module gen_clk(clk1,a,b,c,q); input clk1, a, b, c; output q; reg ao,bo,q; wire en; always @(posedge clk1) begin ao <= a; bo <= b; end assign en = ao & bo; always @(posedge en) begin q <= c; end endmodule With generated-clock optimization disabled (Fix generated clocks set to 0), 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).
LO
c a clk1 b b0 Before Generated Clock Optimization a0 Logic clk2 q
When generated-clock optimization is enabled (Fix generated clocks set to 1, 2, or 3), 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.
c q b a
b0 Logic enable
clk1 After Generated Clock Optimization
Enabling Generated-Clock Optimization

Generated-clock optimization is enabled by entering a non-zero value in the Fix generated clocks field in the Device tab of the Implementation Options dialog box. The following table describes the options. Fix generated clock value 0 1 2 3 Description
Disable generated-clock optimization. Perform optimization with no messages. Perform optimization and report unoptimized sequential elements. The default. Perform optimization and report the status of all sequential elements.
When a value of 2 or 3 is entered, the log file includes a generated clock optimization report.
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, such as ao and bo in the previous figure, cannot have an active set or reset. For example, if ao has an active-low reset, then the reset must be disabled (tied high) for generated-clock optimization. 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. 4. With generated-clock optimization, you do not have to specify a primary clock. LO
Edge-Detection Logic
Edge-detection logic is used with generated-clock conversion to identify the active edge of the generated clock. A TCL command (insert_gcc), which is read by nfilter, inserts an instance of an edge-detection cell into the logic for each specified generated clock.
Command Usage
The insert_gcc command, which inserts the edge-detection cell, has the following syntax: insert_gcc -master_clk masterClockName -gen_clk genClockName -direction rising|falling [-div_ratio integer] [-delayed_clk delayClockName] The command arguments define the master clock, generated clock, and the active generated clock edge for each edge-detection cell. These commands are written to a tcl file which is then added to the project. Nfilter reads these commands and inserts edge-detection cell instances into the netlist. The mapper, based on the active clock edge, connects either the ena_rise or ena_fall output pin to the enable pin of the sequential logic and connects master_clock to the clock pins. The edge-detection cell IP (syn_edge_detect.v) is included in the /lib/synip directory. A define_generated_clock_en attribute has been defined to support edge-detection logic. The attribute is attached to the edge-detection module to identify the view, clock signals, and clock edges. The attribute syntax is: define_generated_clock_en {v:edge_det} {dummy_gen_clk} {mas_clk} {ena_rise} {ena_fall}
LO
CHAPTER 18
Specifying Constraints
This chapter describes how to specify constraints for your design. It covers the following:
Using the SCOPE UI, on page 606 Specifying Timing Constraints, on page 612 Specifying Timing Exceptions, on page 622 Setting Clock Priority in Xilinx Designs, on page 628 Setting Clock Priority in Xilinx Designs, on page 628 Using Auto Constraints, on page 645 Translating Altera QSF Constraints, on page 647 Converting and Using Xilinx UCF Constraints, on page 649
For additonal information about working with constraints, see Working with Constraint Files, on page 54.
Using the SCOPE UI
Using the SCOPE UI

You can use a text editor to create a constraint file as described in Working with Constraint Files, on page 54, but it is easier to use the SCOPE (Synthesis Constraint Optimization Environment) window, which provides a spreadsheet-like interface for entering constraints. The SCOPE interface 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. If you want to use a text editor to edit a constraint file, close the SCOPE window before editing the file, or you will overwrite results. You can also use the SCOPE window to add attributes, define collections and specify constraints for them. For details, see Adding Attributes in the SCOPE Window, on page 113 and Creating and Using Collections (SCOPE Window), on page 632.
Creating a Constraint File Using the SCOPE Window

The following procedure shows you how to open the SCOPE window to generate constraint files. 1. To create a new constraint file, follow these steps:
Compile the design (F7). If you do not compile the design, you can still
use the SCOPE window, but the software does not automatically initialize the clocks and I/O ports. You have to type in entries manually because the software has no knowledge of the design.
Open the SCOPE window by clicking the SCOPE icon in the toolbar
( ), pressing Ctrl-n, or selecting File->New. If you use one of the latter two methods, select Constraint File (SCOPE) as the type of file to open. This opens the Initialize New Constraint File dialog box.
LO
Using the SCOPE UI
File->New
Ctrl-n
Optionally, select the constraints to be initialized and click OK. If you

started with a compiled design, setting these options automatically initializes the Clock and Inputs/Outputs tabs with the appropriate signals. 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. 2. To open an existing file, do one of the following:
Double-click the file from the project window. Press Ctrl-o or select File->Open. In the dialog box, set the kind of file
you want to open to Constraint Files (SCOPE) (*.sdc), and double-click to select the file from the list.
Using the SCOPE UI
The SCOPE window opens with the file you specified. For details about editing the file, see Entering and Editing Constraints in the SCOPE Window, on page 608. If you want to edit the Tcl file directly, see Using a Text Editor for Constraint Files, on page 56.
Entering and Editing Constraints in the SCOPE Window

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 Certify tool also lets you add constraints automatically. For information about auto constraints, see Using Auto Constraints, on page 645. 1. Click the appropriate tab at the bottom of the window to enter the kind of constraint you want to create: To define...
Clock frequency for a clock signal output of clock divider logic A specific clock frequency that overrides the global frequency Edge-to-edge clock delay that overrides the automatically calculated delay. Constraints for a group of objects you have defined as a collection with the Tcl command. For details, see Creating and Using Collections (SCOPE Window), on page 632. Input/output delays that model your FPGA input/output interface with the outside environment Delay constraints for paths feeding into/out of registers Paths that require multiple clock cycles Paths to ignore for timing analysis (false paths) Maximum delay for paths
Click... Clocks Clock to Clock Collections
Inputs/ Outputs Registers Delay Paths Delay Paths Delay Paths
LO
Using the SCOPE UI
To define...
Attributes, like syn_reference_clock, that were not entered in the source files I/O standards for certain technologies of the Altera and Xilinx devices for any port in the I/O Standard panel of the SCOPE window. 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
Click... Attributes I/O Standard
Other
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. 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. 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: Prefix Identifiers v:design_name c:clock_name i:instance_name p:port_name t:pin_name b:name n:net_name
Description for...
hierarchies or views (modules) clocks instances (blocks) ports (off-chip) hierarchical ports, and pins of instantiated cells bits of a bus (port) internal nets
Using the SCOPE UI
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, Frequency or 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 Timing Constraints, on page 612. 3. For common editing operations, refer to this table: To...
Cut, copy, paste, undo, or redo Copy the same value down a column Insert or delete rows Find text
Do...
Select the command from the popup (hold down the right mouse button to get the popup) or from the Edit menu. Select Fill Down (Ctrl-d) from the Edit or popup menus. Select Insert Row or Delete Rows from the Edit or popup menus. Select Find from the Edit or popup menus. Type the text you want to find, and click OK.
4. 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 54 for information about the commands in this file. 5. 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 68. LO
Using the SCOPE UI
Setting SCOPE Display Preferences

You can set format and colors in the SCOPE window. The following table lists some preferences and shows you how to set them. To...
Set the appearance of lines and buttons in the SCOPE table
Do this...
With a SCOPE window open, select View->Properties. Set the options you want on the Display Settings form. Check the Save settings to profile option if you want to settings to be the default. Select a SCOPE row. Select Format->Style. On the Styles form, check Save as Default if you want the new settings to be the default. Select the category you want to change (Row Header or Standard), and click Change. Set the display options you want and click OK on both forms. Select a SCOPE row. Select Format->Style. On the Styles form, check Save as Default if you want the new settings to be the default. Select the category you want to change (Column Header or Standard), and click Change. Set the display options you want and click OK on both forms. Select a SCOPE cell. Select Format->Cells. Set the display options you want and click OK. Select a column or row in the SCOPE window. Select Format->Align. Click the alignment you want and click OK. Select a column or row in the SCOPE window. Select Format->Resize Rows or Format->Resize Columns. Select a SCOPE cell. Select Format->Cover Cells to hide a cell. Select Format->Remove Covering to show a hidden cell.
Set fonts, colors, and borders for a row
Set fonts, colors, and borders for a column
Set fonts, colors, and borders for a single cell Align text in columns and rows
Size columns/rows to text Hide/show cells
Specifying Timing Constraints

You can define timing constraints in the SCOPE interface, which automatically generates a Tcl constraints file, or manually with a text editor, as described in Using a Text Editor for Constraint Files, on page 56. The SCOPE interface is much easier to use, and you can define various timing constraints in it. For the equivalent Tcl syntax, see the Certify Command Reference. See the following for different timing constraints:
Entering Default Constraints, on page 612 Setting Clock and Path Constraints, on page 612 Defining Clocks, on page 614 Defining Input and Output Constraints, on page 619 Specifying Standard I/O Pad Types, on page 620 Specifying Xilinx Timing Constraints, on page 621
To set constraints for timing exceptions like false paths and multicycle paths, see Specifying Timing Exceptions, on page 622.
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 612). For auto constraints, see Using Auto Constraints, on page 645. To apply the constraints, add the file to the project according to the procedure described in Making Changes to a Project, on page 68. The constraints file has an sdc extension. See Working with Constraint Files, on page 54 for more information about constraint files.
Setting Clock and Path Constraints

The following table summarizes how to set different clock and path constraints from the SCOPELO window. For information about setting compile attributes, see Adding Attributes in the SCOPE Window, on page 113. For information about setting default constraints, see Entering Default Constraints, on page 612.
To define...
Clocks
Pane Clock
Do this to set the constraint...

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 Check the Enabled box. See Defining Clocks, on page 614 for information about clock attributes. Set the clock constraints as described for clocks, above. Check the Virtual Clock box. Specify the route delay in nanoseconds. Refer to Defining Clocks, on page 614, Defining Input and Output Constraints, on page 619 and the Register Delays section of this table details. 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. See Defining Input and Output Constraints, on page 619 for information about setting I/O constraints. Select the register (Register). Select the type of delay, input or output (Type). Type a delay value (Value). Check the Enabled box. 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. Resynthesize your design.
Virtual clocks Route delay
Clock Clock Inputs/ Outputs Registers Clock to Clock
Edge-to-edge clock delay
Input/output Inputs/ delays Outputs Register delays
Registers
To define...
Maximum path delay
Pane Delay Path
Do this to set the constraint...

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 623 for more information. Select another port or register if needed (To/Through). Set the delay value (Max Delay). Check the Enabled box. See Defining Multi-cycle Paths, on page 626. See Defining False Paths, on page 626 for details.
Multi-cycle paths False paths
Delay Paths Delay Paths Clock to Clock Attributes
Global attributes
Set Object Type to <global>. Select the object (Object). Set the attribute (Attribute) and its value (Value). Check the Enabled box. Do either of the following: Select the type of object (Object Type). Select the object (Object). Set the attribute (Attribute) and its value (Value). Check the Enabled box. Set the attribute (Attribute) and its value (Value). Select the object (Object). Check the Enabled box. Type the TCL command for the constraint (Command). Enter the arguments for the command (Arguments). Check the Enabled box.
Attributes
Attributes
Other
Other
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 645), do not define any clocks. The following procedures show you how to define clock frequency (Defining Clock Frequency, on LO page 615) and set other clock constraints that affect timing, like clock groups (Defining Other Clock Requirements, on page 618).
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 618 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 specified. Each clock that uses the global frequency is assigned to its own clock group. See Defining Other Clock Requirements, on page 618 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:
A
clkA clkB
If clkA is... And clkB is...
Logic
The effect for logic C is... clkB be constrained to the inferred clock domain for clkA clkA be constrained to the inferred clock domain for clkB.
Undefined
Defined
The path is unconstrained unless you specify that
Defined
Undefined
The path is unconstrained unless you specify that
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. The path is unconstrained.
Undefined
Undefined
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. Source
Register Instance, like a PLL or clock DLL
Add SCOPE constraint/define_clock to...

Register. 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. Net. Make sure to use the n: prefix in the SCOPE interface.
Combinatorial logic
4. For signals other than clocks, define frequencies with the syn_reference_clock attribute. You can add this attribute on the SCOPE Attributes tab. You might need to do this if your design uses an enable signal as a clocking signal because of limited clocking resources. If the enable is slower than the clock, defining the enable frequency separately instead slowing down the clock frequency ensures more accuracy. If you slow down the clock frequency, it affects all other registers driven by the LO clock, and can result in longer run times as the tool tries to optimize a non-critical path.
Define this attribute 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 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 DCMs Phase shift and frequency multiplication properties like duty_cycle_correction and clkdv_divide DCM properties like clkfx_multiply and clkfx_divide
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.
Resynthesize your design.
Defining Other Clock Requirements

Besides clock frequency (described in Defining Clock Frequency, on page 615), 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, on page 619 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 keepbuf generated for the gated
clock. LO 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

In addition to setting I/O delays in the SCOPE window as described in Setting Clock and Path Constraints, on page 612, 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 placeand-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.
Resynthesize your design.
Specifying Standard I/O Pad Types

For certain Altera and Xilinx technologies, 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 for different vendors, refer to the relevant section in the Reference Manual: Altera I/O Standards, on page 357 and Xilinx I/O Standards, on page 364.
LO
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.
Specifying Xilinx Timing Constraints

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:
UCF ucf2sdc Synthesis SDC Constraints User constraints
Timing
Physical
synplicity.ucf
design.ncf
1. To specify user constraints, use the SCOPE interface. See Entering and Editing Constraints in the SCOPE Window, on page 608 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 649.
Specifying Timing Exceptions
3. Synthesize the design. The synthesis tool writes out the timing constraints and physical constraints into separate files: synplicity.ucf design.ncf
Contains all timing constraints, whether user-specified or translated from a ucf file Contains all physical constraints
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.

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 optimization.
Max Delay Paths Point-to-point delay constraints for paths.

The following show you how to specify timing exceptions in the SCOPE GUI. For the equivalent Tcl syntax, see the Certify Command Reference.
Defining From/To/Through Points for Timing Exceptions, on page 623 Defining Multi-cycle Paths, on page 626 Defining False Paths, on page 626
For information about resolving timing exception conflicts, see Conflict Resolution for Timing Exceptions, on page 387 in the Reference Manual. LO
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 387 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 (c:), register (i:), top-level input or bi-directional port (p:), or black box output (i:). 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 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:
define_multicycle_path -from {i:aq i:bq} 2 define_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 (c:), register (i:), top-level output or bi-directional port (p:), or black box input (i:). 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 net (n:), hierarchical port (t:), or instantiated cell pin (t:). 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.
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. LO 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.
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.
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 Multi-cycle Paths

To define a multi-cycle path constraint, use the Tcl define_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 623 for more information. 3. Select another port or register if needed (From/To/Through). 4. Type the number of clock cycles (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.
Defining False Paths

You define false paths by setting constraints explicitly on the Delay Paths tab or implicitly on the Clock or Clock to Clock tabs. You can also define false paths with the corresponding define_false_path, define_clock, and define_clock_delay Tcl commands. See Defining From/To/Through Points for Timing Exceptions, on page 623 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: LO
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).
Check the Enabled box.

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 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. Mark the Enabled check box.
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. Mark the Enabled check box.
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: Select Project->Implementation Options->Constraints Disable Use clock period for unconstrained IO
Setting Clock Priority in Xilinx Designs

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} For details about the attribute and how it is forward-annotated, refer to syn_clock_priority Attribute, on page 768 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 628 Specifying Clock Priority for BUFG and BUFGMUX Elements, on
page 630
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 Forward-annotation of Clock Priority to UCF, on page 769 of the Reference Manual for details. 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. LO
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}
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 propagated 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} -clockgroup clk0_derived_clock define_clock {i:CLK_BUF0} -name {i:CLK_BUF0} clockgroup clk0fx_derived_clock -freq 100
-freq 30 -
define_attribute {i:CLK_BUF0} {syn_clock_priority} {1} define_attribute {i:CLK_BUF0FB} {syn_clock_priority} {1} Note that you cannot set this attribute on any other instances except BUFGs.
LO
Using Collections
Using Collections
A collection is a group of objects. It can consist of just one object, or of other collections. You can set the same constraint for multiple objects if you group them together in a collection. You can either define collections in the SCOPE window or type the commands in the Tcl script window.
Comparing Methods for Defining Collections, on page 631 Creating and Using Collections (SCOPE Window), on page 632 Creating Collections (Tcl Commands), on page 635 Using the Tcl Find Command to Define Collections, on page 638 Using the Expand Tcl Command to Define Collections, on page 640 Viewing and Manipulating Collections (Tcl Commands), on page 641
Comparing Methods for Defining Collections

The find and expand Tcl commands that are used to define collections can either be entered in the Tcl script window or in the SCOPE window. It is recommended that you use the SCOPE interface for two reasons:
When you use the SCOPE interface, the software uses the top-level
database to find objects, which is a good practice. The Tcl window commands are based on the current Analyst view. If you use the Tcl script window to type in a command after mapping, the search is based on the mapped database, which could have instances that have been renamed, replicated, or removed.
Top a1 a2 a4 a3 B
Using Collections
Similarly, the current Analyst view could be a lower-level view. In the design shown above, 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.
If you use the Tcl script window, you have to redefine the collection the
next time you open the project. When you define a collection in the SCOPE window, the software saves the information in the constraint file for the project.
You cannot apply constraints to collections defined in the Tcl script

window, but you can apply constraints and attributes to SCOPE collections.
Creating and Using Collections (SCOPE Window)

The following procedure shows you how to define collections in the SCOPE window. You can also type the commands directly in the Tcl script window (Creating Collections (Tcl Commands), on page 635). See Comparing Methods for Defining Collections, on page 631 for a comparison of the two methods. 1. Define a collection by doing the following:
Open the SCOPE window and click the Collections tab. In the Collection Name column, type a name for the collection. This is
equivalent to defining the collection with the set command, as described in Creating Collections (Tcl Commands), on page 635.
LO In the Commands column, select find or expand. For tips on using these commands, see Using the Tcl Find Command to Define Collections, on page 638 and Using the Expand Tcl Command to Define
Using Collections
Collections, on page 640. For complete syntax details, see the Reference Manual. 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. See Comparing Methods for Defining Collections, on page 631.
In the Command Arguments column, type only the arguments to the

command you set in the Commands column, so that you locate the objects you want. Do not repeat the command itself. For details of the syntax, see the Reference Manual. Objects in a collection do not have to be of the same type. The collections defined above do the following: Collection find_all find_reg find_comb Finds...
All components in the module endpMux All registers in the module endpMux All combinatorial components under endpMux
The collections you define appear in the SCOPE pull-down object lists, so you can use them to define constraints.
To crossprobe the objects selected by the find and expand commands,

click Select in the Select in Analyst column. The schematic views highlight the objects located by these commands. For other viewing operations, see Viewing and Manipulating Collections (Tcl Commands), on page 641. 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 Collection Name column. Set Commands to one of the operator commands like c_union or c_diff. Type the appropriate arguments in Command Arguments. See Creating Collections (Tcl Commands), on page 635 for a list of available commands and the Reference Manual for the complete syntax.
Using Collections
Click Run Commands. The software runs through the commands in

sequence, so you must first define collections before doing any group or comparative operations. The software saves the 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.
Specify the rest of the constraint as usual. The software applies the
constraint to all the objects in the collection. See examples of constraints in Example: Attribute Attached to a Collection, on page 634.
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 and the netlist.
LO
Using Collections
Creating Collections (Tcl Commands)

This section describes how to type in and use the Tcl collection commands instead of the SCOPE window (Creating and Using Collections (SCOPE Window), on page 632). Although you can type these commands in the Tcl window or put them in a Tcl script, it is recommended that you use the SCOPE window, for the reasons described in Comparing Methods for Defining Collections, on page 631. For details of the syntax for the commands described here, refer to the Certify Command Reference. 1. To create a collection, name it with the set command and assign it to a variable. A collection can consist of individual objects, Tcl lists (which can have single elements as arguments), or other collections. Use the Tcl find and expand commands to locate objects for the collection (see Using the Tcl Find Command to Define Collections, on page 638 and Using the Expand Tcl Command to Define Collections, on page 640). The following example creates a collection called my_collection which consists of all the modules (views) found by the 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.
Using Collections
Create the collection with one of the operator commands from this
table: To...
Add objects to a collection Concatenate collections Create a collection from the differences between collections Create a collection from common objects in collections Find objects that belong to just one collection
Use this command...

c_union. See Examples: c_union
Command, on page 636
c_union. See Examples: c_union
Command, on page 636.
c_diff. See Examples: c_diff Command, on page 637. c_intersect. See Examples: c_intersect Command, on page 637. c_symdiff. See Examples: c_symdiff
Command, on page 637.
3. If your Tcl collection includes instances that have special characters make sure to use extra curly braces or use a backslash to escape the special character. See Examples: Names with Special Characters, on page 638 for details. Once you have created a collection, you can do various operations on the objects in the collection (see Viewing and Manipulating Collections (Tcl Commands), on page 641), 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. LO
Using Collections
This example concatenates collection1and collection2 and names the new collection 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

This example compares a list to a collection (collection1) and creates a new collection called interCollection from the objects that are common: set collection1 {i:reg1 i:reg2} set interCollection [c_intersect $collection1 {i:reg1 i:reg3}] c_print $interCollection "i:reg1" You can also use the command to compare two collections: set common_collection [c_intersect $collection1 $collection2]
Examples: c_symdiff Command

This example compares a list to a collection (collection1) and creates a new 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 collection1 {i:reg1 i:reg2} set diffCollection [c_symdiff $collection1 {i:reg1 i:reg3}] c_list $diffCollection {"i:reg2" "i:reg3"} You can also use the command to compare two collections: set symdiff_collection [c_symdiff $collection1 $collection2]
Using Collections
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\[*\]}
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 Comparing Methods for Defining Collections, on page 631. 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 (Using the Expand Tcl Command to Define Collections, on page 640). This section lists some tips for using the Tcl find command. 1. Tcl find always searches at the top-level of your design, irregardless of the current Analyst view. 2. Create a collection by typing the find 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 == FDE] The result is a random number like s:49078472, which is the collection of objects found. For a list of some useful find commands, see Examples: Useful Find Commands, on page 640. 3. The following table lists some usage tips for specifying the find command. For the full details of the syntax, refer to the Certify Command Reference. LO
Using Collections
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. This example finds any object in the current view that starts with either a or A:
find {a*} -nocase

Pattern matching You have two 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. Use the -object_type argument. The following command finds all nets that contain syn.
Restricting search by type of object Restricting search to hierarchical levels below the current view Restricting search by object property
find -net {*syn*}

Use the -hier argument. The following example finds all objects below the current view that begin with a:
find {a*} -hier

Select Project->Implementation Options. On the Device tab, enable Annotated Properties for Analyst. Compile your design. After the compile stage, the tool annotates the design with properties like clock pins. You can find objects based on these annotated properties. Use the -filter argument to the find command. The following example finds any register in the current view that is clocked by myclk.
find -seq {*} -filter {@clock==myclk} find -seq {*} -clock myclk 4. 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 (Tcl Commands), on page 641:
Select the collection in an HDL Analyst view (select).

Using Collections
Print the collection using the -print option to the find command. Print the collection without carriage returns or properties (c_list). Print collection in columns, with optional properties (c_print).
5. To manipulate the objects in the collection, use the commands described in Viewing and Manipulating Collections (Tcl Commands), on page 641.
Examples: Useful Find Commands

To find...
Instances by slack value Instance within a slack range
Use a command like this example...

set result [find hier inst {*} filter @slack <= {-1.000}] set result [find hier inst {*} filter @slack <= {-1.000} && @slack >= {+1.000}]
Pins by fanin/fanout value set result [find hier inst {*.D} filter @fanin <= {50}] Sequential components by primitive type
set result [find hier seq {*} filter @view=={ FDRSE}
Using the Expand Tcl Command to Define Collections

The Tcl expand command returns a collection 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 the Certify Command Reference.
Specify at least one from, to, or through 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 through 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} LO
Using Collections
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 through 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 clockenable net across one level of hierarchy: expand -thru {n:cen} -level 1
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}
To print a list of the objects found, either use the -print argument to the
find command, or use the c_print or c_list commands (see Creating Collections (Tcl Commands), on page 635).
Viewing and Manipulating Collections (Tcl Commands)

The following section describes various operations you can do on the collections you defined. For full details of the syntax, see Tcl Collection Commands in the Certify Command Reference. 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). 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 collection.
Using Collections
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 644. 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]} {i:EP0RxFifo.u_fifo.dataOut[1]} {i:EP0RxFifo.u_fifo.dataOut[2]} {i:EP0RxFifo.u_fifo.dataOut[3]} {i:EP0RxFifo.u_fifo.dataOut[4]} {i:EP0RxFifo.u_fifo.dataOut[5]} 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. Object Name {i:EP0RxFifo.u_fifo.dataOut[0]} {i:EP0RxFifo.u_fifo.dataOut[1]} {i:EP0RxFifo.u_fifo.dataOut[2]} {i:EP0RxFifo.u_fifo.dataOut[3]} {i:EP0RxFifo.u_fifo.dataOut[4]} {i:EP0RxFifo.u_fifo.dataOut[5]} LO {i:EP0RxFifo.u_fifo.dataOut[6]} {i:EP0RxFifo.u_fifo.dataOut[7]} {i:EP0TxFifo.u_fifo.dataOut[0]} {i:EP0TxFifo.u_fifo.dataOut[1]}
slack 0.3223 0.3223 0.3223 0.3223 0.3223 0.3223 0.3223 0.3223 0.1114 0.1114
view "FDE" "FDE" "FDE" "FDE" "FDE" "FDE" "FDE" "FDE" "FDE" "FDE"
clock clk clk clk clk clk clk clk clk clk clk
Using Collections
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 Tcl Collection Commands in the Certify Command Reference. To...
Copy a collection
Do this...
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.
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. Use the foreach command. This example iterates through all the objects in the collection:
Iterate through a collection
foreach port [find -port *] { define_false_path -from $port }
Using Collections
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]
LO
Using Auto Constraints

Auto constraining is available for certain technologies. You can 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 Auto Constraints, on page 326 in the Reference Manual. 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 define_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.
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 flopto-flop paths. Even when the software auto constrains the I/O paths, it does not generate these constraints for forward-annotation. 4. Synthesize the design. 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 forwardannotates these constraints to the place-and-route tools. 5. Check the results in AutoConstraint_designName.sdc and the log file. To open the sdc file as a text file, right-click the file in the Implementation Results view and select Open as Text. LO The flop-to-flop constraints use syntax like the following: define_clock -name {b:leon|clk} -period 13.327 -clockgroup Autoconstr_clkgroup_0 -rise 0.000 -fall 6.664 -route 0.000
Translating Altera QSF Constraints
6. You can now add the generated sdc file to the project and rerun synthesis with these constraints.

If you have an Altera Quartus Settings File (QSF) with timing or pad constraints, you can use the qsf2sdc translator to translate these constraints to the sdc format and use the translated constraints to drive synthesis. 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: install_dir/bin/qsf2sdc -iqsf constraints_file.qsf -osdc constraints_file.sdc [-oqsf residual_constraints_file.qsf] [-all] [-silent] The translator generates a constraint file in the sdc format, which contains the timing-related constraints from the QSF file that are relevant to synthesis. It ignores the other backend constraints in the file. See Altera qsf2sdc Utility, on page 421 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. The translator converts the most common timing and physical constraints. However, because of the diversity and complexity of QSF format, the resulting sdc file requires manual intervention.
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.
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 one sdc file.
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 Physical Constraints: SYN_LOC on IO pins and pad types Physical constraints applied to invariant objects (such as registers, instantiated macros and modules) can be safely translated to SDC constraints. Use the Design Planner tool for advanced physical constraints.
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. This command generates a report that checks the syntax and applicability of the timing constraints in the sdc file(s) for your project. The LO report is written to the projectName_cck.rpt file. 6. Add the generated sdc file to the project, and use it to drive synthesis.
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. The following procedures show you how convert the UCF constraints in logic and physical synthesis designs and then forward-annotate them for place-androute. Although this utility is also documented here, it is recommended that you do not use this method, as it will not be available in future releases of the software.
Using Xilinx UCF Constraints in a Logic Synthesis Design, on page 650 Support for UCF Conversion, on page 653 Using the Legacy UCF2SDC Utility, on page 657.
The process for the command-line ucf2sdc_old utility (see Xilinx ucf2sdc Utility, on page 408 in the Reference Manual) is a little different from the other method described, as it does not use mapper information, run the constraint checker, or create a new project. The utility is still available, but will not be supported in future releases.
Using Xilinx UCF Constraints in a Logic Synthesis Design

You can run logic synthesis in the Certify 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:

UCF NCF XCF
Top-level constraint file, with corresponding EDIF file (edf) Block-level constraint file, with corresponding EDIF file (edn, edf, ngc or ngo) Block-level constraint file, with corresponding EDIF file (ngc or ngo)
These files must refer to design objects n 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 toplevel, and others for blocks. See Supported Input Files for UCF Conversion, on page 653 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.
LO
3. Select Project->Convert Vendor Constraints to open the UCF to SDC Conversion dialog box.
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 Generated Files after UCF Conversion, on page 654 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 653 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 physical 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. LO
Support for UCF Conversion

For procedures on converting UCF constraints, see the methods listed Converting and Using Xilinx UCF Constraints, on page 649. The following describe what the software supports when translating UCF constraints to SDC.
Supported Input Files for UCF Conversion, on page 653 Generated Files after UCF Conversion, on page 654 Supported UCF Constraints, on page 655 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. 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. 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.
NCF
XCF
Generated Files after UCF Conversion

The tool creates these files after UCF conversion: ucf2sdc.log prjFile_conv.prj ucfFile_conv.sdc
Log file that contains messages after ucf conversion completes. The default name for the new project that was generated. 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. 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. 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.
synplicity.ucf
unsupported.ucf
Top.srd Top.ucf Top.srs IP1.ngc IP1.xcf Top.srs IP2.edn IP2.ncf Top.prj
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 For further synthesis
LO
The next figure shows how the project-level input files are handled in a posttranslation synthesis run:
Top.v Top.sdc Top_conv.sdc Top_unsupported.ucf 1P1.ngc IP1_conv.sdc IP1_unsupported.ucf 1P2.edn IP2._conv.sdc IP2_unsupported.ucf Top.prj For P&R Logical and Physical Synthesis Top.edf synplicity.ucf
Supported UCF Constraints

The UCF converter supports the following types of constraints: FF PERIOD FROM/TO TIG OFFSET TNM TNM_NET TIMEGRP LOC IO PROPS General PROPs
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
RAM ROM
DSP
Net
Yes Yes Yes Yes Yes
Inst
View
Collection
Yes
Port
Yes Yes Yes Yes Yes
Pin
Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes
Yes Yes Yes Yes
Yes
Yes
Yes
Yes
Yes Yes Yes
Yes Yes Yes Yes
Yes Yes Yes
Yes Yes Yes
Yes
Yes
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 BRAMS_PORT[A/B] INPUT_JITTER, PRIORITY, DATAPATHONLY RISING, FALLING CLOSED, OPEN HIGH, LOW, VALID Description
Predefined keyword
TIMESPEC constraint TIMEGRP constraint AREA_GROUP constraint OFFSET constraint
LO
Using the Legacy UCF2SDC Utility

If you have a Xilinx User Constraint File (UCF) with timing or pad constraints, you can also use the ucf2sdc_old command to translate these constraints to the sdc format and use the translated constraints to drive synthesis. However, it is recommended that you use the methodology described in Using Xilinx UCF Constraints in a Logic Synthesis Design, on page 650, as the ucf2sdc_old command will be phased out in future releases. 1. Run this utility.
Make sure the input UCF file has a ucf extension. From the command line, run the translator on the UCF file. The
translator is in the bin directory: install_dir/bin/ucf2sdc_old.exe. Use the following syntax: install_dir/bin/ucf2sdc_old -iucf constraints_file.ucf -osdc constraints_file.sdc The translator generates a file in the sdc format, with the translated timing-related constraints from the UCF file. It ignores the other backend constraints in the UCF file. See Xilinx ucf2sdc Utility, on page 408 in the Reference Manual for details. The following table shows which UCF constraints are translated: Supported on INST, NET, PIN, SET
AREA_GROUP BLKNM BUFG DRIVE FAST HBLKNM HU_SET IOB IOBDELAY IOSTANDARD KEEP_HIERARCHY LOC MAP OPT_EFFORT OPTIMIZE PERIOD PHASE_SHIFT REG RLOC RLOC_ORIGIN SLEW SLOW STARTUP_WAIT TIMEGRP TIMESPEC TNM TNM_NET TPSYNC TPTHRU U_SET USE_RLOC XBLKNM
Supported on NET
COLLAPSE MAXDELAY MAXSKEW OPEN_DRAIN PULLDOWN PULLUP USELOWSKEWLINES WIREAND
2. After translating the constraints, edit the new sdc file. The translator converts the most common timing and physical constraints. However, you still need to check it manually.
Visually inspect the translated file. The original UCF commands are
written as comments in the new sdc file so that you can validate the translated constraints.
Manually edit the SDC file to complete the translation of constraints,

as necessary. 3. To run physical synthesis, create one sdc file.
Include the timing constraints created previously for logic synthesis

into the sdc file containing the translated physical constraints. Make sure that the following constraints are combined into one 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 Physical Constraints: Register packing into IOB LOC on IO pads Macro LOC/RLOC constraints (BUFG, DCM, DSP, MULT, etc.) Instance LOC/RLOCs (Register, LUT, SRL, RAMS, RAMD, etc.) AREA_GROUP constraints Physical constraints on invariant objects like registers, instantiated macros and modules, can be safely translated to SDC constraints. Use the Design Planner tool for advanced physical constraints.
Also, include any synthesis attributes, from logic synthesis, such as

syn_ramstyle, in the sdc file.
LO
4. Make sure all UCF constraints are forward-annotated to theP&R tool.
Edit the original input ucf file and delete all constraints that were
successfully translated to sdc.
If any untranslated UCF commands remain in the original file (such

as the PROHIBIT constraint), add the edited ucf file to the project. This file now only contains the untranslated commands. These UCF constraints are not used for synthesis, but after synthesis, the tool copies the untranslated UCF commands to the synplicity.ucf file and appends the other sdc timing constraints to the same file. After synthesis, all timing constraints are in the synplicity.ucf file. 5. Save the project file. 6. Use the sdc file to drive synthesis. The tool generates two output constraint files after synthesis: synplicity.ucf
Contains all timing constraints, whether user-specified sdc constraints, ucf constraints translated to sdc, or unsupported ucf constraints that are passed without translation Physical constraints that are not used for synthesis are included in this file, along with other unsupported constraints. Contains all physical constraints for forward-annotation.
design.ncf
See Specifying Xilinx Timing Constraints, on page 621 for an illustration. 7. Make sure to use the updated synplicity.ucf file and the design.ncf file to drive the Xilinx place-and-route tool. If necessary, update any scripts or par_opt files generated with older versions of the synthesis tools.
LO
CHAPTER 19
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 14, Instantiating and Inferring High-Level Objects. This chapter describes the following:
Optimizing Altera Designs, on page 662 Optimizing Xilinx Designs, on page 671
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 562. This section discusses the following topics that are specific to Altera technologies:
Working with Altera PLLs, on page 663 Packing I/O Cell Registers, on page 664 Specifying Core Voltage in Stratix III Designs, on page 666 Specifying Core Voltage in Stratix III Designs, on page 666 Using LPMs in Simulation Flows, on page 667 Working with Quartus II, on page 669
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 382 Inferring RAMs, on page 398 Inferring Shift Registers, on page 431 Working with LPMs, on page 436
LO
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. 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 Synplicity software in the corresponding lib/altera/quartus_IInn directory. For example, the altera_mf.vhd file for use with Quartus 8.1 is in the quartus_II81 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.
Packing I/O Cell Registers

You can improve input or output path timing in designs by packing registers into I/O cells with the syn_useioff attribute. With Altera Stratix, when this attribute is enabled, registers are not packed into Multiply/Accumulate (MAC) blocks. When packing registers, the order of precedence is registers, followed by ports, and then global. 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. Format
Verilog VHDL
Example module test(d, clk, q) /* synthesis syn_useioff=1 */; architecture rtl of test is attribute syn_useioff : boolean; attribute syn_useioff of rtl : architecture is true; define_global_attribute syn_useioff 1
Constraint file syntax
2. To set the attribute locally, set syn_useioff=1 on a port. Format

Verilog
Example module test(d, clk, q); input [3:0] d; input clk; output [3:0] q /* synthesis syn_useioff=1 */; reg q; 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 : boolean; attribute syn_useioff of q : signal is true; endLO test; define_attribute {p:q[3:0]} syn_useioff 1
VHDL
Constraint file syntax

The software packs registers with asynchronous clear pins and asynchronous preset pins. The software can infer the I/O cell if you have a preset or clear, and an embedded flip-flop in the I/O cell.
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
LO
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 436.
Simulation Flows
The simulation flows vary, depending on the method used to instantiate the LPMs. For information about instantiating LPMs, see Instantiating LPMs Using VHDL Prepared Components, on page 441, Instantiating Altera LPMs as Black Boxes, on page 437, and Instantiating LPMs Using a Verilog Library (Altera), on page 442. The following table summarizes the differences between the flows: Black Box Flow
Applies to any LPM Synthesis LPM timing support Synthesis procedure RTL simulation Post-synthesis (vm) simulation Post-P&R (vo) simulation Software version Yes No Many steps Complicated steps Yes Yes Any version Max+PlusII Quartus II 1.0 or earlier
Verilog Library/VHDL Prepared Component Flows

No Yes Simple Easy No Yes Quartus II 1.1 or later
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.
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. For example apex20Ke_atoms.v. 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 LPMs Using VHDL Prepared Components, on page 441 or Instantiating Altera LPMs as Black Boxes, on page 437.
For Verilog designs, use the library methods described in

Instantiating LPMs Using a Verilog Library (Altera), on page 442 or Instantiating Altera LPMs as Black Boxes, on page 437. 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. LO
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 Synplicity synthesis tool, directly from the Synplicity 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 assignments (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. 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 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 project_name_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 LO compiles.
Optimizing Xilinx Designs

This section contains tips for working with Xilinx designs:
Designing for Xilinx Architectures, on page 671 Specifying Xilinx Macros, on page 672 Specifying Global Sets/Resets and Startup Blocks, on page 674 Inferring Wide Adders, on page 675 Instantiating CoreGen Cores, on page 678 Packing Registers for I/Os, on page 682 Specifying Xilinx Register INIT Values, on page 684 Specifying RLOCs, on page 694 Specifying RLOCs and RLOC_ORIGINs with the synthesis Attribute, on page 696
Using Clock Buffers in Virtex Designs, on page 697 Working with Clock Skews in Xilinx Virtex-5 Physical Designs, on
page 698
Reoptimizing With EDIF Files, on page 700 Improving Xilinx Physical Synthesis Performance, on page 701 Running Post-Synthesis Simulation, on page 702 Instantiating Special I/O Standard Buffers for Virtex, on page 699
For additional Xilinx-specific techniques, see Working with Gated Clocks, on page 587, Inferring RAMs, on page 398, and Inferring Shift Registers, on page 431.
Designing for Xilinx Architectures

The tips listed here are in addition to the technology-independent design tips described in Tips for Optimization, on page 562.
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.
Specify a UNISIM library using the following syntax:

library unisim; use unisim.vcomponents.all; Remove any other package files with user-defined UNISIM primitives.
Specifying Xilinx Macros

The synthesis tool provides Xilinx macro libraries that you can use to instantiate 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, do the following:
Review the library file for the available macros. The Verilog library is
install_dir/lib/xilinx/unisim.v.
Add the unisim.v Xilinx macro library file to your project file. Make sure the library is the first in the list of source files..
2. To use a VHDL library, do the following:
Review the unisim.vhd macro library in the install_dir/lib/xilinx

directory to check the macros that are available.
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; use unisim.vcomponents.all; You do not need to add LO macro library files to your the source files for the 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 673 for an example.
OBUF Instantiation Example

The following examples show the declaration of OBUF in macro library files:
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 module OBUF(O, I); /* synthesis syn_black_box */ parameter IOSTANDARD="default"; parameter SLEW="SLOW"; parameter DRIVE=12; output O; input I; endmodule
Verilog
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
Data : OBUF generic map ( IOSTANDARD => "LVCMOS2", SLEW => "FAST", DRIVE => 24 ) port map ( O => o1, I => i1 ); OBUF Data(.O(o1), .I(i1)); defparam Data.IOSTANDARD = "LVCMOS2"; defparam Data.SLEW = "FAST"; defparam Data.DRIVE = 24;
Verilog
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 LO the GSR resource with a Xilinx startup block.
1. Specify access to the GSR as follows:
To automatically use the GSR if needed, eslect 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. For XC4000 technologies, the synthesis tool forces the creation of a startup block to access the GSR resource, if it is appropriate for your design. 3. To instantiate a start-up block manually, do the following:
Go to the install_dir/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 structures 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.
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 Attribute, on page 778 for the syntax fo r this attribute. 3. Synthesize the design. If your structure has less than three pipelined registers, you see an advisory message in the log file, because three pipelined registers results in the best performance. LO
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
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 679. 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); 6. Synthesize the design. If you supplied structural EDIF netlists, the software optimizes the design based on the information in the structural netlists. The generated LO reports contain the optimization information.
Instantiating Virtex PCI Cores

For Virtex PCI cores, you can use either a top-down or bottom-up methodology. This figure shows a design that is used in the explanations of both methodologies, below.
PCIM_TOP PCIM_LC FF I/O I/O CFG FF FF
BUFG
FF
PCI_LC_I
PING64
BUFG I/O
FF
FF I/O
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 to ensure that the EDIF bus names 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 Synplicity Virtex file (install_dir/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. LO
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 crossboundary optimizations. The following procedure refers to the design shown in the previous figure. 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 Synplicity Virtex file (install_dir/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 I/Os

When a register drives an input or output, you might want to pack it in an IOB instead of a CLB. For example, when
The chip interfaces with another, and you have to minimize the registerto-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: 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 : boolean; attribute syn_useioff of rtl : architecture is true; For details about attaching attributes using the SCOPE interface and in the source code, see Adding Attributes and Directives, on page 110. 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. LO
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;
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 : boolean; 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 Register syn_useioff Value
1 0
Description
Packs registers into the I/O pad cells, overriding port or global specifications. Does not pack registers into I/O pad cells, overriding port or global specifications. Packs registers into the I/O pad cells, overriding any global specification. Does not pack registers into I/O pad cells, overriding any global specification. Packs registers into the I/O pad cells. Does not pack registers into I/O pad cells.
Port
1 0
Global
1 0
Specifying Xilinx Register INIT Values

You can specify initial values for registers so that the RTL, gate-level simulation, and the final implmentation 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 specification 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: LO HDL Initialization reg myreg=0; initial myreg=0; (Verilog only)
For example: Verilog HDL Initialization VHDL HDL Initialization reg error_reg = 1b0; reg [7:0] address_reg = 8hff; signal tmp: std_logic = '0';
This is the preferred method to pass INIT values to the Xilinx place-androute 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:
Verilog reg [3:0] rst_cntr /* synthesis INIT="1" */; VHDL SDC
attribute INIT: string; attribute INIT of rst_cntr : signal is "1"; define_attribute {i:rst_cntr} INIT {"1"}
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 page 962 in the Reference Manual. 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: Verilog HDL Bus Initialization reg [7:0] address_reg = 8hff; VHDL HDL Bus Initialization signal q: std_logic_vector (11 downto 0) := X"755";
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.
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 define_attribute define_attribute define_attribute {i:init_attrver.rst_cntr[0]} {i:init_attrver.rst_cntr[1]} {i:init_attrver.rst_cntr[2]} {i:init_attrver.rst_cntr[3]} INIT INIT INIT INIT {"0"} {"1"} {"0"} {"1"}
5. Synthesize the design. The tool forward-annotates the values to the Xilinx P&R tool in the EDIF netlist.
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 686
Manually Inserting Xilinx I/Os in Verilog, on page 689 Manually Inserting Xilinx I/Os in VHDL, on page 691 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 LO or VHDL design.
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 689 and Manually Inserting Xilinx I/Os in VHDL, on page 691. See xc_loc Attribute, on page 953 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
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 5. Synthesize the design. 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 port (cout: out bit; output: out bit_vector (3 downto 0); input: in bit_vector (3 downto 0); ce, load, clk, rst: in bit ); -- Place a single I/O for cout at location A1. LO attribute xc_loc : string; attribute xc_loc of cout: signal is "A1";
-- 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 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 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 install_dir/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.
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 install_dir/lib/xilinx/unisim.v macro library file to the top of the source files list for your project. 3. Create instances of I/Os by instantiating a black box in your Verilog 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 690 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 IBUF IBUF IBUF OBUF OBUF OBUF OBUF i3 i2 i1 i0 o3 o2 o1 o0 /* /* /* /* /* /* /* /* synthesis synthesis synthesis synthesis synthesis synthesis synthesis synthesis xc_loc="P20" xc_loc="P19" xc_loc="P18" xc_loc="P17" xc_loc="TL" xc_loc="TL" xc_loc="TL" LO xc_loc="TL" */ */ */ */ (.O(in_c[3]), (.O(in_c[2]), (.O(in_c[1]), (.O(in_c[0]), .I(in[3])); .I(in[2])); .I(in[1])); .I(in[0]));
*/ */ */ */
(.O(out[3]), (.O(out[2]), (.O(out[1]), (.O(out[0]),
.I(out_c[3])); .I(out_c[2])); .I(out_c[1])); .I(out_c[0]));
OBUF cout_p /* synthesis xc_loc="BL" */ (.O(cout), .I(cout_c));
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; use unisim.vcomponents.all; 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 install_dir/lib/xilinx directory. Do not edit this file in any way. 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. 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; use unisim.vcomponents.all; See the source code in VHDL Manual I/O Insertion Example, on page 692 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.
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; use synplify.attributes.all; use ieee.std_logic_1164.all; -- Library and use clauses for access to the Xilinx Macro Library. library unisim; use unisim.vcomponents.all; 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 if rising_edge(clk) then q<=dz; end if; end process; end behave;
LO
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. 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. 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 : For details about the syn_insert_buffer syntax, see syn_insert_pad Attribute, on page 830 in the Reference Manual 2. To infer IBUFDS, IBUFGDS, OBUFDS, OBUFTDS, and IOBUFDS differential buffers, do the following:
sel c2 c1 0 1 D[19:0] Q[19:0] dout[20:1]
clk
din[20:1]
dout[20:1]
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 Attribute, on page 771 in the Reference Manual.
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 696. 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. Family
Spartan families Virtex and Spartan-3 families
xc_map Value fmap hmap lut
Max. Module Inputs

4 3 4
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; use IEEE.std_logic_1164.all; entity fmap_xor4 is port (a: in std_logic; b: in std_logic; c: in std_logic; d: in std_logic ); end fmap_xor4; LO
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; //Code for XC4000 or Spartan fmap_xor4 x03 /*synthesis xc_uset="SET1" xc_rloc="R0C0.f" */ (z03, a[0], a[1], a[2], a[3]); 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 694. 1. In the source code, use the synthesis attribute to specify the RLOC and RLOC_ORIGIN values:
Verilog /* synthesis RLOC_ORIGIN="X0Y2" RLOC="X0Y0" */; VHDL
attribute attribute attribute attribute
RLOC_ORIGIN : string; RLOC_ORIGIN of behave : architecture is "X0Y2"; RLOC : string; RLOC of q : signal is "X0Y0";
For code examples, see RLOC Constraints, on page 963 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 theVerilog 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. define_attribute define_attribute define_attribute define_attribute {i:tmp[0]} {i:tmp[1]} {i:tmp[2]} {i:tmp[3]} RLOC RLOC RLOC RLOC {"X3Y0"} {"X2Y0"} {"X1Y0"} {"X0Y0"}
3. Synthesize the design. The tool forward-annotates the values to the Xilinx P&R tool in the EDIF netlist.
LO
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 Adding Attributes in the SCOPE Window, on page 113 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) ) ) 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
Working with Clock Skews in Xilinx Virtex-5 Physical Designs

The Certify software supports clock skews for Virtex-5 devices and the SRM clock insertion delay property (Clock input arrival_time). Clock insertion 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. Hence, this results in improved timing correlation between the Certify 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)
Requested Period: - (Setup Time): + (Clock Delay at Ending Point): + (Clock Latency at Ending Point): = Required Time: - (Propagation Time): - (Clock Latency at Starting Point): = Slack (non-critical): 5.000 0.004 4.157 0.000 9.153 0.746 0.000 8.407
LO
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)
Requested Period: 5.000 - (Setup Time): 0.004 + (Clock Latency at Ending Point): 0.000 = Required Time: - (Propagation Time): - (Clock Delay at Starting Point): - (Clock Latency at Starting Point): = Slack (critical): 4.996 0.745 4.157 0.000 0.094
The Certify 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 recommendation, derive the clock period the same as the original clock and add a 2-cycle multicycle path from the clock to itself.
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, bidir_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) ) ;
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 Timing Constraints, on page 612 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_in & b; endmodule
Reoptimizing With EDIF Files

You can resynthesize an EDIF file to refine and optimize your design further. 1. Make sure your design conforms to these rules:
The design must not have mixed language files. The name of the EDIF file matches the module name.
2. Create a project and add the EDIF file to the design.
LO
3. Specify the EDIF as the top-level design.
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, specify the library first: library.module
Click OK.
4. Set any other options you want and resynthesize your design.
Improving Xilinx Physical Synthesis Performance

The Certify 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 I/O delays I/O standards including drive, slew and pull-up/pull-down Multi-cycle and false paths Max-delay paths DCM parameters Register packing into IOBs 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 to 15 percent 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 performance. 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..
Ensure placement for I/Os, block RAMs, and DSP 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.
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: 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 install_dir/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 my_tools/lib/vhdl_sim/synplify.vhd LO
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 Synplicity 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.
LO
CHAPTER 20
Working with Vendor IP

This chapter describes how to work with IP from different sources. It describes the following:
Using Hyper Source, on page 706 Working with Altera IP, on page 711 Importing Projects from Quartus, on page 735 Working with Xilinx IP Cores, on page 745
Using Hyper Source
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 more information:
Using Hyper Source for Prototyping, on page 706 Using Hyper Source for IP Designs, on page 706 Threading Signals Through the Design Hierarchy of an IP, on page 707
Using Hyper Source for Prototyping

For prototyping, use hyper source to address the following issues:
Use it to efficiently thread nets across multiple modules to the top-level

design to support Time Domain Multiplexing (TDM).
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 the RTL. After the RTL has been fully tested with complete QoR results, use hyper source to debug. For example:
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 LO might need to be added through several levels of hierarchy in the RTL. The instrumentation logic can be included anywhere in the design, so
Using Hyper Source
you can use hyper source and hyper connect to easily thread the necessary connections during synthesis.
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 connections must be manually added to the RTL code. However, if you use hyper source to thread signals through an EDIF, you must 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 708. 1. Define how to connect to the signal source. The following applies 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.
Using Hyper Source
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. 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 label = "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 label = "tag_name"; /* global name or instance path V /* 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; LO input clk, we; input [7:0] din1, din2; wire [7:0] din;
Using Hyper Source
syn_hyper_source my_source(din); defparam my_source.label = "probe_sig"; /* to thread the signal this /* /* tag_name must match to name used in the hyper connect block */ defparam my_source.w = 8; always @(posedge clk) if (we) dout <= din; assign din = din1 & din2; endmodule module sub1_module (clk, dout, din1, din2, we); output[7:0] dout; input clk, we; input [7:0] din1, din2; 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; input [7:0] din1, din2; 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; input [7:0] din1, din2; syn_hyper_connect connect_block(probe); defparam connect_block.label = "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
Using Hyper Source
The following figures show how the hyper source signal automatically gets connected through the hierarchy of the IP in the HDL Analyst view.
RTL View
LO
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 711 Implementing Megafunctions with Clearbox Models, on page 715 Implementing Megafunctions with Grey Box Models, on page 725 Including Altera MegaCore IP Using an IP Package, on page 731
For information about working with Megacore IPs in imported Quartus designs, see Importing Quartus Designs with Megacore IPs, on page 741.
Using Altera LPMs or Megafunctions in Synthesis

You can include Altera LPMs or Megafunctions in your Synplify Pro and Synplify Premier 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 712.
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 716 and Using Clearbox Information for Instantiated Megafunctions, on page 720
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 722.
Infer Altera LPMs or megafunctions included in the installDirectory/lib/altera

directory. This lets the Synplify Pro and Synplify Premier tools access supported LPMs and Megafunctions as required. Note that if you are using a VHDL component from a non-default Quartus library, you must set the Quartus 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 714 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 714, instantiate 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 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 5. Synthesize the design. 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";
LPM / Megafunction Example

The following example shows the megafunction wrapper and the associated defparams generated by the Altera MegaWizard Plug-in Manager for a singleport 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), Copyright 2011 Synopsys, Inc. 714 Certify User Guide March 2011
LO
.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 synthesis software 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 Implementing Megafunctions with Grey Box Models, on page 725) or clear boxes, as described here. The Synplify software does not support this flow. 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
synthesize with a clear box model, you get better timing and resource utilization 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 716
Using Clearbox Information for Instantiated Megafunctions, on page 720 Instantiating Clearbox Netlists for Megafunctions, on page 722
Inferred Megafunction Instantiated Megafunction Instantiated Megafunction with Clearbox Netlist
Synthesis Timing optimization and resource utilization use Clearbox information.
Synthesis Clearbox netlist used for timing analysis. No optimization.
VQM VQM includes Clearbox internals if option was set
VQM VQM does not include Clearbox primitives.
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: LO Multipliers in DSP blocks Use syn_multstyle to control inference.
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.
Use syn_srlstyle to control inference. 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.
Shift registers RAMs
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 Stratix II, Stratix III, or Stratix IV.
On the same tab, check that Verification Mode is disabled. Set the Altera Models device option.
To generate vqm that contains...
The contents of the megafunction as well as grey box netlists for any grey boxes in the design The contents of the megafunction The megafunction without its contents
Set it to...
on clearbox_only off
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]; always @(posedge clk) begin q = mem[read_add]; end always @(posedge clk) begin 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.
LO
RTL View
Technology View
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.
Using Clearbox Information for Instantiated Megafunctions

There are two ways of instantiating megafunctions and using Clearbox information 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 722. 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 Stratix II, Stratix III, Stratix IV.
On the same tab, check that Verification Mode is disabled. Set the Altera Models device option.
To generate vqm that contains...
The contents of the megafunction as well as grey box netlists for any grey boxes in the design The contents of the megafunction The megafunction without its contents
Set it to...
on clearbox_only off
Click OK.
LO 4. Set any other options you want, and click Run to synthesize the design. The tool instantiates the megafunction and calls the Clearbox executable, 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 instantiated megafunction by calling Quartus.
RTL View
Technology View
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.
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 716 and Using Clearbox Information for Instantiated Megafunctions, on page 720 ), 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 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 LO 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 10.0 are in the quartus_II100 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. 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 Technology views both show the lowest-level primitives. The following figure for example, shows stratixii_ram_blocks.
Technology View
RTL View
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. LO
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. 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 715) 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:
Inferred Megafunction Instantiated Megafunction Instantiated Megafunction with Grey Box Netlist
Synthesis Calls Altera for grey box timing and resource information.
Synthesis Uses netlist for timing and resource information.
VQM VQM does not include grey box internals
The following procedures show you how to implement an Altera megafunction as a grey box.
Automatically Using Grey Box Information for Megafunctions, on

page 726
Using Grey Box Information for Instantiated Megafunctions, on

page 726
Instantiating Megafunctions Using Grey Box Netlists, on page 728
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 Stratix II, Stratix III, or Stratix IV.
On the same tab, check that Verification Mode is disabled. To use grey box timing information, set Altera Models device option to
on.
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. 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 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 LO netlist, refer to the procedure in Instantiating Megafunctions Using Grey Box Netlists, on page 728.
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 Stratix II, Stratix III, or Stratix IV.
On the same tab, check that Verification Mode is disabled. To use grey box timing information, set Altera Models device option to
on.
Click OK.
4. Set any other options you want, and click Run to synthesize the design. The tool instantiates the megafunction and calls the grey box executable, 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. 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 incorporate cores into your 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: top.v my_ip_core.v
Top level design file. See top.v, on page 735. Top-level wrapper generated by the MegaWizard tool, which instantiates the encrypted module encrypted_ip.v. See my_ip_core.v, on page 735. Encrypted IP core that is not readable.
encrypted_ip.v
my_ip_core_syn.v A timing and resource estimation netlist (grey box file) for use in synthesis. 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.
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.
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 megafunction in your synthesis design. In the synthesis tool, add the grey box netlist file to your synthesis
project. LO 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 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.
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. LO
Set any other options or constraints you want.

6. Synthesize the design.
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 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.
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 728). 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: top.v my_ip_core.v
Top level design file. See top.v, on page 735. Top-level wrapper generated by the MegaWizard tool, which instantiates the encrypted module encrypted_ip.v. See my_ip_core.v, on page 735.
my_ip_core_enc.v Encrypted IP core that is not readable. 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 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 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.
LO
5. 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. 6. Instantiate the NIOS core in the top-level file for your synthesis design. 7. Synthesize the 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 Synplify Premier Technology view.
Technology View
RTL View
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 toplevel 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. LO
Importing Projects from Quartus
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;

You can take a Quartus project and automatically translate it into a synthesis project. To import projects from Quartus, see the following:
Importing Quartus Projects, on page 736 Importing Quartus Designs with Megacore IPs, on page 741 Importing Quartus Designs with Megafunctions/LPMs, on page 742 Troubleshooting Imported Quartus Designs, on page 743
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 qsf2sdc, on page 167 in the Command Reference for the syntax for the utility. 1. Set up your Quartus design and run Quartus.
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 743 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 741 for additional information on incorporating the IP. 2. In the synthesis tool UI, select Import->Import Altera QSF Project. The Import Altera QSF Project dialog box opens.
LO
3. Do the following in this dialog box:
In QSF File, specify the qsf file for the Quartus project you want to
import.
In the Synplify Project Location section, specify the location of project to

be created, and a name for the project.
Click the Import button at the bottom.

The command runs the qsf2syn utility. It reads referenced source files, synthesis settings, and timing constraints from the Quartus qsf and sdc files and uses this information to generate a synthesis project. It creates a synthesis prj file in the location you specified, and puts any attributes and timing constraints in sdc constraint files. The timing constraints are in native sdc format. You can run synthesis on this generated project. See Synthesis Files Generated After Importing the Quartus Project, on page 739 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 740. 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 743 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
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 VHDL/Verilog Constraint Contains...
HDL source files referenced in the Quartus qsf file Translated constraints referenced in the Quartus qsf and sdc files. See Imported Quartus Project Settings and Timing Constraints, on page 740 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.
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
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.
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 recommended 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,
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 736. 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 LO 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.
3. Import the design with the Import Altera QSF command, as described in Importing Quartus Projects, on page 736.
Troubleshooting Imported Quartus Designs

The following table lists some problems and their solutions: Problem Qsf2Syn does not translate SOPC Builder projects
Timing constraints on RTL objects that infer RAMs are not applied properly Constraints applied to RTL objects in generate statements are not applied properly
Solution
Use the procedure described in Importing Projects from Quartus, on page 735 to translate these projects. 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. 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. Manually create the constraints, using the RTL viewer to find the proper object names. Manually add the corresponding constraints found in timing_unapplied.sdc. Use the RTL viewer to find the correct object names. 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. Modify the source code so that blocking and non-blocking assignments are not combined in the same variable. 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.
Constraints applied on 2-D array objects are not translated Constraints embedded in HDL source code are not translated correctly You get an error message about an undefined macro
State machine contains blocking and non-blocking assignments in the same variable You get a compiler error message about undeclared VHDL libraries
Problem
The get_keepers qualifier is translated without a qualifier
Solution
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. Until Quartus fixes this issue, you must manually modify the qip file and change the tag to VERILOG_FILE or VHDL_FILE. 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. 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. 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. 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. Edit the Altera qsf file and ensure that all library statements are included in this file.
The qip file generated by Altera Megawizard tags the top-level IP wrapper file as MISC_FILE instead of VERILOG_FILE or VHDL_FILE
create_generated_clock, that are applied to ALTPLL instantiations in
Clock constraints like
IP megafunctions, are translated to timing_unapplied.sdc Quartus projects with Megacore IPs have IP-related files added directly to the project Quartus designs with Megacore IPs do not have a timing and resource estimation netlist VHDL file order might cause compiler errors
VHDL compiler fails because of missing qsf file
LO
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 745 Secure and Non-secure Cores, on page 746
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. 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. The tool can read the core contents (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. The tool can read the contents of secure NGC cores (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.
NGO
NGC, nonsecured
NGC, secured
The following table broadly summarizes how the synthesis tool treats various kinds of IP: IP Format
EDN, Non-secure NGC, NGO Secure NGC Encrypted EDK Encrypted RTL from encryptIP
Synthesis Input
Add file Add file Add IP with Import IP->Import Xilinx EDK/ISE Project Download with Import IP-> Download IP from Synopsys, unzip, and add file
Synthesis Output Format

Plain text Encrypted EDIF White boxes Black box or plain text, as determined by IP owner
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 Core File EDN NGO NGC, non-secured NGC, secured IP Visibility
Core contents visible to the synthesis tool Core contents visible to the synthesis tool
Effect of Synthesis Optimizations

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. 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.
LO
After you synthesize the design, the synthesis process treats the cores as follows: Non-secure core with no black box attributes attached Non-secure core marked as a white box Secure cores
Limited optimizations like constant propagation can be performed as needed. You can view the internals of the core in the RTL and Technology views. The synthesis tool does not modify the core or write out the internals of the core in the synthesized netlist. Limited optimizations like constant propagation can be performed. You can view the internals of the core in the Technology view.
After synthesis, the tool generates core output files for P&R: 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 649) as well as user-specified timing constraints. Placement constraints are forward-annotated in the designName.ncf file. 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 649) as well as userspecified timing constraints. Placement constraints, excluding constraints for secure cores, are forward-annotated in a designName.ncf file. For each secure core, the tool generates an individual ncf file with the constraints for that core.
NGC, secured
Including Xilinx Cores for Logic and Physical Synthesis

The following procedure shows you how to include Xilinx secure and nonsecure 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. Instantiate the Xilinx core in your top-level RTL. 2. Make sure you are targeting a technology that supports this design flow. 3. 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 746. 4. 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 Attribute, on page 841. 5. Synthesize the design.
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 746.
LO
CHAPTER 21
Analyzing the Log File

This chapter describes how to analyze the log files generated following compilation and after synthesis by Synplify Premier. See the following:
Checking Log Results, on page 750 Handling Messages, on page 753 Validating Logic Synthesis for Physical Synthesis, on page 764
Checking Log Results

You can check the log file for information about the synthesis run. The interface includes 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 the Log File, on page 750 Analyzing Results Using the Log File Reports, on page 753
Viewing 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 also is a text version available. 1. To view the log file, do one of the following:
To view the log file in the default HTML format, select View->Log File.
You see the log file in HTML format.
To see a text version of the log file, double-click the designName.srr file
in the Implementation Results view. A Text Editor window opens with the log file. Alternatively, you can set the default to show the text file version instead of the HTML version. Select Options->Project View Options, and toggle off the View log file in HTML option. The log file lists the compiled files, 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 753.
LO
Log File (Text)
Log File (HTML)
2. To navigate in the log file, use the following techniques:
Use the scroll bars. Use the Find command as described in the next step. In the HTML file, click the appropriate header to jump to that point in
the log file. For example, you can jump to the Starting Points with Worst Slack section. 3. To find information in the log file, select Edit->Find or press Ctrl-f. Fill out the criteria in the form and click OK. For general information about working in an Editing window, including adding bookmarks, see Editing HDL Source Files with the Built-in Text Editor, on page 45. The areas of the log file that are most important are the warning messages. The following table lists places in the log file you can use when searching for information.
To find...
Notes Warnings and errors Performance summary Resource usage Gated clock conversions
Search for...
@N or look for blue text @W and @E, or look for purple and red text respectively Performance Summary Resource Usage Report Gated clock report
4. 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 754 for information. Notes are informational and usually can be ignored. For details about crossprobing and fixing errors, see Handling Warnings, on page 763, Editing HDL Source Files with the Built-in Text Editor, on page 45, and Crossprobing from the Text Editor Window, on page 352. 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. 5. 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 45. 6. 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. LO
Handling Messages
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 check buffers,
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. 2. To check logic resources,
Go to the Resource Usage Report section at the end of the log file. Check the number and types of components used to determine if you
have used too much of your resources.
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 754 Filtering Messages in the Message Viewer, on page 755 Filtering Messages from the Command Line, on page 758 Automating Message Filtering with a Tcl Script, on page 759 Handling Warnings, on page 763
Handling Messages
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 Window, on page 40 in the Reference Manual for a full description of the window.
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. LO
Handling 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.
To filter the messages, use the procedure described in Filtering

Messages in the Message Viewer, on page 755. 4. 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 763.
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 754. For the command line equivalent of this procedure, see Filtering Messages from the Command Line, on page 758. 1. Open the message viewer by clicking the Messages tab in the Tcl window as previously described. 2. Click Filter in the message window.
Handling Messages
The Warning Filter spreadsheet opens, where you can set up filtering expressions. Each line is one filter expression.
3. Set your display preferences.
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 caseLO 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.
Handling Messages
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: 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.
Handling Messages
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 755. 1. Type your filter expressions in the Tcl window using the log_filter command. For details of the syntax, see the log_filter command description in the Certify Command Reference. 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 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 LO @N Synthesizing module writeUSBWireData Compiler Report writeusbwiredata.v (59) usbHostSlave.srr (704) 05:22:06 Mon Oct 18
Handling Messages
Automating Message Filtering with a Tcl Script

The following example shows you how to use a synhooks Tcl script to automatically 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 755 or Filtering Messages from the Command Line, on page 758 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 309. 3. Edit the synhooks.tcl file so that it reads like the following example. For syntax details, see Tcl synhooks Utility, on page 405 in the Reference Manual.
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 ""
Handling Messages
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.
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 through the Srr 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.
LO
Handling Messages
Srr Log File Filter Dialog Box

The Srr 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. 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.
Handling Messages
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 projectName.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
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

LO in the @N:msgID :messageText format. the srr file.
If an ID is suppressed, the mapper/compiler excludes the message from
Handling Messages
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 project stores the user message filter settings from the SRR Log File Filter dialog box. 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 in the project, you must close and reopen the project in the GUI before your changes become effective.
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.
Validating Logic Synthesis for Physical Synthesis

Use the following checklist to validate the results of logic synthesis in your physical design flows. 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 Results, on page 750.
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 invalidate 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.
Altera forward annotation file Xilinx forward annotation file
.tcl .ncf
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 LO the PAR directory) matches the report file.
The file varies, depending on the vendor:

Altera report file Xilinx report file
.tan.rpt .twr
For Altera and Xilinx 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 Xilinx report file
.tan.rpt .twr
For Virtex-5 designs, see Working with Clock Skews in Xilinx Virtex-5 Physical Designs, on page 698. 2. For Xilinx designs, check that the DCM parameters correctly defined in the source code or sdc constraint file. Check the Clock Relationships table in the srr log file.
LO
CHAPTER 22
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 768 Time Budgeting, on page 769 System-Level Timing Analysis, on page 770
Analyzing Timing in Schematic Views
Analyzing Timing in Schematic Views

You can use the HDL Analyst functionality to analyze clock trees in the RTL view: 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 361, Expanding Pin and Net Logic, on page 363 and Expanding and Viewing Connections, on page 367. 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.
LO
Time Budgeting
Time Budgeting
RTL time budgeting is used in an SLP-based flow to estimate timing constraints for the individual FPGAs. This step automatically budgets the top-level timing constraints for each FPGA and annotates this information into the individual synthesis constraint (*_timing.sdc) files. These sdc files are included as a part of an SLP project and provide a more accurate timing constraint for chip-level mapping. RTL time budgeting is performed immediately following SLP generation by selecting Run->Estimate Time-Budgets or by executing the following Tcl command: estimate_timing netlistFilename_slpgen.srp [-effort {high | low}] Note that in addition to the individual constraint files, performing time budgeting creates a top-level srm file for the design which can be viewed by clicking directly on the srm file in the Result Directory window. Two effort levels of timing estimation are supported and controlled by:
the Timing Budget Effort Level setting on the Device panel the following set command option:
set_option -timing_effort {high | low}
the -effort option setting included with the estimate_timing command

When the estimation effort is set to low, timing estimation is faster and less accurate than when the effort is set to high. RTL time budgeting is based on the timing of the RTL netlist after the RTL optimizations have been performed, but without technology mapping. Accuracy is limited by the estimation of the delays assigned to RTL and technology-independent objects such as adders, multipliers, and AND gates. These objects are tuned to the technology, but are still only coarse approximations. When the estimation effort is set to high (the default), timing estimation is based on technology mapping and technology-independent optimizations for a more accurate, but more time consuming, timing estimation. Board trace delays, when provided, are included in the time-budget calculation. Trace delay (tdv) files for a number of the Synopsys-defined HAPS boards are provided and automatically included when the board file is defined. In the absense of a trace delay file, the individual delays must be defined. For information on trace delays, see Board Trace Delays, on page 811.
System-Level Timing Analysis

SLP allows synthesis and subsequent timing analysis of individual FPGA devices by the synthesis tool. With SLP projects, performing system-level timing analysis, including inter-FPGA paths, requires implementing the individual SLP projects in the synthesis tool, defining the SLP database in Certify, and then performing timing analysis on the combined project database.
Defining the SLP Database

To consolidate the SLP implementations, a set of syn_slp_database attributes is defined to point to the intermediate srd netlist files generated for the individual SLP implementations by Synplify Premier. These attributes are included in a constraint ( sdc) file in the top-level Certify project. The attribute syntax is: define_attribute {v:view} syn_slp_database {path_to_srd_file} In the above syntax, view is the FPGA device and is case-sensitive; path_to_srd_file is either the absolute or relative path to the corresponding srd file in the database. The following example uses FPGA device u1 with a relative path to the srd file: define_attribute {v:u1} syn_slp_database {./synthesis_files/u1/verilog/u1.srd} A template file (slp_system_timing.sdc) is included in the top-level Certify project directory. You can edit the individual entries in this file and then add the file to your project or you can copy and paste the syn_slp_database entries into an existing constraint (sdc) file.
Timing Analysis Flow

To perform system-level analysis: 1. From the top-level Certify project, write post-partitioned netlists for the LO individual FPGAs by selecting the SLP Generation button to display the SLP Generation dialog box.
2. Enter the path to the post-partition result file and check one (or both) of the SLP generation options. Generate SLP Mixed Projects is generally used with designs in the development phase that have a potential for incremental changes to allow debugging of the SLP projects using the Identify debugger or a simulator; Generate SLP Database Projects is generally used with stable designs intended for post-synthesis analysis.
3. Synthesize the SLP projects. Projects can be syntheized individually by highlighting the project under the implementation and selecting Synthesize SLP Project from the popup menu (see below) or all projects can be synthesized with a single operation by clicking the Run SLP Projects button in the Project view
4. Add the supplied slp_system_timing.sdc template file (included in the toplevel Certify project directory) to the top-level project and edit the individual device entries to point to the corresponding srd netlist files for each SLP project (see Defining the SLP Database, on page 770).
Note that you can add the edited template file entries to an existing constraint (sdc) file. 5. From the top-level Certify project, select Run->Estimate Time-Budgets from the top-level menu. When you run estimate time budgets, the Estimate Timing block in the flow graph turns yellow during execution and then green when estimation is complete. To check the estimation results, click on the Estimate Timing block and select View Log File to display the projectName_time_est.srr file. 6. From the top-level menu, select Analysis->Timing Analyst or click the Timing Analyst icon to display the Timing Report Generation dialog box (the analyst commands are available only after estimating time budgets). 7. In the dialog box:
In the Filters section, check the Open Report and Open Schematic boxes.
Enter any from/to/through values. Note that objects specified in the from/to/through values are identified by their post-partitioned names which include an extra level of hierarchy to identify the FPGA instance that contains the object.
In the System Level Timing Analysis section, make sure that Perform
System Level Timing Analysis is checked and that the correct path to the post-partitioned netlist is specified.
In the Output Files section, make sure that SRM File is checked and
that the correct path to srm file is specified; optionally change the name of the timing analysis file (default projectName.ta).
LO
8. Click the Generate button. A schematic view of the combined FPGAs is displayed and the timing analysis (ta) file 9. See the projectName.ta log file for the timing report. Note: Timing analysis cannot be performed on CPM ports/nets.
LO
CHAPTER 23
Debugging Aids
Debugging aids available for the Certify prototyping tool include:
Assigning Probes, on page 776 Multiplex Probes, on page 778
Assigning Probes
Assigning Probes
Probes are assigned to internal nets to allow internal signals to be monitored as part of the I/O interface and can also be assigned to output ports at the top level of an FPGA design. Because probes connect to the interface, each probe requires an I/O pin.
Assigning Probes to Internal Nets

To assign a probe to an internal net: 1. Open the Partition and RTL Design views. 2. In the Partition Device Tree view, select the top-level FPGA for probe assignment.
Probes icon
3. Use Push/Pop Hierarchy to push down in the RTL Design view to display the internal logic that includes the net/bus to be assigned to a probe or probes. 4. In the RTL view, click on the net to be probed and drag and drop the net over the Probes icon (or the word Internal Probes) in the Partition Device Tree view. The cursor changes to an arrow with a + sign when positioned over Internal Probes.
LO
Assigning Probes
5. The FPGA pin count is dynamically updated in the Info view and device properties. 6. The additional pin or pins are visible when you open the srs file after the SLP project is has been synthesized by Synplify Premier.
Notes on Probes
The following notes apply to assigning probes:
When you are not allowed to make a probe assignment (for example,
attempting to assign a probe to a net located in the black-box bin), the cursor remains a circle and does not change to the arrow with the + sign.
Probes can be assigned to single nets or buses. When assigning a bus to

a probe, one I/O pin is required for each bus bit.
To assign individual bits of a bus to probes, you must select the bit in
the Hierarchy Browser.
You must open the post-synthesis srs file to drag and drop probes into
SCOPE.
Multiplex Probes
Multiplex Probes
The multiplexing of probes can substantially reduce pin count when bringing internal signals out to a devices I/O pins as probes. To support multiplex probes, a file containing special multiplexers must be added to your project and then compiled into the design and instantiated; nets are then assigned to the multiplexers as probes. Verilog and VHDL example multiplexers are included in either the syn_mux.v or syn_mux.vhd file. These files are located in the examples directory (examples/verilog/debugaids/probes or examples/vhdl/debugaids/probes). You can use the example multiplexers directly or use them as templates to develop your own multiplexers. After your design is compiled, viewing the Partition Tree view shows the Multiplex Probes icon.
Adding Probe Multiplexers

Probe multiplexers are added using the Multiplex Probes icon. To add a probe multiplexer: 1. Right click on the Multiplex Probes icon, select Add Module from the popup menu, and select the multiplexer from the list displayed.
LO
Multiplex Probes
Note: If Add Module is not displayed in the popup menu, CPM probe multiplexers have not been compiled into the design. 2. Click on the selected multiplexer. The multiplexer is added under the CPM Probes icon in the Partition Tree view.
You can add any number of multiplexers by repeating steps 1 and 2. When adding additional multiplexers of the same type:
A numerical suffix (beginning with "_2") is added to the multiplexer

name to make it unique.
Multiplexers of the same type are arranged in groups in the Partition

Tree view.
Multiplex Probes
Adding Nets to Multiplexers

To add a net to a CPM probe multiplexer: 1. Select the net in the RTL view. 2. Hold the mouse button down and drag the net to the multiplexers data or control bus or to an expanded bit of the bus. 3. Release the mouse button. The name of the assigned net, in parentheses, is appended to the multiplexer bus or bit name.
Multiplexer Multiplexer Data Bus Net Bus Name Net Bit Name
When adding nets to the data or control bus:
Nets are assigned to a multiplexer beginning with the high-order bit. Multiple nets can be added by using the Ctrl key to select more than one
net from the RTL view or hierarchy browser.
Buses are assigned beginning with the high-order bit. Use the hierarchy
browser to add individual bits of a bus or to change the bit order of a bus.
When there is insufficient room for a net or bus to be assigned to a

multiplexer, the assignment is prevented.
LO
Multiplex Probes
Updating the Post-Partition RTL View

After assigning nets to a multiplexer, the post-partitioned RTL view is updated with the multiplexer logic when you run the Partitioner. To view the added logic, open the partitioned netlist (srp) file in the HDL Analyst and push down into the assigned FPGA
Multiplex Probes
Assigning Control Pins

Every control pin on every CPM Probe module must be explicitly assigned to one of the following:
an internal net from the RTL view VCC Ground a predefined external port
Internal nets are assigned by drag and drop. To connect a control pin to an internal net from the original RTL, drag and drop the corresponding signal from the RTL view or hierarchy browser onto the desired control pin. By dragging and dropping the same signal to another control pin, control pins on more than one module can be assigned to the same internal signal. To connect a control pin to VCC or GND, select the individual control pin in the Partition Tree view and right click to bring up the popup menu with the VCC and GND selections. Select the desired level from the menu.
LO
Multiplex Probes
Assigning Control Pins to External Ports

Control pins are connected to external pins by first defining the external port names and then assigning the external ports to the control pins. To define an external port name, select an individual control pin, right click to bring up the popup menu, and select Port to display the Port Connection dialog box.
In the dialog box, enter the name for the external port in the Create New Port field on the right and click Add to List. When entering port names:
Click Add to List to add the defined port to the Select Port list. If you press
return, the port name entered is immediately assigned to the selected control pin, and the dialog box is closed.
Check the name carefully before clicking Add to List. Once added to the
Select Port list, the name cannot be edited.
Bus ports (vectored signals) can be defined using standard bus syntax
(starting and ending bits separated by a colon and enclosed in square brackets). When a bus port is added to the Select Port list, the individual bits are selected using the drop-down arrow in the Bit field.
Multiplex Probes
To assign an external port to the selected control pin, highlight the port in the Select Port list and click OK. When assigning ports to control pins:
To assign an individual bit of an external bus, highlight the bus in the

Select Port field and then select the desired bus bit with the drop-down arrow in the Bit field.
The same external port can be assigned to more than one control pin by
selecting a new control pin in the Partition Tree view, selecting External and highlighting the port in the Select Port list, and then clicking OK.
To remove an assignment, select the control pin in the Partition Tree

view and then select Disconnect from the popup menu. Use SCOPE to assign the external control pins to specific FPGA package pins. See the SCOPE documentation for details.
Creating Your Own Modules

The cpm_probes_mux.vhd file includes the mp_4bit, mp_16bit, and mp_64bit sample CPM probe modules for VHDL, and the cpm_probes_mux.v file includes the Mp_4bit, Mp_16bit, and Mp_64bit sample CPM probe modules for Verilog. These files are included in subdirectories under the examples directory. You can define your own CPM probe modules in VHDL or Verilog. After you create a module, add its v or vhd file to your project and recompile your design. When the source file is compiled, the Select Module dialog box will list the new module. The following example is a simple multiplexer module with a shift register select mechanism written in Verilog. In the example, note the synthesis directives entered as pseudo comments that allow Certify to determine how to interpret the module. In the example, there are two input pins that act as controls (control and ctl_clk). To support control groups, each of these pins must include a syn_cpmprobe_control directive to identify it as a control pin.
LO
Multiplex Probes
//======================================================= module tst_64bit(a, o, control, ctl_clk) /* synthesis syn_implement="1" */ /* synthesis syn_cpmprobe_type="tst_64bit" */ ; input [63:0] a; input control /* synthesis syn_cpmprobe_control=1 */; input ctl_clk /* synthesis syn_cpmprobe_control=1 */; output o; reg o; reg [5:0] ctl; always @ (posedge ctl_clk) begin ctl = ctl << 1; ctl[0] = control; end always @ (a or ctl) begin case (ctl[5:0]) 6'b000000: o = 6'b000001: o = 6'b000010: o = 6'b000011: o = 6'b000100: o = 6'b000101: o = 6'b000110: o = 6'b000111: o = 6'b001000: o = 6'b001001: o = 6'b001010: o = 6'b001011: o = 6'b001100: o = 6'b001101: o = 6'b001110: o = 6'b001111: o = 6'b010000: o = 6'b010001: o = 6'b010010: o = 6'b010011: o = 6'b010100: o = 6'b010101: o = 6'b010110: o = 6'b010111: o = 6'b011000: o =
a[0]; a[1]; a[2]; a[3]; a[4]; a[5]; a[6]; a[7]; a[8]; a[9]; a[10]; a[11]; a[12]; a[13]; a[14]; a[15]; a[16]; a[17]; a[18]; a[19]; a[20]; a[21]; a[22]; a[23]; a[24];
Multiplex Probes
6'b011001: 6'b011010: 6'b011011: 6'b011100: 6'b011101: 6'b011110: 6'b011111: 6'b100000: 6'b100001: 6'b100010: 6'b100011: 6'b100100: 6'b100101: 6'b100110: 6'b100111: 6'b101000: 6'b101001: 6'b101010: 6'b101011: 6'b101100: 6'b101101: 6'b101110: 6'b101111: 6'b110000: 6'b110001: 6'b110010: 6'b110011: 6'b110100: 6'b110101: 6'b110110: 6'b110111: 6'b111000: 6'b111001: 6'b111010: 6'b111011: 6'b111100: 6'b111101: 6'b111110: 6'b111111: endcase end endmodule
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
a[25]; a[26]; a[27]; a[28]; a[29]; a[30]; a[31]; a[32]; a[33]; a[34]; a[35]; a[36]; a[37]; a[38]; a[39]; a[40]; a[41]; a[42]; a[43]; a[44]; a[45]; a[46]; a[47]; a[48]; a[49]; a[50]; a[51]; a[52]; a[53]; a[54]; a[55]; a[56]; a[57]; a[58]; a[59]; a[60]; a[61]; a[62]; a[63];
LO
CHAPTER 24
Post-Synthesis Operations
Post-synthesis operations in Certify include:
Synthesizing with Synplify Premier Running the Identify debugger
Synthesizing with Synplify Premier

After creating the individual SLP projects and performing time-budget estimation in Certify, the Synplify Premier tool can be used to synthesize the individual projects. To launch Synplify Premier directly from Certify, you must specify the path to the Synplify Premier executable by selecting Options->Configure Synplify Launch and entering the path to the Synplify installation directory.
The Maximum number of parallel jobs selection allows multiple SLP projects to be run in parallel when there are multiple licenses and CPU cores available on a single machine. This option can also be set with a set_option max_parallel_jobs Tcl command. Note: When entering the path to the Synplify installation, do not include a closing slash or back-slash after the version string.
Synthesizing SLP Projects in Certify

To synthesize an SLP project in Certify, highlight the project in the Certify Project view and select Synthesize SLP Project from the popup menu. To synthesize all of the SLP projects in a single operation, click the Run SLP Projects button in the Project view. Note that Certify calls the Synplify Premier mapper to synthesize the projects.
Data Base File Structure

As a result of synthesizing an SLP project, the requisite output files are generated and the combined database is updated with the synthesis results. In the implementation directory (proto), a synthesis_files directory is created. Within this directory are subdirectories for each FPGA and within these subdirectories are a mixed and/or an srs subdirectory (according to the SLP LO generation options selected) containing the corresponding synthesis result files.
Checking the Results in Synplify Premier

The synthesis results for any of the SLP projects can be checked directly in Certify by opening the corresponding log (srr) file in text mode. However, launching Synplify Premier from a project is recommended in order to view both the log file and error messages and to correct any problems encountered during synthesis.
To launch Synplify Premier from Certify: 1. Highlight the project under the implementation. Note that if you have both a mixed.prj and an srs.prj, you can select either project. 2. Right click and select Launch Synplify from the popup menu to synthesize the selected project in the Synplify Premier synthesis tool.
3. After opening the Synplify Premier tool, open the other projects using Open Project->Existing Project.
LO
Running the Identify Debugger

The Synopsys Identify tool set is a dual-component system that is a valuable part of the HDL design flow process available to Certify. The system consists of the Identify instrumentor and Identify debugger tools.
The Identify instrumentor allows you to select your design instrumentation at the HDL level to define an on-chip hardware probe. The Identify instrumentor is used prior to partitioning to define the sampling logic to be added to the design.
The Identify debugger interacts with the on-chip hardware probe and
lets you do live debugging of the design after the design is synthesized by the Synplify Premier mapper and loaded into the FPGAs. You can run the Identify tool set independently; the Certify tool has integrated the Identify instrumentor and Identify debugger into the synthesis user interface. This section describes how to take advantage of this integration and how to run the Identify debugger (for information on running the Identify instrumentor from Certify, see Including Identify Sampling Logic, on page 142).
Launching the Identify Debugger

After synthesizing the individual partitioned projects with the Synplify Premier mapper (see Synthesizing with Synplify Premier, on page 787) and before launching the Identify debugger:
Place and route each FPGA Generate the bit file for each FPGA device Complete the JTAG cable interface Program the individual FPGA devices
After completing the above tasks: 1. If necessary, redisplay the Certify project view. 2. Expand the Identify implementation by clicking the + sign. 3. Select (highlight) a project and select Tools->Launch Identify Debugger from the main menu or click the Launch Identify Debugger icon in the menu bar.
LO
CHAPTER 25
Board Description Files

Board description files define or reference device information, instantiate physical devices, and define trace wiring. All board files are written in Verilog and have a vb extension. Certify directives define and instantiate the modules for the physical devices. The Certify tool includes a board wizard that lets you select predefined or off-the-shelf Synopsys HAPS boards and also can assist you in the creation of user-defined board description files. When creating a board description file, the wizard is used to define the following:
Technology and number of FPGAs (multiple technologies from the same

vendor are supported)
Types of FPGAs including part, package, and speed grade Traces among the available FPGAs on boards without predefined pin
connectivity
Defining Physical Device Modules

Modules in the board description file are defined for the following physical devices:
FPGAs Board-level Black Boxes Connectors Board Module Board Module
FPGAs
FPGA modules either can be defined or referenced within the board description file. All FPGA modules must be from the same vendor, but can vary in technology (family), speed grade, package, and device capacity.
Board-level Black Boxes

Board-level black boxes are used for any hardware other than an FPGA, connector, or routing chip. Black boxes cannot be defined with the board wizard. Examples of board-level black boxes are:
any logic design block that will not be implemented within an FPGA; for
example, RAM or a large ALU
a black box from the design; for example, an IP module

When defining a black box:
bus ports can be used connected ports should be declared as input or output unconnected ports must be declared as inout
LO
An example of a black box declaration and instantiation is shown in below.
Declaration
{
{
Instantiation
module MEMORY (DATA_IN, DATA_OUT, MEM_RD, MEM_WR); /* synthesis syn_black_box */ /* synthesis syn_noprune = 1 */ /* synthesis syn_partition = "black_box=RAM" */ input MEM_RD, MEM_WR; input [63:0] DATA_IN; output [63:0] DATA_OUT endmodule . . . module board(); /* synthesis syn_partition = "board" */ wire [63:0] STORE, RETRIEVE; wire READ, WRITE; . . . MEMORY RAM (STORE, RETRIEVE, READ, WRITE);
Connectors
Connectors are black boxes that are used for board connectivity (with the outside world). Only trace assignments can be made to a connector, and no logic assignment is permitted.
An example of a connector declaration and instantiation is shown in below.
Declaration
{
{
Instantiation
module SYSTEM_INTERFACE (R_DATA_IN, S_DATA_OUT, WR_CMD); /* synthesis syn_black_box */ /* synthesis syn_noprune = 1 */ /* synthesis syn_partition = "connector" */ inout [63:0] S_DATA_OUT, R_DATA_IN; inout WR_CMD; endmodule . . . module board(); /* synthesis syn_partition = "board" */ wire [63:0] DATAIN; wire [63:0] DATAOUT; wire WR_CMD, CLK, RESET; . . . SYSTEM_INTERFACE SysIF (DATAOUT, DATAIN, WR_CMD);
Board Module
The board module instantiates all of the FPGA, black box, connector, and routing chip modules. The board module also includes the wire declarations for each trace and predefined probe.
LO
Board Description Guidelines
Board Description Guidelines

When creating a board-description file:
If the board is not predefined, use the largest devices and packages with
the highest pin count; start with more FPGAs than intended to allow additional resources for grouping instances and what if scenarios (unused FPGAs are discarded by the partitioner).
Leave all unused pins on the devices unconnected to limit the trace list
to only what is needed in the pin assignment table.
Do not use a module name that is the same as a design module or entity
name.
Board I/Os should be represented by connectors. Logic-level black boxes that are assigned to board-level black boxes
should use the same I/O pin names (case sensitive) in both the design and board modules in order to avoid an interface mismatch and to enable automatic black-box pin assignment.
Using the Board Wizard

As mentioned earlier in this chapter, the board wizard is limited to creating FPGA entries and the corresponding FPGA board module entries (black box, connector, and routing chip entries must be manually defined). Because the board wizard does not allow detailed pin-to-pin connections, it cannot be used to define the connectivity for predefined boards. Additionally, the board wizard can select an off-the-shelf board for a project from an extensive list of HAPS boards available from Synopsys.
Synopsys HAPS Board Selection

The board wizard also can be used to add off-the-shelf Synopsys HAPS boards to a project. To add a predfined, HAPS board to your project: 1. Click on the Board Wizard icon in the menu bar (the magic wand) to display the Step 0 - Prototype System screen. 2. Make sure that the Add single off the shelf board from Certify library radio button is selected and click Next> to display the Step 1 - Add Board from Certify Library screen.
LO
3. Select (highlight) the board file in the Filename column and click the Finish button to add the file to your project. Note: If you are intending to use the Certify HSTDM feature, you must enable the HSTDM switch in the board file and you must define the clock and reset pins. For more information, see Enabling HSTDM Mode, on page 241 and Configuring the Board Definition Files, on page 240.
Vendor Board Files

Certify can use boards from third-party vendors. A third-party board file must have a vb extension and must compile successfully with the Synopsys FPGA Verilog compiler. Third-party board files can be installed in the lib/board subdirectory for selection directly from the board wizard or simply added to the project file. When adding a board file from the board wizard, you can include a text string in the first line of the file as a comment (text preceded by //) which will be displayed in the board wizards board selection screen.
Creating an Initial Single-Board File

To use the board wizard to create an initial single-board file: 1. Click on the Board Wizard icon in the menu bar (the magic wand) to display the Step 0 - Prototype System screen.
2. Make sure that the Create single custom board radio button is selected and click Next> to display the Step 1 - FPGA Selection screen.
LO 3. Enter the number of FPGAs to be included in the first field.

4. In the Device field, select Single if all of the FPGAs will be from the same technology or select either Mixed Altera or Mixed Xilinx if you are going to mix technologies from the selected vendor. 5. If you selected Single in step 4, select the technology from the drop-down list of available technologies and click Next to display the FPGA selection screen shown in the following figure. If you selected either Mixed Altera or Mixed Xilinx in step 4, click Next to display the FPGA selection screen; you will select the technologies for the individual FPGAs from this screen.
6. If you selected either of the mixed-vendor technologies, select the technology for the first FPGA from the Technology drop-down menu. If you are using the same technology for all of the FPGAs (if you selected Single in step 4), continue with step 7. 7. Enter the part, package, and speed grade for the first FPGA. The available entries for these fields depend on the technology selected. 8. If desired, you can change the instance name in the FPGA Name entry. 9. Click Next> to display the screen for the next FPGA (U2). 10. If you selected either of the mixed-vendor technologies, select the technology for the second FPGA. If you are using the same technology for all of the FPGAs, continue with step 11.
11. Enter the part, package, and speed grade information for the second FPGA and click Next>. You can mix parts, packages, and speed grades within the same technology. If you entered 3 (or more) for the number of FPGAs in the Step 1 screen, you are again prompted to enter component information for the next FPGA. Note: You can go back and change the Step 1 screen or any of the Step 2 screens before advancing to the Step 3 screen. 12. When you click Next> after defining the last FPGA, the Step 3 screen is displayed.
13. With the Add Traces tab selected (the default), define the traces among the available FPGAs. When defining traces:
The LSB of a trace is connected to the first available FPGA pin in

alphabetical order. Subsequent bits are connected to the next available pin in order.
By default, traces are named automatically. To override the default,

make sure that the Automatic box is not checked.
Select the Bits or Bus radio button and specify the trace width. If you
LO select Bits, each individual bit is defined with a wire statement in the board description file.
Define the trace path between FPGAs by highlighting two or more of

the FPGAs listed in the Devices column. Note that you have no control over which FPGA pin that the trace will be assigned to. 14. Each time you define a bus or trace, click Create Trace. The Used Pins column will show the number of pins used by each FPGA, and the Available Pins column will show the number of undefined pins available on each FPGA. 15. Use the Modify Traces tab to examine your trace list or to delete individual traces. The Filter Traces dialog box can be used to list traces by device interconnect (see Using the Modify Traces Tab, on page 804). 16. When satisfied with your trace definitions, click Finish (on either tab). You are then prompted to enter a filename for your board file. Note: Do not use the name of a design module or entity name for the name of the board file. When you enter a filename and click Save, you are asked if you want the board file added to the active project. Note: After you click Finish, you cannot use the board wizard to add or change information in the board file.
Automatic Naming Convention

To speed up trace creation, Automatic naming can be used (Automatic box checked on the Add Traces tab). When enabled, trace names are created according to the following rules:
When devices are selected using the Ctrl key, instance names are concatenated, with underscore separators, in the order the devices were selected. For example, clicking U1, U3, and U2 results in a trace name beginning with U1_U3_U2.
When devices are selected using the Shift key, instance names are
concatenated, with underscore separators, beginning with the first selected instance name with the other instance names added in alphabetical order. For example, clicking U4 and then clicking U2 with the Shift key (to select U2 and U3) results in a trace name beginning with U4_U2_U3.
Trace names are terminated with a 3-digit trace number beginning with
t000. This number is incremented when the same root name (instance sequence) has already been used in order to make the name unique.
Using the Modify Traces Tab

The Modify Traces tab is used to examine your trace list and to delete individual traces. Additionally, the list of traces can be filtered to show only the traces that interconnect specific devices. The following figure shows the Modify Traces tab.
To delete one or more traces, select the trace name or names and click Delete Trace. Once a trace is created, it cannot be modified; use Delete Trace and Create Trace on the Add Traces tab. To filter the list of displayed traces, click Filter Traces. The Filter Traces dialog box is displayed. LO
When no devices are selected, all traces are displayed in the trace list. If one or more devices are selected as shown above, the trace list is reduced to only the traces that include interconnections between the selected devices. The figure below shows the filtered trace list for traces interconnecting U2 and U3.
To redisplay the complete list, click Select None in the Filter Traces dialog box.
Board Wizard Limitations

The board wizard is intended to be used for Certify-defined boards to perform quick partitioning to determine the optimum number and type of FPGA devices required for a design. In this capacity, the board wizard exhibits the following limitations:
Boards with predefined pin connectivity are not supported. With the
board wizard, you cannot perform individual pin assignments.
Board-level black boxes, connectors, and routing chips are not

supported.
Probes (single-pin traces) are not supported. Mixing of technologies on a single board is not supported.
When using the board wizard to define single boards:
Make sure you click Bus when defining a bus trace. If Bit is selected (the
default), each individual bit is listed with a wire statement.
Make sure all of your Step 2 device selections are correct before
advancing to Step 3.
Before clicking Finish in Step 3, make sure that you have added all
possible traces. Once you exit the board wizard for single boards, any additions or changes to the board file can only be done with a text editor.
LO
Board Description File Format
Board Description File Format

The structure of a board description file is shown below.
Module definitions for components on board
{
{
"altera/plandata/EPF10K10LC84.v>" "altera/plandata/EPF10K30RC208.v>" "icube/plandata/IQX240BPQ304L.v>" Trace between "<path_to_oscillator.v>" U1 and RC1 module board(); /* synthesis syn_partition = "board" */
include include include include wire clk, reset, ... , sig02_U1, sig03_U1, sig04_U1; ... wire [63:0] data_in, data_out; IQX240BPQ304L RC1 ( .pin_1(un01_RC1), .pin_2(sig01_U1), .pin_4(sig02_U1), ... .pin_300(data_in[63]), .pin_303(data_in[62])); oscillator OSC (.clk(clk), rst(reset)); EPF10K30RC208 U1 /* synthesis syn_speedgrade = "-2" */ ( .pin_7(sig01_U1), .pin_8(sig02_U1), .pin_9(sig03_U1), ... .pin_207(un207_U1), .pin_208(un208_U1) ); EPF10K10LC84 U2 /* synthesis syn_speedgrade = "-3" */ ( .pin_1(un01_U2), .pin_2(un02_U2), .pin_3(un03_U2), ... .pin_83(un83_U2), .pin_84(un84_U2) ); endmodule
Wire declarations for board connectivity Routing chip Black box
{
{
FPGA
FPGA
{ {
An example board description file is included in Appendix A, Board Description File Example.
Board Description File Directives

The following directives are used to define and instantiate devices in the board description file:
syn_partition Directive syn_noprune Directive syn_speedgrade Directive syn_black_box Directive
syn_partition Directive
Use the syn_partition directive to identify the following modules in the board description file:
FPGAs board-level black boxes connectors a system board routing chips
Syntax
The syntax for the syn_partition directive is: /* synthesis syn_partition = "object_name[=value]" */; In the above syntax description, object_name is one of the following:
fpga black_box connector route board LO
fpga
The keyword fpga defines an FPGA module. For example: /* synthesis syn_partition = "fpga=XCV1000BG560" */
black_box
The keyword black_box defines a board-level black box component. Attach this value to a module definition of a board-level black box component. For example: /* synthesis syn_partition = "black_box=RAM" */
connector
The keyword connector defines a module as an interface connector between the board and the outside world. For example: /* synthesis syn_partition = "connector" */
board
The keyword board defines a module as a board. For example: /* synthesis syn_partition = "board" /*
route
The keyword route defines a routing chip. For example: /* synthesis syn_partition = "route=IQ240BMQ304L" */
syn_noprune Directive
The syn_noprune directive uses a boolean value (1/0). Use syn_noprune = 1 in module declarations for board-level black boxes, connectors, and routing chips to prevent the unused logic from being pruned during technology mapping. For example: /* synthesis syn_noprune = 1 */
syn_speedgrade Directive
Use this directive with individual FPGA module instantiations within a board module definition to denote FPGA speed grade. For example: /* synthesis syn_speedgrade = "-2" */
syn_black_box Directive
Use this directive with individual black box, connector, and routing chip module definitions. For example: /* synthesis syn_black_box */
LO
Board Trace Delays
Board Trace Delays

Certify supports board-specific trace delays defined in a trace delay (tdv ) file. For a number of the predefined HAPS boards, the tdv file is provided and is included in the /lib/board/haps directory. For custom boards, the tdv file containing the delay information must be created by the user. This file is associated with the individual module descriptions in the board (vb) file through an attribute. Delay information from the file is read by the Certify tool and is used to annotate the selected nets in the design with the delay information before the design is passed to the Synplify Premier mapper for synthesis. Input Design Board
.srs .srs .prt .tra
P Plan
Trace Delay File

.tdv
Annotated file with delay values on external nets

.srp
Mapper
.srm
Figure 25-1: Modified flow for handling trace delays
Board Trace Delays
Board Trace Delay File Format

A Tcl file format is used to specify the delay values for traces on boards. The Tcl commands, which make up the board trace delay file, are explained in the following sections.
Start and End Board Trace Delay File Commands

The start_board_delay and end_board_delay commands announce the beginning and ending of trace delay information for a board module; the trace delays are specified by Tcl commands included between these two commands.
The start_board_delay command announces the beginning of the trace

delay descriptions for a board module. start_board_delay boardName The boardName argument is the name of the module in the board (vb) file to which the ensuing trace-delay descriptions apply.
The end_board_delay command indicates the end of the trace delay

descriptions for that board module. end_board_delay The individual delay descriptions for any board module must be enclosed between a start_board_delay command and an end_board_delay command (see the Trace Delay File Example, on page 817).
Simple Trace Delay Command

The define_trace_delay command is the simplest form of a delay value command. The command includes two arguments as shown in the syntax below: define_trace_delay -terminal terminalPin -delay value The -terminal argument identifies one of the trace terminal pins. This pin can be a pin on the FPGA itself or a top-level port on a board (i.e., a connector pin). Terminal trace pins are always single-bit. LO The -delay argument specifies the delay value for the trace. Value is a real number which is always in nanoseconds.
Board Trace Delays
Using Qualifiers
By definition, a trace terminal port is the terminal inside the definition of module, and a trace terminal pin is an instance that is connected to the outside world. To avoid any ambiguity between a terminal pin and a terminal port, the following prefix qualifiers are used:
b: qualifies a terminal as a port name t: qualifies a terminal as an instance pin name

An example of using these qualifiers is included in the section Overriding Delay Values, on page 818.
Pin-Pair Delay Command

The pin-pair delay command is an extension of the simple-delay command with the added capability of defining different delays between different pin/port pairs of a trace. The pin-pair delay command syntax is: define_trace_delay -src_terminal {pin1[,pin2]} -dst_terminal {pin3[,pin4]} -delay value The direction of the signal is explicitly taken from source terminal to destination terminal (a delay value for a signal that actually flows from destination terminal to source terminal is ignored). For example, the command below specifies a delay of 10.4 nanoseconds from pin1 to pin3. define_trace_delay -src_terminal {b:pin1, b:pin2} dst_terminal {b:pin3, b:pin4} -delay 10.4 An automatic expansion of the command also indicates that the specified delay value applies to the other combinations of source-destination pairs (i.e., pin1->pin4, pin2->pin3, and pin2->pin4). Accordingly, for every set of source-destination pins on a trace that has a different delay, a separate command must be used (i.e., if the pin1->pin2 delay is different from the pin1->pin3 delay, two separate commands must be used. The -src_terminal and -dst_terminal arguments in the command are optional and, when excluded, are interpreted as follows:
Excluding the -dst_terminal argument causes the delay value to be used

as the default delay when the specified pin acts as a signal source. define_trace_delay -src_terminal {pinName} -delay value
Board Trace Delays
Excluding the -src_terminal argument causes the delay value to be used

as the default delay when the specified pin acts as the signal destination. define_trace_delay -dst_terminal {pinName} -delay value
Order of Precedence for Delay Values

An order of precedence exists among the redundant delay data available through different formats of the trace delay commands. The order of precedence, from highest to lowest, is as follows: 1. Delays specified on a pair of source-destination terminals in a pin-pair command. 2. The delay specified on a source terminal through a default source terminal. 3. The delay specified on a destination terminal through a default destination terminal. 4. The delay data available through a simple trace delay command.
Handling of Hierarchical Boards

With hierarchical boards, the Certify tool expects that it has the delay information for each board in a file. The definitions for multiple board files can be specified within a single trace delay file provided that the definitions follow the defined syntax. Note that a trace delay file can only contain descriptions of modules that are included in board files; a delay description for a module that has not been instantiated in a board file results in an error. When there are descriptions of modules in multiple board files for a single trace delay file, the file path can be specified in any module. When multiple trace delay files are used, each file is evaluated only once in a command-by-command order. On hierarchical boards, the connections among FPGAs are either directly connected or connected through connector boards. For traces that are connected directly between two FPGA devices, the delay is specified with individual hierarchical ports names (i.e., the port of a device, connector, or black box that can be seen physically as a pin on the device) as shown in the LO following example. define_trace_delay src_terminal {t:fpga_a.pin_A18} dst_terminal {t:fpga_b.pin_A19} delay 10.9
Board Trace Delays
Similarly, when FPGAs are connected to connector-board or black-box instances, the delay specified is between the ports of a connector instance and an FPGA instance. define_trace_delay src_terminal {t:fpga_a.pin_A18} dst_terminal {t:con1.pin_A19} delay 10.9 With hierarchical boards, the Certify software totals the values on the independent traces separated by the hierarchy until a black box or other element such as a buffer or inverter is encountered on the path.
Overriding Trace Delay Values

Generally, delay values are associated with the module definition of each board. These delay values are then taken for every instance of the board. When required, the delay values of a particular signal in a given instance can be modified by specifying the complete hierarchical name of the terminal using the following command syntax: define_trace_delay -src_terminal {sourceTerminal} -dst_terminal {destinationTeminal} -delay value Similarly, complete hierarchical terminal names can be used with the simple delay command. An example at the end of this section will prove helpful in understanding this delay-value modification.
Trace Delay File Information

Trace delay file information can be passed to a project in one of two ways:.
For custom defined boards, you can use the board_trace_delay_file

attribute to associate the trace delay file path with the module description of the board. The attribute name must be followed by the absolute path of the associated trace delay (tdv) file enclosed in double quotes. The '=' character separates the attribute name from the path. The path must be a valid absolute or relative path for the given operating system. /* synthesis board_trace_delay_file = "path" */ The board_trace_delay_file attribute, when applied to a module, is valid only if the same module has also been defined as a board with the syn_partition attribute. The Board Description File Example, on page 816 shows the correct use of the board_trace_delay_file attribute.
Board Trace Delays
The trace delay files for a number of the Synopsys-defined HAPS boards
are provided. The Certify tool automatically includes the corresponding trace delay file by inferring the path in the board file. Note: The trace delay file specifies the delay for traces only and all delay values defined are, by default, in nanoseconds. Delay commands are overriding in that a delay command that occurs later overrides the effects of any previous delay command.
Board Description File Example

/* custom_board.vb.*/ module CON_2X1( pin_1 , pin_2); /*synthesis syn_partition="board"*/ inout pin_1; inout pin_2; tran(pin_1,pin_2); endmodule module my_board(); /*synthesis syn_partition="board"*/ /*synthesis board_trace_delay_file = "C:\ asic_project\board\custom_board.tdv" */ wire _c1_B, _c1_B4; wire _c1_A_B; wire _c1_A, c1_A4; wire _c2_C; wire _c2_A_C; CON_2X1 conn2(.pin_1(_c1_A4),.pin_2(_c1_B4)); XCV100BG256 device_A /* synthesis syn_speedgrade="-4" */ ( .pin_A2(_c1_A), .pin_A3(_c1_A_B), .pin_A4(_c1_A4), . . . ); LO
Board Trace Delays
XCV100BG256 device_B /* synthesis syn_speedgrade="-4" */ ( .pin_A2(_c1_A_B), .pin_A3(_c1_B), .pin_A4(_c1_B4), . . . ); endmodule
Trace Delay File Example

The following is an example of a custom board trace delay file for the module my_board referenced in Board Description File Example, on page 816. start_board_delay CON_2X1 /* Delay Description for connector board*/ define_trace_delay terminal {b:pin_1} delay 10.4 define_trace_delay src_terminal {b:pin_1} dst_terminal {b:pin_2} 3.4 end_board_delay start_board_delay my_board /* Delay Description for top level board*/ define_trace_delay terminal {t:device_A.pin_A4} delay 12.34 define_trace_delay src_terminal {t:device.pin_A4} dst_terminal {t:device_B.pin_A4} delay 2.34 define_trace_delay terminal {t:device_A.pin_A2} delay 23.43 define_trace_delay terminal {t:device_B.pin_A3} delay 12.32 end_board_delay In the above example, the delay value from device_A.pin_A2 to device.pin_A3 through connector conn1 is one of the following:
When the signal flows from b:pin_1 to b:pin_2, the delay value is:
23.43 + 12.32 + 3.4 = 39.15 ns
When the signal flows from b:pin_2 to b:pin_1, the delay value is:
23.43 + 12.32 + 10.4 = 46.15 ns
Board Trace Delays
Overriding Delay Values

The above delay values are associated with every instance of CON_2X1. If required, a delay value can be modified for a given instance as shown in example below. start_board_delay my_board /* Delay Description for top level board*/ ... ... define_trace_delay -terminal {b:conn1.pin_1} -delay 1.2 ... ... end_board_delay Note: Pin conn1.pin_1, when prefixed with b:, unambiguously identifies the net connected to the port inside. If con1.pin_1 is prefixed with t:, the delay of the net connected to the outside terminal of CON_2X1 is modified (i.e., _c1_A). When overriding the delay, you must give the full hierarchical path to the terminals to identify the correct signal.
LO
Board Routing Files
Board Routing Files

A board routing file provides information about the physical traces that must be present to complete the routing of a partitioned board. This file is generated automatically when the partitioner is run on a fully partioned design. The information in the file includes both the FPGA-to-FPGA and FPGA to toplevel port interfaces. The board routing file is processed by the board vendor to determine feasability and to create a complete board description file to replace the initial dummy file created by the Certify board wizard.
File Format
A board routing file entry consists of a single line. Any line that begins with a number sign (#) is a comment and is normally disregarded by any reader or compiler. All other lines start with an asterisk (*) followed by one of the following alpha characters: P, N, J, K, T, or C to denote the entry type. Note that the synatx is not case sensitive. The syntax of the lines of type P, N, J, or K is: *type numberTraces FPGA_1 IO_direction_1 [ FPGA_2 IO_direction_2 ] The format of the lines of type T or C is: *type signalName FPGA_1 IO_direction_1 [ FPGA_2 IO_direction_2 ] In the above syntax lines, type is defined as follows: Type P N J K T C Meaning
Net traces connected to a top-level port Net traces between top-level FPGAs only Clock net traces connected to a top-level port Clock net traces between top-level FPGAs only Single net connected to a top-level port and an FPGA or between top-level FPGAs Single clock net connected to a top-level port or a single net between top-level FPGAs
Board Routing Files
In the syntax definitions:
numberTraces the number of traces (line types P, N, J, and K). signalName the name of the net or trace (line types T and C). FPGA_n the name of the FPGA or black box that the net or trace is
connected to.
IO_direction_n the IN, OUT, or INOUT direction of the net, trace, or

traces for the corresponding FPGA.
Example Extract of a File

#Certify Version 8.2 - Board Routing File - Do not Edit #Generated on: October 13th , 2005 #Modules: U4 U3 U2 U1 #Number of modules = 4 *T PC[0] U4 IN U3 IN U2 OUT *T PC[1] U4 IN U3 IN U2 OUT *T PC[2] U4 IN U3 IN U2 OUT *T PC[3] U4 IN U3 IN U2 OUT *T PC[4] U4 IN U3 IN U2 OUT *T PC[5] U4 IN U3 IN U2 OUT *T PC[6] U4 IN U3 IN U2 OUT *T PC[7] U4 IN U3 IN U2 OUT [] *T ALUB_SEL[0] U2 OUT U1 IN *T ALUB_SEL[1] U2 OUT U1 IN *N 11 U4 U3 U2 *N 12 U4 U1 *J 2 U3 U2 U1 *N 13 U3 U1 *N 8 U3 U2 U1 *N 52 U2 U1 *P 24 U2 U1 #End of BRF.
Delimiter
The default delimiter is a space. To change the delimiter, set the brf_delimiter environment variable to string. LO
Board Routing Files
Board Routing File Flow

The following steps outline the board routing flow. 1. Use the board wizard to create a dummy board file with the specified number of FPGAs. 2. Compile the board file (compile and estimate design). 3. Completely partition the design into the available FPGAs. 4. Run the partitioner to create the board routing file (designName.brf). 5. External to Certify, copy over the board routing file and run the vendor board routing program to create a Certify board (vb) file. 6. Replace the board file in the project with the vendor board file and optionally perform trace assignment. Note: If the board file cannot be successfully generated from the board routing file, it may be necessary to use CPM to limit the required number of traces or to repartition the design to change the routing requirements.
Board Routing Files
LO
APPENDIX A
Board Description File Example

The following is the Verilog board description file (vb) for the tutorial design used in this manual. The board description file is a user-created file that instantiates devices on the board and defines board connectivity. For information on creating board description files, see Chapter 25, Board Description Files. // Certify 5.0 tutorial board file // Written on 5/25 // Copyright Synplicity ìnclude "xilinx/plandata/xcv1000bg560.v" module MEMORY (DATA_IN, DATA_OUT, MEM_RD, MEM_WR) /* synthesis syn_black_box */ /* synthesis syn_partition = "black_box=RAM" */ /* synthesis syn_noprune = 1 */ ; input MEM_RD, MEM_WR; input [63:0] DATA_IN; output [63:0] DATA_OUT; endmodule module CLOCK_GENERATOR (CLK, RESET); /* synthesis syn_black_box */ /* synthesis syn_partition = "black_box=CLOCK_GENERATOR" */ /* synthesis syn_noprune = 1 */ inout CLK, RESET; endmodule
: Board Description File Example
module SYSTEM_INTERFACE (R_DATA_IN, S_DATA_OUT, WR_CMD); /* synthesis syn_black_box */ /* synthesis syn_partition = "connector" */ /* synthesis syn_noprune = 1 */ inout [63:0] S_DATA_OUT, R_DATA_IN; inout WR_CMD; endmodule module SYSTEM(); /* synthesis syn_partition = "board" */ wire wire wire wire wire wire wire wire [63:0] DATAIN; //FROM CONN TO U1 [63:0] DATAOUT; //FROM CONN TO U2 WR_CMD, CLK, RESET; //FROM CONN TO U1 AND U2 [63:0] STORE, RETRIEVE; //FROM RAM TO U1 OR U2 READ, WRITE; //FROM RAM TO U1 [3:0] BUNDLE1; //BETWEEN U1 AND U2 [31:0] BUNDLE2; //BETWEEN U1 AND U2 [23:0] BUNDLE3; //BETWEEN U1 AND U2
// CONNECTOR INSTANCES CLOCK_GENERATOR clock (CLK, RESET); SYSTEM_INTERFACE SysIF (DATAOUT, DATAIN, WR_CMD); // DEVICE INSTANCES XCV1000BG560 U1 /*synthesis syn_speedgrade ="-6" */ ( .pin_A2(DATAIN[63]), .pin_A3(DATAIN[62]), .pin_A4(DATAIN[61]), .pin_A5(DATAIN[60]), . . . .pin_AF29(DATAIN[3]), .pin_AF30(DATAIN[2]), .pin_AF31(DATAIN[1]), .pin_AF32(DATAIN[0]), .pin_AG2(WR_CMD), .pin_AG4(CLK), .pin_AG5(RESET), .pin_AG29(READ), .pin_AG30(WRITE), .pin_AG33(STORE[63]), .pin_AH1(STORE[62]), LO .pin_AH3(STORE[61]), .pin_AH4(STORE[60]), .
. . .pin_AK31(STORE[3]), .pin_AK32(STORE[2]), .pin_AL1(STORE[1]), .pin_AL4(STORE[0]), .pin_AL5(BUNDLE1[3]), .pin_AL6(BUNDLE1[2]), .pin_AL7(BUNDLE1[1]), .pin_AL8(BUNDLE1[0]), .pin_AL9(BUNDLE2[31]), .pin_AL10(BUNDLE2[30]), .pin_AL11(BUNDLE2[29]), . . . .pin_AM16(BUNDLE2[2]), .pin_AM17(BUNDLE2[1]), .pin_AM18(BUNDLE2[0]), .pin_AM20(probeU1_1), .pin_AM22(probeU1_2), .pin_AM23(probeU1_3), .pin_AM24(probeU1_4), .pin_AM26(probeU1_5), .pin_AM27(probeU1_6), .pin_AM29(probeU1_7), .pin_AM30(probeU1_8), .pin_AM31(BUNDLE3[23]), .pin_AN3(BUNDLE3[22]), .pin_AN6(BUNDLE3[21]), . . . .pin_B10(BUNDLE3[2]), .pin_B11(BUNDLE3[1]), .pin_B16(BUNDLE3[0]), .pin_B22(), .pin_B24(), .pin_B25(), . . .
XCV1000BG560 U2 /*synthesis syn_speedgrade = "-6" */( .pin_A2(DATAOUT[63]), .pin_A3(DATAOUT[62]), .pin_A4(DATAOUT[61]), .pin_A5(DATAOUT[60]), . . . .pin_AF29(DATAOUT[3]), .pin_AF30(DATAOUT[2]), .pin_AF31(DATAOUT[1]), .pin_AF32(DATAOUT[0]), .pin_AG2(WR_CMD), .pin_AG4(CLK), .pin_AG5(RESET), .pin_AG29(), .pin_AG30(), .pin_AG33(RETRIEVE[63]), .pin_AH1(RETRIEVE[62]), .pin_AH3(RETRIEVE[61]), .pin_AH4(RETRIEVE[60]), . . . .pin_AK31(RETRIEVE[3]), .pin_AK32(RETRIEVE[2]), .pin_AL1(RETRIEVE[1]), .pin_AL4(RETRIEVE[0]), .pin_AL5(BUNDLE1[3]), .pin_AL6(BUNDLE1[2]), .pin_AL7(BUNDLE1[1]), .pin_AL8(BUNDLE1[0]), .pin_AL9(BUNDLE2[31]), .pin_AL10(BUNDLE2[30]), .pin_AL11(BUNDLE2[29]), . . . .pin_AM16(BUNDLE2[2]), .pin_AM17(BUNDLE2[1]), .pin_AM18(BUNDLE2[0]), .pin_AM20(probeU2_1), LO .pin_AM22(probeU2_2), .pin_AM23(probeU2_3), .pin_AM24(probeU2_4), .pin_AM26(probeU2_5),
.pin_AM27(probeU2_6), .pin_AM29(probeU2_7), .pin_AM30(probeU2_8), .pin_AM31(BUNDLE3[23]), .pin_AN3(BUNDLE3[22]), .pin_AN6(BUNDLE3[21]), . . . .pin_B10(BUNDLE3[2]), .pin_B11(BUNDLE3[1]), .pin_B16(BUNDLE3[0]), . . . .pin_Y29(), .pin_Y30(), .pin_Y32() ) ; MEMORY RAM ( STORE, RETRIEVE, READ, WRITE ); endmodule
LO
APPENDIX B
Filename Extensions
Certify Files
Certify loads, creates and/or updates a number of files. When you create a Certify project, a virtual directory structure is automatically created in the Certify Project view that arranges the files according to:
Design language Board Constraints Partition (RTL logic assignments to physical devices) Pin assignments Certify implementation results
To list all of the files available in the Project view, select Options->Project View Options and check the Show all files in results directory box. For information on specific files, see:
Input Files, on page 830 Output Files, on page 831
: Filename Extensions
Certify Files
Input Files
This section lists the file name extensions of the input files and briefly describes their functions.
.prj a repository for all the information required to complete a design.

This file is in Tcl format and contains references to source files, compile, mapping, and simulation options, specifications for the target device, and frequency constraints.
.ptf a prototyping tool file. This file is used for storing bit-slicing information.
.sdc optional, user-specified constraint file. This file contains information on constraints that you can set for design objects such as clock, clock period, I/O delay, multi-cycle paths and so on.
.tcl a Tcl script file. .vb a board description file. This file describes the board in terms of
FPGAs, board-level black boxes, connectors, and routing chips. A board wizard is available to help create this file.
.vhd/.v VHDL or Verilog source files
LO
Certify Files
Output Files
Certify outputs these files to a results directory. (You can specify the name of this directory when you set the options for an implementation).
.acf Altera assignment and configuration file for MAX+PLUS II;

contains all of the constraints for the design.
.brf board routing file; describes FPGA-to-FPGA and top-level port to

FPGA interface for Certify-defined board.
.edf design netlist in the format of the target place and route tool. .est area estimation file; contains an estimate of the area for each of
the modules in the design. This information is displayed in the RTL and Technology views.
.fse finite state machine status file. Lists the encoding type and
transition states for all state machines in the design.
.info information file (for example, the fsm.info file contains state
transition information for a finite state machine).
.ncf Xilinx netlist constraint file; contains all of the constraints for the
design.
.pmf pin mapping file. A user-defined file that defines the pin mapping
between a Certify device and a vendors schematic symbol.
.prj project files created for each device when source-level partitioning
is enabled (when Generate SLP Mixed Projects or Generate SLP Database Projects is checked on the Implementation Results panel). Files are in Tcl format and contain references to source and constraint files, and device options.
.prt partition file. You create the prt file when you interactively assign
logical blocks to physical devices in the Partition view.
.rpt report file. Report files are generated as a result of running an

explicit command or algorithm (for example, running Trace DRC Report from the Partition view generates the drc.rpt file on trace utilization).
.sap annotated properties file. Contains encoded annotated design

properties generated after compilation.
.sdc output constraint file. Output constraint files, when enabled, are
generated for timing and pin locations for each physical device.
Certify Files
simfiles an ASCII file that lists the Verilog or VHDL files in the
synthesis_files directory. Either Generate SLP Mixed Projects or Generate SLP Database Projects must be checked on the Implementation Results panel.
.srd encrypted intermediate netlist file; when running timing analysis

on SLP database, individual srd files are referenced through attributes.
.srl netlist after RTL design compilation; this file contains the internal
representation of the design.
.srm output by the mapper stage of the process, contains the actual
technology-specific mapped design. This is the representation displayed through the technology view.
.srp partitioned netlist viewable in the technology view. .srr log files. The design.srr file contains all warnings and errors
encountered during synthesis as well as performance information such as clock frequency, critical paths and run times. There is also information regarding resource utilization, such as: I/Os, RAM blocks, LUTs/Registers or L-Cells. This is the file displayed when you click on the View Log button in the Project view. The estimation.srr file contains the information on area estimates for the design.
.srs contains the RTL (schematic) view of the design; this is the representation after initial optimization (between the compiler and mapper phases)
.srx cross reference file; contains the name mapping for modules
between the EDIF netlist and the RTL view (for Altera).
.tcl Altera assignment and configuration file for Quartus; contains all
of the constraints for the design.
.tlg a log file that lists all of the modules compiled into the design. .tra trace assignment file. Created after you partition your design
when you perform net-to-trace assignments.
.v device-level Verilog source file. These files are generated for each
device in the synthesis_files directory when source-level partitioning is enabled (when Generate SLP Mixed Projects or Generate SLP Database Projects is checked on the Implementation Results panel).
.vhd device-level VHDL source file. These files are generated for each
LO device in the synthesis_files directory when source-level partitioning is enabled (when Generate SLP Mixed Projects or Generate SLP Database Projects is checked on the Implementation Results panel).
Certify Files
.vhm VHDL output files resulting from the mapping process. One vhm
file is generated for each device and one vhm file is generated for the entire design (system.vhm) when Write Mapped VHDL Netlist is checked on the Implementation Results panel. These files are used by third-party tools for simulation/verification of the mapper output.
.vhp The VHDL netlist for the partitioned design (system.vhp). Generate
SLP Mixed Projects or Generate SLP Database Projects must be checked on the Implementation Results panel.
.vm Verilog output files resulting from the mapping process. One vm file
is generated for each device and one vm file is generated for the entire design (system.vm) when Generate SLP Mixed Projects or Generate SLP Database Projects is checked on the Implementation Results panel. These files are used by third-party tools for simulation/verification of the mapper output.
.vp The Verilog netlist for the partitioned design (system.vp). Generate
SLP Mixed Projects or Generate SLP Database Projects must be checked on the Implementation Results panel.
.vqm Altera design netlist for Quartus place and route.
Certify Files
LO
APPENDIX C
Project Conversion
This appendix is included to describe how to convert projects created with Certify releases prior to the C-2009.09 release.
Conversion Script
The current release includes a script for converting projects created with releases prior to the Certify C-2009.09 release. The script is named prototyping_conversion.tcl and is included in the lib directory. The script includes four individual routines.
Loading the Script

To enable the conversion script, source the script from your project as follows: 1. Open the existing project to be converted in Certify C-2009.09. 2. From the project directory, source the script file by entering the following at the Tcl window prompt: source $LIB/prototyping_conversion.tcl In the above command, the $LIB environment variable is used to avoid a space in the installation path when Certify is installed in Program Files.
: Project Conversion
Conversion Script
Note: The script is only active for the current Certify session. To verify if the script is in place, enter the following command at the Tcl prompt: conv_par If the message wrong # args: should be "conv_par inpfile outfile" is displayed, you have installed the script successfully; if the message invalid command name "conv_par" is displayed, the script is not accessible from Certify.
Converting Projects
To convert an existing pre-2009.09 Certify project and its corresponding par and paf files, execute the following command from the Tcl prompt: conv_prj preCentaurus.prj newCentaurus.prj [0 | 1] The script calls all of the necessary individual conversion routines for converting the existing par and paf files. The conv_prj script makes the following assumptions:
a single par/paf file pair per project file the script must be run from the same root directory as the prj file to be
converted
if the target board file for the project is a HAPS board, the numeric
argument must be 1.
LO
Conversion Script
After executing conv_prj script, load the converted project.
Enter project -load newCentaurus.prj at the Tcl prompt. In the Project Management section, execute Run Preparation to generate
the design and board netlist srs files.
In the Partition Management section, select Load Database and make sure
that the Load Prototyping Commands check box is selected.
Referenced Routines
The following routines are called automatically by the conv_prj script. The routines are not intended to be run individually, and their descriptions are included only for reference.
conv_par Routine
The conv_par routine converts a par partition file from a previous Certify release to a C-2009.09-compatible prt partition file using the following syntax: conv_par inputFilename.par outputFilename.prt In the syntax, inputFilename is the name of the source (existing) par partition file and outputFilename is the name of the C-2009.09-compatible prt file to be generated. The conv_par routine generates a new file (outputFilename.prt) containing the logic_place Tcl command equivalents. The following examples show the original partition file for the tutorial design (commchip.v) and the resulting, C-2009.09-compatible partition file.
Conversion Script
Original (pre-C-2009.09) Partition File
Script-generated Partition File
LO
Conversion Script
conv_cpm Routine
The conv_cpm routine creates a C-2009.09-compatible CPM file (cpm) from information in existing partition and pin-assignment files (the C-2009.09 release generates CPM information in a single cpm file). The routine uses the following syntax: conv_cpm inputPartitonName.par inputPinAssignName.paf outputFilename.cpm In the syntax, inputPartitionName.par and inputPinAssignName.par are the names of the source (existing) partition and pin-assignment files. The order of these files can be reversed. OutputFilename.cpm is the name of the C2009.09-compatible cpm file to be generated. The conv_cpm routine generates a new file (outputFilename.cpm) containing the cpm_place Tcl command equivalents.
conv_paf Routine
The conv_paf routine converts a pin-assignment (paf) file from a previous release to a C-2009.09-compatible trace-assignment (tra) file using the following syntax: conv_paf inputFilename.paf outputFilename.tra In the syntax, inputFilename.paf is the name of the source (existing) pinassignment file and outputFilename.tra is the name of the C-2009.09-compatible trace-assignment (tra) file to be generated. Note that because the names of board traces differ, auto-trace assignment is used during the conversion. If, following the conversion, the trace assignments are not as desired, you must make the trace assignments manually. The conv_paf routine generates a new file (outputFilename.tra) containing the net_place Tcl command equivalents; conversion problems are reported in the Tcl window.
Conversion Script
conv_paf_trace Routine
The conv_paf_trace routine converts a pin-assignment (paf) file from a previous release to create a C-2009.09-compatible net-placement assignment list using the following syntax: conv_paf_trace inputFilename.paf outputFilename.tra In the syntax, inputFilename is the name of the source (existing) pin-assignment file and outputFilename is the name of the C-2009.09-compatible net placement assignment list to be generated. The conv_paf_trace procedure generates a new file (outputFilename.tra) containing the net_place Tcl command equivalents; conversion problems are reported in the Tcl window.
LO
APPENDIX D
Top-down Conversion
This appendix is included to describe how to convert existing projects that were developed using the now obsolete top-down methodology to the SLP project flow. For designs completed with the top-down methodology, the original partition file, pin-assignment file, and any CPM data from these two files must be converted to the D2009.09-release format. Note: The partitioned netlist (srp) file from the top-down project is no longer valid.
Project Conversion in the GUI

To convert a top-down project to individual D-2009.09-compatible SLP projects using the Graphical User Interface (GUI): 1. Open the existing top-down project in the current D2009.09 release. 2. From the project directory, run the prototyping_conversion.tcl script (Run->Run Tcl Script).
: Top-down Conversion
3. Convert the existing partition (par ) and pin-assignment (paf) files to the D2009.09 format using the conv_par and conv_paf_trace conversion script procedures, respectively (see Appendix C, Project Conversion). If the existing design uses CPM, run the conv_cpm procedure to create a standalone cpm file. Note: If your design uses a HAPS board, the trace assignments normally will not match; use the conv_paf procedure and perform trace assignment manually. 4. Select Load Database in the Partition Management section or click the Load board and netlist files icon in the menu bar to bring up the Load Prototyping Files dialog box. 5. Select the Custom Load tab and, in the Partition Commands section, enter the names of the converted partition and pin-assignment files and, if present, the CPM file.
6. Click the Load All button to load the files. The files loaded are listed in the display area. Click the Close button to close the dialog box. 7. Use the Partition View and Trace Assignment buttons in the Partition Management section to view the conversion results. 8. Click the SLP Generation LO button in the SLP Management section.to open the SLP Generation dialog box.
9. In the dialog box, enter the name of the post-partition result file, check the appropriate SLP generation options, and then click the Execute button to generate the individual SLP projects.
The individual SLP projects are generated and listed under the implementation. Right-click on a project and select Synthesize SLP Project to synthesize the project in Synplify Premier.
Project Conversion Tcl Commands
Project Conversion Tcl Commands

The following is a simple Tcl command sequence for converting a top-down design to individual SLP projects. // load the existing 9.2 project project -load C:/DesignsII/comm3a/proj_1.prj // source the conversion script source C:/tools/certd200909/lib/prototyping_conversion.tcl // convert the existing files conv_par partition1.par new_partition1.par conv_paf_trace partition1.paf new_partition1.paf // load the board and netlist files load_board {C:\DesignsII\comm3a\rev_2\commboard.srs} load_netlist {C:\DesignsII\comm3a\rev_2\commchip.srs} // load the area estimation file load_estimate_file -area {C:\DesignsII\ comm3a\rev_2\commchip.est} // source the converted files source {C:\DesignsII\comm3a\new_partition1.par} source {C:\DesignsII\comm3a\new_partition1.paf} // run SLP generate slp_generate C:/DesignsII/comm3a/ commchip_proto_files/commchip_sm_srpar.srp -hdl // launch the SLP project in synthesis tool project_launch C:/DesignsII/comm3a/rev_2/ synthesis_files/U1/U1_srs.prj
-database
LO
Index
See also RAMs multi-port LPM megafunction example (Verilog) 437 LPM megafunction example (VHDL) 439 multi-port RAMs 410 P&R file for untranslated settings 739 packing I/Os 664 PLLs. See altplls Quartus batch mode 670 Quartus integrated flow 669 Quartus interactive flow 670 simulating LPMs 667 Stratix III LUTRAMs 411 Stratix RAM 405 Verilog LPM library 442 Altera MegaWizard generating LPM files 437 altpll component declaration files 663 constraints 663 using 663 altshift_tap, set implmentation style 431 ALTSYNCRAM for LPMs 437 ALTSYNCRAM, Altera Stratix 405 archiving projects 120 custom file list 124 FTP site 123 area bias QPT 155 area estimation 144 area, optimizing 563 asterisk wildcard Find command 346 attr_applied.sdc file 739 attr_unapplied.sdc file 739 attributes adding 101, 110 adding in constraint files 58 adding in SCOPE 106, 113 adding in Verilog 103, 112
845
Symbols
.acf file 61 .cdc file specifying attributes and directives 104 .edf file 678 .ini file setting preferences from the UI 329 .ncf file 61 .ndf file 678 .sdc file 607 .vhm file 702 .vqm file Clearbox 724 _conv.prj file 654 _conv.sdc file 654
A
Actel I/O pad type 620 Adder/Subtractor compiling with SYNCore 507 adders wide. See wide adders/subtractors. Alt key column editing 46 mapping 353 Altera Clearbox. See Clearbox design tips 662 grey box See grey box I/O packing 664 instantiating LPMs as black boxes 437
adding in VHDL 102, 111 collections 634 CPM 266 for FSMs 396, 581 syn_resources 382 syn_timing_estimation_effort 769 syn_trace_attr 213 VHDL package 102, 111 attributes in.cdc file 104 auto constraints, using 645 automatic partitioning 149, 156 automatic trace assignment 222
B
B.E.S.T 357 backslash escaping dot wildcard in Find command 346 Behavior Extracting Synthesis Technology. See B.E.S.T bit slicing 176 guidelines 182 legal primitives 182 black boxes 382 adding constraints 387 CPM net qualification 256 defined 382 EDIF naming consistency 392 for IP cores 678 gated clock attributes 594 internal area 382 pin attributes 392 prepared component method (Altera) 441 specifying timing information for Xilinx cores 678 support 382 trace assignments 222 Verilog 383 VHDL 384 block RAM dual-port, mapping with registered address 413 glue logic in 414 mapping dual port coding style 419 mapping ROM (Xilinx) 420 mapping to single-output dual-port 419 mapping to single-port 417
846
single-port mapping with registered address 413 using registered addresses 412 using registered output 415 board description file 793 directives 808 format 807 naming restriction 803 board description file example 816 board modules 794 board resources 293 board routing file 819 board view 199 editing 202 manual layout 201 saving custom 204 board wizard 798 limitations 806 board_define_attribute 231, 233, 238 boards partitioning pre-defined 149, 156 bookmarks in source files 46 using in log files 752 breaking up large primitives 176 browsers 334 buffering crontrolling 571 BUFG clock priority 630 for fanouts 572 BUFGDLL 697 BUFGMUX clock priority 630 BUFGMUX_1 inference 693 bus traces capacity 193 properties 193 buses assigning to probes 780 INIT values for bits 685 RLOC values for bits 696 byte-enable RAMs SYNCore 485
Index
C
c_diff command, examples 637 c_intersect command, examples 637 c_list command different from c_print 642 example 644 using 643 c_print command different from c_list 642 using 643 c_symdiff command, examples 637 c_union command, examples 636 callback functions, customizing flow 309 case sensitivity Find command (Tcl) 639 cdc file syntax 105 Certify Pin Multiplexer, see CPM Clearbox adding instantiated file 723 implementing megafunctions with 715 inferring megafunctions 716 instantiating megafunctions 720 instantiating with netlist 722 using 715 using instantiated netlists in Quartus 724 clock buffers 697 clock constraints edge-to-edge delay 613 false paths 627 setting 613 clock DLLs 697 clock domains setting up 618 clock generation modules 278 clock groups effect on false path constraints 627 for global frequency clocks 615 Xilinx DCMs and DLLs 617 clock path skew (Synplify Premier) 765 clock skew (Synplify Premier) 765 clock skew example (Synplify Premier) 698, 699 clock synchronization 273 global reset 280
clock trees 768 clocks asymmetrical 616 defining 614 for DCMs and DLLs 617 for PLLs 617 frequency 616 gated. See gated clocks gated. See gated clocks. HSTDM considerations 241 implicit false path 627 limited resources 618 overriding false paths 627 primary 276 collections adding attributes to 634 adding objects 636 concatenating 636 constraints 634 copying 643 creating from common objects 636 creating from other collections 633 creating in SCOPE 632 creating in Tcl 635 crossprobing objects 633 definition 631 diffing 636 highlighting in HDL Analyst views 641 iterating through objects 643 listing objects 643 listing objects and properties 642 listing objects in a file 643 listing objects in columnar format 642 listing objects with c_list 642 special characters 638 Tcl window and SCOPE comparison 631 using Tcl expand command 640 using Tcl find command 638 viewing 641 color coding bus traces 193 impact analysis 163 colors in text files 49 column editing 46 commands netlist editing 318 slice_primitive 176 comments characters for, in text files 49
847
source files 46 compiler directives (Verilog) specifying 90 connectivity viewing 369 connectivity matrix 369 displaying 187 filtering 370 hidden nets 369 hiding 187 toggling 369 Connectivity Matrix Filter dialog box 370 constants extracting from VHDL source code 93 preserving top-level 98 constraint files 54 See also SCOPE Altera QSF 647 applying to a collection 634 colors 49 comments 49 creating in a text editor 56 creating with SCOPE 606 defining clocks 56 defining register delays 57 editing 609 fonts 50 forward-annotating 60 I/O standrads 174 opening 607 options 86 specifying through points 623 tabs 50 types of 608 vendor-specific 60 when to use 54 constraints altplls 663 black box 387 checking 60 translating Altera QSF 647 translating with ucf2sdc_old 657 translating Xilinx contraints for logic synthesis 650 context for object in filtered view 360 control pins external assignments 783 internal assignments 782
848
conversion script loading 835 routines 837 converting projects 836 CoreGen 678 cores, instantiating in Xilinx designs 678 counter compiler SYNCore 531 counters compiling with SYNCore 526 CPM attributes 266 automatic assignment 257 blocks 263 communications interface 264 design considerations 270 directives 266 manual assignment 257 moving assignments 155 net qualification 255 partitioning 252 run time 155 user interface 253 CPM elements adding to design 261 CPM fast clock estimation 260 CPM modules 263 CPM ratio QPT 154 create_instance command 320 creating board files 798 critical paths using -route 564 crossprobing 349 collection objects 633 filtering text objects for 354 from FSM viewer 355 from log file 752 from message viewer 755 from text files 352 Hierarchy Browser 350 importance of encoding style 356 paths 353 RTL view 351 Technology view 351 Text Editor view 351 text file example 353 to FSM Viewer 355
Index to place-and-route file 330 Verilog file 351 VHDL file 351 within RTL and Technology views 350 current level expanding logic from net 365 expanding logic from pin 364 searching current level and below 343 custom folders creating 71 customer support 40 customer support, contacting 40 customization callback functions 309 design size amount displayed on a sheet 330 design views moving between views 329 DesignWare building blocks 537 foundation library 537 minPower library 538 multiprocessing licenses 539 VHDL component instantiation 542 DesignWare-compatible models supported 546 Verilog 540 Verilog function inferencing 541 VHDL 541 device properties 192 dialog boxes Connectivity Matrix Filter 370 QPT Options 153 directives adding 101, 110 adding in Verilog 103, 112 adding in VHDL 102, 111 black box 388, 389, 391 board description file 808 CPM 266 for FSMs 396 specifying for the compiler (Verilog) 90 syn_asynchronous_cpm 266 syn_black_box 810 syn_cpm_control 266 syn_cpm_srcontrol 267 syn_cpm_system_clock 268 syn_cpm_type 267 syn_implement 268 syn_noprune 809 syn_partition 808 syn_speedgrade 810 syn_state_machine 580 syn_tco 388, 389, 391 syn_tpd 388, 389, 391 syn_tsu 388, 389, 391 directives in .cdc file 104 Dissolve Instances command using 373 dissolving 373 DLLs defining clocks 617
D
DCM clock priority 628 DCMs defining clocks 617 default enum encoding 93 define_attribute 109, 116 define_clock constraint 56 define_false_paths constraint 57 define_generated_clock_en attribute 603 define_input_delay constraint 57 define_multicycle_path constraint 57 define_output_delay constraint 57 define_reg_input_delay constraint 57 define_reg_output_delay constraint 57 define_trace_delay command 812 design changes source-level partitioning 283 design considerations CPM 270 design entry 36 design flow customizing with callback functions 309 design flows FPGA generic 36 design guidelines 562 design hierarchy viewing 358
849
dot wildcard Find command 346 drivers preserving duplicates with syn_keep 565 selecting 367 dual-port RAMs 410 block RAMs with single registered output, Xilinx 419 Stratix 406
E
edge detection generated clocks 603 EDIF structural, for Xilinx IP cores 678 synthesizing 700 EDIF files reoptimizing with 700 Editing window 45 EDN core 745 effort level timing estimation 769 emacs text editor 48 encoding styles and crossprobing 356 default VHDL 93 FSM Compiler 578 end board delay command 812 environment variables SYN_TCL_HOOKS 309 error messages gated clock report 596 errors definition 44 filtering 755 sorting 755 source files 44 Verilog 44 VHDL 44 Expand command connection logic 367 pin and net logic 363 using 364
expand command (Tcl). See Tcl expand command Expand Inwards command using 364 Expand Paths command different from Isolate Paths 367 Expand to Register/Port command using 364 expanding connections 367 pin and net logic 363 external ports assigning to control pins 783, 784
F
false paths defining between clocks 627 I/O paths 627 impact of clock group assignments 627 overriding 627 ports 627 registers 627 setting constraints 626 fanouts buffering vs replication 571 hard limits 571 soft global limit 570 soft module-level limit 570 using syn_keep for replicaton 566 using syn_maxfan 570 fast clock estimator 260 fast synthesis using 136 feature comparison FPGA tools 29 FIFO compiler SYNCore 451 FIFO flags empty/almost empty 460 full/almost full 459 handshaking 460 programmable 462 programmable empty 465 programmable full 463 FIFOs compiling with SYNCore 446 files
850
Index .acf 61 .ncf 61 .prf file 757 .sdc 607 altpll component declarations 663 board description 793 board description format 807 board routing (.brf) 819 creating board 798 filtered messages 758 fsm.info 579 input 830 log 750 message filter (prf) 757 output 196, 831 pin assignment (.tra) 225 rom.info 337 searching 117 selecting partition 161 simulation 285 specifying tcl 176 statemachine.info 378 synhooks.tcl 309 Tcl 306 See also Tcl commands Tcl batch script 305 technology 444 vendor 444 Filter Schematic command, using 361 Filter Schematic icon, using 362 filtering 361 advantages over flattening 361 using to restrict search 343 Find command 343 browsing with 342 hierarchical search 344 long names 342 message viewer 755 reading long names 345 search scope, effect of 346 search scope, setting 344 setting limit for results 345 using in RTL and Technology views 343 using wildcards 346 wildcard examples 348 Find command (Tcl) See also Tcl find command finding information on synthesis tool 40
Fix Gated Clocks option. See gated clocks Flatten Current Schematic command transparent instances 371 using 371 Flatten Schematic command using 371 flattening 370 See also dissolving compared to filtering 361 hidden instances 372 transparent instances 371 using syn_hier 568 fonts setting in text files 50 foreach command 643 forward annotation frequency constraints in Xilinx 672 vendor-specific constraint files 60 forward-annotation Xilinx core files 747 foundation library 537 FPGA design flow, generic 36 frequency clocks 616 defining for non-clock signals 616 internal clocks 616 setting global 85 from constraints specifying 623 FSM Compiler advantages 576 enabling 578 FSM encoding user-defined 397 using syn_enum_encoding 397 FSM Explorer 576 running 582 when to use 576 FSM view crossprobing from source file 352 FSM Viewer 376 crossprobing 355 fsm.info file 579 FSMs See also FSM Compiler, FSM Explorer
851
attributes and directives 396 defining in Verilog 393 defining in VHDL 395 definition 393 optimizing with FSM Compiler 576 properties 378 state encodings 378 transition diagram 376 viewing 376 function inferencing DesignWare-compatible models 541
GSR, Xilinx 674
H
HAPS I/O standards 172 I/O standards report 173 voltage regions 171 HAPS board configuration HSTDM 240 HDL Analyst See also RTL view, Technology view crossprobing 349 filtering schematics 361 Push/Pop mode 337, 339 traversing hierarchy with mouse strokes 335 traversing hierarchy with Push/Pop mode 337 using 357 HDL Analyst tool deselecting objects 327 selecting/deselecting objects 326 HDL Analyst views highlighting collections 641 hidden instances consequences of saving 359 flattening 372 restricting search by hiding 343 specifying 358 status in other views 359 hidden nets 369 hierarchical design expanding logic from nets 365 expanding logic from pins 364 hierarchical instances dissolving 373 hiding. See hidden instances, Hide Instances command multiple sheets for internal logic 360 pin name display 362 viewing internal logic 359 hierarchical objects pushing into with mouse stroke 336 traversing with Push/Pop mode 337 hierarchical search 343 hierarchy flattening 370 traversing 334
G
gated clocks attributes for black boxes 594 conversion example 591 conversion report 595 conversion requirements 590 defining 618 error messages in report 596 examples 588 procedure for fixing 592 restrictions 598 Synplicity approach 587 generated clocks edge-detection 603 generated-clock conversion 600 generics extracting from VHDL source code 93 get_net command 320 global comments initializing Xilinx RAM 427 global optimization options 84 global reset 280 global sets/resets Xilinx designs 675 glue logic Altera Stratix RAM 405 grey box netlist file 728 grey box flow MegaCore with greybox netlist 728 grey boxes using 725 greybox flow MegaCore with IP package 731
852
Index hierarchy browser clock trees 768 controlling display 330 crossprobing from 350 defined 334 traversing hierarchy 334 HSTDM auto assignment 230 board definition 240 circuit training 244 clock considerations 241 manual assignment 232 mode enable 241 module assignment 233 net qualification 238 output reports 243 parameters 231, 233, 238 prioritizing assignments 237 trace assignment 214 training status 244 Virtex-5 resources 249 HSTDM generate 235, 239 HSTDM pin training error codes 245 HSTDM report file 245 hyper source example 708 for IPs 706 for prototyping 706 IP design hierarchy 706 threading signals 707 constraining 619 packing in Altera designs 664 packing in Xilinx designs 682 specifying pad type (Xilinx) 699 I2C commands 247 Identify debugger 791 Identify implementation 78 impact analysis 162 Impact Analysis window 162 opening 188 implementation Identify 78 implementation options device 82 global frequency 85 global optimization 84 part selection 82 specifying results 86 implementations copying 78 deleting 78 multiple. See multiple implementations. renaming 78 inference BUFGMUX/BUFGMUX_1 693 INIT property initializing Xilinx RAMs, Verilog 426 initializing Xilinx RAMs, VHDL 428 specifying with attributes 429 INITvalues Xilinx registers 684 input constraints, setting 619 input files 830 insert_buffer command 320 instance properties 195 instances preserving with syn_noprune 565 properties 323 properties of pins 324 IP cores 678 IP design hierarchy hyper source 706 IPs Altera 711 SYNCore byte-enable RAMs 485
853
I
I/O insertion 575 VHDL manual (Xilinx) 691 I/O locations assigning automatically (Xilinx) 686 manually assigning (Xilinx) 691 I/O pads specifying I/O standards 620 I/O paths false path constraint 627 I/O standards 172, 620 constraint file 174 report 173 voltage regions 172 I/Os auto-constraining 646
using hyper source for debug 706 Isolate Paths command different from Expand Paths 367, 368
K
key assignments customizing 310 keywords completing words in Text Editor 46
L
lcell primitive Clearbox 715 libraries Xilinx post-synthesis simulation 702 licenses DesignWare multiprocessing 539 limitations QPT 160 location constraints RLOC_ORIGIN 696 RLOCs with synthesis attribute 696 RLOCs with xc_attributes 694 log file gated clock conversion report 595 gated clock error messages 596 log files checking FSM descriptions 583 checking information 750 colors 49 fonts 50 setting default display 750 state machine descriptons 579 tabs 50 viewing 750 Log Watch window moving 754 resizing 754 logic expanding between objects 367 expanding from net 365 expanding from pin 364 logic preservation syn_hier 569 syn_keep for nets 565 syn_keep for registers 565
854
syn_noprune 565 syn_preserve 565 logic replication 167 logic synthesis translating UCF constraints 650 logical folders creating 71 LPM_RAM_DQ VHDL example 441 LPMs Altera megafunction example (Verilog) 437 Altera megafunction example (VHDL) 439 black box method simulation flow 667 comparison of Altera instantiation methods 436 creating synthesis projects 742 generics method, Cypress 441 including in physical synthesis 711 instantiating as black boxes 436 instantiating as black boxes (Altera) 437 instantiating with a Verilog library (Altera methodology) 437 instantiating with a Verilog library (Synplicity methodology) 442 instantiating with VHDL prepared components 441 using in Altera simulation flows 667 Verilog library simulation flow 668 VHDL prepared component simulation flow 668 VHDL prepared components instantiation example 441 LPMs, Altera 436 LUTRAMs, inferring 411
M
mac_mult primitive Clearbox 715 mac_out primitive Clearbox 715 macro libraries (Xilinx) 672 macros (Xilinx) 672 manual trace assignment 206 mapping parallel 283
Index matrix connectivity 369 MegaCore grey box flow with grey box netlist 728 greybox flow with IP package 731 Megacore IPs importing in a Quartus design 741, 742 megafunctions altplls 663 creating synthesis project 742 grey boxes 725 including in physical synthesis 711 inferring Clearbox information 716 instantiating Clearbox 720 instantiating Clearbox with netlist 722 using Clearbox 727 using grey box netlist 728 Megawizard altplls 663 memory usage maximizing with HDL Analyst 375 Message viewer filtering messages 755 keyboard shortcuts 755 saving filter expressions 757 searching 755 using 754 using the F3 key to search forward 755 using the Shift-F3 key to search backward 755 messages demoting 760 filtering 755 promoting 760 saving filter information from command line 758 saving filter information from GUI 757 severity levels 762 suppressing 760 writing messages to file 758 minPower library 538 mixed language files 51 restrictions 51 models DesignWare-compatible 539 modules board 794 pre-assigning in QPT 160
mouse strokes pushing/popping objects 335 multicycle paths setting constraints 614 multiple implementations 76 running from workspace 80 multi-port RAMs See also dual-port RAMs Altera Stratix 410 multisheet schematics 327 for nested internal logic 360 searching just one sheet 343 transparent instances 328 multi-terminal nets 219
N
navigating among design views 329 ncf file cores 747 output physical constraints 621 using as input for logic design 650 ncf files translating to sdc 653 netlist editing 313 commands 318 RTL-level 314 Tcl commands 318 netlist partitioning 292 nets assigning to probes 780 CPM qualification 255 expanding logic from 365 hidden 369 multi-terminal 219 preserving for probing with syn_probe 565 preserving with syn_keep 565 properties 323 selecting drivers 367 New property 325 NGC cores 745 NGO core 745 non-secure core flow synthesis 748 notes filtering 755
855
sorting 755 notes, definition 44 nram primitive. See dual-port RAMs, multi-port RAMs
O
objects finding on current sheet 343 flagging by property 324 selecting/deselecting 326 online tutorial 139 optimization for area 563 for timing 564 generated clocks 600 logic preservation. See logic preservation. preserving hierarchy 569 preserving objects 565 tips for 562 OR 625 output constraints, setting 619 output files 196, 831 specifying 86
P
p_nram primitive. See dual-port RAMs, multi-port RAMs, nram primitive package library, adding 67 pad types industry standards 620 parallel mapping 283 parameters extracting from Verilog source code 90 Partition Device view ToolTips 194 partitioning automatic 149, 156 bit slicing 176 preparing for 141 replicating logic 167 source-level 283 partitioning board view 199 path constraints false paths 626
856
pathnames using wildcards for long names (Find) 345 paths crossprobing 353 tracing between objects 367 tracing from net 365 tracing from pin 364 pattern matching Find command (Tcl) 639 pattern searching 117 PDF cutting from 46 physical constraints Xilinx output file 621 physical synthesis improve performance (Altera) 701 pin assignments saving 225 pin locations specifying (Xilinx) 686 pin names, displaying 362 pin training error codes 245 pin-assignment file (.tra) 225 pins expanding logic from 364 properties 323 reserving 225 placement definition 37 PLLs defining clocks 617 port names defining 783 port types supported in SLP 289 ports false path constraint 627 properties 323 POS interface using 623 post-synthesis simulation, Xilinx 702 pre-assigning modules 155 QPT 160 pre-defined boards
Index partitioning 149, 156 QPT flow 150, 156 QPT options 153 preferences crossprobing to place-and-route file 330 displaying Hierarchy Browser 330 displaying labels 331 RTL and Technology views 329 SCOPE 611 sheet size (UI) 330 primary clocks 276 primitives breaking up large 176 pin name display 362 pushing into with mouse stroke 336 viewing internal hierarchy 358 probe modules creating 784 probes adding in source code 584 assigning 776 assigning buses to 780 assigning nets 780 assigning to traces 225 definition 584 multiplexing 778 trace assignments 225 Product of Sums interface. See POS interface project synthesizing 788 project command archiving projects 120 copying projects 128 unarchiving projects 125 project files adding files 68 adding source files 64 creating 64 definition 64 deleting files from 68 opening 68 replacing files in 68 VHDL file order 67 VHDL library 67 projects archiving 120 converting 836
copying 128 files after importing from Quartus 739 importing from Quartus 735 restoring archives 125 properties bus trace 193 device 192 displaying with tooltip 323 finding objects with Tcl Find 639 instance 195 reporting for collections 642 viewing for individual objects 323 prototyping using hyper source threading 706 Push/Pop mode HDL Analyst 335 keyboard shortcut 337 using 335, 337
Q
QPT area bias 155 CPM ratio 154 limitations 160 pre-assigning modules 160 seeding 155 trace assignment 216 trace utilization 154 QPT Options dialog box 153 qsf importing 736 qsf file translated files for synthesis 739 qsf2sdc translating constraints 647 qsf2syn.log file 738 Quartus batch mode 670 imported settings and constraints 740 importing design with Megacore IP 741 importing design with megafunctions 742 importing LPMs 742 importing megafunctions 742 importing projects from 735 integrated flow 669 interactive flow 670 supported constraints for import 740
857
supported project settings for import 740 synthesis project files 739 using instantiated Clearbox netlist files 724 Quartus II using synthesis results to run 669 QUARTUS_ROOTDIR variable inferring Clearbox megafunctions 717 instantiating Clearbox 720 question mark wildcard, Find command 346 quick partitioner 149, 156 Quick Partitioning Technology see QPT
R
RAM inference multi-port RAMs, Altera 410 Stratix dual-port 406 ram_block primitive Clearbox 715 RAMs Altera Stratix 405 compiling with SYNCore 469 dual-port, Stratix 406 initializing 421 initializing values (Xilinx) 425 mapping LUTRAMs 411 multi-port. See dual-port RAMs, multi-port RAMs SYNCore, byte-enable 485 RAMs, inferring 398 advantages 398 Xilinx block RAMs 412 regions voltage 171 register constraints, setting 613 register packing See also syn_useioff attribute 682 Altera 664 Xilinx 682 registers false path constraint 627 INIT value 684 relative placement. See RLOCs replication controlling 571
858
report files HSTDM 245 reports gated clock conversion 595 I/O standards 173 voltage region 173 reserving pins 225 resource sharing optimization technique 563 overriding option with syn_sharing 573 results example 573 using 573 resources board 293 restrictions source-level partitioning 289 RLOC_ORIGINs specifying 696 RLOCs 694, 696 specifying with synthesis attribute 696 specifying with xc attributes 694 ROM block RAM mapping (Xilinx) 420 rom.info file 337 ROMs compiling with SYNCore 496 viewing data table 337 routing definition 37 RTL netlist editing 314 RTL Design view ToolTips 194 RTL view analyzing clock trees 768 crossprobing collection objects 633 crossprobing description 349 crossprobing from 350 crossprobing from Text Editor 352 defined 322 description 322 filtering 361 finding objects with Find 343 finding objects with Hierarchy Browser 341 flattening hierarchy 370 highlighting collections 641 opening 323
Index selecting/deselecting objects 326 sequential shift components 432 setting preferences 329 state machine implementation 579 traversing hierarchy 334 inferring 431 mapping 431 SRL16 primitives 431 Verilog 435 VHDL 434 set command collections 643 set_option command 307 sheet connectors navigating with 328 sheet size setting number of objects 330 shift register lookup table. See sequential shift components shift registers. See sequential shift components Shift-F3 key Message Viewer 755 Show Cell Interior option 358 Show Context command different from Expand 360 using 360 signals threading with hyper source. See hyper source simulation files 285 single-port RAMs block RAM with registered output, Xilinx 417 slice_primitive command 176 Slow property 325 source code crossprobing from Tcl window 355 defining FSMs 393 fixing errors 47 opening automatically to crossprobe 351 optimizing 562 specifying RLOCs 694, 696 when to use for constraints 54 source files See also Verilog, VHDL. adding comments 46 adding files 64 checking 43 colors 49
859
S
schematics multisheet. See multisheet schematics page size 330 selecting/deselecting objects 326 SCOPE adding attributes 106, 113 adding probe insertion attribute 585 assigning Xilinx pin locations 687 case sensitivity for Verilog designs 639 collections compared to Tcl script window 631 drag and drop 609 editing operations 610 I/O pad type 620 keyboard shortcuts 610 multicycle paths 626 setting constraints 606 setting display preferences 611 specifying RLOCs 694, 696 state machine attributes 396 scope of the document 23 scripts conversion 835 sdc converting from Xilinx ucf 653 search browsing objects with the Find command 342 browsing with the Hierarchy Browser 341 finding objects on current sheet 343 setting limit for results 345 setting scope 344 using the Find command in HDL Analyst views 343 secure core flow synthesis 748 See also search seeding 155 sequential shift components Altshift_tap 431
column editing 46 comments 49 copying examples from PDF 46 creating 42 crossprobing 352 editing 45 editing operations 45 fonts 50 mixed language 51 specifying default encoding style 93 specifying top level file for mixed language projects 52 specifying top level in Project view 67 specifying top-level file in the Implementation Options dialog box 93 state machine attributes 396 tabs 50 using bookmarks 46 source-level partitioning 283 restrictions 289 simulation 285 time budgeting 769 special characters Tcl collections 638 specifying levels 373 SRLs See sequential shift components standard cells 444 start_board_delay command 812 startup block (Xilinx) 674 state machines See also FSM Compiler, FSM Explorer, FSM viewer, FSMs. attributes 396 descriptions in log file 579 implementation 579 parameter and define comparison 394 statemachine.info file 378 Stratix dual-port rams 406 syn_asynchronous_cpm directive 266 syn_black_box instantiating LPMs (Altera) 437 syn_black_box directive 810 syn_cpm_control directive 266 syn_cpm_srcontrol directive 267 syn_cpm_system_clock directive 268
860
syn_cpm_type directive 267 syn_dspstyle attribute inferring wide adders/subtractors 676 syn_edif_bit_format attribute 678 syn_edif_scalar_format attribute 678 syn_encoding attribute 396 syn_enum_encoding directive FSM encoding 397 syn_forward_io_constraints attribute 60 syn_hier attribute controlling flattening 568 preserving hierarchy 569 syn_implement directive 268 syn_insert_buffer attribute BUFGMUX 693 syn_isclock black box clock pins 392 syn_keep replicating redundant logic 566 shift register inference 432 syn_keep attribute preserving nets 565 preserving shared registers 565 syn_keep directive effect on buffering 572 syn_macro white-boxing non-secure cores 748 syn_maxfan attribute setting fanout limits 570 syn_noprune directive 809 preserving instances 565 shift register inference 432 syn_partition directive 808 syn_preserve effect on buffering 572 preserving registers with INIT values 684 syn_preserve directive preserving FSMs from optimization 396 preserving logic 565 syn_probe attribute 584 inserting probes 584 preserving nets 565 syn_ramstyle attribute glue logic for Altera Stratix RAMs 405 multi-port RAM inference 402
Index preventing glue logic (no_rw_check) 414 syn_reference_clock defining non-clock signal frequencies 616 syn_reference_clock constraint 56 syn_replicate attribute using buffering 572 syn_resources attribute 382 syn_sharing directive overriding default 573 syn_speedgrade directive 810 syn_srlstyle attribute altshift_tap 431 mapping sequential shift components to registers 431 setting shift register style 431 syn_state_machine directive using with value=0 580 SYN_TCL_HOOKS environment variable 309 syn_tco directive 388, 389, 391 syn_timing_estimation_effort attribute 769 syn_tpd directive 388, 389, 391 syn_trace_attr attribute 213 syn_tsu directive 388, 389, 391 syn_useioff attribute packing registers (Altera) 664 packing registers (Xilinx) 682 shift register inference 432 SYNCore Adder/Subtractor 507 counter compiler 526, 531 FIFO compiler 446, 451 RAM compiler 469 RAM compiler SYNCore 475 RAMs, byte-enable 485 ROM compiler 496 SYNCore adder/subtractor adders 514 dynamic adder/subtractor 520 subtractors 517 SYNCore FIFOs definition 451 parameter definitions 456
port list 454 read operations 453 status flags 459 write operations 452 SYNCore ROMs clock latency 505 dual-port read 503 parameter list 504 single-port read 502 synhooks automating message filtering 759 synhooks.tcl file 309 Synplicity product family 28 synplicity.ucf file non-secure cores 747 relation to ncf file 621 secure cores 747 Synplify Premier features 29 overview 29 Synplify Pro features 29 overview 29 Synplify Pro software starting 32 Synplify software starting 32 synplify UNIX command 32 synplify.ucf 654 synplify.vhd 702 syntax checking source files 44 syntax check 44 synthesis Synplify Premier 787 Xilinx non-secure cores 748 Xilinx secure cores 748 synthesis check 44 Synthesis On/Off Implemented as Translate On/Off 93 synthesis_files directory 286 synthesis_on/off 93
861
T
tabs setting in text files 50 tcl callbacks customizing key assignments 310 Tcl commands batch script 305 entering in SCOPE 614 netlisting editing 318 running 306 Tcl expand command crossprobing objects 633 usage tips 640 using in SCOPE 632 tcl file commands slice_primitive 176 Tcl files 306 colors 49 comments 49 fonts 50 guidelines 55 naming conventions 55 synhooks.tcl 309 tabs 50 using variables 307 wildcards 56 Tcl find command annotating properties 639 case sensitivity 639 crossprobing objects 633 database differences 633 examples of filtering 640 pattern matching 639 Tcl window vs SCOPE 631 usage tips 638 using in SCOPE 632 Tcl Script window crossprobing 355 displaying 188 hiding 188 message viewer 754 Tcl script window collections compared to SCOPE 631 Tcl scripts See Tcl files. technology files 444 technology mapping, description 37
862
Technology view crossprobing 349, 350 crossprobing collection objects 633 filtering 361 flattening hierarchy 370 general description 322 highlighting collections 641 opening 323 selecting/deselecting objects 326 setting preferences 329 state machine implementation in 579 traversing hierarchy 334 text editor built-in 45 external 48 using 45 Text Editor view crossprobing 351 Text Editor window colors 49 crossprobing 48 fonts 49 text files crossprobing 352 The Synplicity Product Family 28 through constraints 623 AND lists 624 OR lists 624 time budgeting 769 time stamp, checking on files 69 TimeQuest supported constraints for import 741 timing analysis 768 system level 770 timing constraints 56 translating qsf 739 Xilinx output file 621 timing estimation effort level 769 timing optimization 564 timing report specifying format options 88 timing_applied.sdc file 739 timing_unapplied.sdc file 739 tips memory usage 375
Index to constraints specifying 623 ToolTips, locations 194 top level entity specifying in VHDL 92 top level module specifying in VHDL 92 top-level constants preserving 98 trace assignment automatic 222 black boxes 222 buses 218 filtering nets 209 HSTDM 214 manual 206 net display 208 probes 225 QPT 216 scratchpad 212 trace display 210 trace assignments probes 225 saving 225 trace delay file example 817 trace utilization QPT 154 traces, adding to board description file 802 training status HSTDM 244 transparent instances flattening 371 lower-level logic on multiple sheets 328 tutorial online 139 ucf2sdc.log file 654 ucf2sdc_old translating Xilinx constraints 657 UINISIM library simulation 702 UNISIM library 672 UNIX commands synplify 32 unsupported.ucf 654
V
vendor files 444 Verilog ifdef and define statements 90 adding attributes and directives 103, 112 adding probes 584 Altera LPM library 442 Altera LPM megafunction example 437 Altera PLLs 663 black boxes 383 case sensitivity for Tcl Find command 639 checking source files 43 choosing a compiler 89 clock DLLs 697 creating source files 42 crossprobing from HDL Analyst view 351 defining FSMs 393 defining state machines with parameter and define 394 editing operations 45 extracting parameters 90 inferring DesignWare functions 541 initializing RAMs 421 instantiating LPMs as black boxes (Altera) 437 macro library (Xilinx) 672 mixed language files 51 RAM structures for inference 399 RLOCs 694 sequential shift components 435 specifying compiler directives 90 structural, for instantiated Clearbox 722 Verilog 2001 setting global option from the Project view 89
863
U
UCF constraints 649 input files 653 supported 655, 656 translating for logic synthesis 650 ucf file translating with ucf2sdc_old 657 using as input for logic design 650 ucf file. See also synplicity.ucf
setting option per file 89 VHDL adding attributes and directives 102, 111 adding probes 584 Altera LPM megafunction example 439 Altera PLLs 663 black boxes 384 case sensitivity for Tcl Find comand 639 checking source file 43 clock DLLs 697 constants 93 creating source files 42 crossprobing from HDL Analyst view 351 defining FSMs 395 editing operations 45 extracting generics 93 initializing RAMs with variable declarations 424 initializing with signal declarations 422 instantiating LPMs as black boxes (Altera) 437 LPM instantiation example 441 macro library (Xilinx) 672 mixed language files 51 prepared components method of instantiation 441 RAM structures for inference 399 RLOCs 694 sequential shift components 434 structural, for instantiated Clearbox 722 VHDL files adding library 67 adding third-party package library 67 order in project file 67 ordering automatically 67 vi text editor 48 views arranging 187 Virtex block RAM. See also block RAM. clock buffers 697 I/O buffers 699 PCI core 678 virtual clock, setting 613 voltage region reports 173 voltage regions 171 report 173
864
vqm inferred Clearbox 717 instantiated Clearbox 720 instantiated Clearbox with netlist 724
W
warning messages definition 44 warnings feedback muxes 564 filtering 755 handling 763 sorting 755 white boxes using syn_macro on non-secure cores 748 wide adders/subtractors example 677 inferring 675 prerequisites for inference 676 wildcards effect of search scope 346 Find command (Tcl) 639 message filter 756 wildcards (Find) examples 348 how they work 346 windows Impact Analysis 162 workspaces creating 79 using 80 write modes, Virtex-II 415
X
xc_clockbuftype attribute specifying 697 xc_fast attribute for critical paths 671 xc_loc attribute assigning locations in SCOPE 687 xc_map attribute relative location 694 xc_padtype attribute specifying I/Os 699 xc_rloc attribute
: specifying relative location 695 xc_uset attribute grouping instances for relative placement 695 using to group instances 695 xcf files translating to sdc 653 Xilinx block RAMs 412 clock buffers 697 CoreGen 678 defining DCMs and DLLs 617 design guidelines 671 GSR 674 I/O buffers 699 I/O insertion, manual 691 I/O locations 686 I/O pad type 620 including cores for synthesis 748 INIT property 426 INIT property, VHDL 428 IP cores 678, 745 macro libraries 672 macros 672 non-secure core flow 748 packing registers 682 post-synthesis simulation 702 reoptimizing EDIF 700 secure core flow 748 specifying pin location 686 startup blocks 674 synthesis constraint files 621 tips for optimizing 671 Virtex-II write modes 415
865
LO
866

Certify Partition Driven Synthesis: User Guide

Uploaded by

Document Information

Original Description:

Original Title

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

Certify Partition Driven Synthesis: User Guide

Uploaded by

Copyright:

Available Formats

Certify Partition Driven Synthesis User Guide

Service Marks (SM)

Restricted Rights Legend

Certify User Guide, March 2011

Certify User Guide, March 2011

Chapter 2: Preparing the Input

Chapter 3: Setting up a Project

Chapter 4: Fast Synthesis

Chapter 5: Partitioning a Design

Chapter 6: Layout of the Certify Partition Board View

Chapter 7: Trace Assignment

Chapter 8: Time-Domain Multiplexing

Chapter 9: HAPS Clock Synchronization

Chapter 10: Source-Level Partitioning

Chapter 11: Scripting

Chapter 12: Netlist Editing

Chapter 13: Analyzing Logic in HDL Analyst

Chapter 14: Instantiating and Inferring High-Level Objects

Chapter 15: Generating IP with SYNCore

Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Chapter 16: Using DesignWare IP

Chapter 17: Specifying Design-Level Optimizations

Chapter 18: Specifying Constraints

Chapter 19: Optimizing for Specific Targets

Chapter 20: Working with Vendor IP

Chapter 21: Analyzing the Log File

Chapter 22: Analyzing Timing

Chapter 23: Debugging Aids

Assigning Control Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782 Creating Your Own Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784

Chapter 24: Post-Synthesis Operations

Chapter 25: Board Description Files

Copyright 2011 Synopsys, Inc. 18

Certify User Guide March 2011

Appendix A: Board Description File Example Appendix B: Filename Extensions

Appendix C: Project Conversion

Appendix D: Top-down Conversion

Certify User Guide March 2011

Copyright 2011 Synopsys, Inc. 19

Copyright 2011 Synopsys, Inc. 20

Certify User Guide March 2011

ASIC Prototyping Using FPGAs

Certify User Guide March 2011

Copyright 2011 Synopsys, Inc. 21

Chapter 1: ASIC Prototyping Using FPGAs

What is the Certify Prototyping Tool?

What is the Certify Prototyping Tool?

Copyright 2011 Synopsys, Inc. 22

Certify User Guide March 2011

About This Manual

Chapter 1: ASIC Prototyping Using FPGAs

About This Manual

The user guide contains task-based information. For a breakdown of

Chapter 1, ASIC Prototyping Using FPGAs

Chapter 2, Preparing the Input

Chapter 3, Setting up a Project

Chapter 4, Fast Synthesis

Chapter 5, Partitioning a Design

Certify User Guide March 2011

Copyright 2011 Synopsys, Inc. 23

Chapter 1: ASIC Prototyping Using FPGAs

About This Manual

Chapter 6, Board View