NXpython specification

 

Table of figures

Hierarchy report providing user modules detection

Unused pattern reported due to incorrect addModule arguments

Output tables from reportInstances() method

Report region

Data and clock delay between a source and destination register

Examples of timing domains D1, D2, D3 in a simple design

Hold/Setup time relationship for active high launch and active high latch clocks

Hold/Setup time relationship for acitve high launch and active low latch clocks

Hold/Setup time relationship for active low launch and active high latch clocks

Hold/Setup time relationship for active low launch and active low latch clocks

Summary.timing example

Example 1 of critical paths table

Example 2 of critical paths table

Example of path detail table

 

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_*”), …)

 

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:

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:

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.

Example:

 

clearBanks()

clearBanks() method remove all bank specification previously added in the project.

This method takes no argument.

Example:

 

clearPLLs()

clearPLLs() method remove specification and location for PLLs previously added in the project.

This method takes no argument.

Example:

 

clearPads()

clearPads() method remove all inputs/outputs of the HDL module previously configured into specific pads of the FPGA.

This method takes no argument.

Example:

 

clearPins()

clearPins() method remove all inputs/outputs of the HDL module previously configured into specific pins of the embedded FPGA

This method takes no argument.

Example:

 

clearWFGs()

clearWFGs() method remove specification and location for WFGs previously added in the project.

This method takes no argument.

Example:

 

confineModule(name, region)

This method allows to confine a module into a user defined region of the FPGA.

Arguments:

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.

Example:

getTimingUnit()

This method returns the timing unit used in STA.

Example:

 

getTopCellName()

This method returns the name of the top HDL module. If the HDL module is defined inside a library, the name is prefixed by the name of the library followed by a # character.

This method takes no argument.

Example:

Output:

 

getVariantName()

This method returns the variant of the project. The default value of the variant is 'NG-MEDIUM'.

This method takes no argument.

Example:

Output:

 

initRegister(command, value)

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:

 

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.

This section presents the methods of the simulator object. This object controls the simulation of the design.

addTestBench([library], testBench)

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

Arguments:

Name

Type

Description

library

string

Name of the HDL library that contains the testbench file.

testBench

string

Testbench file relative to the project directory.

Example:

addTestBenchs([library], fileList)

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

Arguments:

Name

Type

Description

library

string

Name of the HDL library that contains the testbench file.

fileList

list

List of testbench files relative to the project directory.

Example:

 

addWave(wave)

This method is used to add a signal which will be displayed in vsim. It is also possible to add all the available waves by passing '*' as argument.

Arguments:

Name

Type

Description

wave

string

Name of the signal.

Example:

 

addWaves(wavelist)

This method is used to add several signals which will be displayed in vsim.

Arguments:

Name

Type

Description

waveList

list

List of signal.

Example:

destroy()

This method is used to destroy the simulator object.

This method takes no argument

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:

 

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.

© NanoXplore 2022