Table of figures

Copyright

All the contents of this document are protected by the copyright law. They may not be disclosed to third parties or copied or duplicated in any form without the written consent of NanoXplore.

Introduction

This document is intended to guide users of NanoXplore NXmap software through all the steps involved in the design flow and the options available in NanoXplore design suite:

nxmap is a graphical interface that allows user to view and compile an existing project.
nxpython is a wrapper around Python executable that allows user to control nxmap software as a wrapper. It fully supports Python syntax, structures and external modules.
The creation of a new project can be performed with both nxmap and nxpython tools.

All commands described in this document for NXpython can be applied to the provided VHDL examples in example folder.

Package description

The provided nXmap archive contains the following directories:

bin folder contains binary files for each supported Linux distribution
doc folder contains documentation files in pdf format
example folder contains several examples of different projects with design sources in VHDL
lib64 folder contains dynamic libraries and Python modules for each supported Linux distribution and associated Python version
share folder contains additional files (vhdl libraries, simulation libraries, etc...)

Installation

To install nxmap, the user needs to unpack nxmap-VERSION.tar.gz file into the installation directory (e.g. /opt/NanoXplore) using the following command:

$> tar xzf nxmap-VERSION.tar.gz -C /opt/NanoXplore

To set the license, it is required to export the following shell variable:

$> export LM_LICENSE_FILE=27000@servername

Where servername is the hostname of the server running the license daemon and 27000 is the port the daemon listens to.

Run nxpython

To run nxpython, use the following command:

$> /opt/NanoXplore/NXmap3/VERSION/bin/nxpython

To use the nanoxmap module in python, user must first call the following command in nxpython:

Nxpython specification

Command list and context

Heraafter a table of all available nxpython commands and the context they affect:

Méthod	Project	Synthesize	Place & Route	Bitstream	STA	Simulation
addBank				X
addBanks				X
addBlackBox		X
addDSPLocation			X
addFalsePath					X	X
addFile	X
addFiles	X
addIP	X
addMappingDirective		X
addMaxDelayPath					X	X
addMemoryInitialization				X
addMinDelayPath					X	X
addModule		X
addMulticyclePath					X	X
addPLLLocation			X
addPad		X	X
addPads		X	X
addParameter	X
addParameters	X
addPin		X	X
addPins		X	X
addRAMLocation			X
addRingLocation			X
addRingLocations			X
addVerilogIncludeDirectories	X
addVerilogIncludeDirectory	X
addVlogDefine	X
addVlogDefines	X
addWFGLocation			X
adjustAperture			X
applySdcFile	X
clearBanks	X
clearPLLs	X
clearPads	X
clearPins	X
clearWFGs	X
confineModule			X
constrainModule		X	X
constrainPath		X	X
createAnalyzer					X
createClock					X
createGeneratedClock					X
createObstruction			X
createRegion			X
createSimulator						X
destroy	X
destroyObstruction	X
destroyRegion	X
developCKGs					X
exportAsIPCore	X
exportRegions	X
exportSites	X
generateBitstream				X
generateSTANetlist	X
getDirectory	X
getLowskewSignals	X
getTimingUnit	X
getTopCellName	X
getVariantName	X
initRegister				X
limitLowskew			X
listAvailableLocations	X
load	X
modifyRegion			X
place	X
progress	X
rejectLowskew			X
removeFile	X
removeFiles	X
reportDesignComplexity	X
reportInstances	X
reportLowskewSignals	X
reportPorts	X
reportRegions	X
reportRegisters	X
resetTimingConstraints	X
route	X
save	X
setAnalysisConditions					X
setAperture			X
setCaseAnalysis					X
setClockGroup					X
setDescription	X
setDeviceID				X
setDirectory	X
setFalsePath					X
setFocus			X
setGCKCount			X
setInputDelay					X
setMaxDelay					X
setMinDelay					X
setMulticyclePath					X
setOption	X
setOptions	X
setOutputDelay					X
setSite			X
setTimingUnit	X
setTopCellName	X
setVariantName	X
synthesize	X
translateAperture			X

General commands

This chapter presents the general purpose commands. These commands do not need any object to be called as they are directly defined in the nxmap module.

createProject([workingDirectory])

This method is used to create an empty project object. The project can then be loaded or built.

Arguments:

Name	Type	Description
workingDirectory	string	the working directory in which files will be saved

When no argument is supplied, the working directory will be the one nxpython is launched from.

Example:

getErrorCount()

This function returns the number of errors issued during Synthesize, Place and Route flow steps.

This function takes no argument.

Example:

Output:

getRemarkCount()

This function returns the number of remarks issued during Synthesize, Place and Route flow steps.

This function takes no argument.

Example:

Output:

getWarningCount()

This function returns the number of warnings issued during Synthesize, Place and Route flow steps.

This function takes no argument.

Example:

Output:

listOptions()

This method lists all available options for current project.

This method takes no argument.

Example:

Output:

printError(message)

This function is used to print an error message in the nxmap output. This includes terminal output and log file if set. An error message is prefixed by ERROR string so it can be easily found.

When using this method, the global number of errors is incremented by 1.

Arguments:

Name	Type	Description
message	string	error message to print

Example:

Output:

printRemark(message)

This function is used to print a remark message in the nxmap output. This includes terminal output and log file if set. An error message is prefixed by REMARK string so it can be easily found.

When using this method, the global number of remarks is incremented by 1.

Arguments:

Name	Type	Description
message	string	remark message to print

Example:

Output:

printText([message])

This function is used to print a message in the nxmap output. This includes terminal output and log file if set. When no message is given, method prints a new line in the nxmap output.

Arguments:

Name	Type	Description
message	string	message to print

Example:

Output:

printWarning(message)

This function is used to print a warning message in the nxmap output. This includes terminal output and log file if set. A warning message is prefixed by WARNING string so it can be easily found.

When using this method, the global number of warnings is incremented by 1.

Arguments:

Name	Type	Description
message	string	warning message to print

Example:

Output:

setCoreCount(core_count)

This function sets the number of core to use in multi-thread algorithm.

Minimum value is 1. The tool uses the number of logic cores of the computer as a maximum.

Arguments:

Name	Type	Description
core_count	integer	core count number

Example:

Output:

setDirAutoChange(change_project_dir)

This function allows to create a user-defined directory to stock the reports created during the execution of the flow.

Arguments:

Name

Type

Description

change_project_dir

boolean

Change project directory when loading a project file when True (default).

Keep the current project directory when False

Example:

setLogDirectory(log_directory)

This function allows to create a user-defined directory to stock the reports created during the execution of the flow.

Arguments:

Name	Type	Description
log_directory	string	Name of the directory to be created.

Example:

Output:

usage()

This method displays application usage.

This method takes no argument.

Example:

Output:

version()

This method displays application version.

This method takes no argument.

Example:

Output:

Expected expressions for NXpython methods

NxPython methods get a standardized format for arguments expecting a path.

This section describes the expression format specific to NX.

Impacted methods:

The following methods allow regular expressions / wildcard formats in order to match with multiple instances:

· addDSPLocation

· addModule

· addRAMLocation

· constrainPath

· getInstances

· getModels

· getRegisters

· setSite

· …

Maintainability:

It is no longer necessary to escape (with the ‘\’ character) special characters for these methods.

Affected special characters are:

· ‘[‘

· ‘]’

· ‘(‘

· ‘)’

· ‘|’

For instance, the constraint:

addModule('timing_pipe$X2A98C8C6$', 'GEN_HIER0.GEN_COL[0].COL_PIPE', 'GEN_HIER0_COL-%')

can be replaced by:

addModule('timing_pipe(X2A98C8C6)', 'GEN_HIER0.GEN_COL[0].COL_PIPE', 'GEN_HIER0_COL-%')

However, the old format is still compliant and still operates.

User use:

In a usual way, a copy/paste of a path from a log file works for the constraint.

In addition, it is comfortable to use ‘*’ and ‘+’ characters to match several paths.

‘*’ matches with any character: can be very useful to match with all paths beginning with a specified path.

‘+’ matches with any character but ‘|’: can be very useful to match with all paths beginning with a specified path without matching with lower hierarchy levels.

Hereafter an example with existing paths and constraints:

Existing Path \ Path in constraint	start_path\|mycell_*	start_path\|mycell_+
start_path\|mycell_12	Match	Match
start_path\|mycell_12\|some_sub_cell	Match	No match

Note:

If the user needs to use regular expressions ignoring auto-escaping of special characters, it is possible to set the constraint using back quotes as follow:

addMappingDirective(getModels(“add_`[1-2][0-9]`u_*”), …)

Project related methods

This section presents the methods related to the project object.

addBank(name, dict)

The method addBank allows user to configure a specific bank of the FPGA. The pads inside the defined bank will be used first to configure inputs/outputs of the HDL module. For the given bank, the configuration has two basic arguments name and dict.

Arguments:

Name	Type	Description
name	string	the name of the bank. The bank name must respect syntax of the various banks included in current FPGA variant.
dict	dictionary	the dictionary of parameters of the bank. All keys and values of the dictionary are string.

dict is a dictionary which can take the following keys:

Type	Description
voltage	voltage of the bank (V)

The voltage must be one of the following values:

1.5
1.8
2.5
3.3

Example:

addBanks(dict)

The method addBanks allows user to configure several banks of the FPGA to be used for configuration of inputs/outputs of the HDL module. addBanks use a dictionary as an argument.

Arguments:

Name	Type	Description
dict	dictionary	the dictionary of banks. See addBank method for the list of available keys

Example:

addBlackBox(name, type, mapping, interface)

The method addBlackBox allows users to define customized mapping of certain HDL modules on the specific FPGA blocks and to dispose the interface of the blocks.

Arguments:

Name	Type	Description
name	string	the name of HDL module that is intended to be custom-mapped.
type	string	the nxpython object type (further details below).
mapping	string	the mapping target (further details below).
interface	string	the interface mapping between HDL module and nxpython (further details below).

The type argument can only be overridden for specific object types. The available types are:

Type	Description
ROM	Represents a ROM
RAM	Represents a RAM

For each type, there are some specific instances in the FPGA onto which it can be mapped. This can be specified using mapping argument. The following table presents all the available mapping targets for each type:

Type	Mapping targets	Description
ROM	RF, RAM	A ROM can be mapped onto RF blocks or RAM blocks
RAM	RF, RAM, RAM_ECC	A RAM can be mapped onto register files (if not split read/write port) or RAM blocks or RAM blocks with error detection/correction code

The argument interface argument specifies the interface mapping between the HDL module and nxpython.

Space character is not allowed in interface argument

When setting ROM value for type argument, the nxpython interface is:

Interface	Description
AD	Address to read data from
DO	Output data
CK	Clock

Used only when creating synchronous memory (with one clock)

When setting RAM value for type argument, the nxpython interface depends on the mode RAM is being used in:

RAM mode: Simple port

Interface	Description
CK	Clock
AD	Address
DI	Input data
DO	Output data
WE	Write enable
RE	Read enable (optional)

RAM mode: Split read/write port (1 port for read and 1 port for write)

Interface	Description
CK0	Read clock
AD0	Read address
DO0	Read output data
RE0	Read enable (optional)
CK1	Write clock
AD1	Write address
DI1	Write input data
WE1	Write enable

RAM mode: True dual port (2 ports for read/write)

First port:

Interface	Description
CK0	Clock
AD0	Address
DI0	Input data
DO0	Output data
WE0	Write enable
RE0	Read enable (optional)

Second port:

Interface	Description
CK1	Clock
AD1	Address
DI1	Input data
DO1	Output data
WE1	Write enable
RE1	Read enable (optional)

Example:

If the HDL design contains a micro code ROM define in VHDL as:

User can add a black box to force nxpython to recognize this module as a ROM.

addBlackBox() : for Preplaced IP

The idea is to offer the possibility to the user to reuse the result of an nxmap flow as an IP in a top design.

For instance, the user will work on a design named IP with the desired performance.

Preplaced IP for addBlackBox()

The user can then reuse the result of this first flow in another design. named top, which instanciates the IP entity several times.

Nxmap will use the result of synthesis and place from the first flow and replicate then in the top flow

Replication of synthesized IP

To specify that an entity of the design top must be taken into account as a preplaced IP, the user has to add the following constraint before the synthesis

The first argument is the name of the VHDL entity
The second argument must be ‘IP’
The third argument is the .nym Preplace results of the IP
The fourth argument is a string character which lists for each instanciation of the entity, the name of the instance followed by : and the region of the IP in fortmat (col x row). Instanciations are separated by the character ;

Limitations :

This functionality has some important limitations :

Variant

The variant on which the IP design is prepared must be strictly identical to the variant used for the design. For example, NG-MEDIUM in both cases.

Aperture

It is necessary that the IP design is placed/routed using minimal aperture.

addBlackBox

The method addBlackBox should be called only once by an entity in the top design.
For instance, it is not allowed to use the following lines :

Fabric instances

Among the instances of the ring, some are not supported yet :
CDC, CKS, FIFO, XFIFO

Ring instances

Among the instances of the ring, some are not supported yet :
PLL, WFG, CR5, SOC_IF, HSSL

addDSPLocation(pattern, place)

This method is used to select the spot in which a DSP should be placed before launching Place step execution.

Arguments:

Name	Type	Description
pattern	string	the pattern to match DSP name. The path can contain regular expressions, all wildcard expressions are allowed and special characters must be escaped.
place	string	the place where to place DSP.

DSP must be placed into CGB elements. As each CGB contains two DSP macros, user has to specify for place argument either to use the left DSP (L) or the right DSP (R) into the CGB.

Wildcard symbol is accepted for pattern argument.

Example:

The pattern argument does not support regular expressions

addFalsePath(from_list, to_list)

This method is used to specify the false path for the timing paths. This constraint is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
from_list	string	the command which specifies how to get a list of timing path starting points. A valid timing starting point is an input port or a register. A valid command can be: getPort(port_name), getPorts(name_expression), getRegister(register_name), getRegisters(name_expression), getRegistersByClock(clock_name)
to_list	string	the command which specifies how to get a list of timing path ending points. A valid timing ending point is an output port or a register. A valid command can be: getPort(port_name), getPorts(name_expression), getRegister(register_name), getRegisters(name_expression), getRegistersByClock(clock_name)

Example:

addFile([library], file)

This method is used to add a HDL source file to the project. The file can be added to a specific library by passing its name as the first optional library argument. The default library is work.

Arguments:

Name

Type

Description

library

string

name of the HDL library that contains the source file.

file

string

HDL source file, the path can be absolute or relative to the directory of the project.

file argument supports several flags for language compilation : VHDL_93, VERILOG_95, VERILOG_2K (default flag for verilog)

Example:

addFiles([library], fileList)

This method is used to add several HDL source files to the project. The files can be added to a specific library by passing its name as the first optional library argument. The default library is work.

Arguments:

Name	Type	Description
library	string	name of the HDL library that contains the source files.
fileList	list	list of HDL source files, the path can be absolute or relative to the directory of the project.

Example:

addIP(name)

This method is used to import HDL source files of a NX IP core into the current project.

The name must be a valid NX IP name (file name without extension). The available NX IP core can be found in install_path/share/ips directory.

Arguments:

Name	Type	Description
name	string	the name of the NX IP core to be add as a source file.

Example:

addMappingDirective(name, type, mapping)

This method is used to add a mapping directive for Synthesis flow step which overrides the default nxpython mapping behavior for a specific HDL module or instance.

Arguments:

Name	Type	Description
name	string	the name of HDL module or instance that is intended to be custom-mapped.
type	string	the target type of the directive (further details below).
mapping	string	the target mapping of the directive (further details below).

The name argument can be a regular expression matching a HDL module or instance name. In order to specify whether to search for module or instance, the user has to use the getModels(...) or getInstances(...) keyword.

The type argument can only be overridden for specific object types. For each type, there are some specific instances in the FPGA onto which it can be mapped. This can be specified using mapping argument. The following table presents all the available mapping targets for each type:

Type	Mapping targets
ADD	LUT, CY, DSP
LTN	LUT, CY, DSP
MUL	CY,DSP
RAM	RF, RAM, RAM_ECC, DFF
ROM	LUT, RF, RAM

Example:

If the HDL design named myTest contains a small 3 write ports and 3 read ports FIFO named myFifo, nxpython cannot automatically map it into RF or RAM, but user can add a mapping directive to map it into DFF:

addMaxDelayPath(from_list, to_list, delay)

This method is used to specify the maximum delay path for the timing paths. It is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
from_list	string	the command which specifies how to get a list of timing path starting points. A valid timing starting point is a register.
to_list	string	the command which specifies how to get a list of timing path ending points. A valid timing ending point is a register.
delay	integer	the required maximum delay value in ps for specified paths.

Example:

The name argument can be a regular expression matching a HDL module or instance name. In order to specify whether to search for module or instance, the user has to use the getModels(...) or getInstances(...) keyword.

The available file formats are:

Type	Format
NX	NanoXplore Proprietary format

The NX File format is a simple format in which initialization bits are written in ASCII. Each line of the file represents one vector in the memory. NULL MSBs and empty (only 0's) lines at the end of the file are NOT mandatory.

Example:

To initialize a memory called IMG_1' in a design called 'test_init' using data from a file called "initdata.nx", call:

If you declare a memory array 'array(0 to 5) of std_logic_vector(0 to 3)' and want to load an identity matrix, the file should contain:

Since it is not mandatory to initialize:

the end of the array if it contains only zeros

MSBs if they are null

The previous example can be written this way:

addMinDelayPath(from_list, to_list, delay)

This method is used to specify the minimum delay path for the timing paths. It is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
from_list	string	the command which specifies how to get a list of timing path starting points. A valid timing starting point is a register.
to_list	string	the command which specifies how to get a list of timing path ending points. A valid timing ending point is a register.
delay	integer	the required minimum delay value in ps for specified paths.

Example:

addModule(model, instance, format)

This method is used to add a HDL module definition to the current project that contains all HDL logic elements including within the model given in argument.

Arguments:

Name	Type	Description
model	string	the regular expression pattern to match the model name of the module. All regular expressions are allowed and special characters must be escaped.
instance	string	the regular expression pattern to match the instance name of the module. If instance pattern is empty, it will match any occurrence of the associated model. All regular expressions are allowed and special characters must be escaped.
format	string	the format of the internal name of the matched modules (character % is replaced by an incremental value).

Example:

nxpython reports user modules detection in the hierarchy.rpt (previous figure) file with detailed information including resources used for each module and detailed hierarchy of all modules defined in the current project.

hierarchy.rpt also allows to check if pattern expression provided for model and instance arguments have been fully accepted by nxpython tool. User must especially be careful about the regular expression operator '*', which is accepted whereas the wildcard operator '*' is not supported. See full details with an incorrect example.

Example:

Here is the correct regular expression to be used.

Example:

addMulticyclePath(from_list, to_list, cycle_count)

This method is used to specify the multicycle path for the timing paths. It is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
from_list	string	the command which specifies how to get a list of timing path starting points. A valid timing starting point is a register.
to_list	string	the command which specifies how to get a list of timing path ending points. A valid timing ending point is a register.
cycle_count	unsigned	An unsigned value that represents a number of cycles the data path must have for setup check.

Example:

addPad(name, parameters)

This method allows user to configure an input/output of the HDL module into specific pad of the FPGA. For the given pad, the configuration has two basic argument (name and parameters).

Arguments:

Name	Type	Description
name	string	the HDL input/output name.
parameters	dictionary	the keys are the parameters names and the values are the parameters values.

The parameters argument is a dictionary which can take the following keys:

location (string)	inputDelayOn (boolean)	turbo (boolean)
standard (string)	inputDelayLine (integer)	signalSlope
drive (string)	outputDelayOn (boolean)	outputCapacity
weakTermination (string)	outputDelayLine (integer)	registered
slewRate (string)	differential (boolean)
termination (string)	terminationReference (string)

The standard key must respect the following values:

LVCMOS (Default)
LVDS
LVDS_STR
SSTL
HSTL

LVDS is the nominal LVDS standard. LVDS_STR is a strong LVDS with higher voltage (ex : 550mVpp LVDS vs 900mVpp LVDS_STR for NG-LARGE variant).

The I/O differential (Default False) activation is conditioned only by the LVDS standard:

standard	differential
LVDS	True
LVDS_STR	True
LVCMOS	False
SSTL	False
HSTL	False

In case of differential mode, the user must only declare the “_P” pad. The associated differential “_N” pad will be automatically set by the software with the same parameters.

The drive key must respect the following values:

2mA (only allowed for LVCMOS standard - Default for LVCMOS standard)
4mA (only allowed for LVCMOS standard)
8mA
16mA
I (only allowed for SSTL and HSTL standard - Default for SSTL and HSTL standard)
II (only allowed for SSTL and HSTL standard)
Undefined (only allowed for LVDS standard - Default for LVDS standard)

As an example for NG-Large variant, the following array gives a trade-off between the maximum frequency reachable and noise limitation plus power consumption:

drive	LVCMOS	LVDS	SSTL 2.5V	SSTL 1.8V	HSTL
2mA	Fmax = 50MHz	-	-	-	-
4mA	Fmax = 100MHz	-	-	-	-
8mA	Fmax = 200MHz	-	-	-	-
16mA	Fmax = 300MHz	-	-	-	-
I	-	-	8mA, Fmax=300MHz	8.6mA, Fmax=400MHz	8mA, Fmax=400MHz
II	-	-	16mA, Fmax=300MHz	13.4mA, Fmax=400MHz	16mA, Fmax=400MHz
undefined	-	3.5mA, Fmax=400MHz	-	-	-

The weakTermination key must respect the following values:

None
PullDown
PullUp (Default)
Keeper

The slewRate key must respect the following values:

Slow
Medium (Default)
Fast

The termination key specifies the output impedance of the pad in Ohms. In differential mode, the impedance is two times the value. It’s specified in Ohms, in the range 30 to 80 Ohms (Default is set to minimum value).

Min and max values depend on the variant and the bank voltage.

The inputDelayLine and outputDelayLine keys should be between 0 (Default) and 63. This number correspond to a number of step. Values are applied only if inputDelayOn and outputDelayOn are set to True.

The terminationReference key is used only if termination is set (Default '-'). It must respect the following criteria to be set to ‘Floating’ value otherwise it should always be defined as ‘VT’.

Must be set to ‘Floating’ if:

differential is set to ‘True’
weakTermination is set to ‘None’

‘VT’ otherwise

Unit of inputSignalSlope key is V/ns in the range [0.5;20] (Default 0).

Unit of ouputCapacity key is pF in the range [0;40] (Default 0).

When set to ‘True”, the turbo key (Default False) specifies that the input buffer of the pad is in turbo mode. As an example for NG-Large variant, the following array gives a trade-off between the maximum frequency reachable and power consumption:

Standard	Turbo enabled (True)	Turbo disabled (False)
LVCMOS 3.3V	Fmax = 200MHz	Fmax = 100MHz
LVCMOS 2.5V	Fmax = 300MHz	Fmax = 200MHz
LVCMOS 1.8V	Fmax = 300MHz	Fmax = 150MHz
LVCMOS 1.5V	Fmax = 300MHz	Fmax = 150MHz
LVDS	Fmax = 400MHz	Fmax = 100MHz
SSTL 2.5V	Fmax = 300MHz	Fmax = 150MHz
SSTL 1.8V	Fmax = 400MHz	Fmax = 150MHz

The registered key (Default '') allows user to merge registers into Input/Output pads. This key can take the following values:

registered	Polarity of pad
I	Input
IC	Input with tri-state management
O	Output
OC	Onput with tri-state management
IO	Input and Output
IOC	Input and Output with tri-state management

When a key is not in the dictionary, its value is set to default, i.e. 0 for inputDelayLine/outputDelayLine/signalSlope/outputCapacity and False for all the boolean arguments.

Example:

addPads(pads)

This method is used to configure inputs/outputs of the HDL module into specific pads of the FPGA. The argument is a dictionary that associates the HDL input/output name to a dictionary, which can contain some keys (location, type, weakTermination, slewRate, termination, inputDelayLine, outputDelayLine, differential, terminationReference, turbo) as defined in addPad(name, parameters).

Arguments:

Name	Type	Description
pads	dictionary	the keys are the HDL input/output names and the values are dictionaries of parameters.

Example:

addPin(name, location)

This method allow user to configure an input/output of the HDL module into specific pin of the embedded FPGA. This method is reserved to embedded variants of FPGA.

Arguments

Name	Type	Description
name	string	the HDL input/output name.
location	string	the location of the input/output.

Example:

addPins(pins)

This method allow user to configure inputs/outputs of the HDL module into specific pins of the embedded FPGA. This method is reserved to embedded variants of FPGA.

Arguments:

Name	Type	Description
pins	dictionary	the keys are the HDL input/output names and the values are the locations.

Example:

addParameter(name, value)

This method allows user to specify the value of the top design generic parameters.

Arguments:

Name	Type	Description
name	string	the name of the generic parameter.
value	string	the value of the generic parameter.

Example:

addParameters(parameters)

In case of a large number of parameters, a parameter dictionary can be created consisting of the name of the parameter as a key and its respective value. Both name and value must be string.

Arguments:

Name	Type	Description
parameters	dictionary	parameters dictionary where keys are the parameters names and values the parameters values.

Example:

addPLLLocation(pattern, location)

This method is used to set the spot in which a PLL should be set.

Placement of PLL elements can also be done during instantiation (with location generic in source code).

Arguments:

Name	Type	Description
pattern	string	A pattern to match the PLL instance name. The path must be set entirely.
location	string	the requested location for the PLL. Valid locations are CKG[1-4].PLL1

Example:

addRAMLocation(pattern, place)

This method is used to select the spot in which a RAM should be placed. This method must be used and declared before launching Place step execution.

Arguments:

Name	Type	Description
pattern	string	the pattern to match RAM name. All wildcard expressions are allowed and special characters must be escaped.
place	string	the place where to place RAM.

RAM must be placed into selected CGB element with place argument.

Wildcard symbol is accepted for pattern argument.

Example:

addRingLocation(name, location)

This method is used to place an instance in the I/O ring of the FPGA. addRingLocation can be used instead of addPLLLocation, addWFGLocation or addPin.

Example:

Name	Type	Description
name	string	the name of the instance. The path must be set entirely.
location	string	the spot in which to set the instance.

Example:

addRingLocations(dictionary)

In case of a large number of instances to be placed in the I/O Ring, a dictionary can be created consisting in the name of the instance as a key and its association location. Both name and location must be string.

Arguments:

Name	Type	Description
dictionary	dictionary	dictionary where keys are the names and locations of the instances to be placed in the ring.

Example:

addVerilogIncludeDirectory(directory)

This method is used to add an extra directory containing Verilog files to the project. This is used when the included files are external to the working directory.

Arguments:

Name	Type	Description
directory	string	name of the directory containing Verilog files. Can be in absolute or relative.

Example:

addVerilogIncludeDirectories(directoryList)

This method is used to add several extra directories containing Verilog files to the project. This is used when the included files are external to the working directory.

Arguments:

Name	Type	Description
directoryList	list	list of the directories containing Verilog files. Can be in absolute or relative.

Example:

addVlogDefine(name,value)

This method is used to add a parameter definition for Verilog files.

Arguments:

Name	Type	Description
name	string	name of the parameter.
value	string	value of the parameter.

Example:

addVlogDefines(dictionnary)

This method is used to add parameters definition for Verilog files.

Arguments:

Name	Type	Description
dictionnary	dictionnary	dictionnary of parameters.

Example:

addWFGLocation(name, location)

This method is used to set the spot in which a WFG should be set.

Placement of WFG elements can also be done during instantiation (with location generic in source code).

Arguments:

Name	Type	Description
name	string	the name of the instance. The path must be set entirely.
location	string	the requested location.

Valid locations depend on the variant:

NG-MEDIUM	CKG[1−4].WFG_R[1−2]
	CKG[1−4].WFG_M[1−3]
	CKG[1−4].WFG_C[1−3]
NG-LARGE	CKG[1−4].WFG_R[1−3]
	CKG[1−4].WFG_M[1−3]
	CKG[1−4].WFG_C[1−4]

Example:

adjustAperture(regionName, above, left, right, below)

This method is used to move the aperture of a region or the whole design.

Arguments:

Name	Type	Description
regionName	string	name of the region.
above	integer	number of rows to shift the aperture above
left	integer	number of rows to shift the aperture on the left
right	integer	number of rows to shift the aperture on the right
below	integer	number of rows to shift the aperture below

Example:

applySdcFile(filePath)

This method is used to apply a Synopsys Design Constraints (SDF) file to a project for STA or TimingDriven purpose.

Arguments:

Name	Type	Description
filePath	string	path of the SDF file.

Name	Type	Description
name	string	the module name.
region	string	the region to confine the module in.

When a module is added to the current project with command, nxpython will generate a module name with automatic incremental syntax in case of listing different modules with similar names.

Example:

constrainModule(hierarchy, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

This method constrains a HDL module into a specific region. The aim of constrainModule is to provide a unique and simple function to perform the whole region driven flow described in Creating and handling regions section.

Signatures:

constrainModule(hierarchy, moduleName, leftCol, topRow, width, height, regionName)

constrainModule(hierarchy, moduleName, type, leftCol, topRow, width, height, regionName)

constrainModule(hierarchy, moduleName, leftCol, topRow, width, height, regionName, exclusive)

constrainModule(hierarchy, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

Arguments:

Name	Type	Description
hierarchy	string	the line corresponding to the module found in hierarchy.rpt log file. The path must be set entirely.
moduleName	string	the name to identify the module in GUI and log files.
type	string	impact the strength of constraint related to neighbor modules. ‘Hard’ specifies all logic to be constrained in the region. ‘Soft’ implies some logic could be placed outside of the region to be connected with external logic.
leftCol	integer	the number of the most left column of the region.
topRow	integer	the number of the most top row of the region.
width	integer	the width of the region (in number of columns).
height	integer	the height of the region (in number of rows).
regionName	string	the name to identify the region (in number of rows).
exclusive	boolean	exclusive : can be ‘True’ or ‘False’

Example:

constrainPath(sourceList, targetList, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

This method constrains a virtual module into a specific region. The aim of this function is to identify source and destination registers in order for all logic elements (LUT, carry) between these registers to be placed into a region created with the regionName argument.

Signatures:

constrainPath(sourceList, targetList, moduleName, leftCol, topRow, width, height, regionName)

constrainPath(sourceList, targetList, moduleName, type, leftCol, topRow, width, height, regionName)

constrainPath(sourceList, targetList, moduleName, leftCol, topRow, width, height, regionName, exclusive)

constrainPath(sourceList, targetList, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

Arguments:

Name	Type	Description
sourceList	stringList	the list of source register names or patterns. All regular expressions are allowed and special characters must be escaped.
targetList	stringList	the list of target register names or patterns. All regular expressions are allowed and special characters must be escaped.
moduleName	string	the name to identify the module in GUI and log files.
type	string	impact the strength of constraint related to connected resources. ‘Hard’ specifies only the logic contained in the path is constrained. ‘Soft’ implies some additional resources connected to the logic contained in the path could be placed in the region too.
leftCol	integer	the number of the most left column of the region.
topRow	integer	the number of the most top row of the region.
width	integer	the width of the region (in number of columns).
height	integer	the height of the region (in number of rows).
regionName	string	the name to identify the region (in number of rows).
exclusive	boolean	exclusive : can be ‘True’ or ‘False’

Example:

createAnalyzer

If a targeted design is already routed, user can launch static timing analysis by creating a timing analyzer.

This method takes no argument.

Example:

createClock(target, name, period, [rising, falling])

This method is used to create a clock constraint of a timing point. This constraint is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
target	string	the command which specifies how to get a clock related point. A valid command can be: getPort(port_name), getRegisterClock(register_name) (or getRegister(register_name)) and getClockNet(clock_net_name).
name	string	user clock name of the created clock.
period	unsigned	the period value in ps.
rising	unsigned	specific rising edge in ps for clock waveform. Range: [0, period[ (default value is 0).
falling	unsigned	specific falling edge in ps for clock waveform. Range: ]rising, rising + period] (default value is period/2).

Example:

In the example above, to define a clock with 100MHz for net "Clk", the following three commands are equivalent:

createGeneratedClock(source, target, name, relationship)

This method is used to create an internally generated clock constraint at a timing point. This constraint is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
source	string	the command which specifies how to get a source clock related point. A valid command can be: getClock(), getPort(port_name), getRegisterClock(register_name) (or getRegister(register_name)), getClockNet(clock_net_name), getWFGOutput(wfg_name)
target	string	the command which specifies how to get a clock related point. A valid command can be: getRegisterClock(register_name) (or getRegister(register_name)), getClockNet(clock_net_name)
Name	string	user clock name of the generated clock
relationship	dictionary	the relationships for computing clock wave of generated clock from master clock. All valid parameters can be: MultiplyBy : unsigned DivideBy : unsigned DutyCycle : unsigned (1 to 99) Phase : unsigned (0 to 359) Offset : integer (delay in ps) Edges : list [unsigned, unsigned, unsigned] (in non- decreasing order) EdgeShift : list [integer, integer, integer] (delay in ps)

Example:

In the example above, the master clock "Clk" was created as 100MHz and the generated clock "clk1" is divided by 2 from the master clock. But noted that the "clk_reg" is driven by falling edge of master clock, the relation between the master clock and generated clock is the following:

The relationship generated by above command is:

createObstruction(name, column1, row1, column2, row2)

This method is used to create an obstruction object which will be removed from nxmap resources for Place & Route steps.

Arguments:

Name	Type	Description
name	string	defines the name of the aperture
column1	unsigned	the obstruction first abscissa. A valid abscissa value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row1	unsigned	the obstruction first ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.
column2	unsigned	the obstruction second abscissa. A valid abscissa value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row2	unsigned	the obstruction second ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.

Example:

createRegion(name, column1, row1, column2, row2, exclusive)

This method is used to create a region among the FPGA resources where HDL elements will be placed during Place step.

Arguments:

Name	Type	Description
name	string	defines the name of the region
column1	unsigned	the region first abscissa. A valid abscissa value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row1	unsigned	the region first ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.
column2	unsigned	the region second abscissa. A valid abscissa value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row2	unsigned	the region second ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.
exclusive	boolean	set if the region is exclusive

Example:

createSimulator()

This method is used to create a simulator object. A simulator object is used to simulate the project with a specified testbench.

This method takes no argument.

This method returns an object of class Simulator.

Example:

destroyObstruction(name)

This method is used to destroy a given obstruction object.

Arguments:

Name	Type	Description
name	string	the name of the obstruction to be destroyed

Example:

destroyRegion(name)

This method is used to destroy a given region.

Arguments:

Name	Type	Description
name	string	the name of the region to be destroyed

Example:

developCKGs()

This method automatically creates a generated clock constraint on each output of the PLLs and WFGs in current project.

This constraint is used by timing driver algorithms and static timing analysis. This method takes no argument.

Ecample:

destroy()

This method is used to destroy the project.

This method takes no argument.

Example:

Output:

display()

This method is used to open current project in nxmap graphic user interface. It can be called several times from the same Python script.

This method takes no argument.

Example:

exportAsIPCore(file, options)

This method is used to export the synthesized design to an IPCore. An IPCOre is a HDL description (at NX components level) that can be given as part of new source design to nxmap.

The export is different from the save() method as it is done during the second step of synthesis.

Arguments:

Name	Type	Description
file	string	path of the output file can be absolute or relative to the directory of the project.
options	dictionary	dictionary that contains optional configuration

The options dictionary must contain at least the coreName key. The following keys are available:

Name	Description
coreName	the name of the top entity in the IPCore (default is top cell name during synthesis)
obfuscate	if set to ‘Yes’, the generated code is obfuscated (default is ‘No’)
encrypt	used to encrypt the generated file using IEEE P1735 standard. If set to ‘None’, the file is not encrypted, otherwise it is and the value corresponds to the software targeted: ‘NX’: to reuse file in nxmap ‘MGC’: to reuse file in QuestaSim ‘All’: to reuse the file in nxmap and / or QuestaSim
author	author information used in the encrypted file header
license	license information used in the encrypted file header

Example:

exportRegions()

This method is used to export all constrainModule constraints in the console. It can be useful if the user modified the region location or size and want to get new constraints to copy them in the script.

Example:

exportSites(projectVariable,fileName)

This method is used to export all setSite constraints in a file. It can be useful in order to keep all TILE locations.

Name	Type	Description
projectVariable	string	the name of the project variable (usually ‘p' or 'project’).
fileName	string	file name to generate constraints into.

Example:

generateBitstream(file)

This method is used to save the bitstream configuration file to disk. The extension of the target file must be .nxb

Arguments:

Name	Type	Description
file	string	path of the output file can be absolute or relative to the directory of the project.

Example:

generateSTANetlist(filePath,condition)

This method is used to generate routed netlist and SDF file.

Arguments:

Name	Type	Description
filePath	string	path of the output file without extension

Example:

setDeviceID(id)

This method is used to change the Device ID in the bitstream header before generating it.

Arguments:

Name

Type

Description

id

integer

id value in decimal in the range [0;15].

Value 0 is the default Device ID.

Value 15 is the broadcast mode.

Example:

getDirectory()

This method returns the project current directory. This directory is used as root for all relative paths passed as argument of generic functions and/or methods. The default value of the directory is the current working directory.

This method takes no argument.

Example:

getLowskewSignals(ignoreTop, showCandidates)

This method is used to get lowskew signals or potential candidates to be lowskew signals. It gives a table of impacted lobes for each lowskew signal

Arguments:

Name	Type	Description
ignoreTop	boolean	ignore top level instances in fanout count.
showCandidates	boolean	show candidates to be lowskew signals.

This method is used to write in registers during the generation of bitstream.

Arguments:

Name	Type	Description
command	string	name of the command register to write in.
value	string	value to be write in the command register (in hexadecimal format).

Example:

limitLowskew(signal, lobes)

This method is used to limit a lowskew signal to be used in only specified lobes.

Arguments:

Name	Type	Description
signal	string	name of the signal.
lobes	string	list of specified allowed lobes for the lowskew signals. Lobes must be separated by “,” character

Example:

listAvailableLocations(name)

This method is used to print all available pads for a bank or for all banks of a variant .

Arguments:

Name	Type	Description
name	string	name of the IO bank.

Example:

load(file)

This method is used to load a previously saved project from disk. The input format (file extension) must be .nym (nxmap archive).

Arguments:

Name	Type	Description
file	string	nxmap archive file (extension must be .nym).

Example:

modifyRegion(name, column1, row1, width, height, exclusive)

This method is used to modify the location or the size of an existed region.

Arguments:

Name	Type	Description
name	string	name of the region.
column1	integer	the number of the most left column of the region.
row1	integer	the number of the most top row of the region.
width	integer	the width of the region (in number of columns).
height	integer	the height of the region (in number of rows).
exclusive	boolean	region is exclusive or not

Example:

place()

This method is used to run the place algorithm on a project.

This method takes no argument.

Example:

progress(step, number)

This method allows to progress through project to a given flow step.

Arguments:

Name	Type	Description
step	string	name of the global step [Synthesis, Place or Route].
number	unsigned	number in the global step [(1 to 2), (1 to 5) or (1 to 3)]. Synthesize step takes (1 to 2) for number, Place step takes (1 to 5) and Route step takes (1 to 3) for number.

Example:

rejectLowskew(signal)

This method avoids local lowskew signal to be converted in global lowskew signal.

Arguments:

Name	Type	Description
signal	string	name of the signal.

Example:

removeFile(libName, filePath)

This method allows to remove a file from a project.

Arguments:

Name	Type	Description
libName	string	name of the library. Default is work.
filePath	string	path to the file.

Example:

removeFiles(libName, fileList)

This method allows to remove files from a project.

Arguments:

Name	Type	Description
libName	string	name of the library. Default is work.
fileList	list	list of files.

Example:

reportDesignComplexity(html_file)

This method reports the design complexity, clock domain by clock domain, indicating the logic depth for all paths of the design and illustrates it with a chart in HTML format:

Name	Type	Description
html_file	string	output HTML file name.

Example:

The output HTML file looks like:

reportInstances()

This method reports the instances utilization of the programmed design on the current variant. Three tables are printed. The first one contains values for all types of instances. The instances are grouped by categories:

4-LUT	Look up table with a maximum of 4 connected entries

DFF	DFF register
X-LUT	"X-LUT" as defined in datasheet
4-Bits Carry	"4-bits carry look ahead" as defined in datasheet
Register file block	"Register files" as defined in datasheet
Cross domain clock	A two "DFF" pipeline optimized for metastability problem
Clock switch	Elements which logically interrupt a clock without shortening current cycle
Digital signal processor	"DSP" as defined in datasheet
Memory block	"Memory" as defined in datasheet
WFG	"WFG" as defined in datasheet
PLL	"PLL" as defined in datasheet

The second table gives more details about 4-LUTs utilization:

Synthesized from HDL	Number of LUTs that have been instantiated from the design
Used by DFF	Number of LUTs that are used by DFFs
Used by CY	Number of LUTs that are occupied by Carrys
Used by RF	Number of LUTs that are occupied by RFs
Used by CKS	Number of LUTs that are occupied by CKSs
Used by Internal	Number of LUTs created while processing the design to solve architectural constrains
Used by Total	Total number of LUTs NOT instanciated from the design
4-LUT count	Overall use of 4-LUT for the current design

The last table gives detailed information about the use of registers:

SFE	Number of DFF registers used by LUTs
Carry	Number of DFF registers used by Carries
DFF sub-total	Total count of DFF registers
CKS	Number of registers used in CKSs
RF	Number of registers used in RFs
DSP	Number of registers used in DSPs
RAM	Number of registers used in RAMs
Pads	Number of DFFs merged in pads
Total	Overall use of registers for the current design

This method takes no argument.

Example:

Output:

reportLowskewSignals(logfile)

This method reports the lowskew signals:

Name	Type	Description
logfile	string	path to the logfile to report (without .log extension).

Example:

reportPorts()

This method reports the ports found in HDL source and the ones manually added by user in the project. The report displays the following information:

Name	Name of the HDL port
Direction	Direction of the port (can be input, output or inout)
Location	Pad location associated to the port (can be set by the user or automatically set by nxmap)
Type	Type of the associated pad
SlewRate	Slew rate value of the associated pad
InputDelayLine	Input delay line of the associated pad
OutputDelayLine	Output delay line of the associated pad
Differential	True if the associated pad is in differential mode
Turbo	True if the associated pad is in turbo mode

This method takes no argument.

Example:

reportRegions()

This method reports occupied resources by HDL elements within every region created in the FPGA.

This method takes no argument.

Example:

The report displays the amount and percentage placed in the created region:

resetTimingConstraints()

This method is used to reset all timing constraints for current project.

This includes clocks, generated clocks, derived clocks of PLLs and WFGs, input delays, output delays, clock groups, case analysis, false paths, multicycle paths, min delay paths and max delays paths.

This method takes no argument.

Example:

route()

This method is used to run the route algorithm on a project.

This method takes no argument.

Example:

save(file,conditions)

This method is used to save the current project into a nxmap archive (.nym), a design netlist (.v or .vhd) or to generate a sdf file containing delays of the design supporting bestcase, worstcase and typical scenarios.

Arguments:

Name	Type	Description
file	string	Target file (extension must be .nym, .v, .vhd or .sdf )
conditions	string	STA environment conditions. Only for SDF generation.

Example:

setAnalysisConditions(conditions)

This method is used to specify the chip conditions for static timing analysis.

This constraint is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
conditions	string	the command which specifies the conditions for static timing analysis.

Example:

setAperture(column1, row1, column2, row2)

This method is used to define the size of aperture. The default size value is bounded to the Fabric dimensions.

Arguments:

Name	Type	Description
column1	unsigned	the aperture first abscissa. A valid abscissa value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row1	unsigned	the aperture first ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.
column2	unsigned	the aperture second abscissa. A valid abscissa value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row2	unsigned	the aperture second ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.

Example:

setCaseAnalysis(value, net_list)

This method is used to specify a constant logic value to the given tests.

This constraint is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
value	unsigned	the valid constant values are 0 or 1
net_list	string	the command which specifies how to get one or several nets. A valid command can be: getNet(net_name), getNets(net_name_expression), getPort(port_name), getPorts(port_name_expression)

setClockGroup(group1_list, group2_list, option)

This method is used to specify which clocks are not related. This constraint is used by timing driver algorithms and static timing analysis.

Arguments:

Name	Type	Description
group1_list	string	the command which specifies how to get a group of clocks. A valid clock should be a clock created by command "createClock". A valid command can be: getClock(clock_name) and getClocks(name_expression).
group2_list	string	same as the argument "group1_list"
option	string	a valid option can be 'asynchronous' or 'exclusive': Asynchronous clocks are those that are completely unrelated. Exclusive clocks are not actively used in the design at the same time

Example:

setDescription(description)

This method is used to set a description to a project.

Arguments:

Name	Type	Description
description	string	description of the project.

Example:

setDirectory(directory)

This method is used to change project directory.

Arguments:

Name	Type	Description
directory	string	new directory path of the project.

Example:

setFocus(column, row)

This method is used to specify the position of the focus for the whole design or just a region.

Arguments:

Name	Type	Description
column	unsigned	the focus abscissa. A valid ordinate value must respect the tile or CGB column coordinate which is available for the selected target variant in the current project.
row	unsigned	the focus ordinate. A valid ordinate value must respect the tile or CGB row coordinate which is available for the selected target variant in the current project.

Example:

setGCKCount(count)

This method is used to limit the number of GCK at the end of Placing step 2.

Arguments:

Name	Type	Description
count	integer	maximum value of GCK.

Example:

setInputDelay(clock, clock_mode, minimum_delay, maximum_delay, port_list)

This method specifies the data arrival times at the specified input ports relative to the clock. The clock must refer to a clock name in the design. This constraint is used by timing driven algorithms and static timing analysis.

Arguments:

Name	Type	Description
clock	string	the command which specifies how to get a clock specified. A valid clock should be a clock created by command "createClock". A valid command: getClock(clock_name).
clock_node	string	specifies that input delay is relative to the falling or rising edge of the clock. It must be "rise"' or "fall".
minimum_delay	integer	applies value as minimum data arrival time.
maximum_delay	integer	applies value as maximum data arrival time.
port_list	string	the command which specifies how to get a list of input pads. A valid command can be: getPort(port_name), getPorts(name_expression).

Example:

setOption(name, value)

This method is used to set the value of a nxpython option. An option can be set at any time of the design flow.

Arguments:

Name	Type	Description
name	string	the name of the option
value	string	the value of the option

The available options are:

Name	Default	Description
'Autosave'	'Yes'	Enable automatic protect save after each flow step.
'BypassingEffort'	'Medium'	Specify the DFF load and reset spreading level into the low-skew network (can be 'Low', 'Medium' or 'High'): Low: all Load and Resetare sent in low skew Medium: NXmap choose an effective balance High: all Load and Reset are routed in common parts ( high routing constraint)
'CongestionEffort'	'High'	Specify the routing resources limit per tile (can be 'Low', 'Medium' or 'High'): Low : less routing constraints but may need further more tiles and CGBs Medium : balanced routing constraints but may need more tiles and CGBs High : all routing resources
'Dynamic'	'No'	Refresh view while algorithms are running.
'DefaultFSMEncoding'	'OneHot'	Default encoding of finite state machine (can be 'OneHot', 'OneHotSafe', 'OneHotSafeExtra' or 'Binary'): OneHot: only one bit changes per state OneHotSafe: detects invalid state where all bits are ‘0’ and returns to others case OneHotSafeExtra: detects invalid combinations where there is more than one bit to ‘1’ at a time
'DefaultRAMMapping'	'AUTO'	Default mapping of RAM (can be 'AUTO', 'RF', 'RAM' or 'RAM_ECC').
'DefaultROMMapping'	'AUTO'	Default mapping of ROM (can be 'AUTO', 'LUT', 'RF', 'RAM' or 'RAM_ECC').
'DensityEffort'	'Low'	Specify the instance resources allowed per tile (can be 'Low', 'Medium' or 'High'): Low: less resources (less routing constraints but may need more tiles and CGBs) Medium: well suited resources High: more resources (more routing constraints)
'DisableAdderBasicMerge'	'No'	Disable carry optimization around adders and subtractors.
'DisableAdderTreeOptimization'	'No'	Disable adder mux reordering and adder tree balancing.
'DisableAdderTrivialRemoval'	'No'	Disable simplification of adder that could fit in 1 or 2 LUTs.
'DisableAssertionChecking'	'No'	Deactivate VHDL assertions.
'DisableDSPAluOperator'	'No'	Disable merge of ALU within inferred DSP.
'DisableDSPFullRecognition'	'No'	Disable inference of DSP.
'DisableDSPPreOperator'	'No'	Disable merge of pre-operator within inferred DSP.
'DisableDSPRegisters'	'No'	Disable merge of registers within inferred DSP.
'DisableKeepPortOrdering'	'No'	Disable keep port ordering used in source files when generating HDL netlists.
'DisableLoadAndResetBypass'	'No'	Disable load and reset signal bypass on DFF.
'DisableRAMAlternateForm'	'No'	Disable recognition of registered address read port.
'DisableROMFullLutRecognition'	'No'	Disable merge of ROM recognized as LUT with logic.
'DisableRAMRegisters'	'No'	Disable merge of registers within inferred RAM.
‘ExhaustiveBitstream’	‘No’	Can be used to force generation of all configurations and contexts in bitstream (can be ‘No’, ‘Config’, ‘Context’ or ‘ConfigContext’).
'GenerateBitstreamCMIC'	'No'	Generate bitstream with CMIC.
'IgnoreRAMFlashClear'	'No'	Do not output error when recognizing a RAM with flash clear.
'ManageAsynchronousReadPort'	'No'	If 'Yes', detect asynchronous read port in memories and repair it in synchronous read port. The read port receive the reversed write clock. It can slow down the design and sometimes may cause invalid behavior.
'ManageUnconnectedOutputs'	'Error'	Undriven outputs of HDL modules are treated as 'Error', 'Ground' or 'Power'.
'ManageUnconnectedSignals'	'Error'	Undriven internal signals of HDL modules are treated as 'Error', 'Ground' or 'Power'.
'ManageUninitializedLoops'	'No'	Remove reset-less looped DFF causing extra-mapping and 'X' values in simulation (can be 'No', 'Power, ''Ground').
'MappingEffort'	'Low'	Effort for an optimized mapping (can be 'Low', 'Medium' or 'High'): Low: almost no optimization Medium: balanced optimizations High: almost all optimizations
'MaxRegisterCount'	'2500'	Maximum number of registers handled per HDL module (not the whole design) by the synthesizer.
‘OptimizedMux’	‘Yes’	If set to 'Yes', nxmap will identify and convert every mux in the corresponding optimized 4-LUT structure.
'PartitioningEffort'	'Medium'	Define the size of the netlist subset which will be further optimized for timing goals achievement (can be 'Low', 'Medium' or 'High') : Low: small part Medium: medium part · High: huge part
'PolishingEffort'	'Medium'	It allows to regenerate locally a signal in TILE which in normal way should be provide by an others TILE in order to reduce utilization of routing resources. Low: deactivate Medium: can replicate LUT High: can replicate LUT and DFF
'ReadyOffWithSoftReset'	‘Yes’	Only available for NG-ULTRA variant. It links the ready falling edge to soft reset enabling during the power off reset sequence.
‘ReplicationApproval’	‘Yes’	Allow replication in a close TILE if not possible in the current TILE. No: Do not allow replication Yes: Allow replication
'RoutingEffort'	'Medium'	Routing Optimization level (can be 'Low', 'Medium' or 'High'): Low: no optimization Medium: balanced optimizations High: further optimizations but time consuming
‘Seed’	‘1789’	Seed for placing algorithm start. Depending on the seed, instances are created in a different order and placed so. Can be used in order to generate several Place & Route with the same synthesized project.
‘SimplifyRegions’	‘Yes’	Clear module and region database: delete modules without instance delete regions without module merge identical regions
‘SytemOutputDriven’	'No'	Increase placing close to the ring for instances communicating with. No: No priority for these instances in algorithm Yes: Allow priority for these instances in alogrithm
'TimingEffort'	‘High’	Indicates level of iterations for TimingDriven algorithm. Low: no iteration Medium: a few iteration High: more iterations
'UnusedPads'	'Floating'	State in which the pads must be set when not used. Values can be 'Floating','WeakPullUp', 'WeakPullDown'. Note that when the state is different from 'floating', all the pads are serialized in the bitstream. Note that ‘WeakPulldown’ value is not available on NX1H35S component.
‘VariantAwareSynthesis’	‘Yes’	If set to ‘Yes’ synthesis will automatically map to equivalent resource when specific resource is depleted. For example using DSP when there are no more CY available (can be ‘Yes’ or ‘No’).

Some options can affect only specific processes of the design flow. Following, a table of the specific processes per options:

Name	Synthesize	Place	Route	Bitstream
'Autosave'	X	X	X	X
'BypassingEffort'		X
'CongestionEffort'		X
'Dynamic'		X	X
'DefaultAssertionChecking'
'DefaultFSMEncoding'	X
'DefaultRAMMapping'	X
'DefaultROMMapping'	X
'DensityEffort'		X
'DisableAdderBasicMerge'	X
'DisableAdderTreeOptimization'	X
'DisableAdderTrivialRemoval'	X
'DisableAssertionChecking'	X
'DisableDSPAluOperator'	X
'DisableDSPFullRecognition'	X
'DisableDSPPreOperator'	X
'DisableDSPRegisters'	X
'DisableKeepPortOrdering'	X
'DisableLoadAndResetBypass'	X
'DisableRAMAlternateForm'	X
'DisableRAMRegisters'	X
'DisableROMFullLutRecognition'	X
‘ExhaustiveBitstream’				X
'GenerateBitstreamCMIC'				X
'IgnoreRAMFlashClear'	X
'ManageAsynchronousReadPort'	X
'ManageUnconnectedOutputs'	X
'ManageUnconnectedSignals'	X
'ManageUninitializedLoops'	X
'MappingEffort'	X
'MaxRegisterCount'	X
‘OptimizedMux’	X
'PartitioningEffort'		X
'PolishingEffort'		X
'ReadyOffWithSoftreset'				X
‘ReplicationApproval’		X
'RoutingEffort'		X
‘SimplifyRegions’		X
‘SystemOutputDriven’		X
‘TimingEffort’		X
'UnusedPads'				X
‘VariantAwareSynthesis’	X

Example:

setOptions(options)

This method allows user to set the values of several nxpython options. The options can be set at any time of the design flow.

Arguments:

Name	Type	Description
options	dictionary	the keys of the dictionary are the options names and the values are the options values.

For a list of all available options, see setOption(name, value)

Example:

setOutputDelay(clock, clock_mode, minimum_delay, maximum_delay, port_list)

This method specifies the data arrival times at the specified output ports relative to the clock. The clock must refer to a clock name in the design. This constraint is used by timing driven algorithms and static timing analysis.

Arguments:

Name	Type	Description
clock	string	the command which specifies how to get a clock specified. A valid clock should be a clock created by command "createClock". A valid command can be: getClock(clock_name).
clock_mode	string	specifies that output delay is relative to the falling or rising edge of the clock. It must be "rise"' or "fall".
minimum_delay	integer	applies value as minimum data arrival time.
maximum_delay	integer	applies value as maximum data arrival time.
port_list	string	the command which specifies how to get a list of output pads. A valid command can be: getPort(port_name), getPorts(name_expression).

Example:

setSite(instancePattern, siteName)

This method is used to place a set of register/LUT/Carry instances into a specific TILE site.

This method returns a Boolean value:

If too many instances have been given with instancePattern, setSite returns false
If instances given with instancePattern have been placed successfully, setSite returns true

Arguments:

Name	Type	Description
instancePattern	string	the pattern of the instances.
siteName	string	the name of the site. Must be a TILE element.

Example:

setTopCellName([library], name)

This method is used to set the name of the HDL top module. If the HDL module is defined inside a library, the name of the library can be passed as the first argument.

Arguments:

Name	Type	Description
library	string	name of the HDL library that contains the top module.
name	string	name of the HDL top module.

Example:

setVariantName(variant)

This method is used to set the variant of the project. The default value of the variant is 'NG-MEDIUM'.

Arguments:

Name	Type	Description
variant	string	the name of the variant.

Example:

synthesize()

This method is used to synthesize the HDL source files and realize the technology mapping against nxpython library.

This method takes no argument.

This method uses the following options:

'MappingEffort',
’MaxRegisterCount',
'MergeRegisterToPad',
'DefaultFSMEncoding',
'AdderToDSPMapThreshold',
'ManageUnconnectedOutputs',
'ManageUnconnectedSignals'

This method also uses all the blackboxes and mapping directives set.

Example:

translateAperture(regionName,horizontal,vertical)

This method is used to move the aperture of a region or of the whole design.

Arguments:

Name	Type	Description
regionName	string	the name of the region.
horizontal	integer	number of columns for translation.
vertical	integer	number of rows for translation.

Example:

Static Timing Analysis related methods

This section presents the methods related to the analyzer object. The object controls the static timing analysis.

destroy()

This method is used to destroy the analyzer object.

This method takes no argument.

Example:

launch(parameters)

This method is used to run the static timing analysis.

The analyzer computes a maximum of 'searchPathsLimit' paths for each domain, considering only the paths which slack is less than or equal to 'maximumSlack'.

Temperature and voltage can also be supplied to adjust timing values.

When not given, the parameters take their default values.

Arguments:

Name	Type	Description
parameters	dictionary	Keys are the names of the parameters to set (see following table), values must match the type specified.

Available Parameters:

Name	Type	Description (Default value in bold)
searchPathLimit	unsigned	maximum number of paths computed for each domain. (default value is 10)
maximumSlack	integer	maximum reportable slack in ps. (default is unlimited)
conditions	string	‘bestcase’ : Voltage = typical core voltage + 0.1V Temperature = -40°C 'typical’ : Voltage = typical core voltage Temperature = 25°C ‘worstcase’ : Voltage = typical core voltage - 0.1V Temperature = 125°C

Example:

Launching timing analyzer steps

Step 1, Creating Analyzer:
If a targeted design is already routed, user can launch static timing analysis by creating a timing analyzer. The analyzer can be created using the following command:

Step 2, Launching Static Timing Analysis:
Static Timing Analysis can be launched using the following command:

Please check the previous section launch(parameters) for more information on how to use the launch() function.

Step 3, Generating Static Timing Analysis reports:
In nxpython, a number of reports (.timing) can be produced presenting the results in the form of timing domains, critical paths, violation details, etc... The explanation of these reports can be found in the section Timing reports.

Example:

launch(graphical)

This method is used to run the simulation.

To run the simulation, the simulator object must be fully initialized. You must at least have specified the testbench files and the testbench top cell.

The simulation is launched on a netlist representing the current state of the project.

Arguments:

Name	Type	Description
graphical	boolean	Specify if the vsim GUI should be launched or not.

Example:

setDuration(duration)

This method is used to set length in time of the simulation. If not specified (or set to ‘’), vsim will be launched with run -all.

Arguments:

Name	Type	Description
duration	string	Duration of the simulation.

Example:

setTestBenchTop(testBenchTop)

This method is used to set the top cell name of the testbench.

Arguments:

Name	Type	Description
testBenchTop	string	Top cell of the testbench.

Example:

setWorkingDirectory(workingDirectory)

This method is used to set the working directory of the simulation

Arguments:

Name	Type	Description
workingDirectory	string	Working directory, relative to the project directory.

Example:

Argument related methods

getClock(clock_name)

This argument method is used to get the clock from a given clock name. A valid clock should be a clock created by command createClock.

Arguments:

Name	Type	Description
clock_name	string	the name of the clock used to get the valid clock.

Example:

getClockNet(clock_net_name)

This argument method is used to get the net from a given clock net name. It is used by createClock method to specify a clock related point as argument.

Arguments:

Name	Type	Description
clock_net_name	string	the name of the net clock. The path must be set entirely.

Example:

getClocks(clock_name_expression)

This argument method is used to get the clocks from a given clock name expression. A valid clock should be a clock created by command createClock.

Arguments:

Name	Type	Description
clock_name_expression	string	the name expression of the clock used to get the list of clocks.

Example:

getInstances(intance_name)

This argument method is used to get the instances from an instance name. It can be used by some nxpython methods (addMappingDirective, addMemoryInitialization).

Arguments:

Name	Type	Description
instance_name	string	the name of the instance used to get the valid instance. All regular expressions are allowed and special characters must be escaped.

Example:

getModels(model_name)

This argument method is used to get the models from a model name. It can be used by some nxpython methods (addMappingDirective, addMemoryInitialization).

Arguments:

Name	Type	Description
model_name	string	the name of the model used to get the valid model. All regular expressions are allowed and special characters must be escaped.

Example:

getPort(port_name)

This argument method is used to get the port from a given port name. Some nxpython methods need a port as argument.

Arguments:

Name	Type	Description
port_name	string	the name of the port used to get the valid port. The path must be set entirely.

Example:

getPorts(port_name_expression)

This argument method is used to get the ports from a given port name expression. Some nxpython methods need a list of ports as argument.

Arguments:

Name	Type	Description
port_name_expression	string	the name expression of the port used to get the list of ports.

Example:

getRegister(register_name)

This argument method is used to get the register from a given register name. Some nxpython methods need a register as argument.

Arguments:

Name	Type	Description
register_name	string	the name of the register used to get the valid register. The path must be set entirely.

Example:

getRegisterClock(register_name)

This argument method is used to get the register clock from a given register name. Some nxpython methods need a clock as argument.

Arguments:

Name	Type	Description
register_name	string	the name of the register used to get the valid clock.

Example:

getRegisters(register_name_expression)

This argument method is used to get the registers from a given register name expression. Some nxpython methods need a list of registers as argument.

Arguments:

Name	Type	Description
register_name_expression	string	the name expression of the register used to get the list of registers. All regular expressions are allowed and special characters must be escaped.

Example:

getRegistersByClock(clock_name)

This argument method is used to get all the registers from the same clock domain. Clock must be created before.

Arguments:

Name	Type	Description
clock_name	string	the name of the created clock.

Example:

getWFGOutput(wfg_name)

This argument method is used to get the wfg clock from a given wfg name. Some nxpython methods need a clock as argument.

Arguments:

Name	Type	Description
wfg_name	string	the name of the wfg used to get the valid clock.

Example:

Full script example:

This chapter presents the full Python script of the provided VHDL 'simple' example.

Example:

Timing Analysis

Timing path

Timing path is the connection between two certain nodes in the design i.e. connection between primary input and output ports, connection between primary input ports/clock pins and data input pins of the sequential elements, and connection between intermediate clock pins and primary output ports.

Data delay

In nxmap, data delay is the delay of a timing path. For example, the delay between the launch edge of the clock at the source register and data input pin of the destination register. In following picture, the path for the data delay between source register DFF1 and destination register DFF2 is shown in blue.

Clock skew

Clock skew is the difference between the latch clock delay at the destination register and launch clock delay at the source register. Considering the example shown in previous figure, clock skew is calculated as follows:

Setup/Hold time

Setup time is the minimum amount of time required for a signal to be held stable before the clock transition.

Hold time is the minimum amount of time required for a signal to retain its value after the clock transition. In nxmap, the analysis of setup/hold time is performed in order to calculate the data arrival time which will be explained shortly.

Recovery/Removal time

Recovery time is the minimum amount of time required for an asynchronous control signal to be held stable after its de-assertion before the next active clock edge. The recovery time calculation corresponds to the setup time calculation but for the asynchronous control signals i.e. reset.

Similarly, removal time is the minimum amount of time for an asynchronous signal to be held stable before its de-assertion after the previous active clock edge. The removal time calculation corresponds to the hold time calculation but for the asynchronous signals.

Timing domain

In nxmap, the term ‘domain’ is used to define a group of certain timing paths. As mentioned earlier, the timing paths include the connection between primary input and output ports, connection between primary input ports/clock pins and data input pins of the sequential elements, and connection between intermediate clock pins and primary output ports.

Depending on the initial and terminal nodes of the timing path, a number of timing domains can be defined in a design. Paths having a common clock signal at the source node as well as a common clock signal at the destination node are considered to be in the same domain. Also, the primary input and output ports connected by combinatorial logic are considered to be in the same domain.

For example in following figure, three domains D1, D2 and D3 are shown between input and clock "clk" (D1: input to clk), between clock "clk" of source registers and clock "clk" of destination registers (D2: clk to clk), and between clock "clk" and output (D3: clk to output) respectively.

Data arrival time

In nxmap, data arrival time includes the overall data delay, clock skew and setup/hold time (recovery/removal) for a critical timing path in a domain. Based on the setup/hold verification, data arrival time can be either maximum or minimum. In both cases, data arrival time is calculated as follows:

Setup/Recovery, Hold/Removal time relationship

The transfer of data signal from one sequential element to another requires certain timing checks for correct functionality. It involves hold and setup time verification with respect to launch and latch edge of the clock at the source and destination sequential element respectively.

Launch edge is the active clock edge at which data is sent from a source sequential element. Latch edge is the active clock edge at which the destination sequential element captures the data coming from the source.

Between launch and latch clock, hold and setup time relationship is established which it is essentially the delay between the active edges of these clocks. This relationship is then used to determine positive or negative slack, validating the timing characteristics of the paths in the domain. Following are all the four cases of the active launch and latch clock edges.

Case 1

If both launch and latch clocks have active high edge, hold relationship is established between the current launch edge and the previous or current latch edge ensuring that the data is not captured by the latch edge coming before the launch edge. Similarly, setup relationship is established between the launch edge and the next latch edge ensuring that the data is captured by the latch edge coming after the launch edge.

Inthe following figure, hold and setup relationship is shown between a launch and latch clock with no skew. In case of having different frequencies for launch and latch clock, hold relationship is established between the active launch and latch edges with the minimum difference. Thus, hold relationship gives the minimum delay allowed between launch and latch edges. Whereas, the setup relationship is established between launch and latch edges with minimum difference, hence giving the maximum allowed delay between launch and latch edges.

Case 2

If launch and latch clocks have active high and active low edges respectively, in this case hold relationship is established between active high launch edge and the previous active low latch edge with the minimum difference. Similarly, setup relationship is established between launch edge and the next latch edge with the minimum difference.

The following figure shows hold and setup relationship between active high launch clock and active low latch clock.

Case 3

For the active low launch clock and active high latch clock, the hold relationship gives the minimum delay between active low launch edge and previous active high latch edge. Similarly, setup relationship gives the minimum delay between the active low launch edge and the very next active high latch edge as shown in the following figure.

Case 4

If both launch and latch clocks have active low edges, the hold relationship is established between active low launch edge and previous active low latch edge. Similarly, setup relationship is established between the active low launch edge and the very next active low latch edge as shown in the following figure.

Slack calculation

In nxmap, setup/recovery slack corresponds to the difference between maximum setup/recovery relationship and maximum data arrival time whereas hold/removal slack corresponds to the difference between minimum data arrival and minimum hold/removal relationship.

Timing reports

In nxmap and nxpython, timing analyzer generates a set of reports presenting respectively the summary of analysis, critical paths of each domain, and violation information. All the timing reports are automatically saved in files (.timing) in ‘logs’ directory after a successful analyzing of the routed design.

STA summary

The file "Summary.timing" contains the report of the timing domains as well as hold/removal and setup/recovery summaries in the design. Such domains are grouped by categories:

Domain

Source (beginning of the domain)

Target (ending of the domain)

Frequency

Required (restricted frequency set by 'createClock' method)

Maximum (computed frequency)

Hold/Removal Summary

Slack

Minimum Data Arrival Time

Minimum Required Relationship

Maximum (computed frequency)

Setup/Recovery Summary

Slack

Maximum Data Arrival Time

Maximum Required Relationship

A domain whose source and target registers are driven by defined clocks or driven by the same clock is conceded as synchronous by default. For the Synchronous domains the required relationship can be established for timing verifications. In the case of hold/removal timing verification, the slack represents the difference between the minimum data arrival time and the minimum required relationship.

Similarly, in the case of setup/recovery timing verification, the slack represents the difference between maximum required relationship and maximum data arrival time. For the domains whose source and target registers are driven by the same undefined clock, the required relationships can't be established before analysis. In this case, the minimum required hold/removal relationship is considered as 0ps whereas maximum arrival time is considered as the maximum required setup/recovery relationship.

Generally, a negative slack indicates a violation of timing check. However, in the case where the required hold/removal relationship can't be established (hence, minimum required relationship is 0ps), the negative slack does not fully indicate the violation as the minimum data arrival time is negative. Whereas in the case where the relationship exists, the negative data arrival time producing a negative slack would be a timing violation.

After timing analysis, critical paths for each domains are detailed in a set of timing domain reports (.timing) which are named with the same domains' names. In a domain report, there are three parts:

a summary of the presenting domain (similar to Summary.timing);
two lists of critical longest paths and shortest paths;
detailed tables of each found path.

Critical paths table

The critical paths tables show the lists of longest paths and shortest paths for the given timing domain of the design. The details of such critical paths include:

Slack
Source (beginning of the path)
Target (ending of the path)
Data Delay
Clock Skew
Setup/Recovery (longest only)
Hold/Removal (shortest only)
Depth
Note (falling/rising edges of launch and latch clocks)

Path detail

Following the critical paths table, all the listed critical paths are reported in detail. For each part of the path, the table contents the following information: source (beginning of the path), target (ending of the path), routing delay, internal delay, cumulated delay (from the source of the path), setup/recovery time (for data path), hold/removal time (for data path), clock skew (for data path).

Revision history

The following table shows the revision history of the NXmap3 user manual datasheet:

Date	Version	Revision
2020-04-02	3.0.1	Initial draft datasheet.
2020-12-18	3.0.3	Various corrections for IO names to respect ballout syntaxe now used in NXmap3 software.
2021-04-02	3.0.4	constrainPath() and constrainModule() descriptions introduced. Updated addPad() description to clarify the applications of several options and provide trade-off examples.
2021-07-23	3.0.5	addMappingDirective() supports the mapping of ADD into LUT. addPad() additional precisions: termination specified in Ohms within a range 30 to 80 weakTermination values ‘None’ and ‘PullUp’ not allowed for NG-MEDIUM setLogDirectory() function implemented. addFile() supports VHDL_93, VERILOG_95, VERILOG_2K language identifiers for synthesis through NXmap3. bestcase, worstcase and typical scenarios supported for sdf file generation. Overview of expected expression (full path, wildcard or regular expressions or for NXpython methods) is provided in section 5.2.2 List of NXpython methods expecting expressions.

NXpython specification

Table of figures

Copyright

Introduction

Package description

Installation

Run nxpython

Nxpython specification

Command list and context

General commands

createProject([workingDirectory])

getErrorCount()

getRemarkCount()

getWarningCount()

listOptions()

printError(message)

printRemark(message)

printText([message])

printWarning(message)

setCoreCount(core_count)

setDirAutoChange(change_project_dir)

change_project_dir

setLogDirectory(log_directory)

log_directory

usage()

version()

Expected expressions for NXpython methods

Impacted methods:

Maintainability:

User use:

Project related methods

addBank(name, dict)

addBanks(dict)

addBlackBox(name, type, mapping, interface)

addBlackBox() : for Preplaced IP

addDSPLocation(pattern, place)

addFalsePath(from_list, to_list)

addFile([library], file)

addFiles([library], fileList)

addIP(name)

addMappingDirective(name, type, mapping)

addMaxDelayPath(from_list, to_list, delay)

addMinDelayPath(from_list, to_list, delay)

addModule(model, instance, format)

addMulticyclePath(from_list, to_list, cycle_count)

addPad(name, parameters)

addPads(pads)

addPin(name, location)

addPins(pins)

addParameter(name, value)

addParameters(parameters)

addPLLLocation(pattern, location)

addRAMLocation(pattern, place)

addRingLocation(name, location)

addRingLocations(dictionary)

addVerilogIncludeDirectory(directory)

addVerilogIncludeDirectories(directoryList)

addVlogDefine(name,value)

addVlogDefines(dictionnary)

addWFGLocation(name, location)

adjustAperture(regionName, above, left, right, below)

applySdcFile(filePath)

clearBanks()

clearPLLs()

clearPads()

clearPins()

clearWFGs()

confineModule(name, region)

constrainModule(hierarchy, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

constrainPath(sourceList, targetList, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

createAnalyzer

createClock(target, name, period, [rising, falling])

createGeneratedClock(source, target, name, relationship)

createObstruction(name, column1, row1, column2, row2)

createRegion(name, column1, row1, column2, row2, exclusive)

createSimulator()

destroyObstruction(name)

destroyRegion(name)

developCKGs()

destroy()