Você está na página 1de 35

Synplify & Quartus II

Design Methodology
February 2003, ver. 1.4

Introduction

Application Note 226

As FPGA designs become more complex and require increased


performance, using different optimization strategies has become an
important part of the design flow. Combining VHDL and Verilog
hardware description language (HDL) coding techniques, Synplicity
Synplify and Synplify Pro software constraints, and AlteraR QuartusR II
software options can provide the performance increase needed for todays
system-on-a-programmable-chip (SOPC) designs.
This application note documents some of the key design methodologies
and techniques for achieving better performance in Altera devices using
the Synplify and Quartus II design flow.

f
Software
Support &
Licensing
Requirements
f
Design Flow

Altera Corporation
AN-226-1.4

For more information on using the Synplify software with Altera designs,
go to the Synplicity web site at http://www.synplicity.com.
This application note assumes that you have set up, licensed, and are
familiar with the Synplify or Synplify Pro software.
After obtaining and correctly setting up the license file, set the
LM_LICENSE_FILE environment variable to the location of the license
file to enable the software.
To obtain and license the Synplify software, see the Synplicity web site at
http://www.synplicity.com.
The basic steps in a Quartus II design flow using the Synplify software is:
1.

Create HDL design files within the Synplify software or a text editor.

2.

Import the Verilog HDL or VHDL design files to the Synplify


software for synthesis.

3.

Select a target device and add timing constraints and compiler


directives to optimize the design during synthesis.

4.

After completing synthesis, import the technology-specific netlist


generated by the Synplify software to the Quartus II software for
placement and routing, performance evaluation, and
implementation in an Altera device.

AN 226: Synplify & Quartus II Design Methodology

Figure 1 shows the recommended design flow when using the Synplify
and Quartus II software.
Figure 1. Recommended Design Flow

VHDL

Verilog HDL

Functional
simulation

Timing
contraints

RTL
simulation

Synplify
software
Post synthesis
simulation files
(.vhm / .vm )

Technology
specific netlist
(.vqm / .edf )

Forward annotated
timing constraints
( .tcl / .acf )

Gate-level
timing
simulation

Quartus II
software
Post place-and-route
simulation files
(.vho / .vo )

No

Timing
requirements
satisfied?

Yes

Configuration files
( .sof / .pof )

Configure device

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

The Synplify and Synplify Pro software tools support both VHDL and
Verilog HDL source files. Synplify Pro also supports mixed synthesis,
allowing a combination of VHDL and Verilog HDL source files. After
synthesis, the Synplify and Synplify Pro software produces several
intermediate and output files. Table 1 lists these files with a short
description of each file.
Table 1. Synplify Intermediate & Output Files
File Extension(s)

File Description

.srs

Technology independent register transfer level (RTL) netlist


that can be read only by Synplify

.srm

Technology view netlist

.vm/.vhm

Post-synthesis output design file in Verilog HDL/VHDL


format that you can use for post-synthesis simulation

.srr (1)

Synthesis report file

.edf/.vqm (2)

Technology-specific netlist in electronic design interchange


format (EDIF) (.edf) or Verilog Quartus mapping (.vqm) file
format

.acf/.tcl (3)

Forward-annotated constraints file containing constraints


and assignments

Notes to Table 1:
(1)

(2)

(3)

Altera Corporation

This report file includes performance estimates which are often based on pre-placeand-route information. Please use the fMAX reported by the Quartus II software
after place-and-route, as it is the only reliable source of timing information. This
report file includes post-synthesis device resource utilization statistics which may
inaccurately predict resource usage after place-and-route. The Synplify software
does not account for black-box functions nor for logic element (LE) usage reduction
achieved through register packing performed by the Quartus II software. Register
packing combines a single register and look-up table (LUT) into a single logic cell,
reducing the logic cell utilization below the Synplify software estimate. Use the
device utilization reported by the Quartus II software after place-and-route.
An EDIF output file (.edf) is only created for ACEXTM 1K, FLEXR 10K, FLEX 10KA,
FLEX 10KE, FLEX 6000, FLEX 8000, MAXR 7000, MAX 9000, and MAX 3000
devices. A Verilog Quartus Mapping (.vqm) file is created for all other Altera
device families.
An assignment and configuration file (.acf) file is only created for ACEX 1K,
FLEXR 10K, FLEX 10KA, FLEX 10KE, FLEX 6000, FLEX 8000, MAX 7000, MAX
9000, and MAX 3000 devices. The .acf is generated for backward compatibility with
the MAX+PLUSR II software. A tool command language (Tcl) file (.tcl) for the
Quartus II software is created for all devices, which also contains Tcl commands to
create a Quartus II project and, if applicable, the MAX+PLUS II assignments are
imported from the .acf file.

AN 226: Synplify & Quartus II Design Methodology

Specify timing constraints and attributes for the design in a Synplify


constraints file (.sdc) by using the SCOPER editor in the Synplify software
or the HDL source file. Complier directives can also be defined in the HDL
source file. Many of these constraints are forward-annotated for use by the
Quartus II software in the Tcl file. You can save all project options and
included files in a Synplify project file (.prj).
The HDL Analyst included in the Synplify software is a graphical tool for
schematic views of the technology-independent RTL view netlist (.srs)
and technology-view netlist (.srm) files. You can use the HDL Analyst to
visually analyze and debug the design. The HDL Analyst supports cross
probing between the RTL and Technology views, the HDL source code,
and the Finite State Machine (FSM) viewer. See the Finite State Machine
(FSM) Compiler section.
1

A separate license file is required to enable the HDL Analyst in


the Synplify software. The Synplify Pro software comes with the
HDL Analyst.

Once synthesis is complete, import the EDIF or VQM netlist to the


Quartus II software for place-and-route. You can use the Tcl file generated
by the Synplify software to forward-annotate your constraints.
If the area and timing requirements are satisfied, use the programming
files generated from the Quartus II software to program the Altera device.
As illustrated in Figure 1, if your area or timing requirements are not met,
you can change the constraints in the Synplify software and re-run the
synthesis. Repeat the process until the area and timing requirements are
met.
You can also use other options and techniques in the Quartus II software
to meet area and timing requirements. In some cases source code may also
need modification if area and timing requirements cannot be met using
options in the Synplify and Quartus II software.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Design
Planning

Before you begin a new VHDL or Verilog HDL design, you must first
determine your design methodology. For example, you should decide
whether you will use a top-down or hierarchical bottom-up methodology,
and whether you want to use a block-based design flow. For hierarchical
design flows, you should partition your design for the best performance
and easiest optimization. This section describes design planning
considerations, including:

Top-Down vs. Bottom-Up Design Methodology


Block-Based Design with the Quartus II LogicLock Methodology
Hierarchical Design Partitioning

Top-Down vs. Bottom-up Design Methodology


Most HDL-based designs use either a top-down or bottom-up (blockbased) design methodology. In top-down designs, you apply a single
optimization to the designs top level. Thus, a top-down synthesis flow
has one output netlist file for the entire design.
As designs become more complex and designers work in teams, a blockbased design flow is often more effective. In this approach, you perform
optimization on individual sub-blocks and each sub-block has its own
output netlist file. After you optimize all of the sub-blocks, you integrate
them into a final design and optimize it at the top level. Synthesizing and
optimizing each sub-block separately may provide better overall quality
of results.
Table 2 describes some of the advantages of each synthesis flow.
Table 2. Top-Down vs. Bottom-up Design Flow
Design Flow
Top-down

Description

Advantages

One output netlist for the You can perform optimization across design boundaries and
entire design.
hierarchies for the entire design.
Simple to manage.

Bottom-up
(block-based)

Separate netlist files for


each design module.

You compile each module separately.


You can apply different optimization techniques to each module.
Design modifications do not affect the optimization of other modules.
You can use optimized modules in other designs.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Block-Based Design with the Quartus II LogicLock Methodology


You can use the LogicLock design methodology in the Quartus II software
to perform block-based (bottom-up) compilation. Using the LogicLock
design flow, you can design and optimize each module independently,
integrate all optimized modules into a top-level design, and then verify
the overall system. Incorporating each module into the top-level design
does not affect the performance of each module. The Synplify Pro
software version 7.2 introduces the MultiPoint Synthesis feature to
provide an incremental synthesis flow with the LogicLock design
methodology.

For more information on using the LogicLock feature in the Quartus II


software and the LogicLock design flow, see AN 161: Using the LogicLock
Methodology in the Quartus II Design Software. For specific information on
using the Synplify software with Quartus II LogicLock methodology, see
AN 165: Synplify and Quartus II LogicLock Design Flow.

Hierarchical Design Partitioning


In a hierarchical design flow, you use the Synplify software to create
multiple design files and then link them together in a hierarchy. With this
structure, you can simulate and optimize the individual modules that
comprise the design separately. You can also use the LogicLock design
methodology to follow a block-based bottom-up design methodology.
When following a hierarchical design methodology, it is important to
consider how the design is partitioned.
Altera recommendations for partitioning designs are as follows:

Partition the design at functional boundaries.


Minimize the I/O connections between different partitions.
Do not use glue logic between hierarchical blocks. If you preserve
hierarchy boundaries, glue logic is not merged with hierarchical
blocks. The Synplify software may optimize glue logic separately,
which can degrade synthesis results and is not efficient when used
with the LogicLock design methodology.
Limit clocks to one per block. Partitioning the design in clock
domains makes synthesis and timing analysis easier.
Place state machines in separate blocks to speed optimization and
provide greater encoding control.
Separate timing-critical functions from non-timing-critical functions.
Limit the critical timing path to one hierarchical block. You can group
the logic from several design blocks to ensure the critical path resides
in one block.
Register all inputs and/or outputs of each block, which makes logic
synchronous and avoids glitches. Also, registering outputs may

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

eliminate the need to specify required output times for different


blocks.

General
Synthesis
Design
Guidelines

When designing with HDL code, it is important to understand how a


synthesis tool interprets different HDL coding styles and the results to
expect. This section discusses some basic coding guidelines to provide
optimal synthesis results for Altera designs.

Combinatorial Logic
Logic is combinatorial if outputs at a specified time are a function of the
inputs at that time only, regardless of the previous state of the circuit.
Examples of combinatorial logic functions include decoders, multiplexers,
and adders. When applied to combinatorial logic, the techniques
described in the following sections optimize the performance results
during Synplify synthesis.

Latches
Latches are used in digital logic to hold the value of a signal until a new
value is assigned. Altera devices are register-intensive; therefore
designing with latches uses more logic and leads to lower performance
than designing with registers. When designing combinatorial logic, avoid
creating a latch unintentionally due to the HDL design style. For example,
when CASE or IF statements do not cover all possible conditions of the
inputs, combinatorial feedback can generate latches to hold the output in
the case when a new output value is not assigned. When a latch is created,
Synplify issues warnings.
Omitting the final ELSE clause or WHEN OTHERS clause from an IF or
CASE statement can also generate a latch. Don't care assignments on the
default conditions tend to prevent latch generation. Figure 2 shows
sample VHDL code that prevents the unintentional creation of a latch. If
the final ELSE clause is omitted, an unintentional latch is generated as
shown in Figure 3. Figure 4 shows the schematic representation of the
VHDL code from Figure 2 that includes the final ELSE statement,
preventing the latch from being inferred.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Figure 2. Sample VHDL Code Preventing Unintentional Latch Creation


LIBRARY ieee;
USE IEEE.std_logic_1164.all;
ENTITY nolatch IS
PORT
(a,b,c: IN STD_LOGIC;
sel: IN STD_LOGIC_VECTOR (1 DOWNTO 0);
oput: OUT STD_LOGIC);
END nolatch;
ARCHITECTURE behave OF nolatch IS
BEGIN
PROCESS (a,b,c,sel) BEGIN
IF sel = "00" THEN
oput <= a;
ELSIF sel = "01" THEN
oput <= b;
ELSIF sel = "10" THEN
oput <= c;
ELSE
-- Prevents latch inference
oput <= x;
END IF;
END PROCESS;
END behave;

Figure 3. Schematic Representation of Code Unintentionally Generating a Latch


c
D

Latch
Q

oput

ENA

sel [1..0]

Figure 4. Schematic Representation of Code Preventing Unintentional Latch


Creation
c
oput

sel [1..0]

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Dont Care Conditions for Logic Optimization


The Synplify software generally treats unknowns as dont care
conditions to optimize logic. Within a design, assign the default CASE
value to don't care instead of to a logic value for the best logic
optimization.
For Verilog designs, the Synplify software supports the full_case and
parallel_case attributes. You can use the full_case attribute to
indicate that all possible values have been given and that no additional
hardware is needed to preserve signal values. You can use the
parallel_case attribute to force the implementation of a parallel
multiplexed structure rather than a priority encoded structure.

Sequential Logic
Logic is sequential if the outputs at a specified time are a function of the
inputs at the time and at all preceding times. All sequential circuits must
include one or more registers (flip-flops).
Figure 5 shows sample VHDL code that prevents the unintentional
creation of feedback multiplexer. The final ELSE clause is used to assign
all states and avoid feedback. If the final ELSE clause is omitted, a
feedback multiplexer is generated, and the function requires an extra LE
in the Altera device.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Figure 5. VHDL Code that Prevents Feedback Multiplexer Generation


LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY seq IS
PORT(a,b,c,d,clk,rst : IN STD_LOGIC;
sel : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
oput : OUT STD_LOGIC);
END seq;
ARCHITECTURE behave OF seq IS
BEGIN
PROCESS (clk, rst) BEGIN
IF rst = 1 THEN
oput <= 1;
ELSIF clk=1 AND clkevent THEN
IF sel(0) = 1 THEN
oput <= a AND b;
ELSIF sel(1) = 1 THEN
oput <= b;
ELSIF sel(2) = 1 THEN
oput <= c;
ELSIF sel(3) = 1 THEN
oput <= d;
ELSE
-- Prevents feedback multiplexer
oput <= X;
END IF;
END IF;
END PROCESS;
END behave;

Gated Clocks
Try to avoid using internally-generated gated clocks because they create
logic delays and clock skew, and may require using additional routing
resources on Altera devices. Internally generated clocks may also
introduce glitches that create functional problems.
If you must use an internally generated clock, use the dedicated global,
regional, or fast pins that feed high-fan-out global routing lines.
To implement an internally generated gated clock in a design, you can
promote the clock signal to the global line through the Quartus II
Assignment Organizer by instantiating a GLOBAL primitive.

10

For more information on using the Quartus II Assignment Organizer,


refer to the Quartus II on-line Help.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

State Machine Synthesis


The Synplify software can encode state machines during the synthesis
process. To improve performance when coding state machines, separate
state machine logic from all arithmetic functions and data paths. Figure 6
shows a block diagram of a sample state machine consisting of a 32-bit
counter, an 8-bit 4-1 multiplexer, and a state machine that provides the
control logic for the other two elements in the design.

For more information on the Finite State Machine (FSM) Compiler, refer
to the Synplify Optimization Strategies section.
Figure 6. Sample State Machine

32-Bit
Counter

(8-Bit)
4-to-1
Multiplexer

State Machine

Figure 7 shows an inefficient design style, because the counter and the
multiplexer are incorporated into the state machine description. As a
result, two counters may be inferred during synthesis instead of one
up/down counter. In addition, the multiplexer may have additional logic
associated with its control signals.

Altera Corporation

11

AN 226: Synplify & Quartus II Design Methodology

Figure 7. Inefficient VHDL Code for a Sample State Machine


LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
USE IEEE.std_logic_unsigned.all;
ENTITY bad_FSM IS
PORT (
-- port declarations
);
END bad_FSM;
ARCHITECTURE state_machine OF bad_FSM IS
TYPE State_Type IS (s0, s1, s2, s3, s4, s5);
SIGNAL cur_state: State_Type;
BEGIN
PROCESS(clk,rst) BEGIN
CASE cur_state IS
WHEN s0 =>
--Change the current state (cur_state)
--Implement count operation (count+1)
--Select mux output
WHEN s1 =>
--Set state, count, & mux...
--NOTE: Actual code is not shown due to complexity.
:
:
END CASE;
END PROCESS;
END state_machine;

12

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Figure 8 shows a more-efficient design style. In this example, the


functionality of the counter and the multiplexer are implemented in
separate processes from the state machine.
Figure 8. Efficient VHDL Code for a Sample State Machine
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
USE IEEE.std_logic_unsigned.all;
ENTITY good_FSM IS
PORT (
-- port declarations
);
END good_FSM;
ARCHITECTURE state_machine OF good_FSM IS
TYPE State_Type IS (s0, s1, s2, s3, s4, s5);
SIGNAL cur_state: State_Type;
SIGNAL mux_sel: STD_LOGIC;
SIGNAL count_cntrl: STD_LOGIC;
BEGIN
multiplexer: PROCESS (mux_sel, mux_inputs) BEGIN
--Implement multiplexer based on mux_sel signal
END PROCESS;
counter: PROCESS (clk) BEGIN
--Implement up/down counter based
-- on count_cntrl signal.
PROCESS(clk,rst) BEGIN
CASE cur_state IS
WHEN s0 =>
--Change the current state (cur_state).
--Set count_cntrl signal.
--Set mux_sel signal.
WHEN s1 =>
--Set state, count_cntrl, & mux_sel...
--NOTE: Actual code is not shown due to complexity.
:
:
END CASE;
END PROCESS;
END state_machine;

Altera Corporation

13

AN 226: Synplify & Quartus II Design Methodology

The following are recommendations when coding state machines:

Guidelines for
Altera
Megafunctions
& LPM
Functions

Represent the states in a state machine by defined labels/enumerated


types. This makes the state machine easier to read and reduces the
risk of errors during coding.
Assign default values to outputs derived from the state machine
before the CASE statement to avoid generation of unwanted latches
during synthesis.
Assign states to an X in the default clause of CASE statements to avoid
mismatches between simulation of pre- and post- synthesis versions
of the code.
Synplify provides other state machine optimization options
including FSM Compiler and FSM Explorer for alternate synthesis
capabilities and supports additional state machine attributes to guide
state machine encoding. See the Finite State Machine (FSM)
Compiler and FSM Explorer in Synplify Pro sections for more
information.

Altera provides parameterizable megafunctions ranging from simple


arithmetic units, such as adders and counters, to advanced phase-locked
loop (PLL) blocks, multipliers, and memory structures. These functions
are performance-optimized for Altera devices. Megafunctions include the
library of parameterized modules (LPMs), device-specific embedded
megafunctions such as PLLs, DSP blocks, and LVDS drivers, intellectual
property (IP) available as Altera MegaCore functions, and IP available
through the Altera Megafunction Partners Program (AMPP).

Instantiating Altera Megafunctions in HDL code


There are two potential methods of instantiating Altera megafunctions in
the Synplify software. You can directly instantiate the megafunction in the
Verilog HDL or VHDL code; you can also use the MegaWizard Plug-In
Manager in the Quartus II software to setup and parameterize a
megafunction. The MegaWizard creates a wrapper file that instantiates
the megafunction. The benefits of using the MegaWizard are that all
parameters are properly set and the user does not need any synthesizer
library support as needed in the direct instantiation method. This is
referred to as the black-box methodology.

14

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Figure 9 shows the potential ways to use megafunctions in the AlteraSynplify design methodology. Instantiation and inference of specific
functions will be discussed in later sections.
Figure 9. Potential Ways to Use Megafunctions
Megafunctions

Inference

Instantiation

Using
MegaWizard
Plug-In

Directly
embedding
in HDL

When possible, if the black box does not have registered inputs and
outputs, use GRAY box timing to aid in the synthesis results when the
syn_tpd, syn_tsu, and syn_tco attributes are defined. If you do not
use these attributes, it may lead to inaccurate timing estimates during
synthesis. See Figure 10 for a Verilog HDL example.
Figure 10. Verilog HDL Example
module ram32x4(z,d,addr,we,clk);
/* synthesis syn_black_box syn_tco1=clk->z[3:0]=4.0
syn_tpd1=addr[3:0]->z[3:0]=8.0
syn_tsu1=addr[3:0]->clk=2.0
syn_tsu2=we->clk=3.0 */
output[3:0]z;
input[3:0]d;
input[3:0]addr;
input we
input clk
endmodule

Altera Corporation

15

AN 226: Synplify & Quartus II Design Methodology

For the LPM_MULT, LPM_RAM_DP, LPM_RAM_DQ, LPM_ROM,


LPM_LATCH, and LPM_FF megafunctions, you dont need to
manually create black-box. You can add the <output file>.v or
<output file>.vhd from the MegaWizard to the Synplify project as
part of the Synplify LPM timing flow. By directly instantiating
these LPMs, the Synplify software can estimate timing for these
functions during synthesis using Altera-provided timing
models.

Using the MegaWizard Plug-In Manager


The MegaWizard Plug-In Manager provides a graphical interface for
customizing and parameterizing any available megafunction for the
design. Use the MegaWizard Plug-In Manager to generate a VHDL or
Verilog HDL wrapper file.
The black-box methodology does not allow the synthesis tool any
visibility into the function module thus not taking full advantage of the
synthesis tool's timing driven optimization. For better timing
optimization, add timing models to black boxes. This can be done with the
syn_tpd, syn_tsu, and syn_tco attributes.

For more information about how to use the MegaWizard Plug-In


Manager, refer to the Quartus II software Help.
Table 3 lists the files that are generated by the MegaWizard Plug-In
Manager and describes each file.
Table 3. MegaWizard Plug-In Manager Generated Files
File
<output file>.bsf

16

Description
Symbol for the megafunction used in the Quartus II
schematic editor

<output file>.cmp (2)

Component declaration file

<output file>.inc

Include file for the module in the megafunction wrapper


file

<output file>.tdf (1)

Megafunction wrapper file for instantiation in an AHDL


design

<output file>.vhd (2)

Megafunction wrapper file for instantiation in a VHDL


design

<output file>.v (3)

Megafunction wrapper file for instantiation in a Verilog


HDL design

<output file>_bb.v (3)

Hollow-body declaration of the module in the


megafunction wrapper file used in Verilog HDL designs to
specify port directions

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Table 3. MegaWizard Plug-In Manager Generated Files


File
<output file>_inst.tdf
(1)

Description
Sample AHDL instantiation of the sub design in the
megafunction wrapper file

<output file>_inst.vhd Sample VHDL instantiation of the entity in the


(2)
megafunction wrapper file
<output file>_inst.v (3) Sample Verilog HDL instantiation of the module in the
megafunction wrapper file
Notes to Table 3:
(1)
(2)
(3)

Only generated when AHDL output is selected, which is not supported in the
Synplify software.
Only generated when VHDL output is selected.
Only generated when Verilog HDL output is selected.

Using MegaWizard-generated VHDL Files for Megafunction Instantiation


The syn_black_box compiler directive is used to declare a component
as a black box. The top-level design file must contain the megafunction
component declaration and port mapping. Apply the syn_black_box
directive to the component declaration in the top-level file. Figure 11
shows a sample top level file that instantiates vhdlCount.vhd, which is a
customized variation of the LPM_COUNTER generated by the MegaWizard
Plug-In Manager.
Figure 11. Top-level VHDL Code with Black Box Instantiation of LPM_COUNTER
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY testCounter IS
PORT
(
clk: IN STD_LOGIC ;
count: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
);
END testCounter;
ARCHITECTURE top OF testCounter IS
component vhdlCount
PORT
(
clock: IN STD_LOGIC ;
q: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
);
end component;
attribute syn_black_box : boolean;
attribute syn_black_box of vhdlCount: component is true;
BEGIN
vhdlCount_inst : vhdlCount PORT MAP (
clock => clk,

Altera Corporation

17

AN 226: Synplify & Quartus II Design Methodology

q => count
);
END top;

Using MegaWizard-generated Verilog HDL Files for Megafunction


Instantiation
The syn_black_box compiler directive is used to declare a component
as a black box. The top-level design file must contain the Megafunction
port mapping and module declaration. You must apply the
syn_black_box directive to the module declaration in the top-level file
or a separate file included in the project. Figure 12 shows a sample toplevel file that instantiates verilogCount.v, which is a customized variation
of the LPM_COUNTER generated by the MegaWizard Plug-In Manager.
Figure 12. Top-level Verilog HDL Code with Black Box Instantiation of
LPM_COUNTER
module topCounter (clk, count);
input clk;
output[7:0] count;
verilogCounter verilogCounter_inst (
.clock ( clk ),
.q ( count )
);
endmodule
// Module declaration found in verilogCounter_bb.v
// The syn attribute below is added to
// black box this module.
module verilogCounter (
clock,
q) /* synthesis syn_black_box */;
input clock;
output[7:0] q;
endmodule

Using the Port & Parameter Definition


You can instantiate the megafunction directly in your Verilog HDL or
VHDL code by calling the function like any other module or component.
In VHDL, you also need to use a component declaration. Refer to Quartus
II Help (or your IP documentation) for a list of the megafunctionss ports
and parameters. Help also provides a sample VHDL component
declaration.

18

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Other Synplify Software Attributes for Black-boxing


The following other attributes are supported by Synplify to communicate
details about the characteristics of the black-box module within the HDL
code:

Inferring
Megafunctions
from HDL Code

syn_resources: specifies the resources used in a particular blackbox


black_box_pad_pin: prevents mapping to I/O cells
black_box_tri_pin: indicates a tri-stated signal

The Synplify compiler automatically recognizes certain types of HDL


code and infers the appropriate megafunction, even though you did not
specifically instantiate the megafunction. Because the megafunctions are
optimized for Altera devices, performance may be better than with
generic HDL code. You must also use megafunctions to access certain
architecture- features Altera devices.
The following sections describe the types of logic that the Quartus II Logic
Synthesizer recognizes and maps to megafunctions. The software only
infers functions describeded by HDL code. The software cannot infer
other megafunctions, such as PLLs and LVDS drivers, from HDL code
because these functions cannot be fully or efficiently described in HDL. In
some cases, the Quartus II software has an option that you can use to
disable inference.

Inferring DSP Blocks


Altera StratixTM and Stratix GX devices have dedicated digital signal
processing (DSP) blocks optimized for DSP applications. DSP blocks are
ideal for implementing DSP applications requiring high data throughput,
such as finite impulse response (FIR) filters, complex FIR filters, infinite
impulse response (IIR) filters, fast Fourier transform (FFT) functions,
direct cosine transform (DCT) functions, and correlators.
The Synplify software can translate your HDL code into the appropriate
megafunction for DSP blocks. For more information on inferring DSP
blocks in the Synplify software, refer to AN193: Design Guidelines for
Using DSP Blocks in the Synplify Software.

Altera Corporation

19

AN 226: Synplify & Quartus II Design Methodology

Inferring Memory Elements


The Synplify software uses Behavior Extraction Synthesis Technology
(B.E.S.T.) algorithms to infer high-level structures such as RAMs, ROMs,
operators, FSMs, etc. It then keeps the structures abstract for as long as
possible in the synthesis process. This allows for the use of technologyspecific resources to implement these structures. The Synplify software
can infer basic memory from an HDL design and map it to the appropriate
Altera megafunction.
The two methods for handling memory in the Synplify software: inference
and instantiation. Table 4 shows the advantages and limitations of each
method.
Table 4. Inference vs. Instantiation: Advantages and Limitations
Instantiation
Advantages

Limitations

Inference

Most efficient use of the memory resource for a Coding style allows for portability
specific technology
Support for all RAM types

Timing/area estimation

All parameters supported

No tool dependencies

May not be portable

Synchronous RAM only

Limited or no access to timing and area data


because the RAM is black boxed

Glue logic to implement the RAM might result


in sub-optimal implementation

Additional tool requirements (i.e. Altera


Megafunctions and LPMs)

Reset pin inaccessible (always inactive)


No support for RAM initialization
Read Enable pin inaccessible (always active)

Altera megafunctions are used to instantiate memory in designs. For


information on instantiating Altera megafunctions, please refer to the
Instantiating Altera Megafunctions in HDL code on page 14 section.

Inferring RAM
Follow the guidelines below for the Synplify software to successfully infer
RAM in a design:

The write process must be synchronous.


The read process can be asynchronous or synchronous depending on
the target Altera device family's memory structure.
The address line must be at least 2 bits wide.
1

20

Resets on the memory are not supported.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

These guidelines allow the compiler to extract the RAM and keep it at a
high level until it gets mapped to the technology specific resources. Each
Altera device family has different guidelines for ensuring that memory is
correctly mapped to device resources.
The Stratix, Stratix GX, and Cyclone device families have support for
advanced memory features. Because of the wide variety of functionality,
the process for inferring these memory features requires a more detailed
approach than for the other device families.
For the Stratix, Stratix GX, and Cyclone device families, the minimum
RAM size is 2-bits and the minimum address width is 1-bit.
1

Altera recommends using the megafunction instead of inference


to implement RAM in Stratix and Stratix GX devices because
several of the complex features in the Stratix architecture are
difficult to infer from HDL code.

For more information on using the memory features of the Synplify


software with the memory features of Stratix , Stratix GX , and Cyclone
devices, contact Altera Applications.
The FLEX 10KE, ACEX 1K, APEX 20K, APEX 20KE, APEX 20KC, APEX II,
ExcaliburTM, and MercuryTM families support both single-port and various
levels of dual-port RAM (simple and true). The read address does not
need to be registered, however, if it is not registered, then dual-port RAM
is inferred. For the FLEX 10KE and ACEX 1K devices, the minimum size
is 128-bits and minimum address width is 5-bits. For the APEX 20K, APEX
20KE, APEX 20KC, APEX II, Excalibur, and Mercury families, the
minimum size is 64-bits and the minimum address width is 4-bits.
Table 5 shows a summary of the information for inferring RAM for the
Stratix, Stratix GX, Cyclone, FLEX 10KE, ACEX 1K, APEX 20K, APEX
20KE, APEX 20KC, APEX II, Excalibur, and Mercury device families.

Table 5. Inferring RAM Summary

RAM primitive

Stratix / Stratix GX /
Cyclone

APEX 20K / APEX 20KE / APEX 20K /


APEX II / Excalibur / Mercury

FLEX 10KE /
ACEX 1K

ALTSYNCRAM

ALTDPRAM

ALTDPRAM

Minimum RAM size

2-bits

64-bits

128-bits

Minimum address width

1-bit

4-bits

5-bits

Altera Corporation

21

AN 226: Synplify & Quartus II Design Methodology

Figure 13 shows sample VHDL code for inferring dual-port RAM.


Figure 13. VHDL Code for Inferred Dual-Port RAM
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_signed.all;
ENTITY dualport_ram IS
PORT ( data_out: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_in: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
wr_addr, rd_addr: IN STD_LOGIC_VECTOR (6 DOWNTO 0);
we: IN STD_LOGIC;
clk: IN STD_LOGIC);
END dualport_ram;
ARCHITECTURE ram_infer OF dualport_ram IS
TYPE Mem_Type IS ARRAY (127 DOWNTO 0) OF STD_LOGIC_VECTOR (7
DOWNTO 0);
SIGNAL mem: Mem_Type;
SIGNAL addr_reg: STD_LOGIC_VECTOR (6 DOWNTO 0);
BEGIN
data_out <= mem (CONV_INTEGER(rd_addr));
PROCESS (clk, we, data_in) BEGIN
IF (clk=1 AND clkEVENT) THEN
IF (we=1) THEN
mem(CONV_INTEGER(wr_addr)) <= data_in;
END IF;
END IF;
END PROCESS;
END ram_infer;

When inferring RAM for any of the Altera device families listed above, the
Synplify software generates additional bypass logic. This logic is
generated to resolve a half-cycle read/write behavior difference between
the RTL and post-synthesis simulations. The RTL simulation shows the
memory updating on the positive edge of the clock, and the post-synthesis
simulation shows the memory updating on the negative edge. To
eliminate the bypass logic, the output of the RAM must be registered. By
adding this register, the output of the RAM is seen after a full clock cycle,
by which time the update has occurred thus eliminating the need for the
bypass logic.
Figure 14 shows sample VHDL code preventing bypass logic for inferring
dual-port RAM. The extra latency behavior stems from the inferencing
methodology and is not required when using the instantiation
methodology.

22

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Figure 14. VHDL Code for Inferred Dual-Port RAM Preventing Bypass Logic
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_signed.all;
ENTITY dualport_ram IS
PORT ( data_out: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_in : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
wr_addr, rd_addr : IN STD_LOGIC_VECTOR (6 DOWNTO 0);
we : IN STD_LOGIC;
clk : IN STD_LOGIC);
END dualport_ram;
ARCHITECTURE ram_infer OF dualport_ram IS
TYPE Mem_Type IS ARRAY (127 DOWNTO 0) OF STD_LOGIC_VECTOR (7
DOWNTO 0);
SIGNAL mem : Mem_Type;
SIGNAL addr_reg : STD_LOGIC_VECTOR (6 DOWNTO 0);
SIGNAL tmp_out : STD_LOGIC_VECTOR(7 DOWNTO 0); --output
register
BEGIN
tmp_out <= mem (CONV_INTEGER(rd_addr));
PROCESS (clk, we, data_in) BEGIN
IF (clk=1 AND clkEVENT) THEN
IF (we=1) THEN
mem(CONV_INTEGER(wr_addr)) <= data_in;
END IF;
data_out <= tmp_out; --registers output
preventing
-- bypass logic generation.
END IF;
END PROCESS;
END ram_infer;

Inferring ROM
Follow the guidelines below for the Synplify software to successfully infer
ROM in a design:

The address line must be at least 2 bits wide.


ROM must be half full.
The CASE or IF statement must make 16 or more assignments using
constant values.

The Synplify software infers ROMs from HDL source code that uses CASE
statements, or equivalent IF statements, to make 16 or more signal
assignments using constant values. These constants must all be the same
width. Figure 15 shows sample VHDL code that infers ROM.

Altera Corporation

23

AN 226: Synplify & Quartus II Design Methodology

Figure 15. VHDL Code for Inferring ROM with a CASE Statement
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY rom IS
PORT (addr_in : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
data_out : OUT STD_LOGIC_VECTOR(3 DOWNTO 0)
);
attribute syn_romstyle : string;
attribute syn_romstyle of data_out : signal is "block_rom";
END rom;
ARCHITECTURE rom_infer OF rom IS
CONSTANT value_a : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1000";
CONSTANT value_b : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0100";
CONSTANT value_c : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0010";
CONSTANT value_d : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0001";
CONSTANT value_e : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1100";
CONSTANT value_f : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0110";
CONSTANT value_g : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0011";
CONSTANT value_h : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1110";
CONSTANT value_i : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0111";
CONSTANT value_j : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1011";
CONSTANT value_k : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0001";
CONSTANT value_l : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1100";
CONSTANT value_m : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0110";
CONSTANT value_n : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0011";
CONSTANT value_o : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0011";
CONSTANT value_p : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0011";
BEGIN
PROCESS (addr_in)
BEGIN
CASE addr_in IS
WHEN "0000" => data_out <= value_a;
WHEN "0001" => data_out <= value_b;
WHEN "0010" => data_out <= value_c;
WHEN "0011" => data_out <= value_d;
WHEN "0100" => data_out <= value_e;
WHEN "0101" => data_out <= value_f;
WHEN "0110" => data_out <= value_g;
WHEN "0111" => data_out <= value_h;
WHEN "1000" => data_out <= value_i;
WHEN "1001" => data_out <= value_j;
WHEN "1010" => data_out <= value_k;
WHEN "1011" => data_out <= value_l;
WHEN "1100" => data_out <= value_m;
WHEN "1101" => data_out <= value_n;
WHEN "1110" => data_out <= value_o;
WHEN "1111" => data_out <= value_p;
WHEN others => data_out <= "----";
END CASE;
END PROCESS;
END rom_infer;

24

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Synplify
Optimization
Strategies

For single-clock designs, Altera recommends to specify a global frequency


when using the push-button flow. While this flow is simple and provides
good results, often it does not meet the performance requirements for
more advanced designs. You can use timing constraints, compiler
directives, and other attributes to help optimize the performance of a
design. Enter these attributes and directives directly in the HDL code.
Alternatively, enter these attributes (not directives) into a constraint file
(.sdc) with the SCOPE editor in the Synplify software.
1

The Synplify synthesis report file (.srr) contain timing reports of


estimated place-and-route delays. Alteras Quartus II software
can perform further optimizations on a post-synthesis netlist
from a synthesis vendor such as Synplicity. In addition, designs
may contain black boxes or IP functions that have not been
optimized by the third-party synthesis software. For these
reasons, the Quartus II post place and route timing reports
provide a more accurate representation of the design. The
statistics in these reports should be used to evaluate design
performance.

For more information on applying these attributes, please refer to the


Adding Attributes and Directives section of Chapter 3: Tasks and
Tips in the Synplify User Guide.

Timing-driven Synthesis
The Synplify software supports timing-driven synthesis through userassigned timing constraints to optimize the performance of the design.
The Synplify software optimizes the design to attempt to meet these
constraints. Actual timing results are only obtained after the design has
gone through full place-and-route in the Quartus II software. Using the
NativeLinkR feature, timing constraints, such as clock frequencies, multicycle paths, and false paths, applied in the Synplify software are forwardannotated to the Quartus II software for timing-driven place-and-route.

Clock Frequencies
Use the SCOPE editor to set global frequency requirements for the entire
design and individual clock settings. Use the Clocks tab in the SCOPE
editor to specify frequency (or period), rise times, fall times, duty cycle,
and other settings. Assigning individual clock settings, rather than overconstraining the global frequency, helps the Quartus II and Synplify
software achieve the fastest clock frequency for the overall design. The
define_clock attribute assigns clock constraints.

Altera Corporation

25

AN 226: Synplify & Quartus II Design Methodology

Input/Output Delays
Specify the input and output delays for the ports of a design in the
Input/Output tab of the SCOPE editor or by using the
define_input_delay and define_output_delay attributes. The
Synplify software does not allow you to assign the TCO and TSU values
directly to inputs and outputs. However, a TCO value can be inferred by
setting an external output delay, and a TSU value can be inferred by
setting an external input delay. The following equations illustrate the
relationship between TCO/TSU and the input/output delays:
TCO = Clock period external output delay
TSU = Clock period external input delay
When the syn_forward_io_constraints attribute is set to 1, the
Synplify software passes the external input and output delays to the
Quartus II software through NativeLink integration. The Quartus II
software then uses the external delays to calculate the maximum system
frequency.

Multi-Cycle Paths
Specify any multi-cycle paths in the design in the Multi-Cycle Paths tab
of the SCOPE editor or with the define_multicycle_path attribute. A
multi-cycle path is one that requires more than one clock cycle to
propagate. It is important to specify which paths are multi-cycle to avoid
having the Quartus II and Synplify compilers work excessively on a noncritical path. Not specifying these paths can also result in an inaccurate
critical path being reported during timing analysis.

False Paths
False paths are paths that should not be considered during timing analysis
and/or which should be assigned low (or no) priority during
optimization. Some examples of false paths are slow asynchronous resets
and test logic added to the design. Set these paths in the False Paths tab of
the SCOPE editor or with the define_false_path attribute.

26

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Multiple Clock Domains


The Synplify software can perform timing analysis on unrelated clock
domains. Each clock group is a different clock domain and is treated as
unrelated to the clocks in all other clock groups. All the clocks in a single
clock group are assumed to be related and the Synplify software
automatically calculates the relationship between the clocks. By default,
all clocks are in the same group. Assign clocks to a new clock group by
using the Clocks tab in the SCOPE editor or with the define_clock
attribute.

Finite State Machine (FSM) Compiler


If the FSM Compiler is turned on, the compiler automatically detects state
machines in a design. The compiler can then extract and optimize the state
machine. The FSM Compiler analyzes the state machine and decides to
implement sequential, gray, or one-hot encoding based on the number of
states. It also performs unused-state analysis, optimization of unreachable
states, and minimization of transition logic.
If the FSM Compiler is turned off, the compiler does not infer state
machines. The state machines are implemented as coded in the HDL code.
Thus, if the coding style for the state machine was sequential, then the
implementation is also sequential. If the FSM Compiler is turned on, the
compiler infers the state machines. The implementation is based on the
number of states regardless of the coding style in the HDL code.
You can use the syn_state_machine complier directive to specify or
prevent a state machine for/from being extracted and optimized. To
override the default encoding of the FSM Compiler, use the
syn_encoding directive.

Altera Corporation

27

AN 226: Synplify & Quartus II Design Methodology

The values for this directive are shown in Table 6.


Table 6. syn_encoding Directive Values
Value

Description

Sequential

Generates state machines with the fewest possible flip-flops. Sequential, also called binary, state
machines are useful for area-critical designs when timing is not as much of a concern.

Gray

Generates state machines where only one flip-flop changes during each transition. Gray-encoded
state machines tend to be glitchless.

One-hot

Generates state machines containing one flip-flop for each state. One-hot state machines provide
the best performance and shortest clock-to-output delays. However, one-hot implementations are
usually larger than binary implementations.

Safe

Generate extra control logic to force the state machine to the reset state if an invalid state is
reached. The safe value can be used in conjunction with the other three values, which results in
the state machine being implemented with the requested encoding scheme and the generation of
the reset logic.

Figure 16 shows sample VHDL code for applying the syn_encoding


directive.
Figure 16. VHDL code for syn_encoding
SIGNAL current_state : STD_LOGIC_VECTOR(7 DOWNTO 0);
ATTRIBUTE syn_encoding : STRING;
ATTRIBUTE syn_encoding OF current_state : SIGNAL IS
"sequential";

The default is to optimize state machine logic for speed and area, but this
is potentially undesirable for critical systems. The safe value generates
extra control logic to force the state machine to the reset state if an invalid
state is reached.

FSM Explorer in Synplify Pro


The Synplify Pro software can use the FSM Explorer. The FSM Explorer
automatically explores different encoding styles for a state machine and
then chooses the best encoding based on the overall design constraints.
The FSM Explorer uses the FSM Compiler to identify and extract state
machines from a design. However, unlike the FSM Compiler which
chooses the encoding style based on the number of states, the FSM
Explorer tries several different encoding styles before choosing a specific
one. The trade-off is that the compilation requires more run-time to
perform the analysis of the state machine but finds an optimal encoding
scheme for the state machine.

28

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Retiming in Synplify Pro


The Synplify Pro software can retime a design. Retiming can improve the
timing performance of sequential circuits by automatically moving
registers (register balancing) across combinatorial elements. Be aware that
retimed flip-flops incur name changes. Turn on the retiming option in the
Device tab in the Implementation Options section or by using the
syn_allow_retiming attribute.

Implementations in Synplify Pro


Use the Creating an Implementation option in the Synplify Pro software
to create different synthesis results without overwriting one another. For
each implementation, specify the target device, synthesis options, and
constraint files. Each implementation generates its own subdirectory that
contains all the resulting files, including .vqm and .tcl files, from a
compilation of the particular implementation. You can then compare the
results of the different implementations to find the optimal set of
synthesis options and constraints for a design.

Perform Cliquing
You can only turn on cliquing when the Map Logic to LCELLs option is
turned on. This setting allows the Synplify software to group nodes
together for critical paths. These groups are called cliques. The Synplify
software creates a LogicLock region for the critical paths. Through
NativeLink integration, all LogicLock assignments are passed to the
Quartus II software.

Max Fan-out
When dealing with critical path nets with high fan-outs, you can use the
syn_maxfan attribute to control the fan-out of the net. Setting this
attribute for a specific net results in the replication of the driver of the net
to reduce the overall fan-out. The syn_maxfan attribute takes an integer
value and applies to inputs or registers. (The syn_maxfan attribute
cannot be used to duplicate control signals, and the minimum-allowed
value of the attribute is 4.) Using this attribute may result in increased
logic resource utilization, thus putting a strain on routing resources and
leading to long compile times and difficult fitting.
If you need to duplicate an output register or output enable register, you
can create a register for each output pin by using the syn_useioff
attribute (see Register Packing on page 30).

Altera Corporation

29

AN 226: Synplify & Quartus II Design Methodology

Preserving Nets
During synthesis, the compiler maintains ports, registers, and instantiated
components. However, some nets may not be maintained in order to
create an optimized circuit. Applying the syn_keep directive overrides
the optimization of the compiler and preserves the net during synthesis.
The syn_keep directive takes a Boolean value and can be applied to
wires (Verilog HDL) and signals (VHDL). Setting the value to true
preserves the net through synthesis.

Register Packing
Altera devices allow for the packing of registers into I/O cells. Altera
recommends allowing the Quartus II software to make the I/O register
assignments. However, it is possible to control register packing with the
syn_useioff attribute. The syn_useioff attribute takes a Boolean
value and can be applied to ports or entire modules. Setting the value to
1 instructs the compiler to pack the register into an I/O cell. Setting the
value to 0 prevents register packing in both the Synplify and Quartus II
software.

Preserving Hierarchy
The Synplify software performs cross-boundary optimization by default.
This results in the flattening of the design to allow optimization. Use the
syn_hier attribute to over-ride the default compiler settings. The
syn_hier attribute takes a string value and can be applied to
modules/architectures. Setting the value to hard maintains the
boundaries of a module/architecture and prevent cross-boundary
optimization.
By default, the Synplify software generates a hierarchical .vqm. To flatten
the file, set the syn_netlist_hierarchy attribute equal to 0.

30

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Altera Specific Attributes


The following attributes are for use with specific Altera device features.
These attributes are forward-annotated to the Quartus II project and are
used during the place-and-route process.

altera_chip_pin_lc Used to make pin assignments. This


attribute takes a string value and can be applied to inputs and
outputs. Figure 17 shows how to set the attribute in the SCOPE
editor.

Figure 17. altera_chip_pin_lc with SCOPE Editor

Figure 18 shows VHDL code for making location assignments for Stratix,
Cyclone, APEX 20K, APEX 20KE, APEX 20KC, APEX II, Mercury, and
Excalibur devices. The pin location assignments for these devices are
written to the output Tcl script.
Figure 18. altera_chip_pin_lc with VHDL for APEX 20K, APEX 20KE,
APEX 20KC, APEX II, Mercury, Excalibur, Stratix, and Cyclone Devices
(1)

Note

ENTITY sample (data_in : IN STD_LOGIC_VECTOR (3 DOWNTO 0);


data_out: OUT STD_LOGIC_VECTOR (3 DOWNTO 0));
ATTRIBUTE altera_chip_pin_lc : STRING;
ATTRIBUTE altera_chip_pin_lc OF data_out : SIGNAL IS "14, 5,
16, 15";
Note to Figure 18
(1)

The data_out signal is a 4-bit signal; data_out[3] is assigned to pin 14 and


data_out[0] is assigned to pin 15.

Figure 19 shows VHDL code for making location assignments to


ACEX 1K and FLEX 10KE devices.
1

The @ is used to specify pin locations. For these devices the pin
location assignments are written to the output EDIF.

Figure 19. altera_chip_pin_lc with VHDL for ACEX 1K and FLEX 10KE Devices
ENTITY sample (data_in : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
data_out: OUT STD_LOGIC_VECTOR (3 DOWNTO 0));
ATTRIBUTE altera_chip_pin_lc : STRING;

Altera Corporation

31

AN 226: Synplify & Quartus II Design Methodology

ATTRIBUTE altera_chip_pin_lc OF data_out : SIGNAL IS "@14, @5,


@16, @15";

altera_implement_in_esb and altera_implement_in_eab

Exporting
Designs to the
Quartus II
Software Using
NativeLink
Integration

Implement logic in ESB/EABs rather than logic resources to


improve area utilization. The modules cannot have feedback paths,
and either all or none of the inputs/outputs must be registered. This
attribute takes a Boolean value and can be applied to instances. (This
option is applicable for devices with ESB/EABs only (i.e., the Stratix
architecture is not supported by this option.). For designs targeting
devices with no ESB/EABs, this will have no effect.)
altera_io_powerup Defines the power-up value of an I/O
register which has no set or reset. This attribute takes a string value
(high|low) and can be applied to ports that have I/O registers.
altera_io_opendrain Specifies open-drain mode I/O ports.
This attribute takes a Boolean value and can be applied to outputs or
bidirectional ports for devices that support open-drain mode.

After a design is synthesized in the Synplify software, a .vqm (or .edf) file
and Tcl files are used to import the design into the Quartus II software for
place-and-route. You can run the Quartus II software from within the
Synplify software or as a standalone application. Once you have imported
the design into the Quartus II software, you can specify different options
to further optimize the design.
1

When using NativeLink, the path to your project must not


contain white spaces. The Synplify software uses Tcl scripts to
communicate with the Quartus II software, and the Tcl language
does not accept arguments with white spaces in the path.

Running the Quartus II Software from within the Synplify


Software
You can use NativeLink integration to integrate the Synplify software and
Quartus II software with a single graphical user interface (GUI) interface
for both the synthesis and place-and-route operations. NativeLink
integration allows you to run the Quartus II software from within the
Synplify software GUI or to run the Synplify software from within the
Quartus II software GUI. To use the Quartus II software from within the
Synplify software the follow the steps below:

32

1.

Verify that the QUARTUS_ROOTDIR environment variable points to


the Quartus II software installation directory. This environment
variable is required to use the Synplify and Quartus II software
together.

2.

Turn on one of the following options from the Options menu in the
Synplify software:

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

a.

Set Options: Opens the Quartus II software GUI and places the
synthesized output file, forward-annotated timing constraints,
and pin assignments in a named Quartus II project. You can
then configure options for the project.

b.

Run Foreground Compile: Allows for interactive place-androute. The Quartus II software GUI is opened and automatically
runs the place-and-route with the project settings from the
synthesis run. You can monitor the progress, observe all
messages generated, and execute other Quartus II software
commands.

c.

Run Background Compile: Runs the Quartus II software in


command-line mode with the project settings from the synthesis
run. The results of the place-and-route are written to a log file. It
also generates any additional files specified with the Set
Options.

The <project_name>_cons.tcl file is used to set up the Quartus II project


and calls the <project_name>.tcl file to forward constraints from the
Synplify software to the Quartus II software. The <project_name>.tcl file
contains device, timing, and location assignments.

Using the Quartus II Software to Launch the Synplify Software


You can set up the Quartus II software to run the Synplify software for
synthesis using Nativelink integration.

For detailed information on using NativeLink integration with the


Synplify software, go to Specifying EDA Tool Settings in the Quartus II
Help index.
You can also import the results of the Synplify synthesis and use them
from within the Quartus II software. Among other methods, a Quartus II
project can be created and compiled by running the
<project_name>_cons.tcl script file. This is done by executing the following
Tcl command in the Tcl Console:
source <project_name>_cons.tcl
1

Altera Corporation

To open the Tcl Console, select Utility Windows > Tcl Console
(View menu) in the Quartus II software.

33

AN 226: Synplify & Quartus II Design Methodology

Cross-Probing with Quartus II


The Quartus II and Synplify software support bidirectional cross-probing.
With cross-probing, selecting an object in one application highlights the
same object in the other. For example, selecting an AND in the HDL
Analyst RTL view highlights the corresponding logic elements in the
Quartus II Floorplanner and vice versa. You must enable cross-probing in
both applications. This feature thus provides the ability to connect
post-place-and-route timing results to the source code.

For more information on cross-probing, refer to TB 77: Cross-Probing


Between Synplicity & Quartus II Development Tools.
To enable cross-probing in the Synplify software:
1.

Open a schematic view.

2.

Select External Cross Probing Engaged (HDL Analyst menu).

To enable cross-probing in the Quartus II software:


1.

Open the project in the Quartus II software.

2.

Turn on Enable cross-probing between Quartus II and other EDA


tools option on the EDA Tool Options page of the Options dialog
box (Tools menu).

Conclusion

Design efficiency and performance are critical in SOPC designs. Various


techniques help optimize a design to achieve performance goals and save
design time. By using the VHDL and Verilog HDL coding techniques,
Synplify synthesis constraints, and Quartus II software options, designers
can improve performance and optimize a design for use with Altera
devices.

Revision
History

The information contained in the AN 226: Synplify & Quartus II Design


Methodology version 1.3 supersedes information published in previous
versions.

Version 1.4
The following changes were made to the AN 226: Synplify & Quartus II
Design Methodology version 1.4:

34

Added update and reference information to Synplicity software and


URL.
Added Alter Megafunctions usage information.

Altera Corporation

AN 226: Synplify & Quartus II Design Methodology

Version 1.3
The following changes were made to the AN 226: Synplify & Quartus II
Design Methodology version 1.3:

Updated text on page 1.


Updated text on page 5 and page 6.
Updated text on page 21 to include Stratix GX devices.
Added Cyclone devices to Table 5.
Updated text on page 33.

Version 1.2
The following changes were made to the AN 226: Synplify & Quartus II
Design Methodology version 1.2:

Updated text on page 21.


Added Cyclone devices to Table 5.
Updated text on page 31.

Version 1.1
The following changes were made to the AN 226: Synplify & Quartus II
Design Methodology version 1.1:

101 Innovation Drive


San Jose, CA 95134
(408) 544-7000
http://www.altera.com
Applications Hotline:
(800) 800-EPLD
Literature Services:
lit_req@altera.com
35

Updated text on page 1.


Added Note (2) to Table 1.
Added Figure 10.
Updated text on pages 16, 16, and 21.
Added Note (1) to Figure 18.

Copyright 2003 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the
stylized Altera logo, specific device designations, and all other words and logos that are identified as
trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera
Corporation in the U.S. and other countries. All other product or service names are the property of their
respective holders. Synplify, Synplify Pro, and HDL Analyst are registered trademarks of Synplicity. Altera
products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights,
and copyrights. Altera warrants performance of its semiconductor products to current specifications in
accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or
liability arising out of the application or use of any information, product, or service
described herein except as expressly agreed to in writing by Altera Corporation. Altera
customers are advised to obtain the latest version of device specifications before relying on
any published information and before placing orders for products or services.

Altera Corporation

Você também pode gostar