an226: synplify and quartus ii design methodology

February 2003, ver. 1.4 Application Note 226

Introduction As FPGA designs become more complex and require increased performance, using different optimization strategies has become an

Synplify & Quartus IIDesign Methodology

Altera Corporation 1

AN-226-1.4

important part of the design flow. Combining VHDL and Verilog hardware description language (HDL) coding techniques, SynplicitySynplify and Synplify Pro software constraints, and AlteraR QuartusR II software options can provide the performance increase needed for today’s 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 For more information on using the Synplify software with Altera designs, go to the Synplicity web site at http://www.synplicity.com.

Software Support & Licensing Requirements

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.

f To obtain and license the Synplify software, see the Synplicity web site at http://www.synplicity.com.

Design Flow 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.

2 Altera Corporation

Figure 1. Recommended Design Flow

Functionalsimulation

RTLsimulation

Gate-leveltiming

simulation

Configure device

Yes

No

Timingrequirements

satisfied?

Timingcontraints

VHDL Verilog HDL

Forward annotatedtiming constraints

( .tcl / .acf )

Technologyspecific netlist(.vqm / .edf )

Post place-and-routesimulation files

(.vho / .vo )

Post synthesissimulation files

(.vhm / .vm )

Configuration files( .sof / .pof )

Quartus IIsoftware

Synplifysoftware


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.

Notes to Table 1:(1) This report file includes performance estimates which are often based on pre-place-

and-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.

(2) 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.

(3) 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.

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


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.


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 (block-based) design methodology. In top-down designs, you apply a single optimization to the design’s 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 block-based 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 Description Advantages

Top-down One output netlist for the entire design.

You can perform optimization across design boundaries and 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.


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.

f 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


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.


Figure 2. Sample VHDL Code Preventing Unintentional Latch Creation LIBRARY ieee;USE IEEE.std_logic_1164.all;


ENTITY nolatch ISPORT (a,b,c: IN STD_LOGIC;

sel: IN STD_LOGIC_VECTOR (1 DOWNTO 0);oput: OUT STD_LOGIC);

END nolatch;

ARCHITECTURE behave OF nolatch ISBEGIN

PROCESS (a,b,c,sel) BEGINIF 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

Figure 4. Schematic Representation of Code Preventing Unintentional Latch Creation

oput

[1..0]sel

a

b

cD Q

ENA

Latch

1

0

oput

[1..0]sel

a

b

c

1

0


“Don’t Care” Conditions for Logic Optimization

The Synplify software generally treats unknowns as “don’t 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.


Figure 5. VHDL Code that Prevents Feedback Multiplexer Generation LIBRARY ieee;USE ieee.std_logic_1164.all;


ENTITY seq ISPORT(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 ISBEGIN

PROCESS (clk, rst) BEGINIF rst = ’1’ THEN

oput <= ’1’;ELSIF clk=’1’ AND clk’event THEN

IF sel(0) = ’1’ THENoput <= a AND b;

ELSIF sel(1) = ’1’ THENoput <= b;

ELSIF sel(2) = ’1’ THENoput <= c;

ELSIF sel(3) = ’1’ THENoput <= d;

ELSE -- Prevents feedback multiplexeroput <= ’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.

f For more information on using the Quartus II Assignment Organizer, refer to the Quartus II on-line Help.


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.

f For more information on the Finite State Machine (FSM) Compiler, refer to the “Synplify Optimization Strategies” section.

Figure 6. Sample 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.

Multiplexer4-to-1(8-Bit)

32-BitCounter

State Machine


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;BEGINPROCESS(clk,rst) BEGIN

CASE cur_state ISWHEN s0 => --Change the current state (cur_state)--Implement count operation (count+1)

--Select mux outputWHEN s1 =>--Set state, count, & mux...--NOTE: Actual code is not shown due to complexity. ::

END CASE;END PROCESS;

END state_machine;


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 ISPORT (-- port declarations);

END good_FSM;

ARCHITECTURE state_machine OF good_FSM ISTYPE State_Type IS (s0, s1, s2, s3, s4, s5);SIGNAL cur_state: State_Type;SIGNAL mux_sel: STD_LOGIC;SIGNAL count_cntrl: STD_LOGIC;

BEGINmultiplexer: PROCESS (mux_sel, mux_inputs) BEGIN

--Implement multiplexer based on mux_sel signalEND PROCESS;

counter: PROCESS (clk) BEGIN--Implement up/down counter based-- on count_cntrl signal.

PROCESS(clk,rst) BEGINCASE 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 state_machine;


The following are recommendations when coding state machines:


■ 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.

Guidelines for Altera Megafunctions & LPM Functions

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.


Figure 9 shows the potential ways to use megafunctions in the Altera-Synplify design methodology. Instantiation and inference of specific


functions will be discussed in later sections.

Figure 9. Potential Ways to Use Megafunctions

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 Examplemodule 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 weinput clkendmodule

Megafunctions

Directly embedding

in HDL

Using MegaWizard

Plug-In

InferenceInstantiation


1 For the LPM_MULT, LPM_RAM_DP, LPM_RAM_DQ, LPM_ROM, LPM_LATCH, and LPM_FF megafunctions, you don’t 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.

f 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 Description

<output file>.bsf 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


Table 3. MegaWizard Plug-In Manager Generated Files


Notes to Table 3:(1) Only generated when AHDL output is selected, which is not supported in the

Synplify software.(2) Only generated when VHDL output is selected.(3) 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_COUNTERLIBRARY 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 IScomponent 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,

<output file>_inst.tdf (1)

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

<output file>_inst.vhd (2)

Sample VHDL instantiation of the entity in the megafunction wrapper file

<output file>_inst.v (3) Sample Verilog HDL instantiation of the module in the megafunction wrapper file

File Description


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 top-level 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_COUNTERmodule 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 megafunctions’s ports and parameters. Help also provides a sample VHDL component declaration.


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:

■ syn_resources: specifies the resources used in a particular black-box

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

Inferring Megafunctions from HDL Code

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.


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.

f 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 Resets on the memory are not supported.

Table 4. Inference vs. Instantiation: Advantages and Limitations

Instantiation Inference

Advantages Most efficient use of the memory resource for a specific technology

Coding style allows for portability

Support for all RAM types Timing/area estimation

All parameters supported No tool dependencies

Limitations 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)


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.

f 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

Stratix / Stratix GX / Cyclone

APEX 20K / APEX 20KE / APEX 20K / APEX II / Excalibur / Mercury

FLEX 10KE / ACEX 1K

RAM primitive ALTSYNCRAM ALTDPRAM ALTDPRAM

Minimum RAM size 2-bits 64-bits 128-bits

Minimum address width 1-bit 4-bits 5-bits


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


Figure 13. VHDL Code for Inferred Dual-Port RAMLIBRARY ieee;USE ieee.std_logic_1164.all;USE ieee.std_logic_signed.all;

ENTITY dualport_ram ISPORT ( 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 ISTYPE 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);

BEGINdata_out <= mem (CONV_INTEGER(rd_addr));PROCESS (clk, we, data_in) BEGIN

IF (clk=’1’ AND clk’EVENT) THENIF (we=’1’) THENmem(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.


Figure 14. VHDL Code for Inferred Dual-Port RAM Preventing Bypass LogicLIBRARY ieee;USE ieee.std_logic_1164.all;


USE ieee.std_logic_signed.all;

ENTITY dualport_ram ISPORT ( 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 ISTYPE 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

BEGINtmp_out <= mem (CONV_INTEGER(rd_addr));PROCESS (clk, we, data_in) BEGIN

IF (clk=’1’ AND clk’EVENT) THENIF (we=’1’) THENmem(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.


Figure 15. VHDL Code for Inferring ROM with a CASE StatementLIBRARY ieee;USE ieee.std_logic_1164.all;


ENTITY rom ISPORT (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 ISCONSTANT 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 ISWHEN "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 rom_infer;


Synplify Optimization

For single-clock designs, Altera recommends to specify a global frequency when using the push-button flow. While this flow is simple and provides


Strategiesgood 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. Altera’s 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.

f 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 user-assigned 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, multi-cycle paths, and false paths, applied in the Synplify software are forward-annotated 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 over-constraining 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.


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 non-critical 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.


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.


The values for this directive are shown in Table 6.


Figure 16 shows sample VHDL code for applying the syn_encoding directive.

Figure 16. VHDL code for syn_encodingSIGNAL 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.

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.


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).


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.


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 Note (1)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 DevicesENTITY 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";

■ altera_implement_in_esb and altera_implement_in_eab


— 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.

Exporting Designs to the Quartus II Software Using NativeLink Integration

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:

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:


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-and-route. 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.

f 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 To open the Tcl Console, select Utility Windows > Tcl Console (View menu) in the Quartus II software.


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.

f 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:

■ Added update and reference information to Synplicity software and URL.

■ Added Alter Megafunctions usage information.


Version 1.3

The following changes were made to the AN 226: Synplify & Quartus II

Copyright © 2003 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, thestylized Altera logo, specific device designations, and all other words and logos that are identified as

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


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

Version 1.1


■ 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.


101 Innovation DriveSan Jose, CA 95134(408) 544-7000http://www.altera.comApplications Hotline:(800) 800-EPLDLiterature Services:[email protected]

trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of AlteraCorporation in the U.S. and other countries. All other product or service names are the property of theirrespective holders. Synplify, Synplify Pro, and HDL Analyst are registered trademarks of Synplicity. Alteraproducts 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 inaccordance with Altera's standard warranty, but reserves the right to make changes to anyproducts and services at any time without notice. Altera assumes no responsibility orliability arising out of the application or use of any information, product, or servicedescribed herein except as expressly agreed to in writing by Altera Corporation. Alteracustomers are advised to obtain the latest version of device specifications before relying onany published information and before placing orders for products or services.

an226: synplify and quartus ii design methodology

Documents