LeonardoSpectrum Users Manual

Transcription

LeonardoSpectrum for Altera
User’s Manual
Software Version v2001.1
July 2001
Copyright © 2001 Exemplar Logic, Inc., A Mentor Graphics Company. All rights reserved.
This document contains information that is proprietary to Exemplar Logic, Inc and may be duplicated in
whole or in part by the original recipient for internal business purposes only, provided that this entire notice
appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to
prevent the unauthorized use of this information.
This document is for information and instruction purposes. Exemplar Logic reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Exemplar Logic to determine whether any changes have been made.
The terms and conditions governing the sale and licensing of Exemplar Logic products are set forth in
written agreements between Exemplar Logic and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of
Exemplar Logic whatsoever.
DISCLAIMER
ALTHOUGH EXEMPLAR LOGIC, INC HAS TESTED THE SOFTWARE AND REVIEWED THE
DOCUMENTATION, EXEMPLAR LOGIC, INC MAKES NO WARRANTY OR REPRESENTATION,
EITHER EXPRESSED OR IMPLIED, WITH RESPECT TO THIS SOFTWARE AND DOCUMENTATION,
ITS QUALITY, PERFORMANCE, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR
PURPOSE.
EXEMPLAR LOGIC SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF EXEMPLAR LOGIC INC HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
RESTRICTED RIGHTS LEGEND 03/97
U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirely
at private expense and are commercial computer software provided with restricted rights. Use,
duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the
restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.72023(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted
Rights clause at FAR 52.227-19, as applicable.
Contractor/manufacturer is:
Exemplar Logic Inc.
880 Ridder Park Drive, San Jose, CA 95131
web site: http://www.exemplar.com
email: support@exemplar.com
TRADEMARKS
Exemplar Logic™ and its Logo are trademarks of Exemplar Logic, Inc. LeonardoSpectrum™,
LeonardoInsight™, TimeCloser™, FlowTabs™, HdlInventor™, SmartScripts™,P&RIntegrator™,
DesktopASIC™, XlibCreator™, SynthesisWizard™, and MODGEN™ are trademarks of Exemplar Logic,
Inc.; Model Sim/VHDL™, Model Sim™, and V-System/Verilog™ are trademarks of Model Technology,
Inc.; Renoir™, Monet™, and PackagedPower™ are trademarks of Mentor Graphics Corporation.
Verilog® and Verilog-XL® are registered trademarks of Cadence Design Systems, Inc. All other
trademarks remain the property of their respective owners.
Table of Contents
TABLE OF CONTENTS
Chapter 1
Introducing LeonardoSpectrum............................................................................................... 1-1
HDL Languages ..................................................................................................................... 1-2
Save and Restore Project ....................................................................................................... 1-2
HDLInventor.......................................................................................................................... 1-2
Tcl Script Sourcing ................................................................................................................ 1-2
Using the Synthesis Wizard ...................................................................................................... 1-3
Understanding the Quick Setup Flow ....................................................................................... 1-4
The Quick Setup Task Flow .................................................................................................. 1-5
Applying Constraints with FlowTabs ....................................................................................... 1-8
Technology-Specific Synthesis Options ................................................................................... 1-9
Documentation Available Online ............................................................................................. 1-9
Context-Sensitive Help .......................................................................................................... 1-9
Menu Bar Help....................................................................................................................... 1-9
Product Manuals Online ........................................................................................................ 1-9
PC Hardware and Software Requirements ............................................................................. 1-10
Chapter 2
Preparing for Synthesis ............................................................................................................. 2-1
Preparing Your Design for Synthesis ....................................................................................... 2-2
Checking Your RTL Coding Style ........................................................................................ 2-2
Rules for Partitioning Your Design ....................................................................................... 2-5
Creating a Simple Working Directory Structure ...................................................................... 2-7
Chapter 3
Understanding the User Interface ............................................................................................ 3-1
Understanding the Synthesis Controls ...................................................................................... 3-3
Standard Tcl Commands........................................................................................................ 3-3
LeonardoSpectrum Tcl Commands ....................................................................................... 3-4
Setting Tcl Variables ............................................................................................................. 3-4
Setting Attributes ................................................................................................................... 3-4
Methods for Using Commands With a Tcl Script ................................................................. 3-4
Understanding the Tool Setup Environment ............................................................................ 3-6
Setting the Place and Route Executable Pathnames .............................................................. 3-6
Startup Files ........................................................................................................................... 3-6
Saving and Restoring a Project .............................................................................................. 3-7
Setting Aliases ....................................................................................................................... 3-9
Invoking the Graphical User Interface...................................................................................... 3-9
The leonardo Command......................................................................................................... 3-9
The Main Window at Startup.................................................................................................. 3-10
Tip of the Day ...................................................................................................................... 3-10
LeonardoSpectrum for Altera User’s Manual, v2001.1d
iii
Table of Contents
TABLE OF CONTENTS [continued]
SynthesisWizard .................................................................................................................. 3-11
The Major Elements of the Main Window ............................................................................. 3-12
The Main Window Header ..................................................................................................... 3-13
The Information Window ....................................................................................................... 3-20
Printing the Content of the Information Window ................................................................ 3-20
The HDLInventor Source Code Editor ................................................................................... 3-21
Templates............................................................................................................................. 3-21
Editing Options .................................................................................................................... 3-23
Editing Options - Transcript and Filtered Transcript........................................................... 3-23
More Editing Options .......................................................................................................... 3-24
Printing the Content of the HDLInventor Window ............................................................. 3-26
Changing the Default Session Settings ................................................................................... 3-27
Main Session Settings .......................................................................................................... 3-27
Browser View Options......................................................................................................... 3-29
Schematic Viewer Options .................................................................................................. 3-29
Place and Route ................................................................................................................... 3-30
Using the Variable Editor ....................................................................................................... 3-31
Chapter 4
Loading a Technology Library ................................................................................................. 4-1
Loading a Technology Library ................................................................................................. 4-2
Technology Mapping ................................................................................................................ 4-2
Introduction............................................................................................................................ 4-2
Lookup Table Mapping ......................................................................................................... 4-3
Global Buffers........................................................................................................................... 4-4
I/O Mapping.............................................................................................................................. 4-4
The Technology FlowTab - FPGA ........................................................................................... 4-5
Advanced Settings PowerTab - FPGA .................................................................................. 4-6
Chapter 5
Reading Your Design ................................................................................................................. 5-1
Reading Your Design into Memory.......................................................................................... 5-2
Opening Design Files............................................................................................................. 5-2
Reading Custom VHDL Libraries and Packages .................................................................. 5-2
Understanding the In-Memory Design Data Model ................................................................. 5-3
Understanding the In-Memory Design Data Structure ............................................................. 5-4
How LeonardoSpectrum Infers and Implements Operators ..................................................... 5-6
Understanding Modgen Libraries ............................................................................................. 5-6
Understanding Pre-Optimization .............................................................................................. 5-7
What is Pre-Optimization?..................................................................................................... 5-7
The Input FlowTab ................................................................................................................... 5-8
The VHDL Input PowerTab ............................................................................................... 5-10
iv
Table of Contents
The Verilog Input PowerTab .............................................................................................. 5-11
The EDIF Input PowerTab ................................................................................................. 5-12
Chapter 6
Setting Timing Constraints ....................................................................................................... 6-1
Setting Timing Constraints ....................................................................................................... 6-3
Setting Global Timing Constraints on Sub-Blocks................................................................ 6-3
Resets ..................................................................................................................................... 6-4
Clocks .................................................................................................................................... 6-4
Setting Clock Constraints ...................................................................................................... 6-4
Setting Clock Skew................................................................................................................ 6-5
Multiple Synchronous Clocks per Block ............................................................................... 6-6
Setting the Input Arrival Time............................................................................................... 6-9
Setting Output Required Times: .......................................................................................... 6-10
Setting Multicycle Path Constraints: ................................................................................... 6-11
Known Problem with Setting Multicycle Paths................................................................... 6-12
False Path Constraints:......................................................................................................... 6-12
Constraining Purely Combinational Designs....................................................................... 6-12
Constraining Mixed Synchronous and Asynchronous Designs........................................... 6-13
The Constraints FlowTab........................................................................................................ 6-16
The Clock Constraints PowerTab ........................................................................................ 6-18
The Input Signal PowerTab ................................................................................................. 6-20
The Output Signal PowerTab .............................................................................................. 6-22
The Internal Signal PowerTab ............................................................................................. 6-24
The Module PowerTab ........................................................................................................ 6-26
The Path Constraints PowerTab .......................................................................................... 6-28
The Report Constraints PowerTab....................................................................................... 6-30
Chapter 7
Optimizing Your Design ............................................................................................................ 7-1
Understanding Global Area Optimization ................................................................................ 7-2
How LeonardoSpectrum Optimizes a Design ....................................................................... 7-2
Understanding Extended Optimization Effort .......................................................................... 7-5
Managing Hierarchy ................................................................................................................. 7-5
Design Partitioning Hints....................................................................................................... 7-6
Implementing Hierarchy in VHDL........................................................................................ 7-7
Flattening Hierarchy .............................................................................................................. 7-7
Protecting Hierarchy .............................................................................................................. 7-8
The Optimize FlowTab ............................................................................................................. 7-9
Advanced Optimization PowerTab...................................................................................... 7-12
v
Table of Contents
Chapter 8
Saving Your Design .................................................................................................................... 8-1
The Output FlowTab ................................................................................................................ 8-2
The EDIF Out PowerTab ...................................................................................................... 8-4
The SDF Out PowerTab ....................................................................................................... 8-5
The Verilog Out PowerTab ................................................................................................... 8-6
The VHDL Out PowerTab .................................................................................................... 8-7
Chapter 9
Performing Physical Layout...................................................................................................... 9-1
The Place & Route Tab............................................................................................................. 9-2
The Altera MAX+PLUS II Place & Route Tab..................................................................... 9-2
The Altera Quartus PowerTab .............................................................................................. 9-4
Quartus Integration ................................................................................................................ 9-5
Chapter 10
Altera FLEX, ACEX, and MAX Synthesis............................................................................ 10-1
The FLEX and ACEX Architecture........................................................................................ 10-2
Introduction.......................................................................................................................... 10-2
Logic Elements (LEs) .......................................................................................................... 10-2
Input/Output Elements (IOEs) ............................................................................................. 10-2
Embedded Array Blocks (EABs)......................................................................................... 10-2
The MAX Architecture ........................................................................................................... 10-2
The Altera Synthesis Flow...................................................................................................... 10-3
The QuickSetup Flow .......................................................................................................... 10-3
The Advanced (Level 3) Synthesis Flow............................................................................. 10-4
Summary of FLEX, ACEX, and MAX Specific Control Variables ....................................... 10-4
User Options that Control Mapping........................................................................................ 10-5
Device .................................................................................................................................. 10-5
Speed.................................................................................................................................... 10-5
Map IO Registers (FLEX 10K and ACEX 1K) ................................................................... 10-5
Max Fanin (MAX only) ....................................................................................................... 10-5
Max PT (MAX only) ........................................................................................................... 10-5
Max Fanout (FLEX and ACEX).......................................................................................... 10-5
Lock LCells (FLEX and ACEX) ......................................................................................... 10-6
Map Cascades (FLEX and ACEX) ...................................................................................... 10-6
Use the Carry/Sum Primitive ............................................................................................... 10-6
Exclude Gates ...................................................................................................................... 10-6
Assigning Device Pin Numbers to Primary I/Os .................................................................... 10-7
Mapping to the Logic Element (LE) in FLEX Devices.......................................................... 10-7
Fanin Limited Optimization................................................................................................. 10-7
vi
Table of Contents
Lookup Table (LUT) Mapping ............................................................................................ 10-8
Managing the Inclusion of Modules ..................................................................................... 10-10
Understanding LeonardoSpectrum Modgen ...................................................................... 10-10
Mapping Combinatorial Logic to Embedded Array Blocks (EABs)................................. 10-11
Implementing a Pipelined Multiplier ................................................................................. 10-13
Mapping Memory Elements to FLEX Devices .................................................................... 10-16
Inferring ROMs from the HDL Code ................................................................................ 10-16
Mapping RAMs to the FLEX 10K Architecture ............................................................... 10-22
Generating Simulation Memory Models with Genmem.................................................... 10-28
LPM Instantiation .............................................................................................................. 10-29
Genmen Verilog Design .................................................................................................... 10-29
LeonardoSpectrum for Genmem ....................................................................................... 10-30
Writing the EDIF Output ...................................................................................................... 10-30
Using FLEX Designs as Input .............................................................................................. 10-32
EDIF Input ......................................................................................................................... 10-32
FLEX 6000/8000 Devices Supported ................................................................................... 10-33
FLEX 10K Devices Supported ............................................................................................. 10-34
ACEX Devices Supported .................................................................................................... 10-36
MAX Family Devices Supported ......................................................................................... 10-37
Chapter 11
Altera APEX Synthesis............................................................................................................ 11-1
APEX 20K/20KE/20KC Family............................................................................................. 11-1
Mapping Options ................................................................................................................. 11-1
LeonardoSpectrum APEX 20K/20KE Mapping.................................................................. 11-2
APEX Technology Support ................................................................................................. 11-3
APEX ESB (Embedded System Block)............................................................................... 11-4
Directing Quartus to Implement a Design Block in PTERM .............................................. 11-4
Simulation with Pre-Layout Verification (Optional)........................................................... 11-5
FSM Encoding (binary, gray, random, onehot, twohot, auto) ............................................. 11-6
APEX 20K Devices Supported............................................................................................... 11-7
APEX 20KE Devices Supported ............................................................................................ 11-8
APEX 20KC Devices Supported ............................................................................................ 11-9
APEX II Devices Supported ................................................................................................. 11-10
Mercury Devices Supported ................................................................................................. 11-11
Excalibur Mips Devices Supported ...................................................................................... 11-12
Excalibur Arm Devices Supported ....................................................................................... 11-13
Appendix A
SynthesisWizard Tutorial......................................................................................................... A-1
SynthesisWizard Tour.............................................................................................................. A-1
Specifying the Technology Library - Step 1 of 4 ................................................................. A-2
vii
Table of Contents
Input Files, Step 2 of 4.......................................................................................................... A-3
Global Constraints, Step 3 of 4 ............................................................................................. A-5
Output File, Step 4 of 4......................................................................................................... A-7
Run........................................................................................................................................ A-8
viii
Table of Contents
LIST OF FIGURES
Figure 1-1. Quick Setup Data Flow Diagram .......................................................................... 1-4
Figure 1-2. Quick Setup Options ............................................................................................ 1-5
Figure 1-3. Setting the Place and Route Tools Path Location ................................................. 1-7
Figure 2-1. Example of Design Partitioning ............................................................................ 2-5
Figure 2-2. Example of Separating Timing Blocks ................................................................. 2-6
Figure 2-3. Registers Placed at the End of a Block ................................................................. 2-6
Figure 2-4. A Typical Working Directory Structure ............................................................... 2-7
Figure 3-1. Relationship between Commands, Variables, and Attributes............................... 3-3
Figure 3-2. Setting the Place and Route Executable Pathnames ............................................. 3-6
Figure 3-3. Main Window at Startup ..................................................................................... 3-10
Figure 3-4. Main Window ..................................................................................................... 3-12
Figure 3-5. Part of Main Window Header ............................................................................. 3-13
Figure 3-6. Example of a Simple Report ............................................................................... 3-20
Figure 3-7. Part of Source Code with Popup Message .......................................................... 3-21
Figure 3-8. Example HDLInventor Template and Bookmarks ............................................. 3-24
Figure 3-9. HDL Source Code Example................................................................................ 3-25
Figure 3-10. HDL Code with Editor Line Number Example ................................................ 3-26
Figure 3-11. Setting Options for the Main Session .............................................................. 3-27
Figure 3-12. Design Browser View Options. ........................................................................ 3-29
Figure 3-13. Setting the Place and Route Tools Path Location ............................................. 3-30
Figure 3-14. The Variable Editor.......................................................................................... 3-31
Figure 4-1. Technology Settings - FPGA ................................................................................ 4-5
Figure 4-2. Advanced Setting PowerTab for Altera FLEX6K ............................................... 4-6
Figure 5-1. The Input FlowTab................................................................................................ 5-8
Figure 5-2. The VHDL Input PowerTab Options.................................................................. 5-10
Figure 5-3. The Verilog Input PowerTab Options................................................................. 5-11
Figure 5-4. EDIF Input PowerTab Options ........................................................................... 5-12
Figure 6-1. Setting Global Timing Constraints on Sub-Blocks............................................... 6-3
Figure 6-2. Clock Constraints .................................................................................................. 6-4
Figure 6-3. Clock Network ...................................................................................................... 6-5
Figure 6-4. Clock Skew ........................................................................................................... 6-6
Figure 6-5. Clock Skew Timing .............................................................................................. 6-6
Figure 6-6. Multiple Synchronous Clocks ............................................................................... 6-7
Figure 6-7. Synchronous Clocks.............................................................................................. 6-7
Figure 6-8. Input Arrival Time ................................................................................................ 6-9
Figure 6-9. Output Time ........................................................................................................ 6-10
Figure 6-10. False Path Constraints ....................................................................................... 6-12
Figure 6-11. Combinational Design....................................................................................... 6-13
Figure 6-12. Constraining Designs with Mixed Signals (1 of 3)........................................... 6-13
Figure 6-15. Constraining Sub-Blocks .................................................................................. 6-15
Figure 6-16. The Constraints FlowTab - Global Constraint Options .................................... 6-16
ix
Table of Contents
LIST OF FIGURES [continued]
Figure 6-17. The Clock Constraints PowerTab Options........................................................ 6-18
Figure 6-18. Clock Waveform Diagram ................................................................................ 6-19
Figure 6-19. The Input Signal Constraints PowerTab Options ............................................. 6-20
Figure 6-20. The Output Signal Constraints PowerTab Options........................................... 6-22
Figure 6-21. The Internal Signal Constraints PowerTab Options ......................................... 6-24
Figure 6-22. The Module PowerTab Options ........................................................................ 6-26
Figure 6-23. The Path Constraints PowerTab Options .......................................................... 6-28
Figure 6-24. The Report Constraints PowerTab Options ...................................................... 6-30
Figure 7-1. A Binary Decision Diagram.................................................................................. 7-3
Figure 7-2. Setting Extended Optimization Effort................................................................... 7-5
Figure 7-3. The Optimize FlowTab Options ........................................................................... 7-9
Figure 7-4. Advanced Optimization PowerTab Options ....................................................... 7-12
Figure 8-1. The Output FlowTab Options ............................................................................... 8-2
Figure 8-2. EDIF Out PowerTab Options................................................................................ 8-4
Figure 8-3. SDF Out PowerTab Options ................................................................................. 8-5
Figure 8-4. VHDL Out PowerTab Options ............................................................................. 8-7
Figure 9-1. Altera MAX+PLUSII Physical Tab Options ........................................................ 9-2
Figure 9-2. Altera Quartus PowerTab Options ........................................................................ 9-4
Figure 10-1. Mapped Circuit Schematic................................................................................ 10-9
Figure 10-2. Output Netlist .................................................................................................... 10-9
Figure 11-1. Writing Power/Ground as Undriven Nets ......................................................... 11-3
Figure A-1. Specifying the Technology Library, Step 1of 4 ................................................. A-2
Figure A-2. Opening the Input Files, Step 2 of 4 .................................................................. A-3
Figure A-3. Setting the Working Directory ........................................................................... A-4
Figure A-4. Set Input File(s) .................................................................................................. A-5
Figure A-5. Global Clock, Step 3 of 4 ................................................................................... A-6
Figure A-6. Output File, Step 4 of 4 ....................................................................................... A-7
Figure A-7. Set Output File ................................................................................................... A-8
Figure A-8. Screen A-8. Warning - Overwriting Output File................................................. A-8
x
Table of Contents
LIST OF TABLES
Table 1-1. System Memory Requirements ............................................................................ 1-11
Table 3-1. Builtin HDL Templates ........................................................................................ 3-22
Table 4-1. LUT Mapping Options for Altera FLEX .............................................................. 4-3
Table 10-1. Modgen Options ............................................................................................... 10-11
Table 10-2. Effect of Pipelining on Quality of Results ....................................................... 10-14
xi
Table of Contents
LIST OF TABLES [continued]
xii
Chapter 1
Introducing LeonardoSpectrum
LeonardoSpectrum for Altera is a suite of high level design tools for Complex Programmable
Logic Devices (CPLDs). LeonardoSpectrum for Altera offers design capture via VHDL and
Verilog entry, register-transfer-level logic synthesis, constraint-based optimization, timing
analysis, and encapsulated place-and-route.
The graphical user interface (GUI) is supported on Windows 95/98/2000/NT; and UNIX HP
and Sun. The GUI provides the following features:
•
Same look and feel for all platforms
•
Windows editing, dragging, and dropping features are available
•
SynthesisWizard, Quick Setup, and FlowTabs guide you through the design process
•
Embedded, interactive, and filtered windows extend task information
•
Quick file changes with right mouse button (RMB)
•
Popups and pulldowns are prevalent
•
Pertinent information is parsed for quick reading
•
Clickable buttons assign tasks
In addition, if you have the LeonardoInsight option, you can cross probe a schematic that is
generated in Renoir with a schematic generated in LeonardoSpectrum. (2) You can view the
whole critical path in one window, even if the path traverses multiple levels of hierarchy. (3)
You can view fanout and fanin cones of logic from a selected net or instance. (4) When the
critical path viewer is in query mode, detailed timing popup information is displayed for the
objects in the critical path. (5) Query mode provides general popup information for every
schematic. (6) The schematic viewer search utility allows you to search for instance, net, and
port; and lists these items for you in a window. (7) The schematic viewer can cross probe with
Renoir.
1-1
HDL Languages
By default you are provided with either the Verilog or VHDL language. You can add either
Verilog or VHDL as a second language.
Save and Restore Project
Entire design projects can be restored on the same or a different machine. Before you quit a
design, you are prompted to save the entire project. Later you can go back and bring up the
discontinued project; the restored project is complete with your specifications and windows
environment.
Project Saves and Restores:
•
File locations for input files, output files, and current working directory
•
Present design information
•
Applied constraints, directives, and attributes
•
All tab selection information: source technology, designation technology, file type,
hierarchy preservation, global constraints, optimization passes, FSM encoding.
HDLInventor
The HDLInventor is an interactive source code editor in LeonardoSpectrum. You can double
click on errors, warnings, and information (red, green, and blue dots) in the information window
or click on the name of your input file to bring up the HDLInventor. The HDLInventor
interactively highlights syntax and synthesis construct errors found during synthesis. You can
make your edits in this window and, if required, insert template(s) of HDL code that you
frequently use.
Tcl Script Sourcing
LeonardoSpectrum provides three ways to source your Tcl script. After you create a Tcl script
in a standard text editor, you can source your script from LeonardoSpectrum as follows:
•
GUI Menu Bar File -> Run Script
•
Batch mode from a shell using the syntax:
% spectrum -file <my_Tcl_script>
1-2
Using the Synthesis Wizard
Refer the topic Batch Mode Operations in the LeonardoSpectrum Reference Manual for
complete syntx.
Using the Synthesis Wizard
You can invoke the Synthisis wizard by clicking on the Wizard’s Hat icon as shown in the
figure below. The SynthesisWizard is designed for the first time users by walking them through
the synthesis flow in four easy steps.
Click to invoke the Synthesis Wizard
Refer to the SynthesisWizard Tutorial starting on page A-1 for more detailed instruction.
1-3
Understanding the Quick Setup Flow
Quick Setup is the default synthesis flow presented to users when LeonardoSpectrum is first
invoked. Quick Setup can be used by advanced as well as beginning users as a simple and quick
means to achieve good first-pass synthesis results. You specify the target technology, open your
input design files, optionally set the target clock frequency, and verify the name and location of
the generated output netlist. You click the Run Flow button to run the entire synthesis flow.
Optionally, you can have Quick Setup automatically invoke the vendor place and route tools to
generate a set of vendor place and route files.
Figure 1-1 is a simplified illustration of the data flow in a Quick Setup synthesis run.
Figure 1-1. Quick Setup Data Flow Diagram
Optional
Schematic
Viewer
Design
Browser
Hierarchy tree view
RT L gate-level view
Critical P ath Trace
.w ork
.xdb
com piled
in-m em ory
H D L design
R TL
(generic-gate)
design
synthesize
M em ory
read
.ver
optim ize
w rite
R un Flow
.ver
W orking Directo ry
1-4
.xdb
technology
-m apped
design
.edf
Tech nolog y-m apped view
W orkin g Directory
The Quick Setup Task Flow
As shown in Figure 1-2, setting up a Quick Setup Flow is fast and straight forward.
Figure 1-2. Quick Setup Options
1. Set the Technology
3. Open Design Files
2. Set Working Directory
4. Set theClock
5. Set the Effort
min
max
6. Verify the Name
and Destination
7. Activate Place and Route
8. “Click”
1-5
Selecting a Technology
When you select an FPGA/CPLD technology, LeonardoSpectrum selects a Device, Speed
Grade, and Wire Load table by default. You may override these selections by moving to the
Technology FlowTab and scrolling through the choices in each dialog box.
Setting the Working Directory
The working directory is the directory where LeonardoSpectrum places all generated output
files. These files include the output files from the synthesis process as well as the output files
from the integrated place and route tools. Since the generated files are many in number, it is a
good practice to separate your design source files and Tcl scripts into a separate sub-directory.
As shown in Figure 1-1, the input source files are kept in a sub-directory named src. If, for
example, your first synthesis run generates the “fastest” possible circuit, you may want to do
one or more optional runs to evaluate the tradeoffs between speed and area. You can simply
copy the src sub-directory into a new working directory named “smallest”, for example, and
the new generated files for the next run will be placed there.
Opening the Design Files
LeonardoSpectrum does not read pre-compiled HDL designs from disk. Instead, the source files
are read directly into memory where LeonardoSpectrum builds an EDIF-like in-memory
database. The design source files do not have to reside in the specified working directory. They
may reside in any location and may even reside in more than one location. You simply click on
the Open files button, navigate to and select a source file, then click Open. The file(s) are listed
in the order in which they will be read. For VHDL source files, order is important. If an opened
file is out of place in the list, you may drag the file into the correct position with the mouse
cursor. The files are read from top to bottom.
Reading Custom VHDL Libraries and Packages
Many standard VHDL libraries and packages are built into LeonardoSpectrum and don’t have
to be specified in the Open file list. If your design references custom libraries and packages,
then you must Open these package source files for reading before your design files are read. The
methods for doing this are fully discussed in the LeonardoSpectrum HDL Synthesis Manual
starting on page 4-4.
Setting the Clock Frequency
This is an optional setting. If you don’t specify a clock frequency, LeonardoSpectrum will
optimize the design to the smallest possible area. If you specify a clock frequency, the smallest
area design will be optimized, then LeonardoSpectrum will re-optimize the hardware in the
critical paths to try to match or slightly exceed your specified clock frequency. This critical path
optimization effort will increase the circuit area, but only in the places necessary to speed up the
design.
1-6
Setting the Optimization Effort
As shown in Figure 1-2, you can set the optimization effort that LeonardoSpectrum should
expend to reach your specified timing constraints. As you move the slider from left to right,
LeonardoSpectrum will expend more effort in trying to reach your constraints, often at the
expense of run time.
Verifying the Output File Name and Location
LeonardoSpectrum creates a set of output files. By default, the output netlist name is based on
the name of the first file in the Input list. The target pathname is the current working directory
and the file type is EDIF (.edf). You should verify that this output file name, type, and target
location is acceptable. If not, you can change the information in the Output File dialog box. The
generated file set includes a technology-mapped structural netlist and a vendor-specific
constraint file. Other files may also be generated, depending on the target technology.
Activating Integrated Place and Route
This is an automated feature for running the selected vendor place and route tools. In order to
work, you must first verify that the proper path location is set to the Vendor’s executable
directory. As shown in Figure 1-3, you can select Tools > Options... from the
LeonardoSpectrum Main pulldown menu and click on the Place & Route Paths tab. The figure
shows the typical path location for Altera Quartus tools. (The actual name of the environment
variable may differ between platforms.)
Figure 1-3. Setting the Place and Route Tools Path Location
Tools > Options...
Running the Flow
You click Run Flow to start the synthesis process and generate a technology-mapped structural
netlist. As shown in Figure 1-1, the opened input files are read by LeonardoSpectrum and an inmemory EDIF style database is created. This is called the RTL database and the design is
composed of generic gates and non-mapped (black box) operators. As shown in Figure 1-1, you
may view this in-memory design with an optional design browser and schematic viewer called
1-7
Applying Constraints with FlowTabs
LeonardoInsight. Next, the in-memory design is mapped to the specified technology and
globally optimized for area. Extended Optimization routines are run, if specified, and the best
results for each module are saved. If a timing constraint is not met at this point, additional
critical path optimizations are run to try to meet the constraints. As shown in Figure 1-1, the
results are kept in a second in-memory technology-mapped design database. The output netlist
and support files are then automatically generated and written to the working directory. If
Automated Place and Route is specified, the P&R tools are run next and the generated P&R
file set is placed in the working directory.
Applying Constraints with FlowTabs
The FlowTabs are designed for the more advanced users who need access to all the embedded
power of LeonardoSpectrum. As shown in the figure below, you bring up the FlowTabs by
clicking on the “A” icon.
Click to Display FlowTabs
FlowTabs
The basic method for using FlowTabs is to first use the Input FlowTab to Read your design into
memory, then you use the remaining FlowTabs to enter and Apply constraints to the in-memory
design. Finally, you press the Run Flow button to optimize the design and write an output
netlist. The details for applying constraints with each FlowTab are found in the following
chapters:
1-8
•
The Technology FlowTab - Loading a Technology Library on page 4-1.
•
The Input FlowTab - Reading Your Design on page 5-1.
•
The Constraints FlowTab - Setting Timing Constraints on page 6-1.
•
The Optimize FlowTab - Optimizing Your Design on page 7-1.
•
The Output FlowTab - Saving Your Design on page 8-1.
•
The Physical FlowTab - Performing Physical Layout on page 9-1.
Technology-Specific Synthesis Options
Technology-Specific Synthesis Options
The options and constraints that you apply to your design may depend on which technology
library you are using. The more you understand about the target technology, the better you will
be able to guide LeonardoSpectrum toward achieving an optimum result. The details for Alteraspecific technologies can be found in the following chapters:
•
Undertanding Altera FLEX Synthesis starting on page 10-1.
•
Undertanding Altera MAX Synthesis starting on page 11-1.
•
Undertanding Altera APEX Synthesis starting on page 11-1.
Documentation Available Online
Context-Sensitive Help
LeonardoSpectrum has context-sensitive help throughout the GUI. While the FlowTabs are
active, you can press F1 to open a context-sensitive help or press the help button. The GUI
window must be selected first to be in current focus when using F1.
The GUI window must be selected first to be in current focus when using F1.
Also, F1 does not work on UNIX.
Note
Menu Bar Help
Online help is available in Windows 95 format. You can view frames of help text and graphics
by moving your cursor to the Main window pulldown menu and selecting:
Help > Help Contents...
You can expand the Table of Contents and select from a variety of topics.
Product Manuals Online
All LeonardoSpectrum product manuals are available for on-screen viewing with the Adobe
Acrobat Reader after LeonardoSpectrum and the Adobe Acrobat Reader are installed from the
LeonardoSpectrum CD-ROM.
1-9
PC Hardware and Software Requirements
You can view the manuals by selecting the following pulldown menu from the Main menu:
Help > Open Manuals Bookcase
The PDF manuals and the Manuals Bookcase also contain HyperText links that guide you to
related documentation on the Web, provided your web browser is operational and properly
configured.
PC Hardware and Software
Requirements
The following are hardware requirements for LeonardoSpectrum for Altera.
Type of PC
An IBM compatible PC with a Pentium or Pentium-Pro CPU is recommended. A 486 PC is
acceptable, but may run slowly.
Operating System
LeonardoSpectrum for Altera requires Windows NT/95/98/2000.
Disk Space
LeonardoSpectrum requires approximately 70 MBytes of disk space for programs and data
files. Plan for an additional 50 MBytes for your files.
1-10
System Memory (RAM)
System Memory Requirements shows the recommended memory for proper operation of
Exemplar synthesis tools. The actual requirements may vary; this depends on your design and
coding style.
Table 1-1. System Memory Requirements
Design Size
Number of Gates
Look Up Tables
Flip-Flops
RAM, MBytes
up to 15,000
up to 1100
500
64
15,000 to 75,000
1100 to 5000
3000
128
75,000 and up
5000 and up
5000
256
A system running with less than the recommended memory may slowdown due
to memory swapping.
Note
1-11
1-12
Chapter 2
Preparing for Synthesis
You can ensure a smooth synthesis process by first following the templates and recommended
coding practices as set forth in the LeonardoSpectrum HDL Synthesis Manual. A summary of
these recommendations are repeated in this section for convenience.
Preparing Your Design for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Checking Your RTL Coding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Rules for Partitioning Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Creating a Simple Working Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2-1
Preparing Your Design for Synthesis
Checking Your RTL Coding Style
Synthesizing State Machines
LeonardoSpectrum encodes state machines during the synthesis process. After a design has
been encoded during synthesis, the design cannot be re-encoded later in optimization. A welldefined VHDL or Verilog coding style must be followed to allow LeonardoSpectrum to identify
the state machine.
Recommendation State machines should be isolated into separate hierarchical blocks. This
speeds optimization performance and allows for easy modifications to state machine encoding.
Supported State Machine Styles
Binary - Generates state machines with the fewest possible flip-flops. Binary state machines are
useful for area critical designs when timing is not an issue.
Gray - Generates state machines where only one flip-flop changes during each transition. Gray
encoded state machines are usually without glitches.
Random - Generates state machines using random state encoding. Random state machine
encoding should only be used when all other implementations are not achieving the desired
results. Random state encoding is not recommended.
OneHot - Generates state machines containing one flip-flop for each state. One hot state
machines provide the best performance and shortest clock to out delays. One-hot
implementations are larger than binary.
Twohot - Twohot encoding sets two flip flops high for each state. The twohot encoding requires
more flip flops than binary and fewer flip flops than onehot. Twohot encoding may be
beneficial to large FSMs where onehot uses too many flip flops, and binary requires too much
decode logic. Refer also to Chapter 2 in the LeonardoSpectrum HDL Synthesis Manual.
Auto - For auto encoding, LeonardoSpectrum varies the encoding based on bit width. More
specifically, enumerated types with fewer elements than global integer lower_enum_break are
encoded as binary; larger enumerated types are encoded as onehot. Values larger than global
integer upper_enum_break are encoded as binary. Auto encoding allows LeonardoSpectrum to
assign encoding on a case-by-case basis.
Setting FSM Encoding with VHDL Attributes
To set the encoding for a particular state machine, insert the following statements into your
code.
2-2
•
•
Declare the type_encoding_style attribute. Type encoding_style is: (BINARY,
ONEHOT, TWOHOT, GRAY, RANDOM, AUTO); attribute TYPE_ENCODING_STYLE: ONEHOT;
Declare your state machine enumeration type. Type my_state_type is:
(s0,s1,s2,s3,s4);
•
Set the type_encoding_style of the state.
Type: attribute: TYPE_ENCODING_STYLE of my_state_type is ONEHOT;
Setting FSM Encoding with Verilog Pragmas
To set the encoding for a state machine in Verilog, you should insert the following comment
text into your Verilog Model above the state machine model
parameter [3:0] // pragma enum state_parameters onehot
idle = 4’b0001,
halt = 4’b0010,
run = 4’b0100,
stop = 4’b1000;
reg[3:0] /*pragma enum state_parameters */state;
Note: In the first line of the above code example, the state machine encoding specified is
onehot. This is an optional specification that could also be set to binary, gray, and random. If
the enum pragma is specified and not set to a partition, indicate FSM encoding. The encoding
default is onehot and can be changed with the set encoding command.
Setting FSM Encoding using the Encoding Variable
Alternatively, the encoding variable is used to set state machine encoding. Once this variable is
set with the Variable Editor (see the Tools pulldown memu), all state machines employ the
specified encoding until another set encoding command issued. Set this variable prior to
reading in VHDL or Verilog code
VHDL Attributes and Verilog pragmas override the encoding variable
Note
VHDL Example
set encoding onehot
read uart_control_sm.vhdl
set encoding binary
read interface_control_sm.vhdl
2-3
Verilog Example
set encoding binary
read -format verilog control.v
Arguments to the Encoding Variable
Arguments
2-4
Description
binary
Sets state machine encoding to binary
onehot
Sets state machine encoding to onehot
twohot
Sets state machine encoding to twohot
gray
Sets state machine encoding to grey
random
Sets state machine encoding to random
auto
Sets state machine encoding based on
bit width.
Rules for Partitioning Your Design
For large designs and team designs, partitioning the design into a hierarchy and maintaining that
hierarchy throughout the synthesis process has many advantages. The following are
recommended steps when you partition a design into leaf blocks:
1. You should place all logic into hierarchical blocks; glue logic does not exist at any level
that is not part of a hierarchical block. When you follow this convention, it helps ensure
that you receive the correct results from the LeonardoSpectrum timing analysis
environment.
Figure 2-1. Example of Design Partitioning
Top Level
P lace alllogic w ithin
a sub-block
S u b b lo ck A
S u b b lo ck B
A void logic,notcontained w ithin a
sub-block thatinterfaces w ith other
sub blocks
2. Gate counts in leaf blocks should be between 10K and 50K gates. Optimizations can be
performed on blocks much larger provided the sub-hierarchy falls within this guideline.
3. In general, you should limit clocks to one per block. Multi-clock designs are supported;
however, setting constraints becomes more complex.
4. You should group similar logic together, i.e., state machines, data path logic, decoder
logic, ROMs. You should pay close attention to blocks that may contain special area or
delay optimizations. For example, if you know a particular block is going to contain the
critical path, you should eliminate any non-critical logic from that block.
5. You should place state machines into separate blocks of hierarchy to speed optimization
and provide more control over encoding.
6. As shown in Figure 2-2, you should separate timing critical blocks from non-timing
critical blocks. LeonardoSpectrum performs area and timing optimizations separately.
By separating timing critical logic into one block, you can perform aggressive area
2-5
optimizations on a greater percentage of the design, and create a smaller circuit that
meets timing.
Figure 2-2. Example of Separating Timing Blocks
S m all
S m all
F ast
F ast
F ast
C ritical
P ath
7. As shown in Figure 2-3, you should place registers at the boundaries of hierarchical
blocks. There are two barriers that constrain optimization, hierarchical boundaries and
registers. When you are designing with hierarchy, you should place registers either at the
front-end or back-end of the hierarchical boundaries, but not at both front and back!
Two barriers are combined into a single barrier. (This minimizes the impact to the
overall results when performing bottom-up optimizations.) If this design practice is
followed, then preserving hierarchy in a design has no impact on optimization results
and allows for faster CPU run times.
Figure 2-3. Registers Placed at the End of a Block
R egisters
placed at
the end of
a block
D e lay = 1
C lo ck
2-6
Creating a Simple Working Directory Structure
Creating a Simple Working Directory
Structure
The working directory is the directory where LeonardoSpectrum places all generated output
files. These files include the output files from the synthesis process as well as the output files
from the integrated place and route tools. Figure 2-4 shows a typical working directory structure
for small to medium sized designs.
Figure 2-4. A Typical Working Directory Structure
Only a few generated files are shown in the illustration. Since the generated files can be many in
number, it is a good practice to separate your design source files and Tcl scripts into a separate
sub-directory. As shown in Figure 2-4, the input source files are kept in a sub-directory named
2-7
Creating a Simple Working Directory Structure
src. If, for
example, your first synthesis run generates the “fastest” possible circuit, you may
want to do one or more optional runs to evaluate the tradeoffs between speed and area. You can
simply copy the src sub-directory into a new working directory named “smallest”, for example,
and the new generated files for the next run will be placed there.
2-8
Chapter 3
Understanding the User Interface
This chapter will help you understand how the basic mechanisms of LeonardoSpectrum work.
In addition, the elements of the Main window of the Graphical User Interface (GUI) are
explained.
Understanding the Synthesis Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LeonardoSpectrum Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Tcl Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Methods for Using Commands With a Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-3
3-3
3-4
3-4
3-4
3-4
Understanding the Tool Setup Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Saving and Restoring a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-6
3-6
3-7
3-9
Invoking the Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
The leonardo Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
The Main Window at Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Tip of the Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
SynthesisWizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
The Major Elements of the Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
The Main Window Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
The Information Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
The HDLInventor Source Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
The HDLInventor Source Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing Options - Transcript and Filtered Transcript . . . . . . . . . . . . . . . . . . . . . . . . . . . .
More Editing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-21
3-21
3-23
3-23
3-24
3-1
Changing the Default Session Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Main Session Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Browser View Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schematic Viewer Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Place and Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-27
3-27
3-29
3-29
3-30
Using the Variable Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
3-2
Understanding the Synthesis Controls
The LeonardoSpectrum Graphical User Interface (GUI) is based on the Tcl language. When you
click on an item in the GUI, you are executing a Tcl command, changing the value of a Tcl
variable, or setting an attribute on a database object. As shown in Figure 3-1, Standard Tcl
Commands provide a foundation for the command structure. LeonardoSpectrum Tcl command
extensions proved the major source of synthesis processing power. This power is directed by
setting Tcl variables. Global constraints and directives are communicated to LeonardoSpectrum
through these variables. A finer level of control is execised when you set attributes on inmemory design objects. In general, a message communicated to LeonardoSpectrum through an
attribute overrides the global messge communicated by setting a variable.
Figure 3-1. Relationship between Commands, Variables, and Attributes
Overrides a Variable
on a Design Object
Sets Global
Constraints/Directives
Adds the Power
of Synthesis
Provides a
Foundation
Standard Tcl Commands
LeonardoSpectrum accepts all standard commands of the Tcl language. Tcl supports commands
that include: variable assignment, handling of lists and arrays, sorting, string manipulation,
arithmetic operations, (if/case/foreach/while) statements, and procedures.
3-3
LeonardoSpectrum Tcl Commands
Exemplar Logic has added a number of command extensions to the Tcl language to handle and
support the synthesis process. These commands are “built-in” and are executed the same as the
standard Tcl commands.
Setting Tcl Variables
You can set and unset variables with the Variable Editor from the Tools pulldown menu.
Global constraints and directives are communicated by the setting of variables and you can redirect the behavior of LeonardoSpectrum by changing the value of these varaibles.
Setting Attributes
An attribute is information that is attached to (owned by) an object in the LeonardoSpectrum inmemory design database. Attributes allow users to fine tune the synthesis process. Attributes
take precedence over variables.
An attribute has a name, a type, a value, and an owner. An attribute’s value typically describes a
characteristic about the design object. Many times the information is used to override a global
constraint that is applied to the design as a whole by setting a Tcl variable.
The concept of an attribute in an HDL language is the same. The attribute is a name/value pair
that is associated with, (“attached to”, “set on”, or “owned by”) a design object in the design. In
VHDL, the attribute construct may be used to associated a design object with an attribute
value and in Verilog, a //exemplar attribute directive may be use. If these attributes are
declared in the source files, the HDL attributes are converted to attributes in the in-memory
database and many time are translated as EDIF properties during an EDIF netlisting operation.
Methods for Using Commands With a Tcl Script
After you create a Tcl script with a standard text editor, you can source your Tcl script from
LeonardoSpectrum as follows:
•
The GUI Menu Bar File -> Run Script
•
The Shell Command Line with a Path to LeonardoSpectrum
Another common method of generating a Tcl script is to manually walk through a synthesis run
using the LeonardoSpectrum GUI. As part of the output, LeonardoSpectrum generates a history
file (.his file). You can also save and use a filtered version of this file which is a version with the
output comments removed. This is a valid Tcl script and can be used as a driver to repeat the
synthesis run automically on the next run. Typically, a user first edits a filtered transcript file to
add a clean_all command as the first line to initialize LeonardoSpectrum. It is also common
3-4
for a user to add “puts” commands throughtout the script that send progress messages to the
LeonardoSpectrum Information Widow as the script executes.
GUI Menu Bar File -> Run Script
On the menu bar click on File -> Run Script. Type in your Tcl script name or click on the
button and choose a Tcl script file. Your script file runs in the GUI Information window.
Command Line with Path to LeonardoSpectrum
Bring up your PC or UNIX window. In the LeonardoSpectrum install area, locate where
$EXEMPLAR points to the location of the software. Type the appropriate argument to source
your Tcl script:
UNIX: $EXEMPLVAR/bin/spectrum -file <my_tcl_script>
PC DVOS: $EXEMPLAR/bin/win32/spectrum -file <my_tcl_script>
3-5
Understanding the Tool Setup Environment
Understanding the Tool Setup
Environment
Setting the Place and Route Executable Pathnames
Before you can use the automatic place and route features of LeonardoSpectrum Quick Setup
FlowTab, you must set the path to the vendor’s place and route tools executable directory.
Figure 3-13 illustrates a typical path location for Altera Quartus tools. The name of the
environment variable may differ between platforms.
Figure 3-2. Setting the Place and Route Executable Pathnames
Tools > Options...
Startup Files
The exemplar.ini is the default startup file for LeonardoSpectrum and .by default, it is
located at the pathname $EXEMPLAR/data. You can customize the startup file as useful way to
pre-configure LeonardoSpectrum for daily optimizations. Refer to the following example:
exemplar.ini Startup File
# Define common aliases
alias lp list_design -ports
alias reportit {report_area; report_delay}
# Set synthesis working directory - Note directory
# slashes are UNIX style for all machines including PCs.
set_working_dir "C:/Exemplar/LeoSpec/v1999.1/demo"
3-6
# Disable Asynchronous Feedback Loops
set delay_break_loops TRUE
Startup files for UNIX
For a customized startup, you can place the exemplar.ini file in your working directory. The
commands in the file are automatically executed when LeonardoSpectrum is invoked.
Startup files for Windows
1. Place the exemplar.ini file in a personal or project folder that is not part of the
LeonardoSpectrum installation directory structure because all the LeonardoSpectrum
files are deleted and replaced with each new software install.
2. Edit the file $EXEMPLAR/data/exemplar.ini to add the following line to the bottom of
the file. You must add this line again after each new software install.
Source d:/<pathname to startup file>/exemplar.ini
Saving and Restoring a Project
LeonardoSpectrum has the powerful ability to “checkpoint” a design optimization in progress.
The term “checkpoint” refers to the ability to take a snapshot of the state of a project, save it,
then fully restore that state at a later point in time. The checkpointed state is called a project.
When you save and restore a project, you can avoid redundant runs and increase your
productivity.
Files Specific to Creating a Project
When you create and save a project, the following new files are added to your working
directory. A project consists of the following three files:
.xdb File
The .xdb file is a binary representation of your in-memory design. The XDB format is
Exemplar Logic’s proprietary format and can only be read by LeonardoSpectrum. If you are a
Level 3 user, this file is a “snap shot” of the present state of the synthesized design and can be
read into memory for future analysis and modification. If you are a Level 2 user, this file is
saved when you save the project, but is ignored when you restore the project because the Level
2 flow always re-reads the source files to start the flow.
3-7
.lsp File
The .lsp file stores the GUI settings of your project. This file is an ASCII file. The .lsp file
contains information like input file path, output file path, FlowTab options settings, and window
settings.
!
Caution
You should avoid editing this file. Editing this file may change the look and
feel of the GUI and also the synthesis run of your design.
.scr File
The .scr file contains several variables that affect the flow of synthesis.
Advantages of Using a Project
There are three main advantages:
1. Power of Check Pointing for Level 3: You can store the design and the design
implementation while you are working on a project. For example, you have optimized
your design and then decide to quit the tool. If you save the optimized design as a project
before you quit, then the optimization is not lost. Later, when you restore the project, the
optimized design is waiting for you to continue the task with further timing optimization
or generating reports. This checkpoint process proves to be very useful and time saving
with large designs.
2. Organizes a design and the synthesis runs in a systematic way: For example, you
want to try your design implementation on two different devices (parts) for your Altera
FLEX 6000 technology. Device 1 is EPF6016QC208 and Device 2 is EPF6016QC240.
In addition, you want to analyze the trade-off between report area and report delay for
each of the Altera FLEX 6000 devices. Now you try your design on Device 1 and
Device 2 and then save each as a project:
a. Device 1 - save as project: high_speed.
b. Device 2 - save as project: low_cost.
c. Later, during your team presentation, for example, you can quickly open the
high_speed.lsp and low_cost.lsp projects. You then click the Report FlowTab
to review the reports for area and delay for the two Altera FLEX 6000 devices.
3. Portable: take your project with you from platform to platform. For example, if you
are working on a module on a PC, and would like to continue the task on a UNIX
workstation, then you can! Caution: If you read in your input files, then you must
ensure that the files installed at the UNIX workstation are in the same directory structure
as the PC.
3-8
Invoking the Graphical User Interface
Starting a Project
Click File -> for the project related commands.
1. Start a new project and run the flow for this task.
2. Next save this project as: my_new_project.lsp
Note Level 3: You can save a project at any checkpoint during synthesis (for example,
after completing optimization), and then open the project and resume the task at a later
time.
3. File -> Recent Projects> shows your saved projects. Select your project,
my_new_project.lsp from this list; LeonardoSpectrum then loads the project.
Setting Aliases
LeonardoSpectrum allows you to set aliases to rename any LeonardoSpectrum command. The
exemplar.ini startup file is the most logical place to define commonly used aliases. For
example:
alias lp list_design -ports
Invoking the Graphical User Interface
When you invoke LeonardoSpectrum with the leonardo command, the tool comes up with the
Graphical User Interface (GUI). When you use the spectrum command, the tool comes up with
a command line interface and can be driven by batch mode options. Refer to the
LeonardoSpectrum Reference Manual Chapter 4 for details.
The leonardo Command
1. When invoking from a Unix shell, type the following:
% $EXEMPLAR/bin/leonardo
2. When invoking from a Windows Command Prompt, type the following:
C:\> leonardo
(Assuming that the PATH variable is set to Exemplar tree ../bin/win32/leonardo.exe)
3. Double-click on a Windows Shortcut with a Target set to the following path:
3-9
The Main Window at Startup
(Exemplar tree).../bin/win32/leonardo.exe
You can customize the leonardo invocation with command switches. Refer to the leonardo
command in Chapter 4 of the LeonardoSpectrum Reference Manual.
As shown in Figure 3-3, when you invoke LeonardoSpectrum for the first time, the main
window is maximized and displays the Tip of the Day.
Figure 3-3. Main Window at Startup
Tip of the Day
The tip of the day is a quick way for new users to get useful information. The tip of the day
opens automatically on the first invocation of LeonardoSpectrum. You can click forwards or
backwards to move through the tips.
3-10
SynthesisWizard
The SynthesisWizard consists of four steps that must be completed in the order presented. If
you are a first-time user, then the SynthesisWizard is recommended to get you started right
away. Continue to “SynthesisWizard Tutorial” on page A-1 for a description of each step.
The SynthesisWizard is one of three ways to synthesize your design; Quick Setup and
FlowTabs are the other two ways.
Note: RMB over the FlowTabs to open this popup:
Allow Docking (rearrange windows and bars as needed)
Hide (turn off windows or bars as needed)
FlowTabs on left (tabs appear on left side of main window)
FlowTabs on top (tabs appear at top of main window, default)
Float in Main Window (float FlowTabs in main window)
3-11
The Major Elements of the Main Window
The Major Elements of the Main Window
Figure 3-4 highlights the features of the main window.
Figure 3-4. Main Window
FlowTabs
Menu Bar
Flow Progress PowerTabs
3-12
Banner
ToolBars
FlowTabs window
Information window
Status Bar
The Main Window Header
Figure 3-5 shows a portion of the main window header. The items and icons on the header are
described in the following tables:
Figure 3-5. Part of Main Window Header
Click for Advanced FlowTabs
Clicking the Advanced FlowTab icon and the Quick Setup FlowTab icon toggles between the
two sets. If you click either of these icons twice, the FlowTabs window closes. Click a third
time and the FlowTabs window re-opens.
The choices on the File pulldown allow you to manage and save
files.
New (Ctrl+N)
File -> New opens an untitled window for a new file. This window
is for entering your design code.
Open... (Ctrl+O)
File -> Open.... The Windows Open utility comes up. Files
available under Files of type: are:
History File (*.his)
VHDL Files (*.vhdl;*.vhd;*.hdl)
Verilog Files (*.v;*.veri;*.h;*.ver)
TCL Files (*.tcl, *.scr)
Log Files (*.log)
EDIF Files (*.edif;*.edf; *.ed)
Report Files (*.sum)
HDL Files (*.vhdl; *.vhd; *.hdl; *.v; *.veri; *.h; *.ver)
All Files (*.*)
3-13
Save (Ctrl+S)
File -> Save to save any file currently in the Information Window.
If this is a new file, you are asked to specify a file name. Save
overwrites the current active file with new information.
Save As... (Ctrl+A)
File -> Save As... to name a new file or rename a file. The
Windows Save As utility opens. You can save as type: History
File (*.his) or All Files (*.*)
Save Command File...
Saving the transcripted commands to a *.tcl file can be a good
starting point to craft a Tcl script. If this is a new file, you will be
asked to specify the file name.
Run Script for Tcl
File -> Run Script to open Run Script. Refer to the
LeonardoSpectrum Reference Manual for Tcl script information.
Click button on Run Script to open the Windows Open utility.
Select a Tcl file (*.tcl) or All Files (*.*).
New Project
File -> New Project to add a new project file *.lsp for
LeonardoSpectrum. New project defaults to unsaved_project.lsp
in the File name: field. You are not prompted for a project name
and location. Before starting a new project, a check is made for
any unsaved current project. If an unsaved project is found, you
are prompted with “Save this workspace before starting a new
one?”
If you click Yes, the Save
Workspace As opens with
unsaved_project.lsp in the
File name: field.
If you click No, all objects
are cleared from memory
and the system is
initialized.
Click to clear memory
and initialize all settings
Open Project
File -> Open Project to bring up the Open utility. Files of type:
LeonardoSpectrum Workspaces (Project) (*.lsp) is the default.
Save Project
File -> Save Project to bring up Save Workspace As for Files of
type: LeonardoSpectrum Workspaces (Project) (*.lsp). You can
also write over your current design with new information.
3-14
Save Project As
File -> Save Project As to bring up Save Workspace As for Files
of type: LeonardoSpectrum Workspaces (*.lsp). When Save As
opens, the current project name is already selected. You are
prompted to confirm project or project file name and location.
When you click OK the entire design is saved to your project
folder or the default unsaved_project.lsp project folder. Note:
v1999.x projects cannot be read by v1998.x unless you set the
following variable in v1999.x to v1998.x:
xdb_write_version v1998.x
Change Working
Directory
File -> Change Working Directory. Use the standard directory
navigator to set up your new Working Directory. The new
Working Directory is saved as part of your design when you do
Save or Save As. This working directory is the starting point for
all relative pathnames, and will become the default output
directory. Specify an absolute (not relative) pathname for your
new working directory. Your current working directory is still
displayed on the right side of the status bar.
Recent Files> (not
available until after first
invocation)
Path(s) to your recent file(s) after first startup.
Recent Projects> (not
available until after first
invocation)
Path(s) to your recent project(s) after first startup.
Exit
File -> Exit to exit LeonardoSpectrum. You are prompted to
confirm.
The Edit menu provides you with a list of Windows editing
commands. The availability of these items depends on the activity
on the main window. For example, an active HDLInventor enables
the editing commands:
Undo (Ctrl+Z)
Edit -> Undo to reverse the last action.
Cut (Ctrl+X)
Edit -> Cut to remove selected text and place on clipboard.
Copy (Ctrl+C)
Edit -> Copy to copy text from clipboard to cursor position.
Paste (Ctrl+V)
Edit -> Paste to paste text from clipboard at cursor position.
Clear (del)
Edit -> Clear to delete selected text.
Select All (Ctrl+A)
Edit -> Select All to select all text.
Find (Ctrl+F)
Edit -> Find to find typed text. Search through files for specific
data.
3-15
Find Next F3
Edit -> Find Next to find the next occurrence of a word or phrase.
Replace (Ctrl+H)
Edit -> Replace to replace text.
Goto Line
Edit -> Goto Line to open Go to line. Enter line number from
displayed source code in HDLInventor.
The View pulldown gives you choices to enable or disable the
displays of:
Toolbar
Status Bar
Report Window
Analysis Pulldown
The Analysis pulldown is available when the HDLInventor is
active. Analysis allows you to:
Trace to Hierarchy (Cross probe from source code to schematic)
Show next (currently unavailable)
The Tools pulldown provides you with the following options:
Design Browser
Tools -> Design Browser to display ports, nets, instances,
registers, and primitive cells. Refer to the LeonardoInsight Users
Manual.
View RTL Schematic
(original, unmapped
design)
Tools -> View RTL Schematic - LeonardoInsight provides you
with a view of your original RTL schematic in the schematic
viewer. Refer to the LeonardoInsight Users Manual.
Note: Before you can bring up the schematic viewer you must
have an active design.
View Gate-Level
Schematic
Tools -> View Gate-Level Schematic - LeonardoInsight provides
you with a view of your gate level design in the schematic viewer.
Refer to the LeonardoInsight Users Manual.
Note: Before you can bring up the schematic viewer you must
have an active design.
3-16
Variable Editor
Tools -> Variable Editor Refer to page 3-31.
Options
Tools -> Options... This is you main access to changing the setup
sesion defaults for various LeonardoSpectrum windows. See page
3-27 for details.
Window pulldown provides you with task bar properties from
Windows to organize and manage several open windows:
Arrange All
Cascade
Tile Horizontal
Tile Vertical
Information - Read Only (Retrieve Information Window.)
Flows Pulldown
Flows pulldown provides you with the following:
SynthesisWizard (toggle steps 1 to 4) - Refer to SynthesisWizard
Tutorial on page A-1.
FlowTabs (toggle between FlowTabs and Command Line)
Help pulldown provides you with:
Help -> Help Contents
Opens a series of tabs that are designed around the Windows
properties. Help has indexes and context-sensitive choices. Help
can guide you through the entire synthesis process.
Help -> Show Extended
Help
This is help text at the top of the SynthesisWizard and FlowTabs.
Help -> Purchase
currently unavailable
Help -> Tip of the Day
Enable or disable Tip of the Day.
Help -> Video Tutorial
Open video tutorial.
Help -> View User
Manuals
List of available pdf documents.
3-17
Help -> About
Opens a display of the LeonardoSpectrum version number, Level
information, and Copyright. Use this information when contacting
technical support.
Exemplar’s Logo
Click on the logo to open your system web browser (for example
Netscape). The web address is: http://www.exemplar.com
Task Icons
The icons can be moved in groups to suit your needs. LMB over
an icon to popup a short balloon title. The entire icon title appears
in the status bar.
Show Hide Flow Bar
Toggle
A step by step wizard for
the synthesis of your
design
Refer to SynthesisWizard in Chapter 12.
Enable Cross Probe
Design Browser
View RTL Schematic
View Technology
Schematic
View Critical Path
Schematic
View the current summary
file
Opens the review window.
3-18
Interrupt the current run
Editing Icons
STOP - red, when completed STOP is grayed out.
The editing icons are available when the HDLInventor is active.
Create a new document
Same function as File -> New.
Open an existing
document
Same function as File -> Open.
Save the active document
Same function as File -> Save.
Print the active document
Print with Windows utilities.
Cut the selection and put it
on the clipboard
Same function as Edit -> Cut.
Copy the selection and put
it on the clipboard
Same function as Edit -> Copy.
Paste/insert clipboard
contents
Same function as Edit -> Paste.
Undo the last action
Same function as Edit -> Undo.
Redo the previous undone
action
Same function as Edit -> Redo.
Show extended help
Show extended help on the SynthesisWizard and FlowTabs pages.
3-19
The Information Window
The Information Window
The Information window is used to display the recorded session transcript and any generated
reports. Green, red, and blue buttons may appear in the left gutter (margin). Green indicates
information, Red indicates an error, and Blue signals a warning. You can double click on blue to
bring up the HDLInventor editor for finding and correcting the source of the error.
Figure 3-6. Example of a Simple Report
1.C heck the fit
2.C heck the tim ing
Printing the C ontentofthe Inform ation W indow
Y ou can printthe contentsoftheInfom ation w indow .Sim ply click the cursoranyw herein the
w indow ,then click thePrintericon in the m ain LeonardoSpectrum toolbar.A printerdialog
box w illappearto help you specify w here the inform ation should be printed.
3-20
The HDLInventor Source Code Editor
Note: Double click LMB over input file name on Quick Setup or Input FlowTabs to open
HDLInventor in the information window.
The HDLInventor is an interactive source code editor. The errors of syntax constructs found
during synthesis are highlighted in distinctive colors. You can easily interpret the color (red,
green, blue) for the type of warning or error. Errors, information, and warnings are annotated
directly to the integrated HDL source code editor, HDLInventor. The source code editor is
linked to the transcript in the message and report window. Line numbering identifies the line
number in the source code. An information message pops up as you move the mouse cursor
over the line number. Refer to Figure 3-7.
Note: Actual line numbers may differ from the examples in Figure 3-7.
Figure 3-7. Part of Source Code with Popup Message
Templates
The HDLInventor includes a list of templates that are predefined RTL templates. You can
instantiate a template directly into your HDL source code. You can also create custom
templates.
Note: LMB over highlighted file in the input window and double click to open HDLInventor.
This editor also contains a set of VHDL and Verilog templates that include a macro template
library of state machines, counters, ALUs, and technology specific comments. The editor allows
you to trace syntax errors directly back to your source code for quick and easy debugging. For
convenience, Table 3-1 lists the builtin templates.
3-21
Table 3-1. Builtin HDL Templates
Template
3-22
Function
Overall Structure
context clauses
library units
Architecture Body
_architecture_name
_entity_name
_signal_name
Finite State
Machine
State Machine with Asynch Reset
State Machine without Asynch Reset
Full Designs
Full Design Counter
Full Design flip flop
Full Design 3-State Buffer
Statements
Case Statement
Component Declaration
Component Instantiation Statement
Concurrent Procedure Call
Concurrent Signal Assignment
Statement
Conditional Signal Assignment
Constant Declaration
Entity Declaration
For Statement
Generate Statement (for generate)
Generate Statement (if generate)
If Statement
Library Clause
Package Declaration
Procedure Call Statement
Process (combinatorial logic)
Process (sequential logic)
Selected Signal Assignment
Statement
Signal Declaration
Signal Assignment Statement
Subtype
Type
USE Clause
Wait Statement
Variable Declaration Statement
Variable Assignment Statement
Editing Options
You can add templates, do edits, and toggle to add or remove bookmarks. Use these steps:
1. RMB over the HDLInventor to open this popup:
2. Undo, Redo, Cut, Copy, Paste
3. Toggle bookmark
4. Open Report Window
5. View line numbers
6. Insert template> (Refer again to Templates in this section.)
7. Highlight the desired code to apply Windows edit functions.
8. Click line of code for placing bookmark next to line number. Click again to remove
bookmark. Refer to Figure 3-8.
9. Click View line numbers to toggle line numbers on and off.
10. Click Insert template> to bring up the template list. Click to select and insert list. The
template requires editing. Refer again to Table 3-1.
Editing Options - Transcript and Filtered Transcript
You can toggle to add or remove bookmarks and to turn messages on and off, for example. Use
these steps:
1. RMB over left margin of either the Transcript or Filtered Transcript to open this popup:
2. Toggle Bookmark
3. View Line Numbers
4. Save (Transcript only)
5. Save Filtered Transcript
6. RMB over left margin of the Filtered Transcript to open this popup list:
7. Show Transcript
8. Show Errors
3-23
9. Show Warnings
10. Show Information
11. Show Commands
Figure 3-8. Example HDLInventor Template and Bookmarks
More Editing Options
Use these steps to edit your code:
1. Click or double click on a red, green, or blue button. Refer to Figure 3-9.
3-24
2. Click to bring up line numbers. Edit source code as needed.
Figure 3-9. HDL Source Code Example
Note: Example lines 449 and 502 in Figure 3-9 (“line 449: Warning,...”; line 502: Warning,...”)
are highlighted with a blue button. Double click on button 449 with the left mouse button to
3-25
open the HDLInventor. Figure 3-10 shows the lines of code for line number 449. The red button
indicates a warning and the green button indicates information.
Figure 3-10. HDL Code with Editor Line Number Example
Printing the C ontentofthe H D LInventorW indow
Y ou can printthe contentsoftheH D LInventorw indow .Sim ply click the cursoranyw herein
thew indow ,then click thePrintericon in them ain LeonardoSpectrum toolbar.A printerdialog
box w illappearto help you specify w here the w indow inform ation should be printed.
3-26
Changing the Default Session Settings
You can change the session settings from the Tools > Options... pulldown menu
Main Session Settings
Figure 3-11. Setting Options for the Main Session
3-27
Option
Description
Run Wizard mode on startup:
When you start up, SynthesisWizard does not
open automatically unless you select this box.
You can also set this option on Input File(s).
Automatically save and restore session
settings
Settings on all session settings are saved. Your
synthesis setup is saved. Default is selected.
Automatically load previous project
(off by default)
When this selection is off, LeonardoSpectrum
opens without any project loaded. This default
is identical to File -> Open Project. When
Automatically load previous project is
selected, LeonardoSpectrum then opens the
previous project, if any.
Automatically save and restore Current
Working Directory
(on by default)
When you start up LeonardoSpectrum, the
current working directory is restored. If
Automatically save and restore Current
Working Directory is off, then a default
current working directory is available.
Automatically Load Statistics after synthesis:
The summary of your synthesis run is loaded.
Sounds:
Music plays when you start up.
Run License Query at startup.
Asks if you want to run with Level 1, 2, or 3.
Run License Query at startup
Disabled if you disable
Run license selection next time
Show page help
Displays text at top of FlowTabs and
PowerTab screens.
Exemplar Variable:
Click to open the set EXEMPLAR variable
browser.
Web Browser Location:
UNIX only: Click to open web browser
location. Invokes your web browser when you
click on a technology logo.
3-28
Browser View Options
Figure 3-12. Design Browser View Options.
Schematic Viewer Options
The display options for the schematic viewer are documented in the LeonardoInsight Users
Manual.
3-29
Place and Route
Before you can use the automatic place and route features of LeonardoSpectrum Quick Setup
FlowTab, you must set the path to the vendor’s place and route tools executable directory.
Figure 3-13 illustrates a typical path location for Altera Quartus tools. The name of the
environment variable may differ between platforms.
Figure 3-13. Setting the Place and Route Tools Path Location
Tools > Options...
3-30
Using the Variable Editor
You can change the values of Tcl variable from the Tools > Variable Editor... pulldown menu
Figure 3-14. The Variable Editor
3-31
Option
Description
Variable Name: Select from pulldown.
These variables are also documented in
alphabetical order in the LeonardoSpectrum
Reference Manual.
Variable Value:
Use default FALSE or type in a value.
Variable Type:
Use default Boolean or type in a variable
type.
Show Advanced Variables. These are typically uncommon
variables.
When Show Advanced Variables is selected, the
advanced variables appear in the Variable Name:
pulldown. For example:
apex_wysiwyg_support is an advanced
variable.
Note: The Variable editor allows you to select and add variables without typing. Refer to the
LeonardoSpectrum Reference Manual, Variables chapter, for a printed list. Advanced variables
are not printed in this list.
3-32
Chapter 4
Loading a Technology Library
This chapter provides a brief introduction to the topic of loading a technology library. You can
find more in-depth information about synthesizing for a specific technology in the in the
following chapters:
•
Altera FLEX Synthesis on page 10-1
•
Altera MAX Synthesis on page 11-1
•
Altera APEX Synthesis on page 11-1
Loading a Technology Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Technology Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Lookup Table Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Global Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
I/O Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
The Technology FlowTab - FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Advanced Settings PowerTab - FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
4-1
In order for LeonardoSpectrum to map your design to a specific technology, you must first load
a library for a specific technology. This library includes both the technology-specific cell
definitions and the modgen operator implementations. Both libraries are automatically loaded
when you select a technology from the list on the Technology FlowTab.
Technology Mapping
Introduction
This section describes the mapping techniques used in LeonardoSpectrum to map
combinational and sequential logic. Also, I/O pad assignments and setting constraints through
the constraint file are described. When running LeonardoSpectrum in the default mode, all I/O
signals are assigned pads. The pads are selected from the target technology library during the
technology mapping phase. If more than one size of the same pad is available,
LeonardoSpectrum chooses the smallest pad size. If the target library contains complex I/Os I/Os with registers in the I/O cell - then LeonardoSpectrum maps these complex I/Os as
required.
Each architecture has different constraints on the usage of complex I/Os. For manually assigned
I/Os, you are responsible for the validity of the output design. You can override the assignments
done by LeonardoSpectrum and assign pads manually. This can be done selectively on each
pad.
4-2
Technology Mapping
Lookup Table Mapping
During the optimization process, combinational logic is decomposed to individual logic
functions. LUT mapping fits these logic functions into a minimal number of LUTs while
meeting timing requirements. For each of the LUT based technologies, a different LUT
mapping is performed. LUT mapping finds an optimal coverage that maps these logic functions.
Table 4-1. LUT Mapping Options for Altera FLEX
Advanced Settings
On/Off
Interactive Command Line Shell
Batch Mode
Map Cascades
on
default
default
off
set altera_use_cascades false
-nocascades
During LUT mapping, Map Cascades controls the mapping of logic to cascade gates for
Altera FLEX 6K, 8K, 10K.
4-3
Global Buffers
Global Buffers
LeonardoSpectrum assigns clock buffers to I/O signals with high-fanouts. This is useful to
speed up clock-to-output timing and input-to-register timing. Also, LeonardoSpectrum checks
that assigning a certain clock buffer does not violate any design rule of the target technology.
I/O Mapping
During I/O mapping, LeonardoSpectrum assigns PADs to all I/Os in the top level of a design.
LeonardoSpectrum can map input buffers, output buffers, tri-state buffers, bi-directional
buffers, and complex I/O cells. LeonardoSpectrum also maps global buffers for clock lines and
high fanout input pads. There are several technology independent options on the Advanced
Settings PowerTab which controls I/O pad assignments. These options affect the complete
design, not just individual I/Os.
4-4
The Technology FlowTab - FPGA
Loading the Technology Library is the first step in the synthesis process.
Figure 4-1. Technology Settings - FPGA
Click to View the
A ltera W eb Site
Option
Description
Part:
This is the part number of your target device. LeonardoSpectrum selects the
part number for you or you can select another from the pull down list
(v50bg256).
Speed:
This the speed grade of your target device. LeonardoSpectrum selects the
speed (process) for you or you can select another from the pull down list .
Wire Load
This is the table that will be used for estimated routing delay values. Actual
routing delays will be determined by the place and route tools.
4-5
Advanced Settings PowerTab - FPGA
Figure 4-2. Advanced Setting PowerTab for Altera FLEX6K
GUI Option
Map Cascades
Lock LCells
4-6
Option
on/off
Interactive Command Line Shell
Batch Mode Option
on
default (true)
default (true)
off
set flex_use_cascades false
-nocascades
on
default (false)
default (false)
off
set dont_lock_lcells true
-dont_lock_lcells
Lock LCells
If Lock LCells is not selected, then this directs LeonardoSpectrum not to force
LCell buffers in the output EDIF netlist. You can then use MAX+PLUS II to
map the combinational logic into LCells. FAST is the recommended setting for
MAX+PLUS II GLOBAL_PROJECT_SYNTHESIS_STYLE.
Map Cascades By default this option is selected. LeonardoSpectrum then maps to cascade gates
where applicable.
Exclude Gates
Scroll through the Exclude Gates list and highlight the gate(s) as needed. The listed Altera FLEX
6K gates are:
Latch, DFFC, FF, DFFP, DFFE, TRI, TRIBUF, CBUF, SCLK, Global, INBUF, OUTBUF,
BDBUF,
TFF, TFFC, TFFP
The selected gate(s) are excluded from the library when your design is mapped to the technology.
In addition, excluded gates are not saved as part of a Project.
Max Fanout:
Use the Max Fanout field on the GUI to override the default max fanout load
specified in the library. However, a synthesized netlist with high fanout nets may
be a problem for the place and route tool. The place and route tool usually splits
the net arbitrarily. High fanout nets can cause significant delays on wires and
become unroutable. On a critical path, high fanout nets can cause significant
delays in a single net segment and cause the timing constraints to fail.
To eliminate the need for splitting of the net by the place and route tool, the
synthesis tool must maintain a reasonable number of fanouts for a net.
LeonardoSpectrum tries to maintain reasonable fanout limits for each target
technology. Default fanout limits are derived from the synthesis library.
Note: The LUT buffering and replication is supported for the Altera FLEX
6/8/10 and 10KA/KE/KB technologies.
General Rule
LeonardoSpectrum maintains reasonable fanouts by replicating the driver which
results in net splitting. If replication is not possible, the signal is buffered. The
buffering of high fanout primary input signals is an example. Buffering the
signal causes the wire to be slower by adding intrinsic delays.
User Switches
On the interactive command line shell type:
set lut_max_fanout <integer>
On specific nets, you can set an attribute to control the max_fanout value:
set_attribute -net <net_name> -name lut_max_fanout -value <int>
Note: Setting this attribute takes precedence over any global fanout
specifications.
4-7
4-8
Chapter 5
Reading Your Design
The LeonardoSpectrum in-memory database is created by reading one or more design source
files into memory. Design files are read in a two-phase process. First, a file is analyzed (checked
for proper syntax), then elaborated (synthesized into an in-memory database composed of
generic gates and black box operators). The read command does both analyze and elaborate
automatically.
Reading Your Design into Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Opening Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Reading Custom VHDL Libraries and Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Understanding the In-Memory Design Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Understanding the In-Memory Design Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
How LeonardoSpectrum Infers and Implements Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Understanding Modgen Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Understanding Pre-Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
What is Pre-Optimization? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
The Input FlowTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
The VHDL Input PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
The Verilog Input PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
The EDIF Input PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
5-1
Reading Your Design into Memory
Reading Your Design
Reading Your Design into Memory
Opening Design Files
LeonardoSpectrum does not read pre-compiled HDL designs from disk. Instead, the design
source files are read directly into memory where LeonardoSpectrum builds an EDIF-like inmemory database. The design source files do not have to reside in a specified working directory.
They may reside in any location and may even reside in more than one location. You simply
click on the Open files button, navigate to and select a source file, then click Open. The file(s)
are listed in the order in which they will be read.
Verilog designs can be read into LeonardoSpectrum in any order. LeonardoSpectrum supports
auto-top detection which automatically locates the top-level module so no particular file order is
required as in VHDL.
For VHDL source files, order is important. VHDL files must be read in bottom-up order, i.e.,
lower-level blocks must be read before the top level blocks. If an opened file is out of place in
the list, you may drag the file into the correct position with the mouse cursor. The files are read
from the top of the list to the bottom.
Reading Custom VHDL Libraries and Packages
Many standard VHDL libraries and packages are build into LeonardoSpectrum and don’t have
to be specified in the Open file list. If your design references custom libraries and packages,
then you must Open these package source files for reading before your design files are read. The
methods for doing this are fully discussed in the LeonardoSpectrum HDL Synthesis Manual
starting on page 4-4.
5-2
Reading Your Design
Understanding the In-Memory Design Data Model
Understanding the In-Memory Design
Data Model
The LeonardoSpecturm in-memory design data base is modeled after the EDIF design data
model. All design data is stored in a set of EDIF-type libraries which start at the root. A library
contains a list of cells, and a cell contains a list of views. In comparison to VHDL, a cell is
equivalent to an ENTITY and a view is equivalent to an architecture. Just as most VHDL
entities have only one architecture, most cells have only one view. Views are the basic building
blocks of your design and are equivalent to a schematic sheet. A view can have three types of
objects; ports, nets, and instances. A view is the implementation or contents of a single level of
hierarchy.
Examples:
•
•
•
•
When you read a VHDL description into LeonardoSpectrum, your VHDL entity
translates to a cell, and the VHDL architecture (contents) translates to a view. By
default, the cell is stored in an EDIF-style library called work (by default). You can
change the name of this library if you wish.
When you load a technology library into LeonardoSpectrum, it becomes an EDIF-type
library in the design database, which contains all of the cells of that technology. Your
design in the work library will reference this technology library as an external EDIF
library.
LeonardoSpectrum creates an EDIF style library of PRIMITIVES automatically. This
library represents all primitive logic functions that LeonardoSpectrum may require when
compiling or elaborating HDL (VHDL and Verilog) descriptions.
LeonardoSpectrum also automatically creates an OPERATORS library. This library
contains operator cells (adders, multipliers, muxes). When compiling HDL descriptions,
these operators are generated when needed.
In summary, the following objects are typically contained within a view and are used to
represent netlists and hierarchies in a design:
•
A view has ports, nets and instances.
•
A port is a terminal of a view.
•
An instance is a pointer to a view.
•
A net is a connection between ports and/or port instances (pointer to the port of the view
under an instance).
5-3
Understanding the In-Memory Design Data Structure
Reading Your Design
Understanding the In-Memory Design
Data Structure
The LeonardoSpectrum Design Browser allows you to graphically browse through all inmemory libraries and the design hierarchy. Understanding the object naming conventions will
help you understand some of the commands that appear in the transcript and will also prepare
you to write Tcl scripts in the future.
To identify an object in the design database, LeonardoSpectrum uses a formalized design
naming convention. Any object in the database is accessible from a single root (the set of
libraries). The root is identified by the design name . (dot). A library is identified by the design
name:
.library_name
The general design name for a view is:
.library_name.cell_name.view_name
Wildcards and regular expressions are accepted and expanded in design names to identify
multiple objects simultaneously.
LeonardoSpectrum also has the concept of a “present design”. This is a design name that
identifies the top of your design hierarchy. When LeonardoSpectrum starts up, the default is set
to the root (.). After you read in a design, the “present design” is set to the top level view as
described in the source file(s).
The formalized naming convention can uniquely identify libraries, cells and views in a single
name. However, since a view can contain three different types of objects (ports, nets, instances),
there may be a problem identifying these uniquely. For example, the name:
.l.c.v.x
does not identify an object x in view v of cell c in library l as a port, net or instance. To work
around this problem, the list_design command (and other commands that accept nets, ports
or instances) all have an option that you can use (-port , -net, or -instance) to identify an
object type.
5-4
Reading Your Design
Understanding the In-Memory Design Data Structure
The result of list_design is a (Tcl) list, which can easily be used in scripts. The following
example script reports how many cells are in each library in the database:
for each i [list_design .] {
set the_length [llength [list_design $i]]
puts “library $i contains $the_length cells”
}
After the demo/mancala.vhd file, for example ($EXEMPLAR/LeoSpec/demo), has been read and
the flex10 library loaded, this script will produce the following output:
library
library
library
library
.PRIMITIVES contains 19 cells
.work contains 2 cells
.OPERATORS contain 6 cells
.flex10 contains 925 cells
The object separator is programmable; the default is . (dot). You can change the separator by
setting the Tcl variable list_design_object_separator. For example, the following script
prints the present design name, changes the object separator, and prints the design name again:
puts “The present design is [present_design]”
set list_design_object_separator /
puts “The present design is [present_design]”
Produces the output:
The present design is .work.mancala_32.exemplar
Info: setting list_design_object_separator to /
The present design is /work/mancala_32/exemplar
LeonardoSpectrum notifies you with a message when it recognizes the setting of a
LeonardoSpectrum built-in variable, rather than a normal Tcl variable.
You can use the following example commands to list commands and variables in the interactive
command line shell:
help (lists all commands)
help present_design (lists options and information)
help list* (lists all list commands)
help -variables (lists all variables)
help -var write* (lists information about write
variables)
5-5
How LeonardoSpectrum Infers and Implements Operators
Reading Your Design
How LeonardoSpectrum Infers and
Implements Operators
When LeonardoSpectrum reads an HDL design, it infers arithmetic and relational operators
(e.g. adders) and implements the operators as blackboxes (there is no underlying functionality)
in the design. LeonardoSpectrum does not implement operators until global area optimization
when it replaces these blackboxes with technology-specific netlists (from the Modgen Library).
Keeping operators as blackboxes reduces the database size and “reading” runtime.
Each blackbox operator uses a naming convention to convey parameter information such as
(type, size, sign, carry). for example:
add_16u_16u_0 -- 16 bit adder, unsigned operands, no carryout
gte_8s_8s -- 8 bit greater than, signed operands
Understanding Modgen Libraries
A Modgen library contains implementations of technology-mapped operator architectures to
meet area and performance specifications, and in general produce smaller or faster operator
implementations compared to generic cell implementations. To take advantage of area/speed
trade-offs, most operators have more than one implementation.
Operator implementation has a great effect on the resulting quality of an optimized design.
Also, the structure of idea operators differs greatly depending on whether area or performance is
the main goal of optimization. This is why most optimization tools on the market today have
special ways of handling operators.
In LeonardoSpectrum, the term “operator” refers to arithmetic operators such as add, subtract,
multiply, and increment. Also, comparison operators like equal and less-than-or-equal are
implemented. Shifts and rotates are considered operators, and have corresponding Modgen
generators as well.
Consider the adder. Depending on design requirements, a designer might choose a ripple adder
(slow, but very compact) or a full carry lookahead adder (much faster, but about twice as much
logic). These types of trade-offs are what Modgen allows.
Since most critical paths include operators, using a Modgen library enables the synthesizer to
produce a better starting point for optimization and decrease synthesis runtimes (since operators
are implemented with technology cells instead of generic primitives, the optimizer does not
have to run on modgen operator blocks). You can also read user-defined module generator
library files written in VHDL (using the load_modgen command). The LeonardoSpectrum
HDL Synthesis Manual presents guidelines for creating your own modgen components.
5-6
Reading Your Design
Understanding Pre-Optimization
Understanding Pre-Optimization
What is Pre-Optimization?
After the generic RTL-data base is created, LeonardoSpectrum does what is called preoptimization (technology-independent optimization). During this process, the following is
accomplished:
•
Components are extracted. Objects such as counters, decoders, RAMs and ROMs are
separated from generic logic. New views of these items are created.
•
Operators that are “disjoint” (only used in different clock cycles) are shared
•
Unused logic (logic that doesn’t affect the output signals) is removed
•
Wide XORs and comparators are optimized by removing common sub-expressions
5-7
The Input FlowTab
Reading Your Design
The Input FlowTab
Figure 5-1. The Input FlowTab
5-8
Reading Your Design
The Input FlowTab
A typical sequence for using this FlowTab is to:
1. Set the working directory.
This defines the place where all the generated output files are placed.
2. Open files for input.
Files may be opened from any directory for reading. The list of open files is read from
top to bottom. Order is important when reading VHDL files. You may “drag” files into
the correct order with the mouse pointer, once the files are open for reading.
3. Click Read to read your entire design into the in-memory database.
You have the option to select the state machine encoding style. You may also turn off resource
sharing. This is typically done when reading an already optimized module.
RMB over your input file to popup the following shortcuts:
Add Input File: (Opens Set Input Files.)
Reverse Order
Toggle Selection
Select All
Open File: (Opens file in the Information Window.)
Set Work Library: (Opens Change work library.)
Set Technology (source): (Clears or Opens lists for FPGA, CPLD, and ASIC)
Set File Type: (Opens lists of output formats including XDB.)
Remove: (Click to remove highlighted input file.)
Remove All: (Click to clear the entire workspace.)
Note: Before compiling, LeonardoSpectrum checks (analyzes) for syntax errors in your source
code. These errors, if any, are highlighted in the HDL editor window with a message.
5-9
The Input FlowTab
Reading Your Design
The VHDL Input PowerTab
Figure 5-2. The VHDL Input PowerTab Options
Option
Description
Use this PowerTab when your input design is in VHDL format. These options are used when
reading a design from Input tab without selecting o Analyze Only. These options apply only to
read. Refer to the example screen settings.
Top Entity:
Defines the top level of design hierarchy. If blank, the last entity
read in is used. The top level is the last one found in the input
file(s). Override this rule with the Entity option and specify the
name of the top level entity.
Architecture:
Specify name in lower case
only.
When used with Entity option, defines the top level of design
hierarchy. If blank, the last architecture that can be synthesized is
used.
Generic (data_width=5)
Sets the value for specified generics in the format
<generic>=<value> [<generic>=<value>...]
Multiple generics may be specified in this format.
VHDL Style
5-10
VHDL 93
is read.
VHDL_87 either the 1993 or 1987 style of VHDL
Reading Your Design
The Input FlowTab
The Verilog Input PowerTab
Figure 5-3. The Verilog Input PowerTab Options
Option
Description
Use this PowerTab when your input design is in Verilog format. LeonardoSpectrum applies
autotop detection to Verilog files. Specify the name of the top module to override this rule.
Refer to the following example settings.
Top Module:
my_top_module
Parameters
top_module_noopt
The Parameters field allows you to set the value for
parameter(s). Multiple parameters may be specified:
[<parameter>=<value>[<parameter>=<value>...]
These are variable parameters like RAM, ROM.
Full Case:
This is a true full synthesis directive. Select to guarantee that
the case statement is interpreted as a full case. If a default
assignment was not used, then this option prevents the
implementation of extraneous latches.
Parallel Case:
This is a parallel synthesis directive. Select to guarantee that
the case statement is parallel. A multiplexer may be the
preferred implementation when case conditions are mutually
exclusive. A multiplexer may also be the preferred
implementation instead of priority encoding a state machine.
5-11
The Input FlowTab
Reading Your Design
The EDIF Input PowerTab
Figure 5-4. EDIF Input PowerTab Options
Option
Description
You should use this PowerTab when your input design is in EDIF format.
Design
This is the top level of the
design to read.
5-12
priority_encoder.edf
LeonardoSpectrum expectsthedesign nam eto besupplied in
the ED IF fileusing the ED IF “design” construct.Y ou can
overridethisrule by specifying thenam e ofthe root(ortop
level)cell.
Chapter 6
Setting Timing Constraints
LeonardoSpectrum allows you to control the optimization and mapping process by setting
timing constraints. A common synthesis flow is to first optimize a design for the smallest area
(without setting any timing constraints), then check for the proper fit. Normally, you should try
to fit your design into 80% of the chip’s capacity without any timing violations. If there are
violations, you can set timing constraints on the reported critical paths using the methods
described in this chapter. When you re-optimize with these constraints applied,
LeonardoSpectrum will work hard to eliminate the violations on these paths. This usually
results in more hardware on the critical paths (due to the increase of parallel structures), but
only the critical paths are affected, not the whole design.
You can set timing constraints using the Constraints FlowTab and its associated PowerTabs.
The PowerTabs give you a more refined degree of control over the settings. Later you will learn
how to save the constraint settings in a constraints file (a .ctr file) that can be loaded into
memory during future Tcl script-driven or batch mode operations.
Setting Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Setting Global Timing Constraints on Sub-Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Setting Clock Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Setting Clock Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Multiple Synchronous Clocks per Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Setting the Input Arrival Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Setting Output Required Times: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Setting Multicycle Path Constraints: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Known Problem with Setting Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
False Path Constraints: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Constraining Purely Combinational Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Constraining Mixed Synchronous and Asynchronous Designs . . . . . . . . . . . . . . . . . . . . 6-13
Setting Multicycle Path Constraints: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
The Constraints FlowTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Clock Constraints PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Input Signal PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Output Signal PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Internal Signal PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-16
6-18
6-20
6-22
6-24
6-1
The Module PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
The Path Constraints PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
The Report Constraints PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
6-2
Setting timing constraints in LeonardoSpectrum can be as simple as specifying the target design
frequency or as powerful as indicating multi-cycle paths between flip flops. Timing constraints
indicate the desired target arrival and required times used for setup and hold analysis.
Constraints can be applied after the design is read into LeonardoSpectrum and before
optimization. LeonardoSpectrum assumes intuitive defaults. At a minimum, you must define
the clock, input port arrival times, and output port required times.
Note: LeonardoSpectrum does not support timing constraints relative to a particular clock.
Everything is referenced to time zero. This includes input arrival times and output setup times
without any reference to a particular clock.
Setting Global Timing Constraints on Sub-Blocks
Like all Tcl variables, Global timing variables apply to the present design in memory. When
you explicitly defined timing constraints, these explicit constraints override the global
constraints. Setting these variables saves considerable time and effort when you perform
bottom-up optimizations. Refer to Figure 6-1.
Figure 6-1. Setting Global Timing Constraints on Sub-Blocks
re g is te r2 o u tp u t
in p u t2 re g is te r
re g is te r2 re g is te r
in p u t2 o u tp u t
Guideline: Set the input2register and register2output variables to one-half of the clock
period. This ensures that the boundary logic of sub-blocks meets timing when combined into the
top-level design.
set
set
set
set
register2register 20
input2register 10
register2output 10
input2output 10
6-3
Resets
Sequential element set and reset pins are automatically blocked during timing analysis. No
special settings or constraints are required to block reset timing paths.
Clocks
LeonardoSpectrum supports one or more synchronous clocks. However, multiple asynchronous
clocks are not supported.
Setting Clock Constraints
Clocks define timing to and from registers. When the clocks are not defined, all registers are
assumed to be unconstrained. Therefore all combinational logic between registers is ignored
during timing optimization. When you define a clock, you have effectively constrained the
combinational logic between all registers to one clock period. Refer to Figure 6-2.
Figure 6-2. Clock Constraints
The clock constraintw ill
define the required tim ing
for alllogic betw een
flops
D
data
Logic C loud
A
Q
Logic C loud
B
D
Q
FF1
FF2
clk
clk
clock
The logic between FF1 and FF2 is constrained to one clock period. If the clock period is 50ns,
then Logic Cloud B has approximately 50ns minus setup of FF2 to meet timing.
LeonardoSpectrum describes clocks by using three basic commands:
clock_cycle <clock_period> <primary_input_port>
pulse_width <clock_pulse_width> <primary_input_port>
clock_offset <clock_offset> <primary_input_port>
By default, the clock network is assumed to be ideal - with no clock delay. The clock arrives at
the same time between all flops. To change the clock network propagated delay, you can set the
propagate_clock_delay variable to TRUE.
6-4
Example of clock constraints:
In the first example in Figure 6-3, the clock period is defined as 40 ns and attached to clock port
“clk”. The default duty cycle is 50%, or a clock pulse width of 20ns. The second example shows
how to change the pulse width to 15ns. The third example demonstrates how one can offset the
clock. This is useful for specifying a clock skew relative to zero.
Figure 6-3. Clock Network
0.0
20.0
40.0
clock_cycle 40 clk
15 ns
clock_cycle 40 clk
pulse_w idth 15 clk
5 ns
clock_cycle 40 clk
pulse_w idth 15 clk
clock_offset 5 clk
15.0
5.0
45.0
Setting Clock Skew
When constraining a design you may want to accommodate clock skew. Clock skew is often the
result of a clock delay incurred by the input clock driver. This may effect the offsetting of the
clock by the skew value. LeonardoSpectrum does not provide a method to directly input a value
for clock skew, however the clock may be offset by the skew value to create the same effect for
timing analysis and optimization.
6-5
Figure 6-4. Clock Skew
InputLogic
C onstraintis
"R elaxed"
data
O utputLogic
C onstraintis
"tightened"
R eg to R eg logic
rem ains unchanged
Logic C loud
A
D
Logic C loud
B
Q
D
FF1
Q
Logic C loud
A
FF2
clk
clk
clock
C lock S kew due
to C lock D river
Figure 6-5. Clock Skew Timing
clock
input_arrival
output_required
M ore Tim e
Less Tim e
offset_clock
Setting a clock skew reduces the input arrival time by the skew value. This provides a relaxed
constraint for the optimization of that logic. Clock skew does not effect register-to- register
logic since all flip flops are subject to the same skew. Clock skew reduces the output-required
time which tightens the timing constraint on the output logic by the skew value.
Multiple Synchronous Clocks per Block
The timing analyzer for LeonardoSpectrum supports only 1 clock per block for exhaustive
timing analysis. Designs with multiple synchronous or asynchronous clocks can be analyzed
6-6
using a technique involving the clock offsets. Refer to Figure 6-6, where Block A and Block B
are each driven by different, synchronous clocks.
Figure 6-6. Multiple Synchronous Clocks
C lo ck d o m a in A
D
data
Logic C loud
A
Q
Logic C loud
B
D
FF1
Q
FF2
clk
clock_a
10ns period
S ignalcrosses
clock dom ains
C lo ck d o m a in B
D
data
clock_b
Logic C loud
A
Q
Logic C loud
B
D
Q
FF1
FF2
clk
clk
15ns period
Figure 6-7. Synchronous Clocks
0ns
5ns
10ns
15ns
20ns
25ns
clo ck_ a
10 ns delay
betw een
1stcycle acive
edges
5 ns m inim um tim e
betw een active edges
occurng in the 2nd
cycle
clo ck_ b
5 ns
offset
1 2 .5 n s
20ns
2 7 .5 n s
clo ck_ b (o ffs e t)
6-7
Procedure for setting multiple, synchronous clock constraints
1. Draw the clock waveforms starting from time zero and complete several clock cycles.
Manually determine the minimum time between active edges - this may not occur in the
first clock cycle - this depends on how the active edges meet. In Figure 6-6, the
minimum time is 5 ns.
2. Determine what the time between active edges is during the first clock cycle. The delta
is 10 ns in Figure 6-6.
3. Subtract the minimum active edge time from the first cycle active edge time. This
number becomes the clock offset for the clock of signal origin. Set the appropriate clock
offset:
> clock_offset 5 clock_b
CAUTION: Setting the clock offset alters the input arrival timing. If you set an input arrival
time of 6 for example, then the clock offset has essentially added that number to the offset (6 +
offset). You now have to adjust the input arrival time to correct for the offset by adding the
offset to the input arrival.
Multiple Asynchronous Clocks
LeonardoSpectrum does not analyze timing for signals that cross between two or more
asynchronous clock domains. This is because the clocks do not have a defined relationship. The
best way to handle this is to ignore all timing between signals that cross between asynchronous
clock boundaries. This can be accomplished by assigning a clock offset to the clock of signal
origin that is equal to or greater than two clock periods. To disable timing between clock
boundaries in Figure 6-7 issue the following command:
> clock_offset 30 clock_b
Input arrival times, if any, need to be increased by the amount of the clock offset.
6-8
Setting the Input Arrival Time
The input arrival time specifies the maximum delay to the input port through external logic to
the synthesized design.
arrival_time <delay_value> <input_port_list>
Figure 6-8. Input Arrival Time
D ata arrives at
inputport"data"
3ns after rising
edge of clock clk> Q delay
B lock A
ExternalV irtual
C ircuit
Logic
C loud A
D
Q
Q
D
3ns
FF2
FF1
clk
clk
clock period of 10
ns is attached to
inputport"clk"
10ns
clk
3ns
data
In Figure 6-8, data arrives approximately 3 ns after the rising edge of clock. Therefore, to
accurately constrain the input port data, you must apply the following constraint:
> arrival_time 3 { data }
If the clock period were defined as 10ns, then the setup of FF2 must be added to the
combinational delay of logic cloud A, and needs to be 7ns to meet timing.
Note: All input arrival times start at time zero and cannot be specified relative to a particular
clock edge. To adjust for a particular clock edge, you must add the clock offset to the arrival
time.
6-9
Setting Output Required Times:
The output required time specifies the data required time on output ports. Time is always with
respect to time zero. In other words, output required time cannot be specified relative to a
particular clock edge
> required_time <required_value> <output_port_list>
Refer to Figure 6-9.
Figure 6-9. Output Time
R equired Tim e directly
specifies the tim ing through
logic cloud A
D
Q
Logic C loud
A
clk
When specifying required times all constraints are assumed to begin at time zero. This
eliminates the need to specify a constraint relative to a particular clock edge. The specified
required time becomes the time constraint on the output logic cloud shown as logic cloud A in
Figure 6-9.
> required_time 7 { d1 }
6-10
Setting Multicycle Path Constraints:
If you have a combinational logic path that, by design, has a delay that is more than one clock
cycle, you can define this constraint by specifying a multi-cycle path in LeonardoSpectrum.
Consider the circuit in the illustration below:
Data only changes every
other clock cycle
D Q
FF1
Logic
Cloud
clk
Need to “relax” timing
requirement for logic
cloud to 2 cycles
D Q
FF1
clk
clock
data
valid for 2 clock cycles
To appropriately constrain the above design, you should apply the following constraint:
set_multicycle_path -from {FF1} -to {FF2} -value 2
M ethod for Specifying M ultiple M ulticycle Paths
Ifyou have m orethan one path leading from ortw o a registerthathasthe sam e m ulticycle
specification,then you can setthe constraintw ith one com m and. Considerthe follow ing
exam ples:
Exam ple 1
A ssum e thatthreem ulticycle pathsfan outfrom the starting registerFF1:
set_multicycle_path -from {FF1} -value 2
Exam ple 2
A ssum e thattw o m ulticyclepathsfan into an ending registerFF3:
set_multicycle_path -to {FF3} -value 2
6-11
K now n Problem w ith Setting M ulticycle Paths
D ue to the auto_disolve function,the hierarchalnam eofa registerm ay change during global
area optim ization.Ifyou specify the nam eofa registerin the set_multicycle_path
com m and,thatnam em ay becom einvalid afteryou exercisethe optimize com m and.Thew ork
around so to setm ulticycle path constraintsafterglobalareaoptim ization,butbefore tim ing
optim ization.A nd,in the set_multicycle_path com m and,you should specify thefull
pathnam e to a register.Forexam ple:
set_multicycle_path -value 2 -from .work.fir_filter.rtl.U1.U2.il
False Path Constraints:
False paths are design paths that you want LeonardoSpectrum to ignore for timing optimization.
Refer to Figure 6-10:
Figure 6-10. False Path Constraints
D
data
Logic C loud
A
Q
Logic C loud
B
D
Q
FF1
FF3
clk
clk
D
Q
FF2
clk
False Path
By taking advantage of the set_multicycle_path command, you can specify the path from
FF2 to FF3 as false. Refer again to Figure 6-10:
> set_multicycle_path -value 10000 -from {FF2} -to {FF3}
Essentially, the path from FF2 to FF3 has been constrained to 10000 clock cycles. Since logic
cloud B probably would not ever take more than 10000 cycles, this path has effectively been
eliminated from timing optimization and timing analysis. Any multicycle path that is
constrained to 10000 or more cycles is reported as a False Path in the Constraint Summary
report.
Constraining Purely Combinational Designs
A purely combinational design contains no clocks. You can constrain these blocks by
specifying the global variable input2output. This constrains any purely combinational paths
through a circuit. For example:
6-12
set input2output 9
Figure 6-11. Combinational Design
data_in
data_out
9 ns
Constraining Mixed Synchronous and Asynchronous
Designs
Some blocks have both synchronous and purely combinational paths through the circuit. A
mealy state machine is a good example of this. To constrain these designs, you apply
synchronous constraints to the ports of the synchronous paths and asynchronous constraints to
the ports of the asynchronous paths.
Figure 6-12. Constraining Designs with Mixed Signals (1 of 3)
Log ic B lock Z
V irtualC ircuit
D
A
Q
Logic C loud
Logic C loud
D
Q
Logic C loud
B
F F2
FF 2
clk
clk
3 ns D elay
C
7 ns
6-13
Logic B lock Z
V irtualC ircuit
A
Logic C loud
D
Q
D
B
Logic C loud
Q
Logic C loud
FF2
F F2
clk
clk
12 ns D elay
C
7ns
16 ns
C lock P eriod = 16 ns
3ns
Input S etup A = 3 ns
10ns
O utputR equired C = 10ns
4ns
O utputR equired B = 4ns
Procedure for Setting Constraints on Mixed Designs
1. Define the clock constraints.
> clock_cycle 16 clk
2. Apply an input arrival constraint assuming the design is entirely sequential.
> arrival_time 3 A
3. Apply an output-required time to the sequential output ports only. Set the constraints for
a sequential circuit ignoring the combinational paths for now.
> required_time 4 B
6-14
4. Apply an output arrival time to the combinational output paths. The maximum delay
constraint applied to these paths is the window created by the difference between the
input arrival time and the output-required time. In Figure 6-14, an input arrival of 3 is set
and a maximum delay through the combinational path of 7ns is desired. The output
required time must be 10ns (10ns - 3ns = 7ns).
required_time 10 C
Constraining Sub-blocks for Timing
Ideally, registers are placed at hierarchical boundaries. However, random logic can be placed at
the hierarchical boundaries, which forces you to constrain the logic appropriately. Unless more
detailed information about the sub-block timing is known, you should use constraints equal to
one-half of the clock period. For example, is the clock period is 20ns, you should specify 10ns
for the required time and 10ns for the arrival time.
If both sides meet timing, then when the blocks are combined, timing is met. Define the global
register2output and input2register variables to equal one-half of the clock period. Refer to
Figure 6-15.
Figure 6-15. Constraining Sub-Blocks
B lo ck
A
1 clock
1/2
clock
B lo ck
B
1/2
clock
1 clock
clock_cycle 20 clk
set input2register 10
set register2output 10
6-15
The Constraints FlowTab
Figure 6-16. The Constraints FlowTab - Global Constraint Options
6-16
Option
Description
Specify Clock
Frequency, (Mhz):
This radio button choice is mutually exclusive with Clock Period. You
can specify the required frequency for your design which is 1/period.
Specify Clock Period,
(ns):
This radio button choice is mutually exclusive with Clock Frequency.
See clock period in diagram.
Specify Maximum
Delay Between all:
This radio button choice gives you control over the delays from port to
register, register to register, register to port, and port to port.
Input Ports to
Registers:
Delay from input port to input of register in nanoseconds.
Registers to
Registers:
Delay from output of one register to input of another register in
nanoseconds.
Registers to Output
Ports:
Delay from output of register to output port in nanoseconds.
Inputs to Outputs
Delay from input port(s) to output port(s).
6-17
The Clock Constraints PowerTab
Figure 6-17. The Clock Constraints PowerTab Options
6-18
Option
Description
Reference Clock Properties:
The Reference Clock is relative to the signal. Every
signal is measured relative to the reference clock.
Reference Clocks are saved in your constraint file.
Frequency: (2 digits of accuracy)
Frequency (Mhz) is mutually exclusive with period.
Period: (2 digits of accuracy)
Period is a waveform that repeats at fixed intervals
(ns).
Offset, ns: (Offset of Leading Edge)
This is the delay after time=0. Timing is absolute.
Timing is offset in nanoseconds from time=0.
Pulse Width, ns: (Duration of Pulse)
Pulse width is a measure of the duration of the pulse
in nanoseconds.
Duty Cycle, %: (Duration of Pulse)
Duty cycle percentage is equal to the pulse width
divided by the period times 100. Some pulses do not
repeat at fixed intervals. The pulse widths and time
intervals may differ.
Pin Location:
This is the equivalent of the PIN_NUMBER attribute.
Buffer: (BUFG, None)
Select None to imply that ports are not assigned pads.
BUFG I/O pads are available for selected technology.
Equivalent of the BUFFER_SIG attribute.
Clock(s)
Browse through the interactive, filtered list of clocks.
This list was built when you read in your design.
Delete Constraints Button
Click Apply to apply deletions.
Select an object and click Delete and then Apply. All
constraints set on this object are deleted.
Figure 6-18. Clock Waveform Diagram
6-19
The Input Signal PowerTab
Figure 6-19. The Input Signal Constraints PowerTab Options
6-20
Option
Description
Input Constraint
Specify the input arrival time and drive characteristics for
each input port. The default is 0 ns arrival time and infinite
drive.
Arrival Time: (ns)
Select a signal for your reference clock. Arrival times at
primary inputs define the maximum delay through logic
external to the design before arrival at that input.
Infinite Drive
This is the default when arrival is 0 ns and load is 0.
Input Drive
Select this option to specify the additional delay per unit load
(ns) for the selected input port(s). This option allows an
accurate modeling of the effects of the load presented at the
gate by the synthesized circuit.
Max Input Load: pf (pico farad)
This is the capacitance load for your gates. The load input
controls operation of the output. If the synthesized circuit
exceeds the number of loads, then LeonardoSpectrum
buffers the load. A buffer or inverter gate with an input load
less than the value specified must exist in the target
technology to meet the constraint. If the technology has a
global maximum load value, then an input cannot present a
load at an input that exceeds the technology maximum.
Max Input Fanout: (loads)
Fanout is the number of loads that the output of a gate can
drive. If the synthesized circuit exceeds the number of loads,
then LeonardoSpectrum buffers the load.
Max Transition: ns (Rise)
This is the rise time in the leading edge of the pulse. This is
the time required for the pulse to go from low level to high
level.
Max Transition: ns (Fall)
This is the fall time in the trailing edge of the pulse. This is
the time required for the pulse to go from high level to low
level.
Pin Location:
This is the attribute PIN_NUMBER.
Insert Buffers: (Global, none,
SCLK)
I/O Pads available for selected technology. This is the
attribute BUFFER_SIG.
Delete Constraints Button:
Input Port(s): window
Browse through the interactive, filtered input port list. This
list was built when you read in your design.
6-21
The Output Signal PowerTab
Figure 6-20. The Output Signal Constraints PowerTab Options
6-22
Option
Description
Output Constraints
Specify the output required time and load
characteristics for each port. The default is output
ports with no load applied.
Required Time (ns):
These choices allow you to constrain the output ports
and apply the required loads. The output clock is
relative to the output port. This is the time required for
a signal to be available at this port.
Load: (pf), pico farad: (Number of
loads driven by output)
This is the capacitance load of the output port. Specify
the amount of external loading on the design output.
The loads value is used to calculate delays and to
ensure that sufficient drive capability is available at an
output. Meeting load and drive requirements may
require choosing a gate with higher drive or replicating
logic. The default output load for the technology is
used, if a load value is not specified.
Fanout: loads: (Number of loads
driven by output)
The output fanout depends on the input. Fanout
specifies the maximum loading a gate can handle.
Specify the number of external fanout loads driven by
the output.
Max Transition: ns (Rise)
This is the rise time in the leading edge of the pulse.
This is the time required for the pulse to go from low
level to high level.
Max Transition: ns (Fall)
This is the fall time in the trailing edge of the pulse.
This is the time required for the pulse to go from high
level to low level.
Pin Location:
This is the attribute PIN_NUMBER.
Pad: (pull down: 0BUF, OBUFT,
None)
Select None to imply that ports are not assigned pads.
BUFG I/O pads are available for selected technology.
Equivalent to the PAD attribute.
Delete Constraints Button:
Output Port(s): window
Interactive filtered list
This list of ports is available in your design. Double
click on a port name to select. This list was built when
you read in the design.
6-23
The Internal Signal PowerTab
Figure 6-21. The Internal Signal Constraints PowerTab Options
6-24
Option
Instance Constraints
Preserve Signal
Assign to Low Skew
Description
Specify which signal to preserve during
optimization.
If selected, your customized signal is preserved
during optimization.
Sets the attribute USELOWSKEWLINES on the
selected nets.
Max Fanout
Sets the limit for the maximum number of fanouts
for the selected signal.
Signals Scroll Window
This is an interactive list of signals. This list was
built when the design was read.
Select an object and click Delete and Apply. All
6-25
The Module PowerTab
Figure 6-22. The Module PowerTab Options
6-26
Option
Description
Module Constraints
Don’t Touch
(Refer to auto_write in Command
Reference Utilities chapter.)
If selected, the specified technology cells are not
optimized (NOOPT). dont_touch is an attribute
used for preserving custom implementations and
technology instantiation; used for optimizing
hierarchically and for protecting buffering.
Optimize for: (pull down with area,
delay)
Choose from pulldown. Choose area. The circuit is
optimized to minimize area and not delay; or
choose delay to optimize for speed and not area.
The default is area.
Effort: (pull down with quick, standard)
Choose from pulldown. Choose quick. Only one
optimization strategy is attempted on the network;
or choose standard to run multiple optimization
algorithms. The default is quick.
Modules:
This is a filtered, interactive list of the modgen
library instances. This list was built when you read
in the design.
Select an object and click Delete and Apply. All
6-27
The Path Constraints PowerTab
Figure 6-23. The Path Constraints PowerTab Options
6-28
Option
Description
From:
This is the starting point for a multicycle or absolute path. A
list of filtered inputs and registers is displayed if the check
boxes are selected. Double click to select.
Inputs
The input ports in your design are shown in the list of objects.
Click to select these ports.
Registers
The registers in your design are shown in the list of objects.
Click to select the starting input port(s) and/or register(s) on
which to apply path constraints from the list of objects. Paths
in your design may be assigned various constraints.
To:
This is the end point for a multicycle or absolute path. A list
of outputs and registers is displayed if the check boxes are
selected. Double click to select.
Outputs
The output ports in your design are shown in the list of
objects. Click to select these ports.
Registers
The registers in your design are shown in the list of objects.
Click to select the starting output port(s) and/or register(s) on
which to apply path constraints from the list of objects. Paths
in your design may be assigned various constraints.
False Path:
False path disables timing analysis between the specified
points. This options executes a set_multicycle_path
command with a value set to 10000 cycles (a false path).
MultiCycle Path (cycles):
Sets a path constraint that is greater than one clock cycle. You
can specify any number of clock cycles in the field. A value
of 10000 or greater causes LeonardoSpectrum to report the
path as a False Path in the Constraint Summary report.
Click Add to add an input to output path. Highlight an existing path, click Delete to delete the
path. Highlight an existing path, complete your From: To: changes, and click Change to change
a path. Click Apply after Add, Delete, Change.
Summary Window Example: lat_mem[1][0]...lat_mem[0][3][2]
6-29
The Report Constraints PowerTab
Figure 6-24. The Report Constraints PowerTab Options
6-30
Option
Description
This report shows all the constraints set on your design. You can save these constraints to a file
or load a file of previously saved constraints.
Load From:
Click on folder 1to bring up Loading Constraint File. Select or
enter constraint file from Files of type: with *.ctr extension.
Use the Windows browser, click, and drag rules as required.
Click on Load button.
Save To:
Click on folder 1to bring up Saving Constraint File. Select or
enter constraint file with *.ctr extension. Use the Windows
browser, click, and drag rules as required. Click on Save
button.
6-31
6-32
Chapter 7
Optimizing Your Design
Understanding Global Area Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
How LeonardoSpectrum Optimizes a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Understanding Extended Optimization Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Managing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Partitioning Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementing Hierarchy in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flattening Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protecting Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-5
7-6
7-7
7-7
7-8
The Optimize FlowTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Advanced Optimization PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
7-1
Understanding Global Area Optimization
LeonardoSpectrum preforms global area optimization and critical path timing optimization
separately on each module in the design. Area optimization is automatically run first, followed
by critical path optimization if required to meet a timing constraint that may be optionally
specified.
How LeonardoSpectrum Optimizes a Design
LeonardoSpectrum uses different techniques during optimization. Depending on the options
chosen, and algorithms run, a design can fall at different points on the area/performance curve.
The following paragraphs provide an overview of some of the techniques that
LeonardoSpectrum uses to optimize a design for area. LeonardoSpectrum uses this process
whenever you click on the Run Flow button.
1. Propagate constants (removes redundant logic introduced during pre-optimization)
2. Implement operators (resolve_modgen)
During global optimization, LeonardoSpectrum implements the operator blocks in two
steps (The optimize command does both of these steps without user interaction):
a. Extracts macro operators (e.g. counters and rams) during the pre-optimization. You
can control whether these macros are inferred using the extract_ram and
extract_counter variables.
b. Populate the operator block with technology cells during modgen resolving.
Note
LeonardoSpectrum sets the NOOPT attribute on all ModGen produced gates. In
addition, the -default_resolving switch forces generic implementations,
even if a Modgen library has been loaded
3. Optimize the Design
The number of optimization passes that LeonardoSpectrum runs differs based on
whether you select the “Quick” or “Standard” optimization efforts. An optimization pass
is a pre-determined set of optimization algorithms. The “Quick” effort runs only one
pass, while the “Standard” effort runs four passes. At the end of each optimization pass,
LeonardoSpectrum reports the Area, number of Flip-flops, Delay, and time for each
hierarchical block.
When optimizing a hierarchical circuit, each block is optimized independently.
Combinational logic is not moved across hierarchical boundaries. This feature allows
7-2
you to quickly re-read blocks into the in-memory design without producing bad logic
(due to previous optimization moving functionality between blocks). If
LeonardoSpectrum preforms multiple passes, it keeps either the smallest area or shortest
delay result depending on the -area or -delay switch on the Optimize FlowTab.
LeonardoSpectrum also runs different optimization algorithms based on the target
technology. For example, LeonardoSpectrum attempts to map combinational logic into
4-input lookup tables for Altera designs. This is called “Fan-in limited decomposition”.
It is one of several technology-specific optimization algorithms built into
LeonardoSpectrum. This algorithm is especially appropriate for lookup-table-based
architectures. The algorithm limits the number of inputs within a circuit partition to
allow fitting into a lookup table.
Optimization is a process of partitioning the circuit, running specific algorithms, and
testing to see if improvements are made. Each of the optimization passes runs a specific
set of algorithms starting with the unmapped (generic primitives from synthesis) design.
Examples of optimization algorithms include:
•
BDD construction
A Binary Decision Diagram (BDD) decomposes the logic into a tree of decision
blocks. Sometimes LeonardoSpectrum cannot build a BDD for certain types of
circuits such as very large multipliers or circuits that are very large. A BDD tends to
grow in size in a linear manner as the number of inputs increase which makes it an
efficient means for representing data (unlike truth tables or PLA representations).
Figure 7-1. A Binary Decision Diagram
ÿþýüûúÿùø÷ö
I0
I1 I2 I3
Z
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
1
0
0
0
0
1
1
0
0
1
1
0
0
0
0
0
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
Binary Decision Diagram
1
1
0
I0
0
1
0
I1
1
0
I2
I3
Z=0
1
0
Z=0
1
0
1
0
Z=1
Z=0
Z=0
Z=1
7-3
•
Factoring - combining like terms to reduce area.
•
Circuit Restructuring - a more global technique.
•
Remapping - utilizing wider gates.
Each pass iterates through a series of algorithms and measures the results. The actual
operations performed in each pass are not released, as this is viewed as a trade secret.
4. Technology mapping.
After the design has been optimized to a minimal area, it is mapped into a technology.
5. Adding IO buffers
If you optimize in Chip mode (Add I/O pads), LeonardoSpectrum adds I/O buffers on all
top-level ports that are not driven by IO buffers.
6. Starting with a design of minimal area, LeonardoSpectrum then re-optimizes the critical
paths to meet timing. This usually means adding more hardware and more parallel
structures to speed things up. Only the critical paths are optimized, thus reducing the
overall increase in area.
7-4
Understanding Extended Optimization Effort
Understanding Extended Optimization
Effort
LeonardoSpectrum has four groups of algorithms that it can be run on each module in your
design. By default, the Quick Setup flow runs Algorithm Group #1. This group produces the
best results 70% of the time. If you select Extended Optimization Effort, LeonardoSpectrum
will run all four algorithm groups on each module in your design. A built-in results filter
automatically selects and retains the best results for each module in the in-memory database.
Figure 7-2. Setting Extended Optimization Effort
P a ss 1
A lg o rith m
G ro u p
#1
P a ss 2
A lg o rith m
G ro u p
#2
P a ss 3
A lg o rith m
G ro up
#3
P as s 4
A lg o rith m
G ro u p
#4
L eon ard o
S p ectru m
D atab ase
B est R esu lt
R e su lt #1
R es u lts #2
R esu lts #3
R es u lt # 4
R esu lt
F ilter
Managing Hierarchy
You can affect the optimization results/methods by modifying the hierarchy in your design (or
just portions of it). Before you create or change design hierarchy, you should consider these
ramifications:
•
Timing constraints do not propagate through hierarchy. If you have hierarchy, you must
set constraints on each block individually. If you have a flat design, you only need to
apply constraints to top level IO.
•
Hierarchical Designs constrain the optimizer
•
Flat Designs are more difficult to understand than hierarchical designs.
•
Instance naming in flat designs will become more abstract
7-5
Managing Hierarchy
•
Hierarchy allows you to isolate and/or separate area and timing critical portions of your
design
Design Partitioning Hints
•
Group similar logic together (e.g. state machines, data path logic, decoder logic, and
ROMs).
Pay close attention to blocks that may lend themselves to special area or delay
optimizations. For example, if you know a particular block is going to contain the
critical path, you should move any non-critical logic from that block.
•
Gate counts in leaf blocks should not exceed 50K gates.
Optimization can be performed on much larger designs provided that the sub-hierarchy
falls within this guideline.
The maximum size of a single level of hierarchy is difficult to define since it is so
dependent on the design. The number of operators, the type and style of the RTL code,
the amount of random logic, etc all play a role in the max size LeonardoSpectrum can
handle. With this said, for designs which are not timing critical, LeonardoSpectrum can
easily handle up to 50k flat blocks, assuming you have sufficient memory. When timing
becomes an issue, then LeonardoSpectrum has limitations that are similar to other
synthesis tools.
LeonardoSpectrum propagates global constraints down the hierarchy. And, if you wish,
you can constrain each block individually if you want to achieve realistic constraints
across hierarchy. Another technique is to use the -force option during timing opt which
will attempt to speed up each hierarchical block by 10%.
•
Separate timing critical blocks from non-timing critical blocks.
Keep in mind that LeonardoSpectrum performs area and timing optimization separately.
By separating timing critical logic into one block, it may be possible to perform
aggressive area optimizations on a greater percentage of the design (thus creating a
smaller circuit that meets timing).
•
Limit clocks to 1 per block.
LeonardoSpectrum does not support multiple, unrelated clocks at this time. If your
design has multiple clocks, you may be able to define a main clock and specify a clock
offset for the other related clocks in the hierarchical block.
•
Place registers at end of hierarchical boundaries.
Since optimization tools can only reduce combinational logic, there are two “barriers”
that constrain optimization, hierarchical boundaries and registers. When designing
7-6
Managing Hierarchy
hierarchically, you should attempt to place registers at either the front or back end of the
hierarchical boundary. This register placement essentially combines the two “barriers”
into one thus minimizing the impact to overall results when optimizing hierarchical
designs.
•
Place state machines into separate blocks of hierarchy.
This partitioning will speed the optimization and provide greater control over encoding.
•
Place tristate drivers at the same level of hierarchy.
This allows you (and LeonardoSpectrum) more flexibility in handling/implementing
tristates. By default, LeonardoSpectrum will not move tristate dirvers across hierarchy
(because it would require changing the port interface on the hierarchical block to pass
the enable signal). You can explictly set all the tristate drivers at the same level by
setting the bubble_tristates options on the Advanced Settings PowerTab of the
Optimize FlowTab.
Implementing Hierarchy in VHDL
The only way to introduce hierarchy within your VHDL design is by using Component
Instantiations.
Flattening Hierarchy
LeonardoSpectrum provides the capability to flatten your entire design or portions of the design
such that you can affect the resulting optimization. The optimizer cannot merge logic across
hierarchical boundaries. As a result, you find that LeonardoSpectrum can achieve better results
if you flatten specific blocks where logic could be optimized together.
Currently, LeonardoSpectrum does not propagate timing constraints down the hierarchy. In
order to timing optimize a hierarchical design, you need to apply the constraints and optimize
each block separately. On the other hand, you can flatten the design, apply your input and
output constraints to the design, and optimize the entire design for timing. However, the timing
optimization on a flattened design likely will take longer than optimizing each block separately.
For example, to flatten your entire design, enter the following command at the
LeonardoSpectrum command line with the top level of your design set as the present design:
ungroup -hier -all
You can also select the instances in the Design Browser, and use the Right Mouse Button to
select the Ungroup popup menu item.
7-7
Managing Hierarchy
Protecting Hierarchy
The Difference Between Don’t Touch and “No Opt”
There are two ways to protect a hierarchical block from optimization. You can apply the
dont_touch attribute to the design object or apply the noopt attribute. The difference is as
follows:
•
dont_touch
•
noopt
prevents an instance from change, including optimization and unmapping.
In contrast to noopt, dont_touch also prevents changing the lower levels of hierarchy
and leaf instances.
also prevents an instance from change. However, in contrast to dont_touch,
lower levels of hierarchy and leaf instances are not protected from change.
Specifying “Don’t Touch”
You can use the dont_touch attribute in LeonardoSpectrum to specify a “don’t touch”
condition on selected instances in the design. You may have portions of your design that have
been hand-implemented and you don’t want LeonardoSpectrum to perform any optimization. If
you have specified a technology component instantiation in your VHDL design, you can
“dont_touch” it after synthesis so LeonardoSpectrum will not substitute it with a different
technology cell.
Sometimes you have a better idea of buffering requirements than the optimizer can understand.
For example, you may want to create a fast-transition clock signal. To do this, you could specify
the buffer as a technology instantiation and retain it through optimization by setting the
dont_touch attribute on the buffer.
You can protect instances in the design such that LeonardoSpectrum will not optimize them.
Specifying “don’t touch” is useful for:
•
Preserving custom implementations
•
Preserving technology instantiations
•
7-8
Optimizing hierarchically (e.g. Optimize a low-level block, then “don’t touch” it and
optimize a level above)
The Optimize FlowTab
There are two major optimization functions within LeonardoSpectrum. The optimize command
preforms global area optimization and may be run with or without timing constraints. Running
without timing constraints produces the smallest area design.This FlowTab is the control panel
to the optimize command. Global optimization is run on each module in the design hierarchy
separately. Normally, LeonardoSpectrum has four groups of algorithms that it can be run on
each module. By default, Algorithm Group #1 is run and produces the best results 70% of the
time.
Figure 7-3. The Optimize FlowTab Options
7-9
Option
Description
Select design to optimize: Click to select an object from the filtered, embedded design browser
tree.
Current Path: This is the design you select from the design browser tree or your present design.
Target Technology: Your current target is shown in the window.
Run type:
Control your run.
Optimize: Default. Runs multiple optimization passes. Optimize
means to reduce and improve logic in your design in terms of area and
delay.
Remap: Does not optimize the network, but maps it into the target
technology. The target may be another technology (retarget).
Optimize Effort - As you move the slider to the right, different combinations of (1) Extended
Optimization, (2) Optimize for, and (3) Hierarchy are set for the synthesis run. Your circuit
timing should improve. The tradeoff is increased synthesis run time.
Extended Optimization Effort: If this box is selected, then LeonardoSpectrum runs an
additional three optimization algorithms (assuming all 4 Pass boxes are selected). While
selecting Passes (1-4) may cause a slower run, an improvement in the use of design space may
occur. The Run type: Optimize: must also be selected.
A report is made for:
Pass 1
Pass 2
Pass 3
Optimize for:
Auto - Let
LeonardoSptecrum
decide what is the
best solution
Delay - The
design is faster
and the area
may be bigger.
Area - The design may be
slower and the area may be
smaller.
Hierarchy Auto
(default auto_dissolve)
Hierarchy Auto is selected by default. Views with 50 or fewer gates
are dissolved.
Hierarchy Preserve
If Hierarchy Preserve is not selected then your design is flatten before
optimizing.
If Hierarchy Preserve is selected then your design hierarchy is not
changed during optimization.
Hierarchy Flatten
If Hierarchy Flatten is selected then your entire design hierarchy is
flattened.
7-10
Pass 4
Add I/O Pads
Add I/O Pads is selected by default. LeonardoSpectrum runs the
optimization in the chip mode and inserts I/O pads in your design. If
Add I/O Pads is not selected, then LeonardoSpectrum runs the
optimization in the macro mode.
Optimize a single level
of hierarchy
If this box is selected then optimizing is limited to a single level (the
current level) instead of all levels.
Run timing
optimization
The optimizations are concentrated on paths in the design that violate
timing.
7-11
Advanced Optimization PowerTab
Figure 7-4. Advanced Optimization PowerTab Options
7-12
Option
Description
Do not use wire delay during delay calculations. (Variable: wire_table FALSE). Select when
interconnect delays are ignored. The use of a wire table during delay calculations is disabled.
Allow converting internal tri-states. (Variable: tristate_map FALSE). Select to allow the
conversion of internal tristates to combinational logic that matches the target technology.
Allow transforming Set/Reset on DFFs and Latches. (Variable: transformation FALSE). Select
to allow transformations to match the target technology.
Break combinational loops statically during timing analysis. (Variable: delay_break_loops
FALSE). Select to allow combinational loops to be broken statically for timing analysis and
critical path reporting. The default is dynamic analysis of combinational loops. This option
speeds up timing analysis, optimization and critical path reporting when dynamic analysis takes
too much time. However, timing analysis is not accurate when this option is used and the design
has combinational loops.
Bubble Tristates: Use these rules: If tristates are not in common levels, then by selecting
Bubble Tristates, the tristates bubble up to the common top level.
If tristates are in a common level and feeding the output port, then by selecting Bubble
Tristates, the tristates bubble up to the top primary output port. This also occurs if tristates are
not in a common level.
Operator Options: (For VHDL and Verilog input formats only.)
Use technology specific module generation library. If the box is not checked, then a default
internal module generation routine is used.
Operator select:
(For VHDL and Verilog
formats only)
Auto: Picks smallest if in area mode; picks fastest if optimization
in delay mode.
Smallest: Picks the most compact implementation available.
Small: Picks a compact implementation.
Fast: Picks a fast implementation.
Fastest: Picks the fastest implementation available.
Extract Clock Enables:
Map to clock-enable flip-flops from VHDL and Verilog.
Extract Decoders:
Controls automatic extraction of decoders in VHDL and Verilog.
Extract ROMs
Controls automatic extraction of ROMs in VHDL and Verilog.
Extract Counters:
Controls automatic extraction of counters in VHDL and Verilog.
Extract RAMs
Controls automatic extraction of RAMs in VHDL and Verilog.
Optimization CPU Limit:
min
Time needed for optimization algorithms to complete. 0 minutes,
no time limit.
7-13
Auto Dissolve Limit:
50 gates, default for CPLDs
Add I/O Pads
If I/O Pads is not selected, then LeonardoSpectrum runs the
optimization in the macro mode. If I/O Pads is selected, then the
optimization runs in the chip mode and pads are inserted in your
design.
Click Apply to apply options. Click Help for assistance.
Note: Your original design is copied with an RTL extension, my_design_RTL. The original
design is optimized, while the copy is retained as a record.
7-14
Chapter 8
Saving Your Design
After you click on Run Flow, your design will be Read (if not already read), optimized, and
written as an output netlist. Before you click on Run Flow, however, you can make changes to
the output options as described in this chapter, then Apply those options before you start the
run.
The Output FlowTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The EDIF Out PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SDF Out PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Verilog Out PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The VHDL Out PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-2
8-4
8-5
8-6
8-7
8-1
The Output FlowTab
Saving Your Design
The Output FlowTab
Figure 8-1. The Output FlowTab Options
8-2
Saving Your Design
The Output FlowTab
Option
Description
Filename:
Note: Use a “-” for
filename to have output
appear on the main
window.
Click on folder to bring up the Set Output Files. This is the placeand-route file. Select from list or type in another filename. This
filename defaults to <input design>.<ext>, where <ext> is based on
the output format. Note: Point at filename to popup the full path
name.
Format:
The radio button output netlist format choices are listed.
Auto
By default the output file is written out in EDIF format (.edf). Auto
determines the actual format based on the filename extension.
VHDL
The output design file is in the VHDL netlist format.
Verilog
The output design file is in the Verilog netlist format.
EDIF
The output design file is in the EDIF netlist format.
SDF (Standard Delay
Format)
The output file is in the SDF netlist format. Output files in SDF are
accepted by all technologies. This is a back-annotated SDF file.
XDB (Exemplar
Database)
The output file is saved in a format that can be read back into
LeonardoSpectrum without processing the netlist to remove
technology-specific information. XDB writes a binary dump of your
database to a file. You can read this file back into
LeonardoSpectrum to restore the design database to the original
conditions when the design was produced. Note: If your input
format is XDB, then load the technology library before reading the
input file. This sequence prevents problems with report delay and
with symbols in the schematic viewer.
Write vendor constraints file: Select to write output file and a vendor’s constraint file.
Pre-Process Netlist: By default executes auto_write command to write a netlist that meets
requirements of your P&R tool. If Pre-Process Netlist is not selected, then the write command is
executed.
Write only the top level of hierarchy to file: Select to limit output file to only the top hierarchy
of file.
Downto:
(leaf-level)
Technology Cells: Output file includes technology cells.
Primitives: Output file includes your original design (leaf level).
Click Write to apply your options.
8-3
The Output FlowTab
Saving Your Design
The EDIF Out PowerTab
Figure 8-2. EDIF Out PowerTab Options
Option
Description
Set EDIF specific options before writing out the EDIF output format.
EDIF GND
Accept default GND or type in your choice. This is your
special name for ground nets. Be sure to select Write out
power and ground as undriven nets with special names.
EDIF Power
Accept default VCC or type in your choice. This is your
special name for EDIF power. Be sure to select Write out
power and ground as undriven nets with special names.
Allow Writing Buses: Before V1998.2, LeonardoSpectrum split buses. For example, A0 and
A1 were split into individual bits for writing buses. Now you can write A+B=sum to indicate
that A bus + B bus is the sum.
Write out power and ground as undriven nets with special names: Enter your names for ground
and power.
Write the contents of cells marked Don’t Touch. Objects marked with dont_touch are not
optimized or unmapped. In contrast to noopt, dont_touch prevents optimization of the lower
levels of hierarchy and leaf instances.
8-4
Saving Your Design
The Output FlowTab
The SDF Out PowerTab
Figure 8-3. SDF Out PowerTab Options
Option
Description
Set your specific SDF options before writing out an SDF file. SDF is not a netlist; SDF is a
format.
SDF Names Style: SDF is a netlist format which derives a style from VHDL or Verilog.
VHDL
The output file is in a SDF netlist format with a VHDL style.
Verilog
The output file is in a SDF netlist format with a Verilog style.
none
The output file is in a SDF netlist format with the default VHDL style.
Write flat netlist
The hierarchy of your design is flattened unless this choice is selected.
8-5
The Output FlowTab
Saving Your Design
The Verilog Out PowerTab
Option
Description
Allow Writing Buses: Before V1998.2, LeonardoSpectrum split buses. For example, A0 and
Click Apply to apply options. Click Help for assistance.
8-6
Saving Your Design
The Output FlowTab
The VHDL Out PowerTab
Figure 8-4. VHDL Out PowerTab Options
Option
Description
Type used for bit by VHDL
writer:
std_logic - This type allows a choice of nine values (0, 1, X, L,
H, W, U, -, Z). Other bit choices allow 0, 1 only.
VHDL Vector Type
std_logic_vector
Specify the type for the bit-vector used in VHDL writer.
Allow Writing Buses: - Before V1998.2, LeonardoSpectrum split buses. For example, A0 and
Write VHDL_87: This directs LeonardoSpectrum to read 1987 style VHDL instead of 1993
style VHDL.
8-7
The Output FlowTab
8-8
Saving Your Design
Chapter 9
Performing Physical Layout
The Place & Route Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Altera MAX+PLUS II Place & Route Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Altera Quartus PowerTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quartus Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-2
9-2
9-4
9-5
9-1
The Place & Route Tab
The Altera MAX+PLUS II Place & Route Tab
Figure 9-1. Altera MAX+PLUSII Physical Tab Options
9-2
Option
Description
Before this P&R tab is available you must load the Altera library, complete the design flow, and
write an output netlist file.
Setup MAX+PLUS II Create (Assignment and Configuration File) ACF file: This option is
selected by default. Setup MAX+PLUS II allows you to change or overwrite an existing ACF
file.
Auto Fast I/O
Select to allow the MAX+PLUS II compiler to implement
registers in Fast I/O. Reduces area requirements, but slows
internal circuitry.
Auto Implement in EAB
(Altera FLEX 10K)
Select this box if you are using wide gates and want to embed
the array block.
Auto Register Packing
If your registers always have a constant input, for example “1”,
then these registers are merged in the EDIF. Implements register
packing by placing a combinational logic function and a register
with a single data input in the same logic cell.
Run MAX+PLUS II
Select this box if you want to run MAX+PLUS II for your EDIF
file.
q Bring up MAX+PLUS II
You want to bring up the MAX+PLUS II GUI.
Timing Analysis
Use the timing information in the SDF, VHDL, or Verilog file to
check place and route for accuracy. Creates either an input to
output delay matrix, a setup/hold matrix, or a register
performance report.
Input-Output Delay
Select for typical delay.
Setup/Hold
You want to check on setup and hold violations.
Register Performance
You want to verify that constraints are met.
Verification: Produce a VHDL or Verilog netlist
for simulation. Generate simulation files and SDF
2.1; enables MAX+PLUS II writers.
VHDL
Verilog
Click Run PR to create your ACF file and to invoke MAX+PLUS II using specified options.
9-3
The Altera Quartus PowerTab
Figure 9-2. Altera Quartus PowerTab Options
Option
Description
Before this Tab is activated, you must load the Altera library, complete the design flow, and
write an output netlist file.
Run Quartus
Select this box if you want to run Quartus on your EDIF netlist.
Bring up Quartus GUI
In contrast to MAX+PLUS II, this selection gives you the
additional step of setting up a project and completing the design
compilation.
Verification: Produce a VHDL or Verilog netlist
for simulation. Generate simulation files and SDF
2.1; enables MAX+PLUS II writers.
9-4
VHDL
Verilog
Depending on the options selected, mapping to APEX 20K/20KE WYSIWYG
primitives is either done by LeonardoSpectrum or by Quartus. By default,
LeonardoSpectrum does the mapping to WYSIWYG primitives.
Note
Quartus Integration
Quartus is encapsulated in the Quick Setup FlowTab and the Advanced P&R FlowTab of the
GUI for LeonardoSpectrum as follows:
•
•
All constraints are set in LeonardoSpectrum for Quartus.
Quartus is executed automatically by P&RIntegrator when the pathname to the Quartus
executable directory is specified. See the topic Setting the Place and Route Executable
Pathnames on page 3-6 for details. The results of cross probing are available in the
information window.
Constraint Passing
LeonardoSpectrum supports passing constraints to Quartus using the Quartus NativeLink API
features. The following constraints are defined on the GUI or with attributes on the interactive
command line shell and passed to Quartus:
•
Global Constraints
•
Clock Frequency
•
Input and Output: Pin Locations
•
Part Numbers and Speed Grades
Constraint Passing Examples
Three project files are generated by LeonardoSpectrum for Quartus.
•
traffic.psf (project settings )
•
traffic.csf (compiler settings)
•
traffic.quartus (project file)
Traffic.psf (project settings)
DEFAULT_DEVICE_OPTIONS
9-5
{
RESERVE_PIN = "AS INPUT TRI-STATED";
RESERVED_ALL_UNUSED_PINS = "AS OUTPUT DRIVING GROUND";
HEXOUT_FILE_COUNT_DIRECTION = UP;
HEXOUT_FILE_START_ADDRESS = 0;
GENERATE_HEX_FILE = OFF;
GENERATE_RBF_FILE = OFF;
GENERATE_TTF_FILE = OFF;
RESERVE_DATA7_THROUGH_DATA1_AFTER_CONFIGURATION = OFF;
RESERVE_RDYNBUSY_AFTER_CONFIGURATION = OFF;
RESERVE_NWS_NRS_NCS_CS_AFTER_CONFIGURATION = OFF;
DISABLE_CONF_DONE_AND_NSTATUS_PULLUPS_ON_CONFIG_DEVICE = OFF;
AUTO_INCREMENT_CONFIG_DEVICE_JTAG_USER_CODE = ON;
CONFIG_DEVICE_JTAG_USER_CODE = FFFFFFFF;
CONFIGURATION_DEVICE = EPC2LC20;
USE_CONFIGURATION_DEVICE = ON;
ENABLE_INIT_DONE_OUTPUT = OFF;
ENABLE_LOCK_OUTPUT = OFF;
ENABLE_DEVICE_WIDE_OE = OFF;
ENABLE_DEVICE_WIDE_RESET = OFF;
RELEASE_CLEARS_BEFORE_TRI_STATES = OFF;
AUTO_RESTART_CONFIGURATION = ON;
USER_START_UP_CLOCK = OFF;
CONFIGURATION_SCHEME = "PASSIVE SERIAL";
JTAG_USER_CODE = FFFFFFFF;
}
Traffic.csf (compiler settings)
CHIP(traffic)
{
AUTO_RESTART_CONFIGURATION = ON;
RELEASE_CLEARS_BEFORE_TRI_STATES = OFF;
USER_START_UP_CLOCK = OFF;
ENABLE_DEVICE_WIDE_RESET = OFF;
ENABLE_DEVICE_WIDE_OE = OFF;
ENABLE_INIT_DONE_OUTPUT = OFF;
ENABLE_LOCK_OUTPUT = OFF;
JTAG_USER_CODE = FFFFFFFF;
CONFIGURATION_SCHEME = "PASSIVE SERIAL";
USE_CONFIGURATION_DEVICE = ON;
CONFIGURATION_DEVICE = EPC2LC20;
CONFIG_DEVICE_JTAG_USER_CODE = FFFFFFFF;
AUTO_INCREMENT_CONFIG_DEVICE_JTAG_USER_CODE = ON;
DISABLE_CONF_DONE_AND_NSTATUS_PULLUPS_ON_CONFIG_DEVICE = OFF;
GENERATE_TTF_FILE = OFF;
GENERATE_RBF_FILE = OFF;
GENERATE_HEX_FILE = OFF;
HEXOUT_FILE_START_ADDRESS = 0;
HEXOUT_FILE_COUNT_DIRECTION = UP;
RESERVED_ALL_UNUSED_PINS = "AS OUTPUT DRIVING GROUND";
RESERVE_NWS_NRS_NCS_CS_AFTER_CONFIGURATION = OFF;
RESERVE_RDYNBUSY_AFTER_CONFIGURATION = OFF;
9-6
RESERVE_DATA7_THROUGH_DATA1_AFTER_CONFIGURATION = OFF;
DEVICE = "EP20K200RC208-3";
|sensor1 :LOCATION = PIN_3;
|red1 :LOCATION = PIN_12;
}
Traffic.quartus (project file)
COMPILER_SETTINGS
{
FOCUS_ENTITY_NAME = |traffic;
RUN_TIMING_ANALYSES = ON;
USE_TIMING_DRIVEN_COMPILATION = ON;
COMPILATION_LEVEL = FULL;
SAVE_DISK_SPACE = ON;
SPEED_DISK_USAGE_TRADEOFF = NORMAL;
FAMILY = APEX20KE;
}
Cross Probing
LeonardoSpectrum provides support for cross probing from within Quartus into the original
HDL files.
When targeting APEX 20K/20KE, LeonardoSpectrum generates a cross reference .xrf file
together with the EDIF netlist. This allows Quartus users to seamlessly cross probe into the
original HDL design files from the floor plan view. Refer to the following example for the
traffic.vhd demo.
9-7
Example Demo: design_name = traffic.vhd
9-8
instance = comp,
red1_obuf,
red1_obuf,
traffic,
1, 57::57:
instance = comp,
green1_obuf,
green1_obuf,
traffic,
1, 57::57:
instance = comp,
red2_obuf,
red2_obuf,
traffic,
1, 57::57:
instance = comp,
green2_obuf,
green2_obuf,
traffic,
1, 57::57:
instance = comp,
reg_state7,
reg_state7,
traffic,
1, 35::35:
instance = comp,
reg_state6,
reg_state6,
traffic,
1, 57::57:
instance = comp,
reg_state5
reg_state5,
traffic,
1, 57::57:
instance = comp,
reg_state4,
reg_state4,
traffic,
1, 57::57:
instance = comp,
reg_state3,
reg_state3,
traffic,
1, 35::35:
instance = comp,
reg_state2
reg_state2,
traffic,
1, 57::57:
instance = comp,
reg_state1
reg_state1,
traffic,
1, 57::57:
instance = comp,
reg_state0
reg_state0,
traffic,
1, 35::35:
instance = comp,
clock
clock,
traffic,
1, 29::29:
instance = comp,
sensor1
sensor1,
traffic,
1, 29::29:
instance = comp,
sensor2,
sensor2,
traffic,
1, 29::29:
instance = comp,
reset
reset
traffic,
1, 29::29:
instance = comp,
red1
red1
traffic,
1, 30::30:
instance = comp,
yellow1
yellow1
traffic,
1, 30::30:
instance = comp,
green1
green1
traffic,
1, 30::30:
instance = comp,
red2
red2
traffic,
1, 30::30:
instance = comp,
yellow2
yellow2
traffic,
1, 30::30:
instance = comp,
green2
green2
traffic,
1, 30::30:
Chapter 10
Altera FLEX, ACEX, and MAX
Synthesis
This chapter presents information specific to the use of Altera FLEX, ACEX, and MAX as a
source or target technology.
The FLEX and ACEX Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
The MAX Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
The Altera Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Summary of FLEX, ACEX, and MAX Specific Control Variables . . . . . . . . . . . . . . . . . . . 10-4
User Options that Control Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Assigning Device Pin Numbers to Primary I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Mapping to the Logic Element (LE) in FLEX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Fanin Limited Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Lookup Table (LUT) Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Managing the Inclusion of Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Managing the Inclusion of Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Managing the Inclusion of Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Understanding LeonardoSpectrum Modgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Mapping Combinatorial Logic to Embedded Array Blocks (EABs) . . . . . . . . . . . . . . . 10-11
Mapping Memory Elements to FLEX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inferring ROMs from the HDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapping RAMs to the FLEX 10K Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating Simulation Memory Models with Genmem . . . . . . . . . . . . . . . . . . . . . . . .
LPM Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-16
10-16
10-22
10-28
10-29
Writing the EDIF Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30
Using FLEX Designs as Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-32
FLEX 6000/8000 Devices Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33
FLEX 10K Devices Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
ACEX Devices Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36
MAX Family Devices Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-37
10-1
The FLEX and ACEX Architecture
Altera FLEX, ACEX, and MAX Synthesis
The FLEX and ACEX Architecture
Introduction
The FLEX and ACEX device families are based on the Altera Flexible Logic Element MatriX
architecture. This SRAM-based architecture offers high-performance, reister-intensive, highgate-count devices with embedded arrays. LeonardoSpectrum supports the FLEX 6000, FLEX
8000, FLEX 10K/ 10KA/10KB/10KE and ACEX 1K familys.
Logic Elements (LEs)
LEs are also known as Logic Cells (LCells). The combinational logic part of an LE is a look up
table (LUT). LEs are at the core of Altera FLEX and ACEX architecture and contain both
combinational logic and registers. The combinational logic is limited by the number of inputs;
functions of up to four inputs can be implemented in one LE. Functions with more inputs must
be separated into multiple levels of LEs. Each LE also contains a register with clear and preset
inputs. In addition, LEs are grouped in LABs. All LEs in a LAB share control signals and
connect to each other through special cascade routing resources.
Input/Output Elements (IOEs)
IOEs in Altera FLEX and ACEX can be configured as inputs, outputs, tristate outputs, or bidirectional pins, with a register in either input or output path.
Embedded Array Blocks (EABs)
EABs are included in the architecture for FLEX 10K and ACEX 1K and are used to implement
memory functions and pterm configurations. Each EAB provides 2048 bits which can create a
RAM, ROM, FIFO, or dual-port RAM. EABs can also be configured as pterms to efficently
implement circuits such as state-machines and wide address decoders.
The MAX Architecture
The MAX family is composed of EPROM devices that are based on the Altera Multiple Array
MatriX architecture. These devices are primarily used to implement functions such as wide
address decoders and state machines that are best implemented in pterm logic.
LeonardoSpectrum provides synthesis for MAX 3000A, 5000; and 7000/A/AE/E/S; and 9000
devices and provide synthesis for these families into any of the other supported technologies.
The basic MAX structures are: macrocells, expanders, and I/O cells.
10-2
The Altera Synthesis Flow
Macrocells contain combinational logic and registers. Macrocells can also be referred to as
Logic Cells (LCELLs). Combinational logic is limited by the number of product terms.
Functions of up to four (MAX5000) or five (MAX7000/9000) product terms can be
implemented on one macro cell. Efficient use of the XOR gate resident in the Macrocell can
increase the number of product terms.
Functions of more product terms must use Expanders, or be broken into multiple levels of
Macrocells. Each Macrocell also contains a register that can be programmed to be a flip-flop or
latch with clear and preset inputs. In addition, Macrocells and Expanders are grouped in LABs,
which are fanin limited. The Macrocells and Expanders impose a fanin limitation on the product
term limitation.
I/O cells in Altera MAX can be configured as inputs, outputs, tri-statable outputs, or bidirectional pins.
LeonardoSpectrum uses dedicated algorithms to optimize logic for the MAX devices given the
product term and fanin limitations of the architecture. The optimization takes advantage of all
MAX resources such as Expanders, XORs and enabled flip-flops. This enables significant
reductions in area and delay for the MAX devices.
The number of Macrocells as well as the number of Expanders is reported. The number of
Macrocells and Expanders is only an estimate. The exact number can only be determined during
fitting, because MAX+PLUS II trades off Macrocells for Expanders, to achieve maximum
utilization of resources. If too many Expanders are used, MAX+PLUS II converts some
Expanders into Macrocells, and consequently may use too many Macrocells for the target
device. Try to fit the other results as well, even if the first pass seems to be the smallest one.
The Altera Synthesis Flow
The QuickSetup Flow
Quick Setup is the default synthesis flow presented to users when LeonardoSpectrum is
invoked. Quick Setup can be used by advanced as well as beginning users as a simple and quick
means to achieve a good first-pass synthesis result. You specify the target technology, open
your input design files, optionally set the target clock frequency, and verify the name and
location of the generated output netlist. You click the Run Flow button to run the entire
synthesis flow. Optionally, you can have Quick Setup automatically invoke the vendor place
and route tools to generate a set of vendor place and route files. You can read a more detailed
discussion about this flow in Chapter 2 of the LeonardoSpectrum User’s Manual.
10-3
Summary of FLEX, ACEX, and MAX Specific Control Variables Altera FLEX, ACEX,
The Advanced (Level 3) Synthesis Flow
The Advanced (Level 3) Flow is an incremental flow that allows you full access to the inmemory database while you guide the data transformation process step-by-step. FlowTabs and
and PowerTabs provide easy access to the basic incremental steps. In addition, you can exercise
a fine degree of control over the usage model with the Interactive Command Line Window. You
can read a more detailed discussion about this flow in Chapter 2 of the LeonardoSpectrum
User’s Manual.
Summary of FLEX, ACEX, and MAX
Specific Control Variables
When you select FLEX, ACEX or MAX as you target technology, LeonardoSpectrum will
automatically optimize you design to the architecture features of that device family. These
optimizations are explained in more detail in the remainder in this chapter. The following table
summarizes the Tcl variables that control these optimizations:
FLEX, ACEX and MAX Specific Control Variables
Variable
FLEX
MAX
Description
lut_max_fanout
X
Overrides the maximum fanout limits are derived from
the synthesis library. See Max Fanout (FLEX and
ACEX).
altera_use_cascades
X
Use this switch to control whether LeonardoSpectrum
maps logic to CASCADES during LUT mapping.
Mapping to cascades can improve density and
preformance, but increase routing congestion. To
increase routability, try turning this off for non-speed
critical modules. See Map Cascades (FLEX and
ACEX).
dont_lock_lcells
X
X
When set false, this gives the implementation software
more freedom to re-map portions of the design if
necessary. See Lock LCells (FLEX and ACEX).
max_fanin
X
Controls the maximum fanin into a function.
max_pt
X
Controls the maximum number of product terms in a
function.
altera_add_carry_su
m
10-4
X
Directs LeonardoSpectrum to use the Altera carry_sum
primitive gate in the EDIF netlist. See Use the
Carry/Sum Primitive.
User Options that Control Mapping
Device
Selects a particular target device for implementation.
Speed
Selects a particular speed grade for implementation.
Map IO Registers (FLEX 10K and ACEX 1K)
If your design meets register2register timing, but does not meet input2register or
register2output timing, then mapping the first and last register in each path to the IOBs may
speed up the input2register or register2output path. Also, if an internal register is driving
multiple I/O ports, then selecting this option will replicate the register multiple times, one for
each port. This also improves the register2output timing. In addition, by utilizing unused IOB
registers, you save on area. The disadvantage to IOB mapping might be that if an IOB mapped
register is in a critical path, then the register2register delay might be made worse because of
increased routing delay.
Max Fanin (MAX only)
Controls the maximum fanin into a function.
Max PT (MAX only)
Controls the maximum number of product terms in a function.
Max Fanout (FLEX and ACEX)
To eliminate the need for the implementaton tool to split a net, the synthesis tool must maintain
a reasonable number of fanouts for each net. LeonardoSpectrum tries to maintain reasonable
fanout limits for each target technology. Default fanout limits are derived from the synthesis
library.
You can use option on the GUI to override the default max fanout load specified in the
technology library. However, a synthesized netlist with high fanout nets may be a problem for
the implementation tool. High fanout nets can cause significant delays on wires and become
unroutable. On a critical path, high fanout nets can cause significant delays in a single net
segment and cause the timing constraints to fail.
10-5
If you are a Level 3 user, you can use the interactive command line shell syntax to set an
attribute on a specific net to control the max_fanout value. The command syntax is:
set_attribute -net <net_name> -name lut_max_fanout -value <int>
Setting this attribute on a specific net takes precedence over the global fanout specification.
Lock LCells (FLEX and ACEX)
By default, this option is selected in the GUI. If you turn this option off, then
LeonardoSpectrum does not to force LCell buffers into the output EDIF netlist. You can then
rely on MAX+PLUS II to map the combinational logic into LCells. (FAST is the recommended
setting for MAX+PLUS II GLOBAL_PROJECT_SYNTHESIS_STYLE.)
Map Cascades (FLEX and ACEX)
By default this option is selected and directs LeonardoSpectrum to map to cascade gates where
applicable. Mapping to cascades can improve density and preformance, but may increase
routing congestion. To increase routability, you should try turning this option off for non-speed
critical modules.
Use the Carry/Sum Primitive
By default, LeonardoSpectrum uses the carry_sum primitive gate in the EDIF netlist to tell the
implementation software that two elements (the carry LUT and sum LUT) go together as one
Lcell. You should turn off this mapping OFF if you are using implementation software that does
not support this mapping. (Versions earlier than MAX+PLUS II Version 10.0.)
Exclude Gates
This field instructs LeonardoSpectrum to exclude the selected gates from the target library.
Multiple gates may be selected.
10-6
Altera FLEX, ACEX, and MAX Synthesis Assigning Device Pin Numbers to Primary
Assigning Device Pin Numbers to
Primary I/Os
You can use the Input PowerTab on the Constraint Editor to assign pin numbers to the primary
I/Os or you can set the PIN_NUMBER attribute on a port interactively from the LeonardoSpectrum
interactive command line shell. The syntax is as follows:
set_attribute -port name -name PIN_NUMBER -val value
If you prefer to assign pin numbers from the HDL source code, you can insert a PIN_NUMBER
attribute. The syntax is as follows:
ATTRIBUTE PIN_NUMBER OF signal_name: SIGNAL IS: value
For example:
attribute pin_number of en: signal is “P14";
LeonardoSpectrum translates the PIN_NUMBER property to the Altera-specific CHIP_PIN_LC
property.
Mapping to the Logic Element (LE) in
FLEX Devices
The following descriptions are provided as background information so you will have a greater
understanding of how LeonardoSpectrum synthesizes and optimizes your design.
Fanin Limited Optimization
The key architectural feature of the FLEX CPLD is that the LE can be any function of four
inputs. A 4-input XOR uses the same area and is as fast as a 4-input AND gate. The function
shown in the following equation can be solved in two ways.
X = (A*(B+C))+(B*D)+(E*F*G*H*I)
Solution (1)
10-7
Mapping to the Logic Element (LE) in FLEX Devices Altera FLEX, ACEX, and MAX
You can decompose a function into a simpler AND/OR equivalent representation, and then split
the gates with large fan-in into multiple gates. Represented in AND and OR gates, X is
decomposed as:
X = T1+T2+T3
T1 = A*T4
T2 = B*D
T3 = E*F*G*H*I
T4 = B+C.
Since T3 has more than four inputs, further decomposition is required:
T3 = E*F*G*T5
T5 = H*I
After fully decomposing the design, you can use the Altera FLEX MAX+PLUS II place-androute software to place the design into physical LEs. In this example, T3 and T5 cannot be
merged because of fan-in limitations. Next, combine T1 with T4 and X with T2. This gives the
following partitioning to four LEs:
LE_1:
LE_2:
LE_3:
LE_4:
X = T1+(B*D)+T3
T1 = A*(B+C)
T3 = E*F*G*T5
T5 = H*I
The critical path is LE_4 → LE_3 → LE_1, resulting in three levels of LEs for the delay.
Solution (2)
A different decomposition of the equation yields partitioning into three LEs:
X = T1+(T2*E)
T1 = A*(B+C)+(B*D)
T2 = F*G*H*I
Since each of the three equations have no more than four inputs, each equation can be placed
into a LE. This design, when implemented, has only two LEs in the critical path, resulting in a
faster and smaller design.
Lookup Table (LUT) Mapping
Lookup table mapping puts logic into 4-input lookup tables and CASCADE gates with the
objective of minimizing the total number of lookup tables or to minimize the delay. In the
10-8
Mapping to the Logic Element (LE) in
output EDIF netlist, the lookup table boundaries are marked with LCell buffers. For example, a
4-1 multiplexer description follows:
module mux4 (out, in, sel) ;
output out ;
input [3:0] in ;
input [1:0] sel ;
assign out = in[sel];
endmodule
LUT mapping maps this multiplexer to two 4-input LUTs and one cascade gate. The schematic
of the mapped circuit is shown in Figure 10-1.
Figure 10-1. Mapped Circuit Schematic
xmplr_INST_4
in(2)
I0
in(2)
I1
0
I2
sel(0)
I3
xmplr_INST_3
I0
0
I1
F4_LUT
in(1)
xmplr_INST_5
in(0)
I0
I1
sel(1)
out_rename
I0
0
out
F1_LUT
CASCADE2
0
I2
I3
F4_LUT
LeoRG 19
LeonardoSpectrum decomposes the LUTs, Figure 10-1, to AND-OR gates for output to
MAX+PLUS II. The output netlist is represented in Figure 10-2.
Figure 10-2. Output Netlist
in(2)
IN1
INV
Y
NOT
IN1
IN2
INV
NOT
xmplr_INST_13
Y
IN2
AND2
INV
sel(1)
IN1
Y
NOT
OR3
IN1
IN2
IN2
INV
NOT
Y
IN3
OR3
AND2
IN1
sel(0)
Y
IN2
INV
NOT
in(0)
out
NOT
AND2
IN2
Y
in(3)
Y
INV
CASCADE
IN1
in(1)
IN1
IN3
AND2
IN1
INV
Y
NOT
LeoRG 20
IN2
INV
NOT
AND2
10-9
Managing the Inclusion of Modules
Understanding LeonardoSpectrum Modgen
LeonardoSpectrum supports various technology-specific implementations of arithmetic and
relational operators used in VHDL or Verilog. Since these implementations have been designed
optimally for a specific target technology, the synthesis results are usually smaller and/or faster
and take less time to compile. LeonardoSpectrum supports module generation for Altera FLEX
6000, FLEX 8000 and FLEX 10K.
The following operators are supported for Altera FLEX technologies:
•
Relational Operators
=
/=
<
•
Arithmetic Operators
+
-
*
•
<=
>
>=
Miscellaneous Functions: counters (up/down, loadable, etc), RAMs,
incrementer/decrementer, absolute value, unary minus
The module generator for each technology uses dedicated hardware resources whenever
possible. Therefore, modgen implementation of operators, such as addition, subtraction,
counters, relational operators is generally smaller in area and faster in delay.
Examples:
•
•
•
Adder in FLEX modgen is implemented using dedicated CARRY chain available in
FLEX architectures to implement the adder carry logic. This leads to very fast carry
propagation and results in excellent timing performance.
Counters in FLEX modgen make use of counter modes available in FLEX architectures
which results in faster and smaller designs.
RAMs in FLEX 10K modgen use dedicated RAMs available in FLEX 10K architecture.
Modgen Options
As shown in Table 10-1, you can control the modgen implementation by selecting from the
optimization options.
10-10
Table 10-1. Modgen Options
Optimize Options
On/Off
Interactive Command Line
Shell
Batch Mode
Auto - Picks smallest if
optimization in area
mode; and picks fastest
if optimization in delay
mode.
on
(default
)
set modgen_select auto
-select_modgen=auto
Smallest - Picks the
best compact
implementation
available.
off
set modgen_select smallest
-select_modgen=smallest
Small - Picks a
compact
implementation.
off
set modgen_select small
-select_modgen=small
Fast - Picks a fast
implementation.
off
set modgen_select fast
-select_modgen=fast
Fastest - Picks the
fastest implementation
available.
off
set modgen_select fastest
-select_modgen=fastest
If Use Technology Specific Module Generation Library is selected then a technology-specific
modgen library is selected. If not selected, then a default library is used.
Mapping Combinatorial Logic to Embedded Array
Blocks (EABs)
By default, the MAX+PLUS II Compiler maps memory and other LPM functions to EABs in
FLEX 10K and ACEX 1K devices. In addition, you can direct the compiler to implement other
combinatorial logic to an EAB by attaching an implement_in_eab attribute to an instance.
10-11
Following is a VHDL example that directs the compiler to implement the mult component in
EAB logic.
entity mult is
port (A,B: integer range 0 to 15;
Q: out integer range 0 to 255);
end mult;
architecture behavior of mult is
begin
Q <= A*B;
end behavior;
entity eab_test is
port (CLK,MAC,RST:bit; A,B: integer range 0 to 15;
Q: buffer integer range 0 to 255);
end eab_test;
architecture behavior of eab_test is
signal P: integer range 0 to 255;
component mult;
port (A,B: in integer range 0 to 15;
Q: out integer range 0 to 255);
end component;
...continued EABs example.
attribute
attribute
attribute
attribute
logic_option:string;
noopt:boolean;
logic_option of ul:label is “implement_in_eab=on”;
NOOPT of ul:label is true;
begin
U1:mult port map (A,B,P); -- Product of A and B
process (RST,CLK)
begin
if (RST=’1’) then --Reset
Q <= 0;
else
if (CLK=’1’ and CLK’event) then --Clock (edge triggered)
if(MAC=’1’) then
Q <= P+Q;
else
Q <= P;
end if;
end if;
end process;
end behavior;
10-12
Implementing a Pipelined Multiplier
LeonardoSpectrum can implement pipelined multipliers for Altera devices.
Introduction
Pipelining combinational logic involves putting levels of registers in the logic to introduce
parallelism and, as a result, improve speed.
Flip flops introduced by pipelining, typically incur a minimum of additional area on CPLDs by
occupying the unused flip flops within logic cells that are already used for implementing
combinational logic in the design.
The LeonardoSpectrum Approach to Pipelining
LeonardoSpectrum requires certain constructs in the input RTL source code description to allow
the pipelined multiplier feature to take effect. These constructs call for “m” levels of registers to
be inferred at the output of the multiplier, where m is an integer greater than 1.
Let n be the smallest integer that is greater than or equal to the base 2 logarithm of the width of
the multiplier/multiplicand. LeonardoSpectrum automatically pipelines the multiplier by
moving the first x levels of the inferred registers into the multiplier, where
x = m-1, for 2 <= m <= n
or
x = n-1, for m > n
Turning off the Pipelined Multiplier Feature
The pipelined multiplier feature is turned on by default. This feature can be disabled by setting
the variable pipeline_mult to false.
set pipeline_mult false
Quality of Results
Post layout areas and delays are presented for Altera FLEX 10K. A comparison is made
between the non-pipelined version and the 4-stage pipelined version of a 16-bit unsigned
multiplier; the non-pipelined version has one level of register at the output.
As shown in Figure 10-2, the speed improvements are significant. Moreover, in the context of
an entire design, the percentage of additional area is minimal.
10-13
Table 10-2. Effect of Pipelining on Quality of Results
Altera FLEX 10K
P & R Area (LCs)
Delay, ns
Mhz
non-pipelined
541
27.4
36.49
pipelined
587
12.8
78.12
Note: Clock Enable, Asynchronous Clear/Set
In the final pipelined multiplier, common clock enable and asynchronous clear are supported in
all levels of registers.
Asynchronous set is supported with these restrictions: Among the levels of registers inferred at
the output of a multiplier, only the last level can have asynchronous set. If asynchronous set is
present on an inferred register level other than the last, then the multiplier is not pipelined; a
message appears to that effect.
Source Code Examples of Pipelined Multipliers
The following source code examples represent an RTL level description of a 16-bit, unsigned
multiplier. The operand inputs are registered on the first clock edge. LeonardoSpectrum infers
four levels of registers at the output of the multiplier and generates a 4-stage pipelined
multiplier.
VHDL Template for an unsigned pipelined multiplier
library ieee ;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
entity pipelined_multiplier is
-- generic size is the width of multiplier/multiplicand;
-- generic level is the intended number of stages of the
-- pipelined multiplier;
-- generic level is typically the smallest integer greater
-- than or equal to base 2 logarithm of size, as returned by -- function
log, which you define.
generic (size : integer := 16; level : integer := log(size));
port (
a : in std_logic_vector (size-1 downto 0) ;
b : in std_logic_vector (size-1 downto 0) ;
clk : in std_logic;
pdt : out std_logic_vector (2*size-1 downto 0));
end pipelined_multiplier ;
architecture exemplar of pipelined_multiplier is
10-14
type levels_of_registers is array (level-1 downto 0) of unsigned (2*size-1
downto 0);
signal a_int, b_int : unsigned (size-1 downto 0);
signal pdt_int : levels_of_registers;
begin
pdt <= std_logic_vector (pdt_int (level-1));
process(clk)
begin
if clk'event and clk = '1' then
-- multiplier operand inputs are registered
a_int <= unsigned (a);
b_int <= unsigned (b);
-- 'level' levels of registers to be inferred at the
-- output of the multiplier
pdt_int(0) <= a_int * b_int;
for i in 1 to level-1 loop
pdt_int (i) <= pdt_int (i-1);
end loop;
end if;
end process;
end exemplar ;
Verilog Template for an unsigned pipelined multiplier
module pipelined_multiplier ( a, b, clk, pdt);
/*
* parameter 'size' is the width of multiplier/multiplicand;
* parameter 'level' is the intended number of stages of the
* pipelined multiplier;
* which is typically the smallest integer greater than or equal * to base
2 logarithm of 'size'
*/
parameter size = 16, level = 4;
input [size-1 : 0] a;
input [size-1 : 0] b;
input clk;
output [2*size-1 : 0] pdt;
reg [size-1 : 0] a_int, b_int;
reg [2*size-1 : 0] pdt_int [level-1 : 0];
integer i;
assign pdt = pdt_int [level-1];
always @ (posedge clk)
begin
// registering input of the multiplier
a_int <= a;
b_int <= b;
10-15
Mapping Memory Elements to FLEX Devices
// 'level' levels of registers to be inferred at the output // of the
multiplier
pdt_int[0] <= a_int * b_int;
for (i = 1; i < level; i = i + 1)
pdt_int [i] <= pdt_int [i-1];
end
endmodule
Mapping Memory Elements to FLEX
Devices
Inferring ROMs from the HDL Code
Currently you can implement ROM behavior in the HDL source code. You can do this with
CASE statements or you can specify the ROM as a table. The HDL is then converted to a variety
of combinational logic in LeonardoSpectrum and mapped to LEs.
The ROM table can be mapped into a combination of decoders, muxes, or constant nets. This
depends on the output data bit pattern. Better utilization may be achieved if the ROM tables are
mapped to specialized blocks in CPLDs: for example, an EAB in the Altera FLEX10K
technology.
LeonardoSpectrum can detect ROMs and can support the mapping of ROM tables. Since
several types of combinational logic can be mapped to ROMs, a flexibility is needed to
determine if a detected ROM should be implemented. The implementation will use default
mapping or map the ROM into EABs.
ROM Detection
By default, the minimum size of a detected ROM is 256. If you want to detect ROMs smaller in
size, then you must set the mem_minimum_size variable to a different value. For example:
set mem_minimum_size 64
set mem_minimum_size 0 (to
detect ROMs of all sizes)
ROM Data Extraction
After the ROM network is detected, the ROM data for the network must be elaborated. The
ROM data is created and converted to the format expected by the target technology.
The following code segments illustrate how ROMs can be specified in your HDL source.
10-16
Verilog Design Example with ROM
Note: set mem_minimum_size 0
module rom_32x4 (addr, dout);
input [4:0] addr;
output [3:0] dout;
reg [3:0] dout;
always @(addr)
begin
case (addr)
0:dout = 4'b1110;
1:dout_ = 4'b0100;
2:dout_ = 4'b1110;
3:dout_ = 4'b1001;
4:dout_ = 4'b1111;
5:dout_ = 4'b0011;
6:dout_ = 4'b1000;
7:dout_ = 4'b0001;
8:dout_ = 4'b0110;
9:dout_ = 4'b0001;
10:dout_ = 4'b1100;
11:dout_ = 4'b0000;
12:dout_ = 4'b0110;
13:dout_ = 4'b0000;
14:dout_ = 4'b0100;
15:dout_ = 4'b0110;
16:dout = 4'b1110;
17:dout_ = 4'b0100;
18:dout_ = 4'b1110;
19:dout_ = 4'b1001;
20:dout_ = 4'b1111;
21:dout_ = 4'b0011;
22:dout_ = 4'b1000;
23:dout_ = 4'b0001;
24:dout_ = 4'b0110;
25:dout_ = 4'b0001;
26:dout_ = 4'b1100;
27:dout_ = 4'b0000;
28:dout_ = 4'b0110;
29:dout_ = 4'b0000;
30:dout_ = 4'b0100;
10-17
VHDL Design Example with ROM
Note: set mem_minimum_size 0
Library ieee;
use ieee.std_logic_1164.all;
package Table_rom is
Type rom_type is array ( 0 to 32 - 1 ) of STD_LOGIC_VECTOR
( 8 - 1 downto 0 ) ;
constant ROM : rom_type :='(
"00011111",
"01111111",
"11111111",
"01111111",
"00011111",
"01111111",
"11111111",
"11111111",
"00111111",
"11111111",
"00000011",
"11111111",
"00001111",
"00111111",
"00001111",
"11111111",
"11111111",
"00111111",
"00001111",
"01111111",
"00111111",
"11111111",
"01111111",
"01111111",
"01111111",
"00111111",
"00111111",
"01111111",
"11111111",
"01111111",
10-18
Model ROM Code
The following is an example of VHDL code from model ROM, primitive, block code M01.
Library ieee;
use ieee.std_logic_1164.all ;
entity rom_example1 is
generic ( DEPTH : in INTEGER ;
DATA_WIDTH : in INTEGER ;
ADDR_WIDTH : in INTEGER );
port( ADDR : in STD_LOGIC_VECTOR((ADDR_WIDTH-1)downto 0);
DATAOUT : out STD_LOGIC_VECTOR((DATA_WIDTH-1)downto 0));
end rom_example1 ;
Input Data Sets for ROM Inferencing
VHDL example (one of two):
Library ieee;
use ieee.std_logic_arith.all;
use work.Table_rom.all;
architecture ex1 OF rom_example1 is
begin
proc_addr: process (ADDR)
variable addr_int: integer range 0 to DEPTH-1;
begin
addr_int := CONV_INTEGER(UNSIGNED(ADDR));
DATAOUT <= ROM(addr_int);
end process;
end ex1;
10-19
VHDL example (two of two):
Library ieee;
use ieee.std_logic_1164.all ;
entity top is
port ( addr_in : in STD_LOGIC_VECTOR((5-1) downto 0) ;
clock : in STD_LOGIC ;
reset : in STD_LOGIC ;
output_enbl : in STD_LOGIC;
data_out : out STD_LOGIC_VECTOR((8-1) downto 0) ) ;
end top ;
architecture top of top is
component rom_example1
generic ( DEPTH : in INTEGER ;
DATA_WIDTH : in INTEGER ;
ADDR_WIDTH : in INTEGER );
port (ADDR : in STD_LOGIC_VECTOR((ADDR_WIDTH-1)downto 0);
DATAOUT :out STD_LOGIC_VECTOR((DATA_WIDTH-1) downto 0));
end component ;
begin
M0 : rom_example1
generic map (DEPTH => 32 ,
DATA_WIDTH => 8 ,
ADDR_WIDTH => 5 )
port map ( ADDR => addr_in,
DATAOUT => data_out);
end top ;
10-20
Mapping
The detected ROM network is mapped to a parameterized library module as shown in the
following table:
LPM_TYPE
element type (set to LPM_ROM)
LPM_WIDTH
data size
LPM_WIDTHAD
address size
LPM_NUMWORDS
memory size
LPM_ADDRESS_CONTROL
unregistered or registered
LPM_OUTDATA
unregistered or registered
LPM FILE
name of file containing the ROM data
The target place and route tool then maps the LPM_ROM to the appropriate logic element in the
technology.
ROM Data File
LeonardoSpectrum generates a ROM data file that contains the ROM programming data as part
of the LPM ROM instantiation. This data is in the Intel Hex Object File format which is
supported by Altera tools. The following example is for a 32x5 ROM:
:020000040000fa
:08000000030f1f0f030f1f1f68
:08000800071f001f0107011f83
:080010001f07010f071f0f0f6e
:080018000f07070f1f0f0f1f58
:00000001ff
Type of Inferencing ROMs
LeonardoSpectrum supports both synchronous and asynchronous ROMs.
10-21
Altera FLEX 10K Modgen Support for ROMs
The Altera FLEX 10K Modgen Library supports asynchronous and synchronous ROMs. The
lpm_roms are mapped to Embedded Array Blocks (EABs) in the Altera FLEX 10K technology.
This allows for better utilization of the device.
If the selected device contains the number of EABs that are required to implement a ROM of the
desired size, then LeonardoSpectrum automatically checks and creates lpm_roms. If the ROM
size does not fit the available EABs, then the default implementation is used.
Mapping RAMs to the FLEX 10K Architecture
LeonardoSpectrum supports LPM RAM components for FLEX 10K. There are two levels of
support for RAMs in LeonardoSpectrum:
•
RAM instantiation
LeonardoSpectrum supports RAM_DQ, RAM_IO through modgen. You can instantiate the
RAM_IO, RAM_DQ components from VHDL and Verilog. LeonardoSpectrum then
implements them using Altera's LPM components (LPM_RAM_DQ, LPM_RAM_IO) and
specifies all the necessary names and properties that are required by MAX+PLUS II. By
instantiating the modgen RAM_DQ, RAM_IO, you do not need to know what names and
properties are required.
•
Direct LPM components instantiation
LPM components can be instantiated directly. You must specify the correct LPM names
and properties required by MAX+PLUS II.
Instantiating RAMs (ram_dq) in the VHDL Source Code
Since the description of ram_dq is in file: $EXEMPLAR/data/modgen/flex10.vhd, you should
run analyze $EXEMPLAR/data/modgen/flex10.vhd in LeonardoSpectrum, before reading in
your design.
A VHDL Example
Note: before beginning the following VHDL example, read in the lpm_components package
from the Altera installation:
read $ALTERA_PATH/vhdl93/lpm/lpm_components.vhd
10-22
library ieee;
use ieee.std_logic_unsigned.all;
use work.LPM_components.all;
library ieee;
use ieee.std_logic_unsigned.all;
use work.lpm_ram_dq.all;
entity ram256x6 is
port (
RD_ADR : in std_logic_vector (7
WR_ADR : in std_logic_vector (7
WR_DATA : in std_logic_vector (5
WE
: in std_logic;
WR_ACCESS : in std_logic;
RAM_DATA : out std_logic_vector
end RAM256x6;
downto 9);
downto 0);
downto 0);
(5 downto 0));
architecture RAM256x6_A of RAM256x6 is
signal ADR: std_logic_vector (7 downto 0);
begin
ADR <= WR_ADR when WR_ACCESS=’1’ else RD_ADR;
RAM0:LPM_RAM_DQ
generic map (LPM_WIDTH=>6;
LPM_WIDTHAD=>8)
port map (
DATA => WR_DATA,
ADDRESS => ADR,
WE => WE,
Q => RAM_DATA);
end RAM256x5_A;
Instantiating LPMs in the Verilog Source Code
You must use the Defparam construct to specify generic values for the instantiated RAM. For a
description of Defparams needed for each RAM and their default values, refer to the Library of
Parameterized Modules (LPM), an Altera document. Defparms values that are not specified use
default values.
10-23
Verilog example:
module lpm_ram_dq ( q, data, inclock, outclock, we, address) ;
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
parameter
input
input
input
output
lpm_type = "lpm_ram_dq" ;
lpm_width = 1 ;
lpm_widthad = 1 ;
lpm_numwords = 2 ;
lpm_file
= "UNUSED" ;
lpm_indata
= "REGISTERED" ;
lpm_outdata = "REGISTERED" ;
lpm_addr_control = "REGISTERED" ;
polar_data
= "NORMAL" ;
polar_inclock = "NORMAL" ;
polar_outclock = "NORMAL" ;
polar_we
= "NORMAL" ;
polar_address = "NORMAL" ;
polar_q
= "NORMAL" ;
[lpm_width-1:0] data ;
[lpm_widthad-1:0] address ;
inclock, outclock, we ;
[lpm_width-1:0] q;
endmodule // lpm_ram_dq
Verilog Example:
module test_lpm_ram (q, data, inclock, outclock, we, address);
parameter width = 8 ;
parameter widthad = 2 ;
parameter numwords = 4 ;
input
input
input
output
[width-1:0] data ;
[widthad-1:0] address ;
inclock, outclock, we ;
[width-1:0] q;
lpm_ram_dq Instance_r (q, data, we, inclock, outclock, address);
defparam Instance_r.lpm_width = width;
defparam Instance_r.lpm_numwords = numwords;
defparam Instance_r.lpm_widthad = widthad;
endmodule
10-24
Inferring RAM from the HDL Source Code
LeonardoSpectrum infers RAMs automatically from VHDL and Verilog. If the modgen library
is loaded, the library uses the LPM description from modgen to implement the RAMs.
For example, consider this Verilog description:
module ram (clk, datain, addr, dataout);
input clk;
input [0:3] datain ;
input [0:1] addr;
output [0:3] dataout;
reg [0:3] r[0:3];
reg [0:1] addr_out;
assign dataout = r[addr_out];
always @(posedge clk)
begin
addr_out = addr;
r[addr] = datain;
end
endmodule
LeonardoSpectrum infers an LPM ram_dq for this design.
The following is a schematic of LeonardoSpectrum output:
addr(1)
xmplr_INST_181_11_10_10
addr(0)
dataout(3)
address(0)
address(1)
datain(3)
datain(2)
data(0)
q(0)
data(1)
q(1)
data(2)
q(2)
data(3)
q(3)
inclock
datain(1)
dataout(2)
dataout(1)
dataout(0)
outclock
we
datain(0)
clk
lpm_ram_dq_4_2
'1'
Y
Vcc
LeoRG 21
10-25
Using RAMs
Types of RAMs Inferred
LeonardoSpectrum supports two types of RAMs:
•
RAM_DQ. RAM_DQ is a single-port RAM with separate input and output data lines.
•
RAM_IO. RAM_IO is a single-port RAM with bidirectional data lines.
Both of these RAM types support synchronous or asynchronous read and write. These RAMs
are automatically inferred by LeonardoSpectrum from VHDL or Verilog.
The inferencing process distinguishes between RAMs that perform the read operation with an
address clocked or not clocked by the write clock (read address clocked). Both of the following
VHDL examples perform synchronous writes (inclock) and synchronous reads (outclock);
LeonardoSpectrum recognizes these VHDL processes as RAMs:
•
•
10-26
The first, entity ram_example1, is when the read operation does not have a clocked
address.
The second, entity ram_example2, is when the read operation does have a clocked
address.
library ieee, exemplar;
use exemplar.exemplar_1164.all;
entity ram_example1 is
port (data: in std_logic_vector(7 downto 0);
address: in std_logic_vector(5 downto 0);
we, inclock, outclock: in std_logic;
q: out std_logic_vector(7 downto 0));
end ram_example1;
architecture ex1 of ram_example1 is
type mem_type is array (63 downto 0) of
std_logic_vector (7 downto 0);
signal mem: mem_type;
begin
l0: process (inclock, outclock, we, address) begin
if (inclock = '1' and inclock'event) then
if (we = '1') then
mem(evec2int(address)) <= data;
end if;
end if;
if (outclock = '1' and outclock'event) then
q <= mem(evec2int(address));
end if;
end process;
end ex1;
The first, entity ram_example1, is when the read operation does not have a clocked address.
10-27
library ieee, exemplar;
use exemplar.exemplar_1164.all;
entity ram_example2 is
port (data: in std_logic_vector(7 downto 0);
address: in std_logic_vector(5 downto 0);
we, inclock, outclock: in std_logic;
q: out std_logic_vector(7 downto 0));
end ram_example2;
architecture ex2 of ram_example2 is
type mem_type is array (63 downto 0) of
std_logic_vector (7 downto 0);
signal mem: mem_type;
signal address_int: std_logic_vector(5 downto 0);
begin
l0: process (inclock, outclock, we, address) begin
if (inclock = '1' and inclock'event) then
address_int <= address;
if (we = '1') then
mem(evec2int(address)) <= data;
end if;
end if;
if (outclock = '1' and outclock'event) then
end if;
end process;
end ex2;
q <= mem(evec2int(address_int));
The second, entity ram_example2, is when the read operation has a clocked address.
Altera FLEX 10K Modgen Support for RAMs
The Altera FLEX 10K Modgen Library supports asynchronous RAMs and synchronous RAMs
that clock the read address with the write clock.
Generating Simulation Memory Models with Genmem
The Genmem flow is supported for Altera FLEX devices. Genmem is an altera utility that
generates simulation models for memory. You can generate RAMs, ROMs, FIFOs, and dual
port RAMs in different sizes. The memory can be synchronous or asynchronous. Genmem
writes the simulation model in VHDL or Verilog.
Use the following flow:
1. Run genmem to generate the desired memory.
10-28
For example:
genmem asynram 256x15 -verilog
This command generates a 256x15 asynchronous RAM model and writes the model in
Verilog.
2. Instantiate the RAM module in your Verilog input file.
LPM Instantiation
You can instantiate any LPM component from VHDL and Verilog formats.
Genmen Verilog Design
Synthesize your Verilog design with LeonardoSpectrum by targeting FLEX 10K.
•
•
•
•
•
The -simple_port_names option is supported.
Generate an EDIF netlist as the output. The genmem component is treated as a blackbox by LeonardoSpectrum. The EDIF netlist that describes your design and the Verilog
file generated by genmem is used as input to MAX+PLUS II. The MAX+PLUS II
software merges the genmem description into the top level design and places and routes
the design.
You need to include the module declaration in this file. In the following Verilog
genmem example, a module declaration is shown.
Set the hdl_array_name_style variable to %s%d to ensure that port names generated by
LeonardoSpectrum match port names generated by genmem.
Generate EDIF netlist as an output. The genmem component is treated as a black-box by
LeonardoSpectrum.
The EDIF netlist that describes the design and the Verilog file generated by genmem is used as
input to MAX+PLUS II place and route. The MAX+PLUS II software merges the genmem
description into the top level design and places and routes it.
10-29
Writing the EDIF Output
LeonardoSpectrum for Genmem
The genmem module declaration must be included in this file as shown in the Verilog example:
module ram_example ( addr, we, d, o);
input [0:7] addr;
input we;
input [0:14] d;
output [0:14] o;
asyn_ram_256x15 i1(.Address(addr), .WE(we), .Q(o), .Data(d));
endmodule
// This module declaration is copied from the genmem file */
module asyn_ram_256x15 (Q, Data, WE, Address);
parameter
parameter
parameter
parameter
LPM_FILE = "UNUSED";
Width = 15;
WidthAd = 8;
NumWords = 256;
input [WidthAd-1:0] Address;
input [Width-1:0] Data;
input WE;
output [Width-1:0] Q;
endmodule
EDIF is the only interface between LeonardoSpectrum and the Altera MAX+PLUS II software.
The following are known problems when writing out EDIF for Altera:
•
•
10-30
Altera EDIF file name should match the design name. The design name, and the file
name are case sensitive. You can change the design name if needed by using the move
command in LeonardoSpectrum.
If the hierarchy is preserved for hierarchical designs, LeonardoSpectrum writes out
hierarchical EDIF. If sub-modules have busses on the boundary, usually
LeonardoSpectrum renames these busses.
For example:
(port
(port
(port
(port
(port
(port
(port
(port
(rename
(rename
(rename
(rename
(rename
(rename
(rename
(rename
p23
p22
p21
p20
p19
p18
p17
p16
"Q(0)")
"Q(1)")
"Q(2)")
"Q(3)")
"Q(4)")
"Q(5)")
"Q(6)")
"Q(7)")
(direction
(direction
(direction
(direction
(direction
(direction
(direction
(direction
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))))))
This causes problems with Altera MAX+PLUS II EDIF reader since the reader does not handle
the rename construct properly. You can solve the problem in two ways:
(1)
Note: -simple_port_names creates simple name for vector ports.
(2)
Set the variable hdl_array_name_style to the Altera bus format.
set hdl_array_name_style = %s%d
LeonardoSpectrum then creates the following EDIF:
(port
(port
(port
(port
(port
(port
(port
(port
Q0
Q1
Q2
Q3
Q4
Q5
Q6
Q7
(direction
(direction
(direction
(direction
(direction
(direction
(direction
(direction
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))
OUTPUT))))))
This EDIF is handled correctly by MAX+PLUS II.
LMF file: To take the EDIF generated by LeonardoSpectrum into MAX+PLUS II. The
exemplar.lmf file is required. The exemplar.lmf file is installed in the $EXEMPLAR/data area.
This file maps the cells LeonardoSpectrum writes to MAX+PLUS II primitives and functions.
Make sure that your MAX+PLUS II environment is set to pick up this .lmf file:
If using the MAX+PLUS II GUI then go to menu Interfaces-->EDIF Reader Settings and
make LMF1 point to exemplar.lmf and click on the checkbox for LMF1.
10-31
Using FLEX Designs as Input
If you are using the MAX+PLUS II through command line then edit the .acf file. Search for
EDIF_INPUT_LMF1 and make EDIF_INPUT_LMF1 = exemplar.lmf. Search for
EDIF_INPUT_USE_LMF1 and make EDIF_INPUT_USE_LMF1 = ON.
Using FLEX Designs as Input
EDIF Input
To retarget a FLEX design into other technologies or to optimize a FLEX design using
LeonardoSpectrum, the design must fit into a single FLEX device. This ensures that the single
EDIF netlist generated by MAX+PLUS II captures the whole design. Also, the EDIF writer
must be turned on when running the MAX+PLUS II compiler. If the design does not fit into a
single device, switch to a bigger device until the design fits. (LeonardoSpectrum does not care
what the input device is, only the input device family or technology.) Use the EDIF file
generated by MAX+PLUS II as input to LeonardoSpectrum, with the FLEX library as the
source technology, and synthesize to the chosen technology. In LeonardoSpectrum, first load
the technology library, then read the design:
1> load_lib flex8
--source lib flex8 is loaded
2> read_altera my_flex_design.edf
3> load_lib z_tech
4> optimize -target z_tech
5> write output_file.edf
--output netlist EDIF file, mapped to target technology z_tech
If the design cannot fit into a single device, let MAX+PLUS II partition the design into several
devices and generate several EDIF files. Then, manually write an HDL file that connects the
devices correctly. The MAX+PLUS II report file (multiple pin connections section) can be
helpful in writing this file. Finally, read all the files into LeonardoSpectrum, first the EDIF files,
then the top level file.
EDIF files generated by MAX+PLUS II contain, in addition to all functional I/O pins, a VCC
pin and a GND pin. These pins are specific to Altera EDIF files. Consequently,
LeonardoSpectrum has a special command for reading Altera files: read_altera.
10-32
FLEX 6000/8000 Devices Supported
FLEX 6000/8000 Devices Supported
Devices Families supported are: FLEX 6000, FLEX 8000, FLEX 10K/10KA/10KB/10KE and
ACEX 1K.
FLEX 6000 Family
Default Speed Grade: 2
Speed Grades supported: 2, 3
Devices Supported
EPF6010A
TC100 TC144
EPF6016
TC144 QC208 QC240 BC256 ATC100 ATC144 AQC208
EPF6-24A
TC144 QC208 QC240 BC256
FLEX 8000 Family
Speed Grades supported: 4, 3, 2
Devices Supported
EPF8282A
LC84 TC100 VTC100
EPF8452A
LC84 TC100 GC160 QC160
EPF8636A
LC84 QC160 GC192 QC208 RC208
EPF8820A
TC144 QC160 QC208 RC208 BC225 GC192
EPF81188A
QC208 QC240 RC240 GC232
EPF81500A
QC240 RC240 GC280 RC304
10-33
FLEX 10K Devices Supported
FLEX 10K Family
Speed Grades supported: 3, 4
Devices Supported
EPF10K10
LC84 TC144 QC208
EPF10K20
TC144 RC208 RC240
EPF10K30
RC208 RC240 BC356
EPF10K40
RC208 RC240
EPF10K50
RC240 BC356 GC403
EPF10K70
RC240 GC503
EPF10K100
GC503
FLEX 10KA Family
Speed Grades supported: 4, 3, 2, 1
Devices Supported
EPF10K10A
TC100 TC144 QC208
EPF10K30A
TC144 QC208 QC240 FC256 BC356 FC484
EPF10K50V
R240 BC356
EPF10K100A
RC240 BC356 FC484 BC600
EPF10K130V
GC599 BC600
EPF10K250A
GC599 BC600
10-34
FLEX 10KB Family
Speed Grades supported: 4, 3, 2, 1
Devices Supported
EPF10K100B
QC240 QC208
FLEX 10KE Family
Speed Grades supported: 3, 2, 1, 1XES, 2XES
Devices Supported
EPF10K30E
TC144 QC208 FC256 FC484
EPF10K50E
TC144 QC208 QC240 FC256 FC484
EPF10K100E
QC208 QC240 FC256 FC484
EPF10K130E
TC144 FC484 FC672
EPF10K200E
GC599 BC600 FC672
10-35
ACEX Devices Supported
ACEX Devices Supported
ACEX 1K Family
Speed Grades supported: 3, 2, 1, 1XES, 2XES
Devices Supported
EP1K10
TC100
EP1K30
TC144 QC208 FC256
EP1K50
TC144 QC208 FC256 FC484
EP1K100
QC208 FC256 FC484
10-36
MAX Family Devices Supported
Devices supported are: MAX 3000A, MAX5000, MAX7000/A/AE/E/S, MAX9000
MAX 3000A Family
Default Speed Grade: -10
Speed Grades supported: -4, -5, -6, -7, -10
Devices Supported
EPM3032
ALC44, ATC44
EPM3064
ALC44, ATC44, ATC100
EPM3128
ATC100, ATC144
EPM3256
ATC144, AQC208
MAX 5000 Family
Devices Supported
EPM5032
LC, LI, PC, PI, DC , JC
EPM5064
LC, LI , JC
EPM5128
ALC , LC, LI , JC, GC, GI
EPM5130
LC, JC, QC, GC
EPM5192
LC, LI , JC, GC, GI
10-37
MAX 7000 Family
Speed Grades supported: -6, -7, -10, -12, -15, -15T, -20
Devices Supported
EPM7032
LC44, LI44, QC44, QI44, TC44, TI44, VLC44, VTC44, VTI44
EPM7064
LC44, LI44, TC44, LC68, LI68, LC84, LI84, QC100, QI100
EPM7096
LC68, LI68, LC84, LI84, QC100, QI100
MAX 7000A Family
Speed Grades supported: -6, -7, -10, -12
Devices Supported
EPM7128A
LC84, LI84, TC100 , TI100 , FC100, TC144, TI144, FC256
EPM7256A
TC100, TI100, TC144, TI144, QC208, QI208 , FC256, FI256
MAX 7000AE Family
Speed Grades supported: -4, -5, -6, -7, -10, -12
Devices Supported
EPM7032AE
LC44, TC44
EPM7064AE
LC44, LI44, TC44, TI44, LC84, TC100, FC100
EPM7128AE
LC84, TC100, FC100, TC144, FC256
EPM7256AE
TC100, TC144, QC208, FC256
EPM7384AE
TC144, QC208, FC256
EPM7512AE
TC144, QC208, FC256, BC256
10-38
MAX 7000B Family
Speed Grades supported: -3, -4, -5, -6, -7, -10
Devices Supported
EPM7032B
LC44, TC44, TC48
EPM7064B
LC44, TC44, TC48, TC100, FC100
EPM7128B
TC48, UC169, FC256,
EPM7256B
TC100, FC100, TC144, UC169, QC208, FC256
EPM7384B
TC144, QC208, FC256
EPM7512B
TC100, TC144, UC169, QC208, BC256, FC256,
MAX 7000E Family
Speed Grades supported: -7, -10, -10P, -12, -12P, -15, -20
Devices Supported
EPM7128E
LC84, LI84, QC100, QI100, QC160
EPM7160E
LC84, LI84, QC100, QI100, QC160, QI160
EPM7192E
QC160, QI160, GC160, GI160
EPM7256E
QC160, RC208, RI208, GC192, GI192
10-39
MAX 7000S Family
Devices Supported
EPM7032S
LC44, LI44, TC44, TI44
EPM7064S
LC44, LI44, TC44, TI44, LC84, LI84, TC100, TI100
EPM7128S
LC84, LI84, QC100, QI100, TC100, TI100, QC160, QI160
EPM7160S
LC84, LI84, TC100, TI100, QC160, QI160
EPM7192S
QC160, QI160
EPM7256S
RC108, RI208, QC208
MAX 9000 Family
Devices Supported
EPM9320
LC84, LI84, RC208, RI208, GC280, BC356, ALC84, ALI84, ARC208,
ARI208, ABC356
EPM9400
LC84, RC208, RC240
EPM9480
RC208, RC240
EPM9560
RC208, RI208, RC240, RI240, RC304, RI304, GC280, BC356, ARC208,
ARI208, ARC240, ARI240, ABC356
10-40
Chapter 11
Altera APEX Synthesis
APEX 20K/20KE/20KC Family
LeonardoSpectrum supports mapping your design to the APEX Family of devices wich
included APEX 20K/20KE/20KC, APEX II, Mercury and Excalibur. Depending on the options
selected, mapping to WYSISYG primitives is either done by LeonardoSpectrum or by Quartus.
By default, LeonardoSpectrum does mapping to WYSIWYG primitives. Quartus is place and
route software from Altera. The Altera APEX technology provides support for WYSIWYG
device primitives.
Mapping Options
By default, mapping to WYSIWYG primitives is TRUE and mapping to complex I/Os is FALSE.
The variable apex_wysiwyg_support enables mapping to WYSIWYG ATOMs (an ATOM is a
WYSIWYG primitive or cell) in APEX 20K/20KE devices. If you need to turn this variable off,
you must also set dont_lock_lcells to TRUE. For example,
set apex_wysiwyg_support false
set dont_lock_lcells true
The variable altera_map_complex_ios enables mapping to I/O flip flops. This variable is
functional if the variable apex_wysiwyg_support is also set to TRUE. For example,
set altera_map_complex_ios TRUE
set apex_wysiwyg_support TRUE
LeonardoSpectrum for Altera User’s Manual, v2001.1a
11-1
As shown in the following figure, the altera_map_complex_ios option is also available on the
GUI as Map I/O Registers.
LeonardoSpectrum APEX 20K/20KE Mapping
LeonardoSpectrum support for mapping to Altera APEX 20K/20KE WYSIWYG cells includes:
1. By default, LeonardoSpectrum maps to all modes of Lcells:
•
Counters
•
QFBK_Counters
•
Arithmetic
•
Normal
2. Mapping to I/Os, including various complex I/O configurations is available.
3. RAMs/ROMS are now mapped to LPM_RAMs and LPM_ROMs. In the future, direct
mapping to APEX 20K WYSIWYG primitives - RAM slices and Pterms (product
terms) - will be provided by LeonardoSpectrum. LPM_RAMs and LPM_ROMs are
implemented as RAM slices by Quartus.
4. APEX 20K/20KE libraries are supported.
5. The current P&R GUI for Quartus provides support for the P&R flow using the Quartus
NativeLink API features. This allows you to access and modify designs in the Quartus
database. Currently, the EDIF format is supported for the output netlist. In contrast to
MAX+PLUS II, the choice box selection of "Bring up the Quartus GUI" allows the
additional step of setting up a project and completing the design compilation.
6. Wireload model support is functional.
7. When possible, LeonardoSpectrum supports the absorption of NOT gates into
WYSIWYG primitives.
11-2
8. By default, GND/VCC are exported as cells. In Quartus, the preference is to export
GND/VCC as undriven nets. As shown in the following figure, you can write
power/ground as undriven net by selecting the options in the GUI, or you can set the
following variable in the Interactive Command Line:
set edifout_power_ground_style_is_net TRUE
Figure 11-1. Writing Power/Ground as Undriven Nets
Click
APEX Technology Support
The APEX 20K/20KE devices use the best features from the current Altera FLEX 10K and
FLEX 6000 family architectures as follows:
•
The LE (logic element) structure for FLEX 6 remains the same.
•
Each LE consists of 4 i/p LUT, D flip flops, carry and cascade chains.
•
A LAB (logic array block) consists of 10 LEs.
•
A set of 16 LABs + 1 ESB (embedded system block) makes a MegaLAB.
The LAB wide control signals are:
•
Synchronous Load - FLEX 10
•
Asynchronous Load - FLEX 6
•
Synchronous Clear - FLEX 6
•
Clock Enable - similar to FLEX 10
11-3
Note: References to FLEX 10K and FLEX 6000 in this chapter are for comparison purposes
only.
Note: There are two new LAB wide clock enable functions. The clock enable in FLEX 10K
utilizes one LUT input.
The following are carry chain changes:
•
Counter mode incorporates lab-wide up/down or count enable.
•
Dedicated logic to start counter from LE1.
The following are output configurations. The normal mode LE can implement three distinct
outputs:
•
combinational out
•
registered output
•
cascade output
APEX ESB (Embedded System Block)
The ESB can be usedm to implement RAM, ROM, or pterm logic as follows:
•
•
•
Single-port RAMs and dual-port RAMs - both synchronous and asynchronous - similar
to FLEX 10KE.
ROMs - similar to FLEX 10KE.
pterm logic: Each ESB contains 32 literals with 16 macrocells in each ESB. You should
mplement the following circuits with pterm: wide multiplexers, state machines, wide
input OR gates, and high fan-in sum-of-product equations.
Directing Quartus to Implement a Design Block in
PTERM
Normally, APEX Embedded System Blocks are used to first implement memory elements such
as RAM and ROM. In cases where you have a design doesn’t use all of the ESB resources for
memory, but does have design elements such as wide multiplexers, state machines, wide input
OR gates, and high fan-in sum-of-product equations, then you can direct Quartus (through
LeonardoSpectrum) to use ESB resources to implement these circuits. This will improve overall
system performance.
11-4
Assume, for example, that you have a complex state machine that is implemented as a module
in you HDL design, and you want to implement the state machine as pterm logic in ESBs. Do
the following:
1. Choose the APEX technology, then read your design into LeonardoSpectrum.
2. As part of setting the design constraints, move to the Constraints FlowTab, then to the
Module PowerTab.
3. Select the state machine block in the Module window, select the option Implement In
PTERM, then click Apply.
This actions flattens the block and tags the block to be implemented as pterm logic when
Quartus maps the logic to the resources in the chip.
If you are a Level 3 user, you can perform the same action from a script or the Interactive
Command Line shell by executing a command similar to the following:
implement_in_pterm .work.state_machine.rtl
Simulation with Pre-Layout Verification (Optional)
After optimization is complete, you may write out and complie a VHDL or Verilog netlist,
compile the WYSIWYG cell models, and then test and simulate the design.
LPM (Library Parameterized Module) RAMs/ROMs
If you have LPM RAMs and ROMs in a design, then you should create simulation models with
genmem (generate memory). Refer to the Altera FLEX Synthesis chapter.
11-5
FSM Encoding (binary, gray, random, onehot, twohot,
auto)
For auto encoding, LeonardoSpectrum varies the encoding based on bit width. Moreover,
enumerated types with fewer elements than global integer lower_enum_break are encoded as
binary; while larger enumerated types are encoded as onehot. Values larger than global integer
upper_enum_break are encoded as binary. The auto default allows LeonardoSpectrum to select
encoding on a case-by-case basis.
NOTE: If LeonardoSpectrum selects onehot for your auto encoded design, then “onehot
encoding” is printed for the log file of your design.
The encoding variable determines how LeonardoSpectrum encodes enumerated types, and
implements a state machine with a state vector of an enumerated type.
Twohot Encoding
Twohot encoding is now added to FSM encoding (binary, gray, random, onehot, twohot, auto).
Twohot sets two flip flops high for each state. The twohot encoding requires more flip flops
than binary and fewer flip flops than onehot. Twohot encoding may be beneficial to large FSMs
where onehot uses too many flip flops, and binary requires too much decode logic.
Refer also to Chapter 2 in the LeonardoSpectrum HDL Synthesis Manual.
Note: Encoding is supported for APEX technologies with small enumerated types of up to five
elements.
11-6
APEX 20K Devices Supported
EP20K100
TC144 QC208 QC240 FC324 BC356
EP20K200
RC208 RC240 RI240 BC356 FC484
EP20K400
BC652 BI652 FC672
APEX 20K Speed Grades
Default Speed Grade: -3,
Speed Grades supported: -3, -2, -1, -1X, -2X, 1V, 1XV, 2V
APEX 20K Wire Load
apex20_default
apex20_quadrant_default
apex20_lab_default
apex20_device_default
apex20_megalab_default
apex20_uncons_default
11-7
APEX 20KE Devices Supported
EP20K30E
TC144 QC208 FC144 FC324
EP20K60E
TC144 QC208 QC240 FC144 FC324 BC356
EP20K100E
TC144 QC208 QC240 FC144 FC324 BC356
EP20K160E
TC144 QC208 QC240 BC356 FC484
EP20K200E
QC208 QC240 BC356 FC484 BC652 FC672
EP20K300E
QC240 BC652 FC672
EP20K400E
BC652 FC672
EP20K600E
BC652 FC672 FC33
EP20K1000E
BC652 FC672 FC33
EP20K1500E
BC652 FC33
APEX 20KE Speed Grades
Default Speed Grade: -3,
Speed Grades supported: -3, -2, -1, -1X, -2X
APEX 20KE Wire Load
11-8
apex20e_default
apex20e_quadrant_default
apex20e_lab_default
apex20e_device_default
apex20e_megalab_default
apex20e_uncons_default
APEX 20KC Devices Supported
EP20K100
CT144C CF144C CQ208C CQ240C CF324C CB356C
EP20K200
CQ208C CQ240C CB356C CF484C CB652C CF672C
EP20K400
CB652C CF672C
EP20K600
CB652C CF672C CF33C
EP20K1000
CB652C CF672C CF33C
EP20K1500
CB652C CF33C
APEX 20KC Speed Grades
APEX 20KC Wire Load
apex20c_default
apex20c_quadrant_default
apex20c_lab_default
apex20c_device_default
apex20c_megalab_default
apex20c_uncons_default
11-9
APEX II Devices Supported
EP2A15
F672C
EP2A25
F672C
EP2A40
F672C
APEX II Speed Grades
Speed Grades supported: 7
APEX II Wire Load
apexii_default
11-10
Mercury Devices Supported
Mercury Devices Supported
Mercury Devices
EP1M120F484C
EP1M350F780C
APEX 20KC Speed Grades
Default Speed Grade: 5ES
Speed Grades supported: 5ES, ES, and 8ES
APEX 20KC Wire Load
Default: STD-1
STD-1, STD-2, STD-3
11-11
Excalibur Mips Devices Supported
Excalibur Mips Devices Supported
Excalibur Mips Devices
EPXM10F1020C
Excalibur Mips Speed Grades
Excalibur Mips Wire Load
11-12
apex20c_default
apex20c_lab_default
Excalibur Arm Devices Supported
Excalibur Mips Devices
EPXA10F1020C
Excalibur Mips Speed Grades
Excalibur Mips Wire Load
apex20c_default
apex20c_lab_default
11-13
11-14
Appendix A
SynthesisWizard Tutorial
Welcome to the SynthesisWizard tutorial. The SynthesisWizard is one of three ways to
synthesize your design; Quick Setup and FlowTabs are the other two ways. basically, the
SynthesisWizard guides you through Understanding the Quick Setup Flow described on page
1-4.
The SynthesisWizard consists of four steps that must be completed in the order presented. If
you are a first-time user, then the SynthesisWizard is recommended to get you started right
away.You can open the SynthesisWizard by clicking on the toolbar SynthesisWizard hat.
Note: While the SynthesisWizard is open, you are restricted entirely to the functions available
on the SynthesisWizard.
SynthesisWizard Tour
The following screens and four steps give you a tour of the SynthesisWizard. The steps ask you
to apply example choices and to use defaults.
•
Step 1 - Set the Technology: Altera FLEX 6K
•
Step 2 - Open the Input Files: pseudorandom.vhd (demo file)
•
Step 3 - Set Global Constraints: 20 MHz
•
Step 4 - Specify the Output File and Finish: pseudorandom.edf (default)
Wizard Buttons
Each of the four SynthesisWizard steps contains buttons that you can click at any time:
•
Help: select for further assistance.
•
Cancel: select to exit the SynthesisWizard.
•
Back: select to return to the previous SynthesisWizard step, if any.
A-1
Specifying the Technology Library - Step 1 of 4
Use the following steps:
Figure A-1. Specifying the Technology Library, Step 1of 4
1. Optional: Click the Altera logo to open your default web browser and access Altera’s
Web page, if a Web page is available
2. Click FPGA to extend the tree and select Altera
3. Select Altera FLEX 6K
4. Click Next>
A-2
Input Files, Step 2 of 4
Open your design Input Files.
Figure A-2. Opening the Input Files, Step 2 of 4
Use the following steps.
1. Set the working directory. The working directory is the place where LeonardoSpectrum
saves output files. Click on the Working Directory folder to open the Set Working
Directory dialog box. Highlight your working directory folder and click Set.
Note: The path to the working directory is also displayed in the status bar near the
bottom of main window.
A-3
Note: The working directory is automatically saved and restored between sessions.
Figure A-3. Setting the Working Directory
2. Click Cancel on Set Working Directory. You now return to Input Files
3. Next, click the Open files button and select the design pseudorandom.vhd
4. Click Open
A-4
5. Use the default Encoding Style for the state machine
Figure A-4. Set Input File(s)
6. Resource Sharing - If you select this option, then operators (adders, multipliers) will be
shared if they are disjoint (never used twice in the same clock cycle).
7. Click Next>
Global Constraints, Step 3 of 4
You can set the timing constraints for the entire design. Use these steps:
1. Use the global constraint defaults.
Type 20 in the Mhz field. A repeating wave form appears in the window with 20 Mhz
values.
A-5
2. If you desired, you can further customize the global constraints with the radio buttons.
Figure A-5. Global Clock, Step 3 of 4
3. If necessary, refer to Setting Timing Constraints on page 6-3 for more information on
how to set timing constraints.
4. Click Next>
A-6
Output File, Step 4 of 4
The Output File dialog, shown in Figure A-6, allows you how to specify the location and format
of your FPGA netlist. The Downto: for Technology or Primitive Cells includes the selected
cells in your output file.
Figure A-6. Output File, Step 4 of 4
Use these steps:
1. Examine the output file pathname for pseudorandom.edf
2. If you desire, click the Filename button to change the output file pathname.
A-7
3. Click Save/Cancel to return to the Output File, step 4 of 4.
Figure A-7. Set Output File
4. Use the Format: defaults.
5. Click Finish. The wizard closes and the synthesis run starts.
Run
During the synthesis run, you can view the Transcript in the Information Window and see the
entire flow run. The device utilization report for pseudorandom.vhd is presented. If you close
the information window, click Window -> pseudorandom.vhd to open your file again. During
synthesizing, the toolbar Stop icon turns red to indicate that the system is working. Click Stop
to stop the run at anytime. The progress of the run appears in the lower left of the status bar.
Ready indicates that the run is complete; Stop is grayed out.
Note: Before the run starts, you are prompted with a warning if an output file already exists. If
you click Yes, then the current output file is replaced.
Figure A-8. Screen A-8. Warning - Overwriting Output File
A-8
Index
INDEX
A
ACEX 1K devices supported, 10-36
Adobe Acrobat Reader, 1-9
Advanced (Level 3) Synthesis Flow, 10-4
Advanced Settings
FPGA PowerTabs, 4-6
Aliases
setting, 3-9
Altera
Quartus, 9-5
Quartus P&R Integration, 9-5
Altera Place & Route
MAX+PLUS II, 9-3
QuartusI, 9-4
APEX 20K devices supported, 11-7
APEX 20K/20KE mapping, 11-1
APEX 20KC devices supported, 11-9, 11-10
APEX 20KE devices supported, 11-8
APEX technology
WYSIWYG primitives, 11-1
architecture, Altera MAX, 10-2
Attributes
relationship to commands/variables, 3-3
setting, 3-4
Auto-Dissolve Hierarchy, 7-10
B
Batch Mode
LUT mapping, 4-3
black box, 10-29
Bubble Tristates, 7-13
Buffers
global, 4-4
C
carry
chain, Altera FLEX, 10-10
cascade
routing resource, 10-2
cascade gate
Altera FLEX, 10-8
CHIP_PIN_LC, Altera FLEX, 10-7
Clock Constraints
PowerTab, 6-18
Clock Skew, 6-5
setting constraints, 6-5
Clocks
Combinational Designs
command line options
-auto, 10-11
-fast, 10-11
-fastest, 10-11
-simple_port_names, 10-29, 10-31
-small, 10-11
-smallest, 10-11
Commands
batch mode, 3-9
leonardo command, 3-9
relationship to variables/attributes, 3-3
spectrum command, 3-9
standard Tcl, 3-3
Tcl extensions, 3-4
using within Tcl scripts, 3-4
Constraint Editor
module, 6-27
output, 6-22
signal, 6-24
Constraints
FlowTab, 6-16
counter
Altera FLEX, 10-10
CPLD
complex programmable logic device, 1-1
D
Database
object, 5-4
decrementer
Index-1
Index
INDEX [continued]
Altera FLEX, 10-10
Defparms, Verilog, 10-23
Design
partitioning hints, 7-6
Design Browser, 5-4
view options, 3-29
Design Files
opening, 1-6, 5-2
Design Partitioning, 2-5
hints, 7-6
Devices Supported
ACEX 1K, 10-36
APEX 20K, 11-7
APEX 20KC, 11-9, 11-10
APEX 20KE, 11-8
Excalibur Arm, 11-13
Excalibur Mips, 11-12
FLEX 10K, 10-34
FLEX 10KA, 10-34
FLEX 10Kb, 10-35
FLEX 10KE, 10-35
FLEX 6K, 10-33
FLEX 8K, 10-33
MAX 3000A, 10-37
MAX 5000, 10-37
MAX 7000, 10-38
MAX 7000A, 10-38
MAX 7000AE, 10-38, 10-39
MAX 7000E, 10-39
MAX 7000S, 10-40
MAX 9000, 10-40
Mercury, 11-11
dont_touch Attribute
vs. noopt Attribute, 7-8
E
EDIF
bus, 10-30
Input, 10-32
netlist, 10-30
Index-2
EDIF (Input) PowerTab, 5-12
EDIF (Output) PowerTab, 8-4
embedded array block (EAB), 10-2, 10-30
Excalibur Arm devices supported, 11-13
Excalibur Mips devices supported, 11-12
Exclude Gates, 4-7
exemplar.lmf file, 10-31
expander, Altera MAX, 10-3
Extended Optimization Effort, 7-5
F
False Paths
FIFO, Altera FLEX, 10-2
Files
.lsp file, 3-8
.scr file, 3-8
.xdb file, 3-7
exemplar.ini, 3-6
Flattening Hierarchy, 7-7
FLEX 10K devices supported, 10-34
FLEX 10KA devices supported, 10-34
FLEX 10KB devices supported, 10-35
FLEX 10KE devices supported, 10-35
flip-flop
enable, Altera MAX, 10-3
FlowTabs
Constraints, 6-16
Input, 5-8
Optimize, 7-9
Output, 8-2
Place & Route, 9-2
Technology, 4-5
FPGA Technology
Advanced Settings PowerTab, 4-6
G
genmem
Index
INDEX [continued]
Altera, 10-29
support, 10-28
Global
specify clock period, 6-17
specify maximum delay, 6-17
Global Area
optimization, 7-2
Global Buffers, 4-4
GND, pin, 10-32
GUI options
optimize options, 10-11
H
HDL
mixing design languages, 1-2
second language, 1-2
hdl_array_name_style, variable, 10-29, 10-31
HDLInventor
bookmarks, 3-23
line numbering, 3-21
printing the window content, 3-26
templates, 3-21
Help
about, 3-18
contents, 3-17
help
online, 1-9
Hierarchy
auto-dissolve, 7-10
flattening, 7-7, 7-10
preserve, 7-10
protecting, 7-8
I
I/O
assign manually, 4-2
complex, 4-2
size of, 4-2
I/O Mapping, 4-4
Icon
editing, 3-19
Exemplar’s logo, 3-18
task, 3-18
incrementer
Altera FLEX, 10-10
Information window
printing the content, 3-20
transcript, 3-23
Input
FlowTab, 5-8
Input Arrival Time
Input shortcuts, 5-9
Input Signal Constraints
PowerTab, 6-20
Interactive Command Line, 4-3
list commands, 5-5
list variables, 5-5
interactive command line shell, 10-11
Internal Signal Constraints
PowerTab, 6-24
Introducing, 1-1
L
LABs, Altera, 10-3
LCELL
primitive, 10-9
Library
cell, 5-3
defined, 5-3
primitives, 5-3
Loading
a technology library, 4-2
Lock LCells
Altera, 10-6
logic
array block, Altera, 10-2
element, Altera, 10-2
lookup table
Altera FLEX, 10-8
Index-3
Index
INDEX [continued]
Lookup Table Mapping, 4-3
lookup table mapping
Altera, 10-8
LPM
instantiation, 10-23
LPM_RAM_DQ, component, 10-22
LPM_RAM_IO, component, 10-22
M
macrocell, 10-3
Main Window
banner, 3-13
header, 3-13
major elements, 3-12
Quick Setup vs Advanced FlowTabs, 3-13
Main window
information window, 3-20
menu bar, 3-13
startup, 3-10
Mapping
I/O mapping, 4-4
lookup table, 4-3
MAX 3000A devices supported, 10-37
MAX 5000 devices supported, 10-37
MAX 7000A devices supported, 10-38
MAX 7000AE devices supported, 10-38, 10-39
MAX 7000E devices supported, 10-39
MAX 7000S devices supported, 10-40
Mercury devices supported, 11-11
Mixed Synchronous and Asynchronous
Designs
Modgen library
defined, 5-6
Module Constraints
PowerTab, 6-26
move command, 10-30
Multicycle Paths
Index-4
Multiple Asynchronous Clocks, 6-8
Multiple Synchronous Clocks, 6-6
N
Net, 5-3
noopt Attribute
vs. dont_touch Attribute, 7-8
O
Object Names, 5-4
Opening Design Files, 1-6
Operators, 5-3
how they are inferred, 5-6
operators
arithmetic, 10-10
relational, 10-10
Optimization
extended effort, 7-5
global area, 7-2
Optimization Effort
setting from the Quick Setup FlowTab, 1-7
Optimize
FlowTab, 7-9
option
HDL languages, 1-2
Output FlowTabs, 8-2
Output Required Times
Output Signal Constraints
PowerTab, 6-22
P
Partitioning, 2-5
Partitioning Hints, 7-6
Partitioning Your Design, 2-5
Path Constraints
PowerTab, 6-28
pin location
Altera, 10-7
Index
INDEX [continued]
pin_number, attribute, 10-7
Pipelined multiplier
Altera, 10-13
Place & Route FlowTab
Altera MAX+PLUS II, 9-2
Place and Route tools
setting the pathname to, 1-7
Port instance, 5-3
PowerTabs
Clock Constraints, 6-18
EDIF, 8-4
FPGA Advanced Settings, 4-6
Input Signal Constraints, 6-20
Input-EDIF, 5-12
Input-Verilog, 5-11
Input-VHDL, 5-10
Internal Signal Constraints, 6-24
Module Constraints, 6-26
Output Signal Constraints, 6-22
Output-EDIF, 8-4
Output-SDF, 8-5
Output-Verilog, 8-6
Output-VHDL, 8-7
Path Constraints, 6-28
Report Constraints, 6-30
SDF, 8-5
Verilog, 8-6
VHDL, 8-7
Pre-Optimization
what is it?, 5-7
Printing
HDLInventor window, 3-26
Information window content, 3-20
product terms, 10-3
Project
new, 3-9
open, 3-14
optimization, 3-8
portable, 3-8
save, 3-9, 3-14
save as, 3-15
starting a project, 3-9
synthesis runs, 3-8
project
save and restore, 1-2
Project Files
.lsp file, 3-8, 3-14
.src file, 3-8
.xdb file, 3-7
project Level 3
checkpoint, 3-8
Projects
recent, 3-15
Protecting Hierarchy, 7-8
Q
Quick Set Flow
opening design files, 1-6
Quick Setup Data Flow, 1-4, 10-3
Quick Setup Flow
activating integrated place and route, 1-7
setting the clock frequency, 1-6
setting the working directory, 1-6
R
RAM
Altera FLEX, 10-2
dual-port, 10-2
inferencing, RTL, 10-25
instantiation, Altera FLEX, 10-22
RAM_DQ
component, 10-22
ram_example1, 10-27
ram_example2, 10-28
RAM_IO
component, 10-22
Reading VHDL Libraries and Packages, 1-6
Ready Message, A-8
Report Constraints
PowerTab, 6-30
Index-5
Index
INDEX [continued]
Resets
Restoring a Project, 3-7
Results
check for critical paths, 3-20
check the fit, 3-20
right mouse button (RMB),, 1-1
RMB(Right Mouse Button), 3-11, 3-23
ROM
Altera FLEX, 10-2
Root, 5-4
libraries, 5-3
RTL
templates, 3-21
RTL Coding
checking your style, 2-2
supported state machine styles, 2-2
RTL Coding Style
checking your style, 2-1
Run
warning prompt, A-8
Run Flow button, 1-4, 1-7, 10-3
S
Saving a Project, 3-7
Schematic
RTL, 7-14
Scripts, 5-5
SDF (Output) PowerTab, 8-5
Selecting a Technology, 1-6
Session Settings
options, 3-27
Setting
aliases, 3-9
attributes, 3-4
the path to place and route tools, 3-6
variables, 3-4
Setting Constraints, 6-3
clock skew, 6-5
global timing, 6-3
Index-6
input arrival time, 6-9
multicycle paths, 6-11
multiple asynchronous clocks, 6-8
multiple synchronous clocks per block, 6-6
on clocks, 6-4
on combinational designs, 6-12
on false paths, 6-12
on mixed synchronous and asynchronous
designs, 6-13
on resets, 6-4
output required times, 6-10
Setting the Working Directory, 1-6
Source Code Editor, 3-21
spectrum command, 3-9
standard features
HDLInventor, 1-2
save and restore project, 1-2
Startup
Main window, 3-10
Startup Files
exemplar.ini, 3-6
State Machine Encoding
setting with Encoding Variable, 2-3
setting with Verilog pragmas, 2-3
State Machines
supported styles, 2-2
Status Bar
working directory path, A-3
SynthesisWizard, 3-11, A-1
FPGA technology, A-2
global clock, A-6
input files, A-3
output file, A-7
step 1 of 4, A-2
step 2 of 4, A-3
step 3 of 4, A-6
step 4 of 4, A-7
T
Tcl, 5-5
Index
INDEX [continued]
Tcl language, 3-3
Tcl script
command line with path, 3-4
interactive command line shell, 3-4
level 2, 3-14
level 3, 3-14
run script, 3-4
Technology
FlowTab, 4-5
Technology FlowTab, 1-6
Technology Library
loading for a synthesis run, 4-2
Tip of the Day, 3-10
Toolbar
editing icons, 3-19
stop icon, A-8
Tools
variable editor, 3-31
Top Entity, 5-10
tristatable output, 10-3
architecture, 5-10
VHDL (Input) PowerTab, 5-10
VHDL (Output) PowerTab, 8-7
VHDL Libraries
reading, 1-6, 5-2
VHDL Packages
reading, 1-6, 5-2
Video demo, 3-17
View
instance, 5-3
port, 5-3
Virtex-II
control variables, 10-4
V
XDB format, 8-3
W
Wildcards, 5-4
Working Directory, A-3
creating a simple structure, 2-7
setting, 1-6
X
Variable Editor, 3-31
Variables
altera_use_cascades, 4-3
dont_lock_lcells, 4-6
flex_use_cascades, 4-6
relationship to commands/attributes, 3-3
setting from the command line, 3-4
setting with the Variable Editor, 3-4
VCC, pin, 10-32
Verilog
full case, 5-11
input, 5-11
parallel case, 5-11
top module, 5-11
Verilog (Input) PowerTab, 5-11
Verilog (Output) PowerTab, 8-6
Version number, 3-18
VHDL
Index-7
Index
INDEX [continued]
Index-8

LeonardoSpectrum Users Manual

Transcription

Similar documents

cpr for the dead of night.

High-Speed Channel Design and Layout

Check out our latest cupola, clock, clock controller and weathervane

Introduction to VHDL , Quartus II Software and FPGA Board

flex fin 600 stirrups

High Performance Modular Multiband Internal Preamplifier for Bass

View Presentation

7300 Cessna Drive - Linville Team Partners