iCEcube2 User Guide
iCEcube2 User Guide
August 2017
Copyright
Copyright © 2017 Lattice Semiconductor Corporation. All rights reserved. This document may
not, in whole or part, be reproduced, modified, distributed, or publicly displayed without prior
written consent from Lattice Semiconductor Corporation (“Lattice”).
Trademarks
All Lattice trademarks are as listed at www.latticesemi.com/legal. Synopsys and Synplify Pro are
trademarks of Synopsys, Inc. Aldec and Active-HDL are trademarks of Aldec, Inc. All other
trademarks are the property of their respective owners.
Disclaimers
NO WARRANTIES: THE INFORMATION PROVIDED IN THIS DOCUMENT IS “AS IS”
WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND INCLUDING
WARRANTIES OF ACCURACY, COMPLETENESS, MERCHANTABILITY,
NONINFRINGEMENT OF INTELLECTUAL PROPERTY, OR FITNESS FOR ANY PARTICULAR
PURPOSE. IN NO EVENT WILL LATTICE OR ITS SUPPLIERS BE LIABLE FOR ANY
DAMAGES WHATSOEVER (WHETHER DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS,
BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OF
OR INABILITY TO USE THE INFORMATION PROVIDED IN THIS DOCUMENT, EVEN IF
LATTICE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME
JURISDICTIONS PROHIBIT THE EXCLUSION OR LIMITATION OF CERTAIN LIABILITY,
SOME OF THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU.
Lattice may make changes to these materials, specifications, or information, or to the products
described herein, at any time without notice. Lattice makes no commitment to update this
documentation. Lattice reserves the right to discontinue any product or service without notice and
assumes no obligation to correct any errors contained herein or to advise any user of this
document of any correction if such be made. Lattice recommends its customers obtain the latest
version of the relevant information to establish that the information being relied upon is current
and before ordering any products.
Contact Information
Lattice Semiconductor Corporation
5555 N.E. Moore Court
Hillsboro, Oregon 97124-6421
United States of America
Tel: +1 503 268 8000
Fax: +1 503 268 8347
http://www.latticesemi.com.
Software Version
This User Guide documents the features of iCEcube2 Software Version 2017.08.
For more information about acquiring the iCEcube2 software, please visit the Lattice
Semiconductor website: http://www.latticesemi.com.
Platform Requirements
The iCEcube2 software can be installed on a platform satisfying the following minimum
requirements.
A Pentium 4 computer (500 MHz) with 256 MB of RAM, 256MB of Virtual Memory, and running
one of the following Operating Systems :
Windows 10 OS, 32-bit / 64-bit
Windows 8/8.1 OS, 32-bit / 64-bit
Windows 7 OS, 32-bit / 64-bit
Windows XP Professional
Red Hat Enterprise Linux WS v4, 5, and 6
Programming Hardware
Here are the following ways to program iCE FPGA devices:
A third party programmer or a processor, using the programming files generated by the
iCEcube2 Physical Implementation Tools. Consult the third party programmer user
manual for instructions.
The iCEblink and iCEman evaluation Board, which not only serves as a vehicle to
evaluate iCE FPGAs, but also includes an integrated device programmer. This
programmer can be used to program devices on the evaluation board, or it can be used
to program devices in a target system. Please visit Lattice Semiconductor website:
http://www.latticesemi.com for additional information on the Evaluation Boards.
Digilent USB cables to program the external SPI Flash.
Programming Software
Standalone Lattice Diamond Programmer software is required to program iCE40 FPGA devices
or SPI flash. Download and install the latest standalone programmer from
http://www.latticesemi.com/ispvm.
For more information about Diamond Programmer, refer “Diamond Programmer” on page 116.
Creating a Project
Starting the iCEcube2 software for the first time, you will see the following interface shown in
Figure 2-1.
The first step is to create a new design project and add the appropriate design files to your
project. You can create a new project by either selecting File > New Project from the iCEcube2
menu, or by clicking the Create a New Project icon as seen in Figure 2-1. The New Project
Wizard GUI is displayed in Figure 2-2.
This example is targeted for iCE40 family device. Follow the following steps to setup the project
properties.
1. Project Name Field: Specify a project name (quick_start) in the Project Name field.
2. Project Directory Field: Specify any directory where you want to place the project directory
in the Project Directory field.
3. Device Family Fields: This section allows you to specify the Lattice iCE device family you
are targeting. For this example, change the Device Family to iCE40.
4. Device Fields: This section allows you to specify the Lattice device and package you are
targeting. For this example, change the Device to HX1K and change the device package to
the VQ100.
5. Operating Condition Fields: This section allows you to specify the operating conditions of
the device which will be used for timing and power analysis.
After the above selections the New Project GUI Wizard has the following settings as shown in
Figure 2-3.
`
Figure 2-3: Tutorial Project Settings
8. Click Next to go to the Add Files dialog box shown in Figure 2-4. You will be prompted to
create a new project directory. Click Yes.
9. In the Add Files dialog box, navigate to: <iCEcube2 installation directory>/examples/blinky
Highlight the following files:
blinky.vhd
blinky_syn.sdc*
After successfully setting up your project, you will return to the iCEcube2 Project Navigator
screen shown in Figure 2-5.
Once synthesis is complete, you will see a green checkmark next to the Run Lattice LSE
Synthesis command. The Output tab shows the actions taken along with any warning or error
messages. Scroll down toward the bottom to see the area, clock, and timing reports. See Figure
2-7.
Navigate to the <iCEcube2 Installation Directory>/examples/blinky and Add blinky.pcf file. See
Figure 2-12.
You can see from the timing analysis that our 32-kHz design is running at over 395 MHz and our
32-MHz clock is running at over 222 MHz (worst case timing). If we were not meeting timing, the
timing analyzer would allow you to see your failing paths and do a more in-depth analysis. For
this tutorial, we won’t go into details on timing slack analysis.
The Diamond Programmer Getting Started dialog box appears, as shown in Figure 2-20.
Diamond Programmer will indicate in the bottom output tab that the Lattice HW-USBN-2A USB
programming cable was detected, as shown in
Figure
2-21.
In the Device Family field, click the Generic JTAG Device box and choose iCE40 from the drop-
down menu, as shown in Figure 2-22 .
In the Device column, choose iCE40HX1K from the drop-down menu, as shown in Figure 2-23.
There are three basic programming flows for configuring the iCE40 device. This section explains
programming iCE40 device using an external SPI Flash device available in iCEblink40-HX1K
evaluation board.
In the Programming File box, browse to the .hex file you generated with iCEcube2.
The Device Properties dialog box should be configured as shown in Figure 2-24. In the Device
Properties dialog box, click OK.
In the Diamond Programmer main window, choose Design > Program, or click the Program icon
in the toolbar, as shown in Figure 2-25. Once the SPI Flash is programmed, the output tab in the
lower left portion of Diamond Programmer indicates Operation successful.
The external SPI Flash on the Lattice iCEblink40-HX1K evaluation board has been programmed,
and the iCE40 is configured from the SPI flash.
Addendum:
Navigate to the <iCEcube2 Installation Directory>/examples/blinky and Add blinky.mtcl file. See
Figure 2-27.
Introduction
This chapter describes the features of the iCEcube2 Project Manager and how to set up a design
Project. The primary functions of the Project Manager include project setup, launching the Lattice
Synthesis Engine (LSE) or Synplify pro for synthesis, placing and routing the design, launching
the Aldec Active-HDL for simulation and launching the software required to Program the target
device.
This chapter assumes that the reader is familiar with the New Project creation process as
described in Chapter 2 Quick Start.
Deleting a specific file can be accomplished by selecting the file name and clicking the right-
button on the mouse. Figure 3-3 below displays the state of the GUI upon clicking the mouse
button.
To set the LSE synthesis tool options, click “right- mouse” button on the “Run LSE Synthesis” as
shown in Figure 3-6.
Set the LSE tool options and click on “OK” button to save the changes. Rerun the LSE synthesis.
To set the Synplify-Pro synthesis tool options, click “right-mouse” button on the “Run Synplify-
Pro Synthesis” item. This will pop up the “Tool Options” wizard. In the “Synplify Pro” tab select
the word “here” to open the Synplify-Pro GUI.
In the Synplify-Pro window, Select “Implementation Options”, set the tool options and save. Rerun
the Synplify synthesis.
Output Window
The iCEcube2 Project Flow Manager software provides an Output Window to display messages,
warnings and errors.
Simulation Wizard
The iCEcube2 windows software installs Aldec Active-HDL, a windows based simulator tool to
perform functional and timing verification of the implemented designs. The “Simulation Wizard” in
the project navigator allows the user to create a simulation project for Aldec Active-HDL, select
the simulation netlist, simulation language and invokes the Aldec Active-HDL interface.
Select Active-HDL icon to invoke the “Simulation Wizard” as shown in Figure 3-12. Refer to
chapter “Simulating Design with ALDEC Active-HDL” for more details about simulation wizard and
simulation steps with Aldec Active-HDL.
The PLL Module Generator allows the user to create a new PLL configuration, or edit an existing
one as shown in Figure 3-14.
The output of the PLL Module Generator is a PLL module file (Verilog), that instantiates a PLL, as
configured by the user. A secondary file (wrapper), that includes an instance of the PLL module,
is generated in order to help instantiate the PLL module in the user’s design. Note that the PLL
module file should be included in the list of design files.
Once a PLL module file has been generated, it can be edited, by selecting the “Modify an existing
PLL configuration” option (Figure 3-14).
Fine Delay Adjustment: The delay contributed by the FDA block can be Fixed or controlled
dynamically during FPGA operation. If Fixed, it is necessary to provide a number (n) in the range
0-15 to specify the delay contributed to the feedback path. The delay for a setting “n” is calculated
as follows
FDA delay = (n+1)*0.15 ps, where “n” is the value specified by the user, and 0 ≤ n ≤ 15
Frequency Specification: The input and output frequency of the PLL should be specified in MHz
as shown in Figure 3-16. Depending on the values provided by the user, the PLL is internally
configured to generate the specified output frequency.
In case the frequency specified is not in the range permitted by the Operation Mode, the software
provides appropriate feedback, as displayed in Figure 3-17.
Other options:
LOCK: A Lock signal is provided to indicate that the PLL has locked on to the incoming signal.
Lock asserts High to indicate that the PLL has achieved frequency lock with a good phase lock.
BYPASS: A BYPASS signal is provided which both powers-down the PLL core and bypasses it
such that the PLL output tracks the input reference frequency.
Low Power Mode: A control is provided to dynamically put the PLL into a Lower Power Mode
through the iCEGate feature. The iCEGate feature latches the PLL Output signal, and prevents
unnecessary toggling.
The RESET (Active Low) port is always generated, and an explicit PLL reset operation is required
to initialize the PLL functionality.
Figure 3-18: iCE40 PLL - Selecting PLL Type and Operation Modes
Figure 3-19: iCE40 PLL - Additional Delay and Phase Shift Options
PLL Summary: The PLL Configuration summary is shown in Figure 3-21. Click on “Save” to
save the PLL configuration file.
REFERENCECLK
PLLCFGREG[3:0] DIVR 0,1,2,…15 divider value
000 DELAY
010/001 PHASE_AND_DELAY
011 EXTERNAL
01 Divide by 7
10 Invalid setting
11 Divide by 5
10 SHIFTREG_90deg
11 SHIFTREG_0deg
1 PAD PLL
The sample configuration register setting for a PAD PLL with 20 MHz reference clock and 200
MHz output frequency is
PLLCFGREG [26:0] =27'b0_1_00_00_00_00_001_010_1001111_0001;
The output of the Module Generator is a module file (Verilog), that instantiates a SPI/I2C, as
configured by the user. Note that the I2C/SPI module file should be included in the list of design
files.
Once an I2C/SPI module file has been generated, it can be edited, by selecting the “Modify an
existing PLL configuration” option (Figure 3-24).
Configure I2C
I2C Tab allows the user to configure the left and right I2C blocks independently as shown in
Figure 3-26. I2C Tab is enabled only when I2C hard IP is selected in the Hard IP Enables Tab.
SDA input: By default 50ns is added to the SDA input. Turn off this option if delay is not required.
SDA output: Turn on this setting to add 50ns delay to the SDA output.
Configure SPI
SPI Tab allows the user to configure the left and right SPI blocks independently as shown in
Figure 3-27. SPI Tab is enabled only when SPI hard IP is selected in the Hard IP Enables Tab.
Generate Module
Once the settings are done generate the soft IP module by selecting “Generate” button. The
wizard displays the status and the generated file details in the “Generate Log” tab as shown in
Figure 3-28.
BRAM Utilization
Specifies BRAM utilization target setting in percent of total vacant sites. LSE will honor the setting
and do the resource computation accordingly. Default is 100 (in percentage).
Optimization Goal
Enables LSE to optimize the design for area, speed, or both. Valid options are:
Area (default) – Optimizes the design for area by reducing the total amount of logic used
for design implementation.
When Optimization Goal is set to Area, LSE ignores the Target Frequency setting and
uses 1 MHz instead.
Timing – Optimizes the design for speed by reducing the levels of logic.
When Optimization Goal is set to Timing and a create_clock constraint is available in an
.ldc file, LSE ignores the Target Frequency setting and uses the value from the
create_clock constraint instead.
Balanced – Optimizes the design for both area and timing.
Propagate Constants
When set to True (default), enables constant propagation to reduce area, where possible. LSE
will then eliminate the logic used when constant inputs to logic cause their outputs to be constant.
You can turn off the operation by setting this option to False.
RAM Style
Sets the type of random access memory globally to BRAM or registers.
The default is Auto which attempts to determine the best implementation. That is, LSE will map to
RAM resources based on the resource availability.
This option will apply a syn_ramstyle attribute globally in the source to a module or to a RAM
instance. To turn off RAM inference, set its value to Registers.
Resource Sharing
When this is set to True (default), the synthesis tool uses resource sharing techniques to optimize
for area. With resource sharing, synthesis uses the same arithmetic operators for mutually
exclusive statements; for example, with the branches of a case statement. Conversely, you can
improve timing by disabling resource sharing, but at the expense of increased area.
ROM Style
Allows you to globally implement ROM architectures using dedicated, distributed ROM, or a
combination of the two (Auto).
This applies the syn_romstyle attribute globally to the design by adding the attribute to the
module or entity. You can also specify this attribute on a single module or ROM instance.
This option specifies a syn_romstyle attribute globally or on a module or ROM instance with a
value of:
Auto (default) – Allows the synthesis tool to choose the best implementation to meet the
design requirements for speed, size, and so on.
BRAM – Causes the ROM to be mapped to dedicated BRAM resources. ROM address or
data should be registered to map it to an BRAM block. If your ROM resources are limited,
for whatever reason, you can map additional ROM to registers instead of the dedicated or
distributed RAM resources using this attribute.
Logic – Causes the ROM to be implemented using the normal logic.
Infer ROM architectures using a CASE statement in your code. For the synthesis tool to
implement a ROM, at least half of the available addresses in the CASE statement must be
assigned a value. For example, consider a ROM with six address bits (64 unique addresses). The
CASE statement for this ROM must specify values for at least 32 of the available addresses.
RW Check on RAM
Adds (True) or does not add (False) the glue logic to resolve read/write conflicts wherever
needed. Default is False.
Top-Level Unit
It is a good practice to specify the top-level unit (or module) of the design. If you don’t, LSE will try
to determine the top-level unit. While usually accurate, there is no guarantee that LSE will get the
correct unit.
You may also want to change the top-level unit when experimenting with different designs or
switching between simulation and synthesis.
If the design is mix of EDIF and Verilog or VHDL, you cannot set an EDIF module as the top-level
unit.
Use IO Insertion
Turns on (True) or off (False) the use of I/O insertion. Default is True.
Use IO Registers
Enables (True) or disables (False) register packing. True forces the synthesis tool to pack all
input, output, and I/O registers into I/O pad cells based on timing requirements. Default is Auto,
which selects True or False based on how Optimization Goal is set.
You can place the syn_useioff attribute on an individual register or port. When applied to a
register, the synthesis tool packs the register into the pad cell, and when applied to a port, packs
all registers attached to the port into the pad cell. The syn_useioff attribute can be set on a:
Top-level port
Register driving the top-level port
Lower-level port if the register is specified as part of the port declaration
Optimization Goal
If set to Area, LSE will choose smaller design forms over faster whenever possible. LSE will also
ignore the Target Frequency option, using a low 1 MHz target instead. If set to Timing, LSE will
choose faster design forms over smaller whenever possible. LSE will also use the timing
constraints in the design’s .sdc file to guide the optimization. If you are having trouble meeting
one requirement (area or speed) while optimizing for the other, try setting this option to
Balanced.
Target Frequency
A lower frequency target means LSE can focus more on area. A higher frequency target may
force LSE to increase area. Try setting this value to about 10% higher than your minimum
requirement. However, if Optimization Goal is set to Area, LSE will ignore the Target Frequency
value, using a low 1 MHz target instead. If Optimization Goal is set to Timing and a create_clock
constraint is available in an .sdc file, LSE will use the value from the create_clock constraint
instead.
LSE has additional options that provide more granular control than Synplify Pro. These options
include:
Carry Chain Length
BRAM Utilization
RAM Style
ROM Style
Other LSE options without Synplify Pro equivalents:
Intermediate File Dump
Memory Initial Value Search Path
Use Carry Chain
Use IO Registers
Propagate Constants
Remove Duplicate Registers
Inferring RAM
The basic inferred RAM is synchronous. It can have synchronous or asynchronous reads and can
be either single- or dual-port. You can also set initial values. Other features, such as resets and
clock enables, can be added as desired. The following text lists the rules for coding inferred RAM.
Following that, Figure 4-1 (Verilog) and Figure 4-2 (VHDL) show the code for a simple, single-port
RAM with asynchronous read.
To code RAM to be inferred, do the following:
Define the RAM as an indexed array of registers.
To control how the RAM is implemented (with block RAM), consider adding the
syn_ramstyle attribute. See “syn_ramstyle” on page 86.
Control the RAM with a clock edge and a write enable signal.
For synchronous reads, see “Inferring RAM with Synchronous Read” on page 69.
For single-port RAM, use the same address bus for reading and writing.
For pseudo dual-port RAM, see “Inferring Pseudo Dual-Port RAM on page 71.
If desired, assign initial values to the RAM as described in “Initializing Inferred RAM” on
page 73.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity ram is
generic (
addr_width : natural := 8;
data_width : natural := 8);
VHDL Examples
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity ram is
generic (
addr_width : natural := 8;
data_width : natural := 8);
port (
addr : in std_logic_vector (addr_width - 1 downto 0);
write_en : in std_logic;
clk : in std_logic;
din : in std_logic_vector (data_width - 1 downto 0);
dout : out std_logic_vector (data_width - 1 downto 0));
end ram;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity ram is
generic (
addr_width : natural := 8;
data_width : natural := 8);
port (
addr : in std_logic_vector (addr_width - 1 downto 0);
write_en : in std_logic;
clk : in std_logic;
din : in std_logic_vector (data_width - 1 downto 0);
dout : out std_logic_vector (data_width - 1 downto 0));
end ram;
VHDL Examples
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity ram is
generic (
addr_width : natural := 8;
data_width : natural := 8);
port (
write_en : in std_logic;
waddr : in std_logic_vector (addr_width - 1 downto 0);
wclk : in std_logic;
raddr : in std_logic_vector (addr_width - 1 downto 0);
rclk : in std_logic;
din : in std_logic_vector (data_width - 1 downto 0);
dout : out std_logic_vector (data_width - 1 downto 0));
end ram;
VHDL
In VHDL, initialize RAM with either signal declarations or variable declarations. Define an entity
with the same ports and architecture as the memory. Use this entity in either a signal or variable
statement with the initial values as shown below.
Inferring ROM
To code ROM to be inferred, do the following:
Define the ROM with a case statement or equivalent if statements.
Assign constant values, all of the same width.
Assign values for at least 16 addresses or half of the address space, whichever is
greater. For example, if the address has 6 bits, the address space is 64 words, and at
least 32 of them must be assigned values.
To control how the ROM is implemented (with distributed or block ROM), consider adding
the syn_romstyle attribute. See “syn_romstyle” on page 92.
entity rom is
port (addr : in std_logic_vector(4 downto 0);
data : out std_logic_vector(3 downto 0) );
end rom;
Verilog Examples
module mult_unsign_7_6(a,b,c);
parameter A_WIDTH = 7;
parameter B_WIDTH = 6;
input unsigned [(A_WIDTH - 1):0] a;
input unsigned [(B_WIDTH - 1):0] b;
output unsigned [(A_WIDTH + B_WIDTH - 1):0] c;
assign c = a * b;
endmodule
Figure 4-13 : Basic Multiplier without Registers
module multaddsub_add_unsign_7_6(a,b,c,din);
parameter A_WIDTH = 7;
parameter B_WIDTH = 6;
input unsigned [(A_WIDTH - 1):0] a;
input unsigned [(B_WIDTH - 1):0] b;
assign c = a * b + din;
endmodule
Figure 4-14: Multiply/Add without Registers
module multaddsub_sub_sign_ir_7_6(clk,a,b,din,c,rst,set);
parameter A_WIDTH = 7;
parameter B_WIDTH = 6;
input rst;
input set;
input clk;
input signed [(A_WIDTH - 1):0] a;
input signed [(B_WIDTH - 1):0] b;
input signed [(A_WIDTH + B_WIDTH - 1):0] din;
output signed [(A_WIDTH + B_WIDTH - 1):0] c;
module multacc_unsign_7_6(clk,a,b,c,set);
parameter A_WIDTH = 7;
assign c = reg_tmp_c;
VHDL Examples
entity m_07x06 is
generic (widtha : natural := 7;
widthb : natural := 6);
port (
ina : in std_logic_vector (0 to widtha - 1);
inb : in std_logic_vector (0 to widthb - 1);
mout : out std_logic_vector (0 to widtha+widthb - 1));
end m_07x06;
entity mult_add_07x06 is
generic (widtha : natural := 7;
widthb : natural := 6);
port (
ina : in std_logic_vector (widtha - 1 downto 0);
inb : in std_logic_vector (widthb - 1 downto 0);
mout : out std_logic_vector (widtha+widthb - 1 downto 0);
inc : in std_logic_vector (widtha+widthb - 1 downto 0)
);
entity mult_sub_07x06_ir_r is
generic (widtha : natural := 7;
widthb : natural := 6);
port (
ina : in std_logic_vector (widtha - 1 downto 0);
inb : in std_logic_vector (widthb - 1 downto 0);
clk : in std_logic;
reset: in std_logic;
mout : out std_logic_vector (widtha+widthb - 1 downto 0);
inc : in std_logic_vector (widtha+widthb - 1 downto 0)
);
end mult_sub_07x06_ir_r;
begin
mout <= reg1_ina * reg1_inb-inc;
entity multacc_07x06_up is
generic (widtha : natural := 7;
widthb : natural := 6);
port (
ina : in std_logic_vector (widtha - 1 downto 0);
inb : in std_logic_vector (widthb - 1 downto 0);
clk : in std_logic;
reset : in std_logic;
mout : out std_logic_vector (widtha+widthb - 1 downto 0)
);
begin
mout <= mout_s ;
mout_s <= reg_mout;
Inferring I/O
To specify types of I/O ports, follow these models.
Verilog
Open Drain:
output <port>;
wire <output_enable>;
assign <port> = <output_enable> ? 1'b0 : 1'bz;
Bidirectional:
inout <port>;
wire <output_enable>;
wire <output_driver>;
wire <input_signal>;
assign <port> = <output_enable> ? <output_driver> : 1'bz;
assign <input_signal> = <port>;
VHDL
Tristate:
library ieee;
use ieee.std_logic_1164.all;
entity <tbuf> is
port (
<enable> : std_logic;
<input_sig> : in std_logic_vector (1 downto 0);
<output_sig> : out std_logic_vector (1 downto 0));
end tbuf2;
architecture <port> of <tbuf> is
begin
<output_sig> <= <input_sig> when <enable> = '1' else "ZZ";
black_box_pad_pin
Directive. Specifies pins on a user-defined black-box component as I/O pads that are visible to
the environment outside of the black box. If there is more than one port that is an I/O pad, list the
ports inside double-quotes ("), separated by commas (,), and without enclosed spaces.
Verilog Syntaxobject /* synthesis syn_black_box black_box_pad_pin = "portList" */ ;
where portList is a spaceless, comma-separated list of the names of the ports on black boxes that
are I/O pads.
module BBDLHS(D,E,GIN,GOUT,PAD,Q)
/* synthesis syn_black_box black_box_pad_pin="GIN[2:0],Q"
*/;
Figure 4-22: Verilog Example
VHDL Syntax
attribute black_box_pad_pin of object : objectType is "portList" ;
where object is an architecture or component declaration of a black box. Data type is string;
portList is a spaceless, comma-separated list of the black-box port names that are I/O pads.
library ieee;
use ieee.std_logic_1164.all;
package my_components is
component BBDLHS
port (D: in std_logic;
E: in std_logic;
GIN : in std_logic_vector(2 downto 0);
Q : out std_logic );
end component;
syn_black_box
Directive. Specifies that a module or component is a black box with only its interface defined for
synthesis. The contents of a black box cannot be optimized during synthesis. A module can be a
black box whether it is empty or not. This directive has an implicit Boolean value of 1 or true.
Verilog Syntax
object /* synthesis syn_black_box */ ;
where object is a module declaration.
VHDL Syntax
attribute syn_black_box of object : objectType is true ;
where object is a component declaration, label of an instantiated component to define as a black
box, architecture, or component. Data type is Boolean.
syn_encoding
Directive for VHDL designs. Defines how enumerated data types are implemented. The type of
implementation affects the performance and device utilization.
VHDL Syntax
attribute syn_encoding of object : objectType is "value" ;
Where object is an enumerated type and value is one of the following: default, sequential, onehot,
or gray.
package testpkg is
type mytype is (red, yellow, blue, green, white,
violet, indigo, orange);
syn_hier
Attribute. Allows you to control the amount of hierarchical transformation that occurs across
boundaries on module or component instances during optimization.
syn_hier Values
The following value can be used for syn_hier:
hard – Preserves the interface of the design unit with no exceptions. This attribute affects only the
specified design units.
object /* synthesis syn_hier = "value" */ ;
where object can be a module declaration and value can be any of the values described in
syn_hier Values. Check the attribute values to determine where to attach the attribute.
VHDL Syntax
attribute syn_hier of object : architecture is "value" ;
syn_keep
Directive. Keeps the specified net intact during optimization and synthesis.
Verilog Syntax
object /* synthesis syn_keep = 1 */ ;
where object is a wire or reg declaration. Make sure that there is a space between the object
name and the beginning of the comment slash (/).
VHDL Syntax
attribute syn_keep of object : objectType is true ;
where object is a single or multiple-bit signal.
entity example2 is
port (in1, in2 : in bit;
clk : in bit;
out1, out2 : out bit );
end example2;
architecture rt1 of example2 is
attribute syn_keep : boolean;
syn_maxfan
Attribute. Overrides the default (global) fan-out guide for an individual input port, net, or register
output.
Verilog Syntax
object /* synthesis syn_maxfan = "value" */ ;
VHDL Syntax
attribute syn_maxfan of object : objectType is "value" ;
entity test is
port (clock : in bit;
data_in : in bit_vector(31 downto 0);
registered_data_out: out bit_vector(31 downto 0)
);
attribute syn_maxfan : integer;
attribute syn_maxfan of data_in : signal is 1000;
Figure 4-32: VHDL Example
Verilog Syntax
object /* synthesis syn_multstyle = "string" */ ;
Where object is a multiply, multiply/add, and multiply/accumulate definition. The data type is
string.
module mult(a,b,c,r,en);
input [7:0] a,b;
output [15:0] r;
input [15:0] c;
input en;
wire [15:0] temp /* synthesis syn_multstyle="logic" */;
endmodule
Figure 4-33: Verilog Example
VHDL Syntax
attribute syn_multstyle of object : objectType is "string" ;
Where object is a signal that defines a multiply, multiply/add, and multiply/accumulate block. The
data type is string.
library ieee ;
use ieee.std_logic_1164.all ;
USE ieee.numeric_std.all;
entity mult is
port (clk : in std_logic ;
a : in std_logic_vector(7 downto 0) ;
b : in std_logic_vector(7 downto 0) ;
c : out std_logic_vector(15 downto 0))
end mult ;
architecture rtl of mult is
signal mult_i : std_logic_vector(15 downto 0) ;
attribute syn_multstyle : string ;
attribute syn_multstyle of mult_i : signal is "logic" ;
begin
mult_i <= std_logic_vector(unsigned(a)*unsigned(b)) ;
syn_noprune
Directive. Prevents instance optimization for black-box modules (including technology-specific
primitives) with unused output ports.
Verilog Syntax
object /* synthesis syn_noprune = 1 */ ;
where object is a module declaration or an instance. The data type is Boolean.
module top(a1,b1,c1,d1,y1,clk);
output y1;
input a1,b1,c1,d1;
input clk;
wire x2,y2;
reg y1;
syn_noprune u1(a1,b1,c1,d1,x2,y2) /* synthesis
syn_noprune=1 */;
endmodule
Figure 4-35: Verilog Example
VHDL Syntax
attribute syn_noprune of object : objectType is true ;
where the data type is boolean, and object is an architecture, a component, or a label of an
instantiated component.
library ieee;
use ieee.std_logic_1164.all;
entity top is
port (a1, b1 : in std_logic;
c1,d1,clk : in std_logic;
y1 :out std_logic );
end ;
architecture behave of top is
component noprune
port (a, b, c, d : in std_logic;
x,y : out std_logic );
syn_pipeline
This attribute permits registers to be moved to improve timing. Depending on the criticality of the
path, the tool move the suitable output registers to the input side to improve timing. If there is no
candidate register identified for pipelining, this attribute will not be honored.
syn_pipeline attribute is applicable only for Timing and Balance mode optimization. The tool
ignores the attribute in Area mode optimization.
Verilog Syntax
object /* synthesis syn_pipeline = {1|0} */ ;
where object is a register declaration.
syn_preserve
Directive. Prevents sequential optimization such as constant propagation, inverter push-through,
and FSM extraction.
Verilog Syntax
object /* synthesis syn_preserve = 1 */ ;
where object is a register definition signal or a module.
VHDL Syntax
attribute syn_preserve of object : objectType is true ;
where object is an output port or an internal signal that holds the value of a state register or
architecture.
library ieee;
use ieee.std_logic_1164.all;
entity simpledff is
port (q : out std_logic_vector(7 downto 0);
d : in std_logic_vector(7 downto 0);
clk : in std_logic );
syn_ramstyle
Attribute. The syn_ramstyle attribute specifies the implementation to use for an inferred RAM.
You apply syn_ramstyle globally to a module or to a RAM instance. To turn off RAM inference,
set its value to registers.
The following values can be specified globally or on a module or RAM instance:
registers – Causes an inferred RAM to be mapped to registers (flip-flops and logic) rather
than the technology-specific RAM resources.
block_ram – Causes the RAM to be implemented using the dedicated RAM resources. If
your RAM resources are limited, you can use this attribute to map additional RAMs to
registers instead of the dedicated or distributed RAM resources.
VHDL Syntax
attribute syn_ramstyle of object : objectType is "string" ;
where object is a signal that defines a RAM or a label of a component instance. Data type is
string.
library ieee;
use ieee.std_logic_1164.all;
entity ram4 is
port (d : in std_logic_vector(7 downto 0);
addr : in std_logic_vector(2 downto 0);
we : in std_logic;
clk : in std_logic;
ram_out : out std_logic_vector(7 downto 0) );
end ram4;
library synplify;
architecture rtl of ram4 is
type mem_type is array (127 downto 0) of std_logic_vector
(7 downto 0);
signal mem : mem_type; -- mem is the signal that defines
the RAM
attribute syn_ramstyle : string;
attribute syn_ramstyle of mem : signal is "block_ram";
Figure 4-42: VHDL Example
syn_romstyle
Attribute. Allows you to implement ROM architectures using dedicated or distributed ROM. Infer
ROM architectures using a CASE statement in your code.
VHDL Syntax
attribute syn_romstyle of object : object_type is "block_rom | logic" ;
syn_use_carry_chain
Attribute. Used to turn on or off the carry chain implementation for adders.
Verilog Syntax
object synthesis syn_use_carry_chain = {1 | 0} */ ;
Verilog Example
To use this attribute globally, apply it to the module.
VHDL Syntax
attribute syn_use_carry_chain of object : objectType is true | false ;
syn_useioff
Attribute. Overrides the default behavior to pack registers into I/O pad cells based on timing
requirements for the target Lattice families. Attribute syn_useioff is Boolean-valued: 1 enables
(default) and 0 disables register packing. You can place this attribute on an individual register or
port or apply it globally. When applied globally, the synthesis tool packs all input, output, and I/O
registers into I/O pad cells. When applied to a register, the synthesis tool packs the register into
the pad cell; and when applied to a port, it packs all registers attached to the port into the pad
cell.
The syn_useioff attribute can be set on the following ports:
top-level port
register driving the top-level port
lower-level port, if the register is specified as part of the port declaration
Verilog Syntax
object synthesis syn_useioff = {1 | 0} */ ;
Verilog Example
To use this attribute globally, apply it to the module. To use this attribute on individual ports, apply
it to individual port declarations.
VHDL Syntax
attribute syn_useioff of object : objectType is true | false ;
Synthesis Macro
Use this text macro along with the Verilog `ifdef compiler directive to conditionally exclude part of
your Verilog code from being synthesized. The most common use of the synthesis macro is to
avoid synthesizing stimulus that only has meaning for logic simulation. The synthesis macro is
defined so that the statement `ifdef synthesis is true. The statements in the `ifdef branch are
compiled; the stimulus statements in the `else branch are ignored. Because Verilog simulators do
not recognize a synthesis macro, the compiler for your simulator will use the stimulus in the `else
branch.
translate_off/translate_on
Directive. Allows you to synthesize designs originally written for use with other synthesis tools
without needing to modify source code. All source code that is between these two directives is
ignored during synthesis.
Verilog Syntax
/* pragma translate_off */
/* pragma translate_on */
library ieee;
use ieee.std_logic_1164.all;
entity adder is
port (a, b, cin:in std_logic;
sum, cout:out std_logic );
end adder;
architecture behave of adder is
signal a1:std_logic;
--pragma translate_off
constant a1:std_logic:='0';
--pragma translate_on
begin
sum <= (a xor b xor cin);
cout <= (a and b) or (a and cin) or (b and cin); end
behave;
Figure 4-51: VHDL Example
create_clock
Creates a clock and defines its characteristics.
Note
In LSE timing, interclock domain paths are always blocked for create_clock. However, the interclock domain
Syntax
create_clock -name name -period period_value source
Arguments
-name name
Specifies the name of the clock constraint, which can be referenced by other constraints.
-period period_value
Specifies the clock period in nanoseconds. The value you specify is the minimum time over which
the clock waveform repeats. The period_value must be greater than zero.
source
Specifies the source of the clock constraint. The source can be ports or nets (signals) in the
design. If you specify a clock constraint on a port or net that already has a clock, the new clock
will replace the existing one. Only one source is accepted. Wildcards are accepted as long as the
resolution shows one port or net.
Example
The following example creates two clocks on ports CK1 and CK2 with a period of 6:
create_clock -name my_user_clock -period 6 [ get_ports CK1
]
create_clock -name my_other_user_clock –period 6 [get_nets
CK2]
set_false_path
Identifies paths that are considered false and excluded from timing analysis.
Syntax
set_false_path [-from port or cell] [-to port or cell]
or
set_false_path [-through through_net]
Arguments
-from port or cell
Specifies the timing path start point. A valid timing starting point is a clock, a primary input, a
combinational logic cell, or a sequential cell (clock-pin).
-to port or cell
Specifies the timing path end point. A valid timing end point is a primary output, a combinational
logic cell, or a sequential cell (data-pin).
-through through_net
Specifies a net through which the paths should be blocked.
Examples
The following example specifies all paths from clock pins of the registers in clock domain clk1 to
data pins of a specific register in clock domain clk2 as false paths:
set_input_delay
Defines the arrival time of an input relative to a clock.
Syntax
set_input_delay delay_value -clock clock_ref input_port
Arguments
delay_value
Specifies the arrival time in nanoseconds that represents the amount of time for which the signal
is available at the specified input after a clock edge.
-clock clock_ref
Specifies the clock reference to which the specified input delay is related. This is a mandatory
argument.
input_port
Provides one or more input ports in the current design to which delay_value is assigned. You can
also use the keyword “all_inputs” to include all input ports.
Example
The following example sets an input delay of 1.2 ns for port data1 relative to the rising edge of
CLK1:
set_input_delay 1.2 -clock [get_clocks CLK1] [get_ports
data1]
set_max_delay
Specifies the maximum delay for the timing paths.
Syntax
set_max_delay delay_value [-from port or cell] [-to port or cell]
Arguments
delay_value
Specifies a floating point number in nanoseconds that represents the required maximum delay
value for specified paths.
If the path ending point is on a sequential device, the tool includes library setup time in the
computed delay.
-from port or cell
Specifies the timing path start point. A valid timing start point is a clock, a primary input, a
combinational logic cell, or a sequential cell (clock pin).
-to port or cell
Specifies the timing path end point. A valid timing end point is a primary output, a combinational
logic cell, or a sequential cell (data pin).
set_multicycle_path
Defines a path that takes multiple clock cycles.
Syntax
set_multicycle_path ncycles [-from net or cell] [-to net or cell]
Arguments
ncycles
Specifies a value that represents the number of cycles the data path must have for setup check.
The value is relative to the ending point clock and is defined as the delay required for arrival at
the ending point.
-from net or cell
Specifies the timing path start point. A valid timing start point is a sequential cell (clock pin) or a
clock net (signal). You can also use the keyword “all_registers” to include all registers’ clock
inputs.
-to net or cell
Specifies the timing path end point. A valid timing end point is a sequential cell (data-pin) or a
clock-net (signal). You can also use the keyword “all_registers” to include all registers’ data
inputs.
Example
The following example sets all paths between reg1 and reg2 to 3 cycles for setup check. Hold
check is measured at the previous edge of the clock at reg2.
set_multicycle_path 3 –from [get_cells reg1] –to [get_cells
reg2]
set_output_delay
Defines the output delay of an output relative to a clock.
Syntax
set_output_delay delay_value -clock clock_ref output_port
Arguments
delay_value
Specifies the amount of time from a “clock_ref” to a primary “output_port.”
-clock clock_ref
Specifies the clock reference to which the specified output delay is related. This is a mandatory
argument.
output_port
Provides one or more (by wildcard) output ports in the current design to which delay_value is
assigned. You can also use the keyword “all_outputs” to include all output ports.
Overview
The iCEcube2 Physical Implementation software constitutes the second half of the iCE design
flow, and is used to implement the design on the iCE FPGA devices. The inputs to Physical
Implementation Tools are an EDIF netlist and SDC constraint files.
In addition, the software supports additional Timing Constraints in SDC format, as well as
Physical Constraints in PCF format, that can be passed directly to the Physical Implementation
tools.
The outputs are the device configuration files used to program the device, and Verilog/VHDL and
SDF files for timing simulation in an industry standard simulator.
In addition, the software also provides several powerful and useful back-end tools such as a
Timing Constraints Editor (SDC), a Floor Planner, a Pin Constraints Editor, a device Package
Viewer, a Power Estimator, and a Static Timing Analyzer.
3. Physical Constraints Editor / Floor Plan Viewer: This tool has a dual function: It allows the
user to create physical constraints after importing the design, which are honored by the
Placer. After the Placer has run, this tool allows the user to view the logic and pin placement
before final bitmap generation. At this stage of the design flow, it allows the user to modify the
placement of logic cells, IO cells and RAM cells, before final routing.
4. Package View: This utility allows the user to view the pin assignments before final bitmap
generation. It also allows the user to modify the pin placement.
5. Pin Attributes Editor: This tool allows the user to view and configure pin properties, such as
pin location, the IO standard and the optional pin Pull Up resistor.
6. Power Estimator: This utility assists users in estimating device power for a given design via
a spreadsheet listing the various utilized resources of the device, the estimated maximum
operating frequency, the core voltage etc.
Floor Planner
The device Floor Plan (Figure 5-3) can be viewed by selecting Tool > Floor Planner from the
Tool menu, by or clicking the Floor Planner icon in the Tools tree in the Project Name pane.
The subsequent details in this section pertain to the viewing capabilities of the Floor Planner.
The Floor Planner also allows the user to manually modify the placement of logic (Logic Cells and
RAM blocks) as well as IO pins. Additional details on the creation/application of Physical
Constraints are provided in 0
The View > Zoom In and View > Zoom Out menu items zoom in and out of the Floor Plan
respectively. Mousing over a cell or net also displays instance information for that cell or net.
A World View pane provides a view of the entire Floor Plan, and can be used to navigate the
floor plan when the Zoom In factor is high.
The placed Logic tiles in the Floor Planner have the following Color conventions. White color
represents an empty cell; Green color represents a placed cell. When you select a particular cell
Figure 5-6: Invoking the Sort and Search functionality in the Logic/IO/RAM/Net pane
Selecting the Sort by Name option sorts the Logic instances based on instance names as shown
below
Select Lock option to fix the instance location in the floor planner view.
Selecting the Search menu item brings up the user interface displayed in Figure 5-9. Note that
the same dialog box can also be invoked from the Edit > Search menu item.
The type of design node (Logic, Net, IO, RAM, Port) should be specified, in order to filter the
search process. In addition, a search pattern with wildcards (*,?) to match the required node
A Right-Mouse-Click on the selected node in the Floor Plan View invokes a menu that allows
the user to display the nets connected to the node. This menu can be invoked for Logic Cells,
Block RAM and IO Cells. The resulting menu for a Block RAM cell is displayed in Figure 5-10.
The user now has the option to selectively display the nets connected to a cell. For example,
selecting the Display fan-in nets menu item displays only the nets that drive the node, i.e. the
fan-in nets. Similarly, if the user wishes to display only the nets that are driven by the selected
node, the Display fan-out nets menu item should be selected. Both, fan-in and fan-out nets, can
be displayed simultaneously, by selecting the Display fan-in & fan-out nets menu item.
As an example, both fan-in and fan-out nets of a Block RAM cell are shown in Figure 5-11. It
should be noted that the fan-in nets connect to the left side of the driven cell, and are depicted in
light yellow. Fan-out nets connect to the right side of the driver cell, and are depicted in dark pink.
Using fan-in and fan-out nets, the user can traverse the design from cell to cell, and make
appropriate decisions about modifying the placement manually.
Note that by default, the fan-in and fan-out nets are displayed whenever a cell is selected. This
setting can be changed by disabling it in the Tool > Tool Options > Floor Planner tab, as
displayed in Figure 5-12 below.
Package View
The Package View tool (Figure 5-13) displays a pin map of the implemented design in the
targeted package, and allows the user to change Pin properties such as Location and IO
Standard. Note that these properties can also be modified from the Floor Planner and the Pin
Constraints Editor.
A Port pane is available and it permits the user to select a design pin, and highlight it in the
package view.
A World View pane provides a view of the entire package, and can be used to navigate the
package view when the Zoom In factor is high.
Mousing over a pin in the package view provides information on its usage, whether the pin is
available, the pin number and the pin name.
The package pins assigned to the user’s design ports are depicted in green, and in general can
be re-assigned to different locations.
The Package Pin Legend (Figure 5-14) shows the color coding of the various pins available on
the selected package, identifying the functions of the pins. For example: power (VCC, VCCIO,
GND, VPP/VDDP, VREF), user IO, and other special purpose pins which provide access to the
low-skew global network (GBIN).
Figure 5-15: The Pin Constraints dialog box invoked from the Package View
Undesired pin location changes can be reverted back to their initial state using the Edit > Undo
menu.
Once all changes are complete, the new pinout can be saved by clicking File > Save Package
View from the main menu.
Note: Any changes to the package pin assignment will require the router to be rerun.
Power Estimator
The iCEcube2 Tool Suite includes a utility for estimating device power consumption for a given
design. The Power Estimator (Figure 5-17) can be invoked by selecting Tools > Power Estimator
from the main menu.
The utility includes a listing of utilized device resources and power dissipated at the estimated
maximum operating frequency. The user can modify several design parameters to analyze their
impact on power consumption. These parameters can be modified on the various tabs of the
Power Estimator GUI.
The Summary tab displayed in Figure 5-17 below allows the specification of the following
operational parameters for the purpose of power calculation only. Note that the operating
conditions specified earlier for Timing Analysis are not impacted by changes to the Power
Estimation parameters.
Core Vdd: The voltage at which the core of the chip operates, in Volts.
IO Voltage: The voltage at which the IO cells operate, in Volts. This can be specified
individually per bank.
Process: The process corner selection for power calculations.
Temperature: The temperature at which the chip operates, in degree Celsius. The
operating temperature can vary from -40°C to 100°C.
The IO tab displayed in Figure 5-18 permits the user to specify the toggle rate for the design’s
input and output ports, as well as loading capacitance for output pins.
The Clock Domain tab allows the user to specify the clock frequency in MHz as shown in Figure
5-19. Note that changing this frequency adjusts the operating frequency of the individual logic
resources like the IO Cells, LUTs, Flip-Flops and Block RAMs (BRAM), as per the built-in toggle
rate estimates. In addition, the switching frequencies of the Sequential Logic Cells (Logic cell in
which the flip-flop is utilized), as well as the Combinational Logic Cells (Logic cell in which only
the LUT is utilized), can be specified, on a per domain basis.
The user can save the current session’s input data while closing the Power Estimator. Next time
when the Power Estimator is open, the previous session’s input data are populated automatically.
Generating a Bitmap
After routing is complete, the last step in the flow is to generate the configuration files (bitmap) for
programming the target device. Clicking the Bitmap icon in the Flow tab generates the bitmap.
Changing the Bitmap Options
The user can change the Bitmap options by selecting Tool > Tool Options > Bitmap. See Figure
5-20.
1. SPI Flash Mode Options: Checking the option will place the PROM in low power mode after
configuration. (Note: This option is applicable only when the iCE FPGA is used as SPI
master mode for configuration)
2. RAM4K Initialization Option: The device configuration files will not include RAM4K
initialization pattern when this option is unchecked.
3. Internal Oscillator Frequency Range: Depending on the speed of the external PROM, this
option adjusts the frequency of the internal oscillator used by the iCE FPGA during
configuration (Note: This is only applicable when the iCE FPGA is used in SPI master mode
for configuration)
Diamond Programmer
Diamond programmer is fully integrated into Lattice Diamond software and also available as a
standalone application. When Diamond programmer is run within the Diamond GUI, it can be only
used to program devices supported by Diamond Software. When Diamond Programmer is run
standalone it can be used to program iCE devices.
Download and install the latest standalone programmer from http://www.latticesemi.com/ispvm.
Launch the standalone programmer to program iCE devices. The following options are available
in the getting started Dialog box as shown in Figure 5-21.
Create a new project from a scan: Use this option to create a project based on
scanning of the attached programming cable. Select the cable type, port and click on
detect cable button to create a new configuration project.
Create a new blank project: Create a new blank project.
Open an existing programmer project: Open an existing configuration project (.xcf)
file.
The following figure shows the programmer main windows. Main window shows the cable
settings, selected device and the programming mode options.
Click on Device Family tab and select the device family. Similarly select the target device.
There are three programming modes available to configure iCE40 devices. Click on Operation tab
in the main window or select Edit -> Device Properties to select the configuration mode.
SPI Flash Programming: iCE40 device is configured using an external SPI Flash device. In this
flow, the iCE40 device acts as the SPI bus master and will therefore control the data flow from the
Click on the program icon or select Design->Program to start program the device. The output
window displays the status of programming.
For more information on iCE40 Programming, refer Standalone Diamond programmer Help ->
Programming the FPGA > Programming and Configuring iCE40 Devices with Programmer.
Memory Initializer
iCEcube2 provides a command line utility to initialize the block memory primitives (BRAM) in the
design after placement and routing. The memory initialize utility directly updates the memory
contents in the post route OA database. This feature allows the user to initialize a single or
multiple memory contents without re-implementing the design. The post route simulation netlist
can be regenerated through Tools ->Generate Simulation Netlist menu item for functional
verifications.
Dos Command
<<icecube2_install_dir>>\sbt_backend\bin\win32\opt\mem
initializer.exe --des-lib <design_OA_database> --mem-
list-file <mem-list-file-name>
export LD_LIBRARY_PATH =
<<icecube2_install_dir>>/sbt_backend/lib/linux/opt/:
$LD_LIBRARY_PATH
<<icecube2_install_dir>>/sbt_backend/bin/linux/opt/mem
initializer --des-lib <design_OA_database> --mem-list-
file <mem-list-file-name>
Options:
--des-lib <design_OA_database> : Specify the design OA database (oadb-XXXX ).
Memory list file Format: Memory list file is a text file which specifies the post-synthesis logical
BRAM instance name or the post-routed physical BRAM instance name as in the post route
simulation netlist and the associated memory initialization file. The format of the file is shown
below
Example: sample_mem.list
memory0 ram1.mem
memory1 ram2.mem
memory2_physical ram3.mem
The floor planner view shows the post synthesis BRAM logical instance names.
This initialize the address A0 with 0003, A1 with 00F3, A2 with 003E, A3 with 004F, B2 with
003B, and B3 with 009F. Address B3 is not parsed and initialized to 0. The other addresses not
specified in the .mem file are initialized to 0.
VHDL Simulation
The post-route files used for VHDL timing simulation are as follows:
Post-Route VHDL netlist: <top_level_design_name>_sbt.vhd
VHDL SDF Timing file : <top_level_design_name>_sbt_vital.sdf
The iCEcube2 software provides VHDL simulation libraries at the following location:
<iCEcube2_installation_directory>/VHDL
Using the above files, the design can be simulated in Aldec Active-HDL simulator or simulated in
an industry standard VHDL simulator, and verified for functionality and timing. The details of
simulating a design with Aldec Active-HDL are described in Simulating Design with ALDEC
Active-HDLChapter 10.
Overview
The iCEcube2 Static Timing Analysis (STA) software is useful for analyzing, verifying and
debugging the timing performances of your design. Static Timing analysis along with functional
verification allows you to verify the overall design operation.
The STA tool accepts timing constraints in Synopsys Design Constraints (SDC) format. The SDC
constraints can be forward annotated by Synplify Pro or LSE. In LSE, SDC constraints are
forward annotated in all Optimization Goal settings except for “Area”. SDC constraints can also
be specified separately by the user through the Timing Constraints Editor (TCE).
This chapter focuses on the following aspects:
The user can select the type of constraint in Constraint Selector tab as displayed in Figure 6-1.
When invalid constraints are specified, the TCE editor displays them in RED color and does not
forward annotate the constraints to the Placer/Router/STA tools.
Selecting this option opens a new window where the user can search pin/clock/cell pin names as
shown in Figure 6-3. The user can also use the “*” and “?” wildcards in the search pattern fields to
search for a specific pin/clock/cell pins.
Clock Constraints
To enter clock constraints, select the Clock tab in the Timing Constraints Editor GUI. The
following fields are displayed under the Clock tab.
Source: Enter the pin name or the port name for the clock in the Source field. The port or pin
name can be selected from the drop-down box. Alternately, the user can search for
ports/cell pins by using the search option. Right clicking in source field gives the option of
searching ports/cell pins, as shown in Figure 6-2.
Name: Enter the name for the clock in the Name field. This is an optional field.
Period: Enter the period in ns, for the clock in Period field.
Waveform: Duty cycle for the clock can be specified in the Waveform field, with rising and falling
time edges of the clock.
For example, when a clock is specified as displayed in Figure 6-4, the following SDC command is
generated:
For every frequency defining path (one per clock), the following fields are displayed in the Critical
Path Summary section:
Start Point: This indicates the pin at which the data path initiates. It can be a top-level design
port (input package pin), the output of a flip-flop or the RDATA output of a RAM block.
For example, in Figure 6-13 “Slack” was added first in ascending order. Then “Start Edge” was
added next in ascending order. So, the results are displayed with ascending order of slack first
and then, the results with same slack are sorted in ascending order of Start Edge.
It should be noted that:
1. Frequency computations are performed only on paths starting from input pads and flip-
flop/RAM outputs, and ending at output pads and flip-flop/RAM inputs.
2. If the paths triggered by a clock are not constrained (timing start point and timing end points),
then the columns Worst Slack, FMAX and Failing Paths are shown as “N/A”. Appropriate
constraints are required in order for clock frequencies to be reported.
3. In the clock summary pane, only the most critical path for each constrained clock is displayed
irrespective of constraints met or not.
4. If the constraints are not met, the “Failing Path #” column shows the no of paths failed
including the most critical path displayed in the summary pane. All the other failing paths can
be viewed through query path options as described in Analyzing Constrained Paths.
Detailed Path Report Pane gives the routing delays and delay of each cell involved in the path
and the slack values. For detailed analysis of Timing Path Reports, refer to “Detailed Timing
Path” section.
The detailed timing path report can be saved in text format by using “Save Detail” Option.
Customize Columns option enables the user to choose the parameters that need to be used while
displaying the timing report. A sample customization option menu is shown in Figure 6-16. It also
enables the user to adjust the width of each column. By using “Move Up” and “Move Down”, the
user can sort out the Columns.
Data Sheet
The Data Sheet report summarizes the timing characteristics of the chip interface. It reports the
‘setup time’ and ‘hold time’ for the input pad to FF paths in the design, maximum and minimum
‘clock to out delays’ for the FF to output pad paths and maximum and minimum ‘path delay’ for
the pad to pad paths.
A sample Data Sheet report by the iCEcube2 software is shown in Figure 6-18.
Select “Input Pad to FF” tab and “Setup Time” sub tab to view the paths and the associated setup
delays. Similarly select the “FF to Output Pad” tab to view the maximum and minimum clock to
out delays and “Pad to Pad” tab to view the maximum and minimum path delays.
Setup Time: Reports the input setup time for each combination of input data port and clock port.
Setup time for an Input port wrt a clock is given by
Setup Time = (Maximum Data delay from Input Pad to FF) + (FF setup delay) - (Minimum Clock Path Delay)
Hold Time: Reports the hold times for design inputs, for each combination of input data port and
clock port. Hold time for the signal on an Input port wrt a clock is given by
Hold Time =(Maximum Clock Path Delay) + (FF hold delay) - (Minimum Data delay from Input
Pad to FF)
Max Pad to Pad Delay: Reports the maximum Pad to Pad delay for a signal traversing a purely
combinational path from input pad (PI) to output pad (PO)
Max Pad to Pad delay = (Maximum Combinational Delay from PI to PO)
Min Pad to Pad Delay: Reports the minimum Pad to Pad delay for a signal traversing a purely
combinational path from input pad (PI) to output pad (PO)
Min Pad to Pad delay = (Minimum Combinational Delay from PI to PO)
Select the path shown in “Setup Time” sub tab to display the detailed path report as shown in
Figure 6-19.
Clicking on the Analyze Paths button allows the user to query paths in the following ways:
1. Querying for the paths based on the “Slack” value.
2. Querying for the paths based on the “Paths Start/End” Points.
3. Querying for the combinational paths based on the “Start/End” Terminals.
By Slack
The By Slack option in the “Analyze Paths” window allows the user to list out all the paths in the
design with increasing slack values.
User can customize the number of paths reported by modifying the value in “Limit Report to n
Paths” option as shown in Figure 6-20.
The Advanced Options section helps the user to customize the paths reported.
The first option in this section is useful to limit the paths reports based on Launch Clock, Capture
Clock and their phases.
The second option helps in limiting the results reported based on the number of paths per start
point and number of paths per end point.
Using the third option the results can be restricted based on the maximum slack value.
The Save Summary and Save Detail provide the ability to save the report in a text format, for all
paths, or the details of the selected path, respectively.
Select one of the path in “Paths summary” panel to display the detailed path summary as shown
in Figure 6-21.
Please note that when the user searches from/to an IO, STA reports the paths as follows:
Other Features
Various other features in Timing Analyzer include:
Timing Corner: The Timing Corner option in the “Timing Analyzer” allows the user to analyze the
timing performance of a routed design under different Power Grade/Operating Conditions, without
having to recompile the design. The Timing Corner window (Figure 6-26) is used to change the
power grade of the device, operating conditions like junction temperature, core voltage and IO
bank voltage. Along with these, user can also select the best, typical, worst cases corners at
which timing analysis should be performed.
Whenever the Operating Conditions/Power Grade are different from the settings used for design
compilation, the changes are highlighted in red. For example, in Figure 6-26, the timing analysis
condition is red, since the design was compiled for ‘Worst’ case timing analysis.
Generate Timing Report and SDF: This option allows the user to save the generated timing
reports and SDF file for the Timing Corner selected in the Timing Viewer.
Cross Probing between the Timing Viewer and Floor Planner: A right click on a pin name in
the detailed timing path report gives options to highlight the pin and the full path in floor planner.
When “Highlight in Floor-Planner” is selected, the selected pin and its connections would be
highlighted in the Floor Planner as shown in the Figure 6-27. When “Highlight Path in Floor-
Panner” option is selected the entire reported path is highlighted in the Floor Planner as shown in
the Figure 6-28. The delay of each instance in the path and the cumulative path delay are also
displayed for the selected path. “Zoom in” for a particular instance to see the delays. The number
displayed inside the instance is the absolute delay and the number on the path is the
accumulated total path delay. This feature helps the user to analyze the reported paths easily.
Figure 6-28: Path Cross Probing between the Timer and Floor Planner
The Clock Summary, Clock Relationship Summary and Data Sheet Report are visible in the
Timing Viewer GUI, and explained in earlier sections. The All Timing Paths report is described
below.
Reference Points:
Reference point section gives details about the start point; end point and reference launch clock
and the slack of the timing path. Typical Reference Points report is as shown below:
Slack Computation:
Slack is the difference between the signal required time and signal arrival time and is computed
using the below formula:
So, from the timing report Slack = ( 10000+1880 -441) - (1880 + 365 +836) = 8357ps.
Here clk is the launch clock. The delay from port clk to Launch Flop clock pin
(reg_0_LC_1_4_0/clk) is shown here. The clock starts from clock port, traverse through global
buffer and reaches Launch Flop Clock Pin at 1880ps.
Second section is the Data Path Delay. Data delay is the delay from Flop output pin
(reg_0_LC_1_4_0/lcout) to Flop input pin ( reg_1_LC_1_4_1/in3). From the report, the data path
delay is (3082-2246)=836ps.
Data path
Pin name model name delay cumulative slack edge Fanout
delay
-------------------- ------------------------- ----- ---------------- ----- ---- ------ ------------------ ------------------------- ------------
reg_0_LC_1_4_0/lcout LogicCell40_SEQ_MODE_1000 365 2246 8357 RISE 1
I__15/I LocalMux 0 2246 8357 RISE 1
I__15/O LocalMux 472 2717 8357 RISE 1
I__16/I InMux 0 2717 8357 RISE 1
I__16/O InMux 365 3082 8357 RISE 1
reg_1_LC_1_4_1/in3 LogicCell40_SEQ_MODE_1000 0 3082 8357 RISE 1
Third section is the Clock path delay of Capture clock. The clock delay is the delay from clock
port to registered latch flop clock pin. From the report, this delay is 1880ps.
Absolute Placement
Relative Placement
SPI Configuration IO Placement.
IO/FF Merge
Global Promotion/Demotion
Absolute Placement
After importing the design into iCEcube2 using “Import P&R Files”, the user can set a placement
location for all the instances like LUTs, DFFs, RAMs, IOs and Carry etc. These constraints can be
applied in Floor Planner, which can be invoked through Tools > FloorPlanner.
Constraining IOs
IOs can be constrained at desired locations by invoking the pin constraint editor box. This can be
invoked by a right click on the IO and selecting “move” option. In the pop up “Pin Constraint
editor” box user can set the Pin location, IO standard and pull up type for the IO as shown in the
Note: Placement of IOs into SPI locations are supported only through constraints.
Relative Placement
Relative Placement Constraints helps the user to group logic, and to fix the placement of the
grouped logic cells relative to each other.
Group Constraints
Once the Synthesis is done and after importing the P&R files, user can create the relative
placement location constraints. User has to invoke the floor planner from Tools > Floor Planner
or by clicking the Floor Planner symbol on the left top corner tools pane.
Creating a Group from Floor Planner is shown in Figure 7-3. In order to create a group, go to the
Group tab in the Floor Planner window. Right clicking on the empty space provides an option to
User can also delete the elements from logic elements from a group. Right-clicking on any logic
element in the ‘Group’ tab, gives the user the option to delete element from the logic group as
shown in Figure 7-5.
Once a region is created, user can assign a Group to a Region by going to Group tab and
changing its properties. Figure 7-7 shows how to set group to an origin. Multiple groups can be
assigned to the same region.
Once creating the constraint is done, user can save the created constraints in PCF file by clicking
the ‘save’ button on the top panel. Then the created PCF file will be automatically added to the
current project. The legality check of the created constraints can be performed by running the
‘Import P&R files’. The adherence of the constraints can be checked out by invoking the Floor
Planner again after running the Placer.
IO/FF Merge
The device IO pads include registers which can be used through explicit instantiation of the
SB_IO primitive, or by merging logic registers into the IO. Similarly, you can separate the IO
registers from the IO pads; this process is called Unmerging.
Creating the merging and unmerging constraints from GUI is shown in Figure 7-8.
After successful “Import P&R Input Files”, open the “Floor planner” and select “GPIO” tab.
Right Clicking on any IO shown in Floor Planner, gives the option to merge/unmerge FF. On
selecting this option, a pop up comes out asking the user to merge/unmerge FF from the IO.
The pop up gives the user the options to merge FF into IO and to separate FF from IO. The
options “Merge FF into Input/Merge FF into Output/Merge FF into Output Enable” specifies where
the Flip Flop should be merged into. Similarly, the options “Unmerge FF from Input/Unmerge FF
from Output/Unmerge FF from Output Enable” specifies from where the Flip Flop should be
separated.
Only the options that are feasible to merge/separate are displayed in the GUI. The options will be
grayed out, whenever merging/unmerging a FF is not possible.
The synthesis tool by default identifies the flops that can be merged into the IO and generates
appropriate directives to the P&R tool. The auto FF merge directive can be controlled by the user
by setting the Merge FF option to “off”. This is shown in Figure 7-9.
Once creating the constraint is done, user can save the created constraints in PCF file by clicking
the ‘save’ button on the top panel. The created PCF file will be automatically added to the current
project. The legality check of the created constraints can be performed by running the ‘Import
P&R files’. The adherence of the constraints can be checked out by invoking the floor planner
again after running the placer.
Once creating the constraint is done, user can save the created constraints in pcf file by clicking
the ‘save’ button on the top panel. Then the created pcf file will be automatically added to the
current project. The legality check of the created constraints can be performed by running the
‘Import P&R files’. The adherence of the constraints can be checked out by invoking the floor
planner again after running the placer.
IP Generation Flow
The sample design used in this document as an IP is an up counter. The RTL for the up counter
is presented below.
module ip (
clock,
enable,
reset,
out
);
input clock;
input reset;
input enable;
2. Browse to the RTL location and add the up counter file “ip.v” into the project. Add timing
constraint files if any. Click Finish to go back to the iCEcube2 main window.
4. After Synthesis, close the Synplify Pro tool. This will bring you back to iCEcube2 tool. The
Synthesis output files “PRJNAME.edf” and “PRJNAME.scf” would be automatically added
to the project. Double Click on “Run All” to run placement, router, and bitmap generation.
6. Double click on “IP Exporter” to save the IP in EDF format. Browse to a location on the
pop window and save the EDF file. By default, the EDIF file is saved in
<PrjName>/<PrjName_Implmnt>/sbt/IP/ location. The saved IP EDF file contains the
locations of all the instances.
module top(
clock,
reset,
enable,
up_count_out,
down_count_out
);
input clock;
input reset;
input enable;
output [7:0] up_count_out;
output [7:0] down_count_out;
reg [7:0] down_count_out;
input clock;
input reset;
input enable;
output [7:0] out;
endmodule
2. Browse to the RTL location and add the Verilog file “system.v” into the project as shown.
Click on Finish to get back to iCEcube2 tool.
4. After successfully running synthesis, close the Synplify Pro Tool. This will bring you back
to iCEcube2 tool. The Synthesis outputs “PRJNAME.edf” and “PRJNAME.scf” would be
automatically added to the project. Now, right click on the “IP Design Files” in “Add P&R
5. Click on “Run All”. This would perform Placement, Routing and Bitmap Generation.
6. Once the Flow is completely run, the placed instances can be viewed again by launching
Floor Planner through Tools > Floor Planner. You can observe that the IP would be
placed according to the locations mentioned in IP EDF.
This section explains the steps to create a top level design file with an IP block instantiation.
1. In your top level design file, instantiate the required IP as shown in Figure 9-1.
2. In the same top level design file, provide a black box definition of the IP building block, as
displayed in Figure 9-2.
module top
(
clkhf_en,
clkhf_pu,
clkhf
) /* synthesis VPP_2V5_TO_1P8V = 1 */;
/* VPP_2V5_TO_1P8V = 1 or 0 */
input clkhf_en;
input clkhf_pu;
output clkhf;
SB_HFOSC OSCInst0 (
.CLKHFEN(clkhf_en),
.CLKHFPU(clkhf_pu),
library ieee;
use ieee.std_logic_1164.all;
entity top is
port (
clkhf_pu : in std_logic;
clkhf_en : in std_logic;
clkhf : out std_logic
);
attribute VPP_2V5_TO_1P8V :boolean;
attribute VPP_2V5_TO_1P8V of top : entity is true; --true or false
end top;
begin
HFOSCinst0 : SB_HFOSC
port map
(
CLKHFEN => clkhf_en,
CLKHFPU => clkhf_pu,
CLKHF => clkhf
);
end behavior;
3. Launch iCEcube2 and create a new project from File > New Project. In the New Project
Window, browse to location where project need to be created, enter the project name, set
device and operation conditions. Select option “Start from Synthesis” and click on Next.
4. Add the top level design file into the project as shown in Figure 9-4. Click on Finish to get
back to the iCEcube2 tool.
2. In Synplify Pro, click on the “Open Project” icon. Select “Existing Project” in the “Open
Projects” dialog box. Browse to the “<user_IP_dir>/IP/I2C_to_SPI_Bridge/V1.1/source”
location and add the existing “I2C_to_SPI_Bridge.prj” file as shown in Figure 9-6. This
opens the “I2C_to_SPI_Bridge” project in Synplify Pro and automatically imports the
required source files. See Figure 9-7.
3. Drag and Drop the IP Project into the top level project as shown in Figure 9-8. This
converts the IP Projects into a “Sub-Project” of the top level project as shown in Figure
9-9.
1. In the Synplify Pro tool, select the top level project and right click on it. Select
“Hierarchical Project Options” as shown in Figure 9-10.
2. In the “Hierarchical Project Options”, specify the Sub-Project Implementation and set run
type as “top_down” as shown in Figure 9-11. Click on the “Synchronize All Options with
Top Level” icon to synchronize Sub-Project options with top-level project options.
4. Exit the Synplify Pro software. This will bring you back to the iCEcube2 environment. The
synthesized netlist is automatically added to the iCEcube2 project. Click on “Run All” to
Place, Route and generate bitmap.
ALDEC Active-HDL
Active-HDL is a windows based RTL/gate-level mixed language simulator from ALDEC. Active-
HDL simulator is fully integrated into iCECube2 windows design environment and launched
directly from the iCECube2 project Navigator. The iCEcube2 simulation wizard helps the user to
perform the following simulation scenarios.
1. Pre-Synthesis Simulation.
2. Post Place-n-Route Functional Simulation (Verilog/VHDL)
3. Post Place-n-Route Timing Simulation (Verilog/VHDL)
VHDL
Add the following library declaration in the HDL file. This library contains all the iCE primitive
VHDL functional and timing models.
library ice;
use ice.vcomponent_vital.all;
VERILOG
When you invoke the Aldec simulator through Simulation Wizard, the appropriate precompiled
libraries are automatically included for the simulation.
If you are running Aldec simulator outside of Simulation Wizard, appropriate precompiled libraries
must be referenced to the simulator.
To add a reference library in a standalone Aldec simulator, click on Design > Settings >
Simulation > Verilog. Browse the available precompiled library list and add the required Verilog
library. Click on Apply and then OK.
For script or bash mode, use the –L switch of the asim command to specify the precompiled
library.
asim -O5 -L ovi_ice +access tb
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
library ice;
use ice.vcomponent_vital.all;
process(clk, reset)
begin
if(reset = '1') then
q <= (others=>'0');
elsif(clk'event and clk = '1') then
q <= q + 1;
end if;
end process;
count <= q;
end behavioral;
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
entity count_tb is
end count_tb;
uut : counter
port map (
clk => clk,
reset => reset,
count => count);
end testbench_arch;
Figure 10-2 : Sample Design and testbench.
Pre-Synthesis Simulation
This section details the steps required for pre-synthesis simulation.
Figure 10-3: Launch Simulation Wizard and Specify Simulation Project name.
3. All the RTL design files in the iCECube2 project would be automatically added under the
source files section as shown in Figure 10-5. Select “+” icon to add “count_tb.vhd” test
bench file.
4. Add “count_tb.vhd” test bench file and click on “Next”. Click on “Finish” in the summary
page as shown in Figure 10-6.
5. The Active-HDL simulator is launched now and the workspace, simulation project, work
library are automatically created as per the simulation wizard inputs. The simulation
source files also added under simulation project. See Figure 10-7.
7. Expand the default work Library and set “count_tb” as top-level entity for elaboration
process.
8. To get internal signal visibility, set the read access to internal signals. To set the access
click on Design > Settings > Simulation > Access to design Objects. Set the signal
access as shown below. Click on Apply and then OK.
For script or bash mode runs, add +access +r +w_nets switch to the asim command.
9. Click on Simulation > Initialize Simulation. After Initialization, the “Design Browser” view
will be changed from “file” view to “Structure” view as shown in Figure 10-11.
10. Right Click on “count_tb” and select “Add to waveform”. A new waveform window will
show up and all the I/O signals in the design are added to the waveform viewer.
11. Type the command “run 1000ns” in the console and press enter. The 1-µs simulation
waveform will show up in the waveform window.
2. Launch simulation wizard by selecting the “AHDL” icon menu in the Project Navigator. In
the Simulation Wizard specify the simulation project name and simulation project
location. Click on “Next”.
Figure 10-14 : Launch Simulation Wizard and Specify Simulation Project name.
3. Select “Post-Route Cell-Level” as Process Stage and Select “Verilog” Simulation. Click
on “Next”.
4. The Verilog post routed simulation netlist “counter_sbt.v” would be automatically added
to the source files panel. Click on the “+” icon to add “count_tb.vhd” test bench file. Click
on “Next”.
5. In the Simulation wizard summary page click on “Finish” to launch the Active-HDL
Simulator.
2. Launch simulation wizard by selecting the “AHDL” icon menu in the Project Navigator. In
the Simulation Wizard specify the simulation project name and simulation project
location. Click on “Next”.
4. The simulation wizard automatically adds the post routed netlist “counter_sbt.v” in
“Source files” panel and the verilog delay format file “counter_sbt.sdf” under “SDF files”
panel as shown in Figure 10-20. Click on “+” icon to add the “count_tb.vhd” test bench
to the “Source files” panel. Click on “Next”.
7. Expand the default work library in the “Design Browser” panel and set “count_tb” as Top-
Level entity.
8. To get internal signal visibility, set the read access to internal signals. To set the access,
click on Design > Settings > Simulation > Access to design Objects. Set the signal access as
shown below. Click on Apply and then OK.
For script or bash mode runs, add +access +r +w_nets switch to the asim command.
10. Select Simulation > Initialize Simulation. After Initialization, the “Design Browser” view will
be changed from “file” view to “Structure” view as shown in Figure 10-24.
For batch mode run, use the “asim” command.
Verilog:
asim -O5 -L ovi_ice +access +r +w_nets tb
VHDL:
asim -O5 +access +r +w_nets tb
12. Type the command “run 1000ns” in the console and press enter. The 1-µs simulation
waveform will show up in the waveform window. The counter output timing delays with
respect to clock positive edge is shown in Figure 10-26.
Overview
The iCEcube2 software provides command line executables at each stage of the flow. The
iCEcube2 installation contains a set of TCL wrapper scripts to set the project and tool options and
execute the individual tools. It also contains top level TCL script to run the default backend flow
starting with edifparser tool to bitmap generation. The environment variables to be set for the
batch mode run are listed at Command Line Execution.
<<iCEcube2_install>>\LSE\bin\nt\synthesis.exe -f <project_name.prj>
Arguments:
-f <project_name.prj> : Specify LSE project file.
Sample project file “top_design_lse.prj” is shown below. Refer iCEcube2 user guide for LSE
project setting options.
###########################
## top_design_lse.prj ##
###########################
#device
-a SBTiCE40
-d iCE40LP8K
-t CM225
#constraint file
-sdc "../src/top_design.sdc"
#options
-frequency 200
-optimization_goal Area
-twr_paths 3
-ver "../src/top_design.v"
-p "C:/examples/sbtProject/top_design"
<<iCEcube2_install>>\sbt_backend\bin\win32\opt\synpwrap\synpwrap.exe
-prj <project_name.prj> -log <logfile_name>
Arguments:
-prj <project_name.prj> : Specify Synplify pro project file
-log <logfile_name> : Specify log file name.
Sample project file “top_design_syn.prj” is shown below. Refer to Synplify-pro user guide for
more project setting options.
###########################
## top_design_syn.prj ##
###########################
#project files
add_file -verilog -lib work "../src/top_design.v"
add_file -constraint -lib work "../src/top_design.sdc"
#implementation attributes
set_option -vlog_std v2001
set_option -project_relative_includes 1
#device options
set_option -technology SBTiCE40
set_option -part iCE40LP8K
set_option -package CM225
set_option -speed_grade
set_option -part_companion ""
#compilation/mapping options
# mapper_options
set_option -frequency auto
set_option -write_verilog 0
set_option -write_vhdl 0
# NFilter
set_option -popfeed 0
set_option -constprop 0
set_option -createhierarchy 0
# sequential_optimization_options
set_option -symbolic_fsm_compiler 1
# Compiler Options
set_option -compiler_compatible 0
set_option -resource_sharing 1
Command:
run_sbt_backend_auto <device_package> <design_topmodule> <project_dir>
<output_dir> <tool_options> <edif_netlist>
Arguments:
<device-package> : Specify the selected device –package name.
Ex: iCE40LP8K-CM225.
<design_topmodule : Specify the design top module name.
<project_dir> : Specify the path to synthesis project dir.
<output_dir> : Specify the synthesis implementation dir.
Backend results will be kept in the same directory.
<tool_options> : Specify tool options. Refer Backend tool Options for
complete list of tool options.
<edif_netlist> : Specify input edif netlist name.
#!usr/bin/tclsh8.4
###########################################
# Tool Interface
############################################
set sbt_root $::env(SBT_DIR)
exit
Each tool in the backend flow accepts parameter values to optimize the design. The
“run_sbt_backend_auto” wrapper accepts the individual tool options as a single argument
as given below
This section covers the tools in the iCEcube2 backend flow and the tool options.
Edif Parser
“Import P&R Input Files” stage in GUI invokes edif parser tool to parse the input edif netlist,
forward annotated timing constraints (scf) and the physical constraints file (pcf). This generates a
design database for placer and route tool. The edif parser tool options are specified with
“:edifparser” keyword in the argument.
Options
[-y | --physicalconstraint <phy_constraints.pcf>]
Specify the design physical constraints file.
Placer
iCEcube2 Placer tool optimally places the design objects into the device layout based on the
given physical and timing constraints to meet the performance requirements. The placer tool
options are specified with “:placer” keyword in the argument.
Options
[ -e | --effort_level <std|mid|high>]
Option to specify the placement effort level. Default is std.
[ -k | --no_autolutcascade]
Disable automatic LUT cascading in placer. By default LUT cascading is enabled.
[ -r | --no_autoramcascade]
Disable automatic RAM cascading in placer. By default RAM cascading is enabled in
placer.
[ -t | --power_driven]
Enable power driven placement mode. By default power driven placement option is
disabled in placer.
[ -p | --pack_area]
Pack for dense area. Default is for timing.
Options
[ --no_timing_driven ]
Option to disable timing driven router optimization. By default timing driven option is
enabled.
[ --no_pin_permutation]
Option to disable LUT pin permutation. By default pin permutation is enabled.
Bitmap
Bitmap generates the bit stream to program the device. The bitmap tool options are specified
with “:bitmap” keyword in the argument.
Options
[--no_low_power]
Change setting of SPI PROM from low power mode after configuration. Default is low
power mode if not specified.
[--no_init_ram]
Do not initialize Block Rams in the design with contents specified in the design or ‘0’.
Default is on.
[--frequency <low|medium|high>]
Select frequency value
[--no_warmboot]
Set warm boot to off. Default is on.
[-- set_security]
Set security mode.
[--set_unused_io_nopullup]
Set all unused IO in the design to no-pullup mode.
SET FOUNDRY=C:\lscc\iCEcube2\LSE
SET SBT_DIR=C:\lscc\iCEcube2\sbt_backend
C:\lscc\iCEcube2\LSE\bin\nt\synthesis.exe –f
top_design_lse.prj
tclsh iCEcube2_flow.tcl
Dos script for Synplify–iCEcube2 flow:
SET SYNPLIFY_PATH=C:\lscc\iCEcube2\synpbase
SET SBT_DIR=C:\lscc\iCEcube2\sbt_backend
C:\lscc\iCEcube2\sbt_backend\bin\win32\opt\synpwrap\sy
npwrap.exe -prj top_design_syn.prj -log icelog.log
tclsh iCEcube2_flow.tcl
Bash scripts
export LD_LIBRARY_PATH=/home/user1/lscc/iCEcube2/LSE
:$LD_LIBRARY_PATH
export FOUNDRY=/home/user1/lscc/iCEcube2/LSE
export SBT_DIR=/home/user1/lscc/iCEcube2/sbt_backend/
/home/user1/lscc/iCEcube2/LSE/bin/lin/synthesis.exe –f
top_design_lse.prj
tclsh iCEcube2_flow.tcl
Bash script for Synplify-iCEcube2 flow:
export
LD_LIBRARY_PATH=/home/user1/lscc/iCEcube2/sbt_backend/
bin/linux/opt/synpwrap:$LD_LIBRARY_PATH
export
SYNPLIFY_PATH=/home/user1/lscc/iCEcube2/synpbase
export SBT_DIR=/home/user1/lscc/iCEcube2/sbt_backend/
/home/user1/lscc/iCEcube2/sbt_backend/bin/linux/opt/sy
npwrap/synpwrap -prj top_design_syn.prj -log
icelog.log
tclsh iCEcube2_flow.tcl
To configure an IO with specific drive value, the user needs specify the “DRIVE_STRENGTH”
synthesis attribute on the IO instance. The design can have maximum of three IO instances with
configured drive strengths and the IO needs to be configured as output-only registered IO.
The iCEcube2 SW replicates the IO instance once or twice based on the specified drive strength
value. The original and the replicate IO instances share the following signal and properties.
Signals
o DOUT0
o DOUT1
o OUTPUT_CLK
o OUTPUT ENABLE
Properties
o PIN_TYPE
o PULL_UP
o IO_STANDARD
The placer auto places the IO in one of the 3 predefined IO group locations. The users can also
constraint the IO group location by using pcf constraints. The drive strengths are reported under
drive strength column in the pin table csv report as shown in Figure 12-1.
Following table shows the package pin locations of high drive IO groups.
Drive Value:
Example:
input a, b, output_clk;
output c;
assign x = a & b;
SB_IO #(.PIN_TYPE("010101") )
x_inst
(.PACKAGE_PIN(c),
.OUTPUT_CLK(output_clk),
.D_OUT_0(x)
) /* synthesis DRIVE_STRENGTH= x2 */;
endmodule
The RGB LED IO can sink between 0 to 24mA current in steps of 4mA per device pin when
configured as high drive sink. Similarly IR LED IO can sink between 0 to 500mA current in steps
of 50mA. The sink current value is set via the primitive parameters. Refer Technology Guide for
the details of parameter settings.
The Open Drain GPIO primitive (SB_IO_OD) instantiated in the design can be used to drive the
LED IO pins, when the LED drive parameters are set to zero. Open Drain IO cannot be placed at
normal IO pin locations and vice versa.
1. Group Creation
create_group $group_name Ex: create_group En_FFs
begin begin
inst0 [x0, y0, z0] EFF_A_Ins [1, 2, 3]
inst1[x1, y1, z1] EFF_B_Inst[1, 2, 4]
end end
3. Region Constraints
create_region –name $region_name –type $type $x_left $y_bottom $x_right $y_top
$type can be blocked (no cells are placed in the region) or
inclusive (holds the cells placed in the region)
set_group_to_region $group_name $region_ name
IO/FF Merge
1. Merge FF to IO
set_io_ff $port_name [-in/-out/-oe]
The options specify where the Flip Flops need to be merged.
Three Options can coexist at same time.
Ex: set_io_ff A1 -in -oe
2. Unmerge FF from IO
seperate_io_ff $port_name [-in/-out/-oe]
Ex: separate_io_ff A1 –in –oe