Impulse NXPython Specification
Table of Figures
Hierarchy report providing user modules detection
Unused pattern reported due to incorrect addModule arguments
Output tables from reportInstances() method
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
Example 1 of critical paths table
Example 2 of critical paths table
Copyright Notice
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 Impulse software through all the steps involved in the design flow and the options available in NanoXplore design suite:
impulse 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 impulse software as a wrapper. It fully supports Python syntax, structures and external modules.
The creation of a new project can be performed with both impulse 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 impulse 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 impulse, the user needs to unpack nxdesignsuite-VERSION.tar.gz file into the installation directory (e.g. /opt/NanoXplore) using the following command:
$> tar xzf nxdesignsuite-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/impulse/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
The table below list 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 |
|
|
|
|
|
addHSSLLocation |
|
|
|
|
|
|
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 |
|
|
|
clearFabricPrePlaceConstraints |
|
| 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 |
|
|
|
|
|
getAnalyzer | X |
|
|
|
|
|
getDirectory | X |
|
|
|
|
|
getErrorCount | X |
|
|
|
|
|
getHierInfo | X |
|
|
|
|
|
getLowskewSignals | X |
|
|
|
|
|
getProject | X |
|
|
|
|
|
getRemarkCount | X |
|
|
|
|
|
getTimingUnit | X |
|
|
|
|
|
getTopCellName | X |
|
|
|
|
|
getVariantName | X |
|
|
|
|
|
getWarningCount | X |
|
|
|
|
|
initRegister |
|
|
| X |
|
|
limitLowskew |
|
| X |
|
|
|
listAvailableLocations | X |
|
|
|
|
|
load | X |
|
|
|
|
|
modifyPad | X |
|
|
|
|
|
modifyRegion |
|
| X |
|
|
|
place | X |
|
|
|
|
|
progress | X |
|
|
|
|
|
printError | X |
|
|
|
|
|
printHierInfo | X |
|
|
|
|
|
printRemark | X |
|
|
|
|
|
PrintText | X |
|
|
|
|
|
PrintWarning | X |
|
|
|
|
|
rejectLowskew | X |
| X |
|
|
|
removeFile | X |
|
|
|
|
|
removeFiles | X |
|
|
|
|
|
removeSoftModules | 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 |
|
|
|
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 impulse 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 impulse 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 impulse 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 impulse output. This includes terminal output and log file if set. When no message is given, method prints a new line in the impulse 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 impulse output. This includes terminal output and log file if set. A warning message is prefixed by WARNING string so it can be easily found.
When using this method, the global number of warnings is incremented by 1.
Arguments:
Name | Type | Description |
message | string | warning message to print |
Example:
Output:
setCoreCount(core_count)
This function sets the number of core to use in multi-thread algorithm.
Minimum value is 1. The tool uses the number of logic cores of the computer as a maximum.
Arguments:
Name | Type | Description |
core_count | integer | core count number |
Example:
Output:
setDirAutoChange(change_project_dir)
This function allows to create a user-defined directory to stock the reports created during the execution of the flow.
Arguments:
Name | Type | Description |
change_project_dir | boolean | Change project directory when loading a project file when True (default). Keep the current project directory when False |
Example:
setLogDirectory(log_directory)
This function allows to create a user-defined directory to stock the reports created during the execution of the flow.
Arguments:
Name | Type | Description |
log_directory | string | Name of the directory to be created. |
Example:
Output:
usage()
This method displays application usage.
This method takes no argument.
Example:
Output:
version()
This method displays application version.
This method takes no argument.
Example:
Output:
Expected expressions for NXpython methods
NxPython methods get a standardized format for arguments expecting a path.
This section describes the expression format specific to NX.
Impacted methods:
The following methods allow regular expressions / wildcard formats in order to match with multiple instances:
· addDSPLocation
· addModule
· addRAMLocation
· constrainPath
· getInstances
· getModels
· getRegisters
· setSite
· …
Maintainability:
It is no longer necessary to escape (with the ‘\’ character) special characters for these methods.
Affected special characters are:
· ‘[‘
· ‘]’
· ‘(‘
· ‘)’
· ‘|’
For instance, the constraint:
addModule('timing_pipe\(X2A98C8C6\)', 'GEN_HIER0.GEN_COL[0].COL_PIPE', 'GEN_HIER0_COL-%')
can be replaced by:
addModule('timing_pipe(X2A98C8C6)', 'GEN_HIER0.GEN_COL[0].COL_PIPE', 'GEN_HIER0_COL-%')
However, the old format is still compliant and still operates.
User use:
In a usual way, a copy/paste of a path from a log file works for the constraint.
In addition, it is comfortable to use ‘*’ and ‘+’ characters to match several paths.
‘*’ matches with any character: can be very useful to match with all paths beginning with a specified path.
‘+’ matches with any character but ‘|’: can be very useful to match with all paths beginning with a specified path without matching with lower hierarchy levels.
Hereafter an example with existing paths and constraints:
Existing Path \ Path in constraint | start_path|mycell_* | start_path|mycell_+ |
start_path|mycell_12 | Match | Match |
start_path|mycell_12|some_sub_cell | Match | No match |
Note:
If the user needs to use regular expressions ignoring auto-escaping of special characters, it is possible to set the constraint using back quotes as follow:
addMappingDirective(getModels(“add_`[1-2][0-9]`u_*”), …)
Project related methods
This section presents the methods related to the project object.
addBank(name, dict)
The method addBank allows user to configure a specific bank of the FPGA. The pads inside the defined bank will be used first to configure inputs/outputs of the HDL module. For the given bank, the configuration has two basic arguments name and dict.
Arguments:
Name | Type | Description |
name | string | the name of the bank. The bank name must respect syntax of the various banks included in current FPGA variant. |
dict | dictionary | the dictionary of parameters of the bank. All keys and values of the dictionary are string. |
dict is a dictionary which can take the following keys:
Type | Description |
voltage | voltage of the bank (V) |
The voltage must be one of the following values:
1.5
1.8
2.5
3.3
Example:
addBanks(dict)
The method addBanks allows user to configure several banks of the FPGA to be used for configuration of inputs/outputs of the HDL module. addBanks use a dictionary as an argument.
Arguments:
Name | Type | Description |
dict | dictionary | the dictionary of banks. See addBank method for the list of available keys |
Example:
addBlackBox(name, type, mapping, interface)
The method addBlackBox allows users to define customized mapping of certain HDL modules on the specific FPGA blocks and to dispose the interface of the blocks.
Arguments:
Name | Type | Description |
name | string | the name of HDL module that is intended to be custom-mapped. |
type | string | the nxpython object type (further details below). |
mapping | string | the mapping target (further details below). |
interface | string | the interface mapping between HDL module and nxpython (further details below). |
The type argument can only be overridden for specific object types. The available types are:
Type | Description |
ROM | Represents a ROM |
RAM | Represents a RAM |
For each type, there are some specific instances in the FPGA onto which it can be mapped. This can be specified using mapping argument. The following table presents all the available mapping targets for each type:
Type | Mapping targets | Description |
ROM | RF, RAM | A ROM can be mapped onto RF blocks or RAM blocks |
RAM | RF, RAM, RAM_ECC | A RAM can be mapped onto register files (if not split read/write port) or RAM blocks or RAM blocks with error detection/correction code |
The argument interface argument specifies the interface mapping between the HDL module and nxpython.
Space character is not allowed in interface argument
When setting ROM value for type argument, the nxpython interface is:
Interface | Description |
AD | Address to read data from |
DO | Output data |
CK | Clock |
Used only when creating synchronous memory (with one clock)
When setting RAM value for type argument, the nxpython interface depends on the mode RAM is being used in:
RAM mode: Simple port
Interface | Description |
CK | Clock |
AD | Address |
DI | Input data |
DO | Output data |
WE | Write enable |
RE | Read enable (optional) |
RAM mode: Split read/write port (1 port for read and 1 port for write)
Interface | Description |
CK0 | Read clock |
AD0 | Read address |
DO0 | Read output data |
RE0 | Read enable (optional) |
CK1 | Write clock |
AD1 | Write address |
DI1 | Write input data |
WE1 | Write enable |
RAM mode: True dual port (2 ports for read/write)
First port:
Interface | Description |
CK0 | Clock |
AD0 | Address |
DI0 | Input data |
DO0 | Output data |
WE0 | Write enable |
RE0 | Read enable (optional) |
Second port:
Interface | Description |
CK1 | Clock |
AD1 | Address |
DI1 | Input data |
DO1 | Output data |
WE1 | Write enable |
RE1 | Read enable (optional) |
Example:
If the HDL design contains a micro code ROM define in VHDL as:
User can add a black box to force nxpython to recognize this module as a ROM.
addBlackBox() : for Preplaced IP
The idea is to offer the possibility to the user to reuse the result of an impulse flow as an IP in a top design.
For instance, the user will work on a design named IP with the desired performance.
The user can then reuse the result of this first flow in another design. named top, which instanciates the IP entity several times.
Impulse will use the result of synthesis and place from the first flow and replicate then in the top flow
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:
addHSSLLocation(pattern,location)
This method is used to set the spot in which a HSSL should be set.
Placement of HSSL elements can also be done during instantiation (with location generic in source code).add
Arguments:
Name | Type | Description |
pattern | string | A pattern to match the HSSL controller instance name. The path must be set entirely. |
location | string | the requested location for the HSSL block. Valid locations are HSSLn |
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:
addMemoryInitialization(name, type, file)
This method is used to specify a file that will be used to initialize a specific memory instance.
Arguments:
Name | Type | Description |
name | string | the name of the instance that is intended to be initialized from a file. |
type | string | the file format (further details below). |
file | integer | the name of the file to load (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 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 can use the wildcard operator '*'. See full details with an example.
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 depending on standard:
standard | differential |
LVDS | True (mandatory) |
LVDS_STR | True (mandatory) |
LVCMOS | False |
SSTL | True |
HSTL | True |
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 (only allowed for LVCMOS standard)
12mA (only allowed for LVCMOS standard)
16mA (only allowed for LVCMOS standard)
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, (Default is set to minimum value).
Min and max values depend on the variant and the bank voltage.
Voltage (V) | NG-MEDIUM | NG-LARGE | NG-ULTRA | |||
Rmin (Ω) | Rmax (Ω) | Rmin (Ω) | Rmax (Ω) | Rmin (Ω) | Rmax (Ω) | |
1.2 | X | X | X | X | 30 | 84 |
1.5 | X | X | X | X | 31 | 88 |
1.8 | 31 | 85 | 30 | 85 | 32 | 92 |
2.5 | 35 | 100 | 34 | 102 | X | X |
3.3 | X | X | X | X | X | X |
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:
| ‘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 CKGn.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:
clearFabricPrePlaceConstraints(regionName)
Clears all preplacing constraints for fabric elements. It removes the impact of the following constraints:
setSite
addRAMLocation
addDSPLocation
It gives the ability to clear all Fabric elements constraints and add new ones.
If no argument is set, constraints for the whole fabric are cleared.
Arguments:
Name | Type | Description |
regionName | string | Region Name. Optional 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 impulse 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 impulse 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 impulse.
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 impulse ‘MGC’: to reuse file in QuestaSim ‘All’: to reuse the file in impulse 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:
getAnalyzer()
This method returns the current analyzer associated to the project to manage STA.
This method takes no argument.
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:
getHierInfo()
This method returns the detailed hierarchy into a dictionary variable.
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:
getProject()
This method returns the project object.
This method takes no argument.
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 (impulse archive).
Arguments:
Name | Type | Description |
file | string | impulse archive file (extension must be .nym). |
Example:
modifyPad(name, parameters)
This method is used to modify the configuration of an existed pad.
This method takes the same parameters as addPad method.
Parameters that only affect the configuration and not the placing can be changed at any time.
Arguments:
Name | Type | Description |
name | string | IO name. |
parameters | dictionary | Configuration parameters. |
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:
printHierInfo()
This method prints the detailed hierarchy of a project with the module matched and all instances per module.
This methods 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()
This method allows to remove files from a project.
This method does not
Arguments:
Name | Type | Description |
libName | string | name of the library. Default is work. |
fileList | list | list of files. |
Example:
removeSoftModules(libName, fileList)
This method allows to remove all HDL soft modules from a project.
This method takes no argument.
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 impulse) |
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 impulse 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.
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: Impulse choose an effective balance High: all Load and Reset are routed in common parts ( high routing constraint) |
'CMICLatency' | '0' | Additional delay between 2 CMIC scans. Expressed in number of BSM clock cycles. |
'CongestionEffort' | 'High' | Specify the routing resources limit per tile (can be 'Low', 'Medium' or 'High'):
|
'Dynamic' | 'No' | Refresh view while algorithms are running. |
'DefaultFSMEncoding' | 'OneHot' | Default encoding of finite state machine (can be 'OneHot', 'OneHotSafe', 'OneHotSafeExtra' or 'Binary'):
Example for binary encoding with 3 states: Example for one hot encoding with 3 states: |
'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'):
|
'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. |
'DisableRegisterMergeInDspForAdd' | ‘No’ | Disable merge of registers in DSP when used as adder |
'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. |
‘InitializeContext’ | 'No' | Initialize all DFF, RFB and RAM of the chip. It increases the bitstream size. |
'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', 'Power' or 'Preserve’. Error: Generates an error Ground: Connect to '0' Power: Connect to '1' Preserve: Preserve attribute set to avoid optimization |
'ManageUnconnectedSignals' | 'Error' | Undriven internal signals of HDL modules are treated as ‘Error', 'Ground', 'Power' or 'Preserve’. Error: Generates an error Ground: Connect to '0' Power: Connect to '1' Preserve: Preserve attribute set to avoid optimization |
'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 in terms of primitive instance merging and simplification (can be 'Low', 'Medium' or 'High'):
|
'MaxRegisterCount' | '2500' | Maximum number of registers handled per HDL module (not the whole design) by the synthesizer. |
‘OptimizedMux’ | ‘Yes’ | If set to 'Yes', impulse 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') :
|
'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.
|
'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.
|
'RoutingEffort' | 'Medium' | Routing Optimization level in terms of routing instances (can be 'Low', 'Medium' or 'High'):
|
‘SaveTiming' | ‘No’ | Save STA in .nym project files
|
‘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. |
'SetRunAfterContext' | ‘No’ | Indicate the sequence in the bitstream between run (routing instances enable) and context (initialization values for DFF, RFB, RAM).
|
'SharingEffort' | 'Medium' | Enables the insertion in lowskew network signal with fanout above the SharingFanout threshold.
Medium and High have the same impact. |
'SharingFanout' | '100' | Fanout threshold to insert signal in lowskew network. This option has an impact only if SharingEffort is set to Medium or High. |
‘SimplifyRegions’ | ‘Yes’ | Clear module and region database:
|
‘SytemOutputDriven’ | 'No' | Increase placing close to the ring for instances communicating with.
|
'TimingEffort' | ‘High’ | Indicates level of iterations for TimingDriven algorithm.
|
'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 |
|
|
'CMICLatency' |
|
|
| 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 |
|
|
|
‘DisableRegisterMergeInDspForAdd’ | X |
|
|
|
'DisableKeepPortOrdering' | X |
|
|
|
'DisableLoadAndResetBypass' | X |
|
|
|
'DisableRAMAlternateForm' | X |
|
|
|
'DisableRAMRegisters' | X |
|
|
|
'DisableROMFullLutRecognition' | X |
|
|
|
‘ExhaustiveBitstream’ |
|
|
| X |
'GenerateBitstreamCMIC' |
|
|
| X |
'IgnoreRAMFlashClear' | X |
|
|
|
'InitializeContext' |
|
|
| 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 |
|
|
'SetRunAfterContext' |
|
|
| 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:
Simulation related methods
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:
Argument related methods
getClock(clock_name)
This argument method is used to get the clock from a given clock name. A valid clock should be a clock created by command createClock.
Arguments:
Name | Type | Description |
clock_name | string | the name of the clock used to get the valid clock. |
Example:
getClockNet(clock_net_name)
This argument method is used to get the net from a given clock net name. It is used by createClock method to specify a clock related point as argument.
Arguments:
Name | Type | Description |
clock_net_name | string | the name of the net clock. The path must be set entirely. |
Example:
getClocks(clock_name_expression)
This argument method is used to get the clocks from a given clock name expression. A valid clock should be a clock created by command createClock.
Arguments:
Name | Type | Description |
clock_name_expression | string | the name expression of the clock used to get the list of clocks. |
Example:
getInstances(intance_name)
This argument method is used to get the instances from an instance name. It can be used by some nxpython methods (addMappingDirective, addMemoryInitialization).
Arguments:
Name | Type | Description |
instance_name | string | the name of the instance used to get the valid instance. All regular expressions are allowed and special characters must be escaped. |
Example:
getModels(model_name)
This argument method is used to get the models from a model name. It can be used by some nxpython methods (addMappingDirective, addMemoryInitialization).
Arguments:
Name | Type | Description |
model_name | string | the name of the model used to get the valid model. All regular expressions are allowed and special characters must be escaped. |
Example:
getPort(port_name)
This argument method is used to get the port from a given port name. Some nxpython methods need a port as argument.
Arguments:
Name | Type | Description |
port_name | string | the name of the port used to get the valid port. The path must be set entirely. |
Example:
getPorts(port_name_expression)
This argument method is used to get the ports from a given port name expression. Some nxpython methods need a list of ports as argument.
Arguments:
Name | Type | Description |
port_name_expression | string | the name expression of the port used to get the list of ports. |
Example:
getRegister(register_name)
This argument method is used to get the register from a given register name. Some nxpython methods need a register as argument.
Arguments:
Name | Type | Description |
register_name | string | the name of the register used to get the valid register. The path must be set entirely. |
Example:
getRegisterClock(register_name)
This argument method is used to get the register clock from a given register name. Some nxpython methods need a clock as argument.
Arguments:
Name | Type | Description |
register_name | string | the name of the register used to get the valid clock. |
Example:
getRegisters(register_name_expression)
This argument method is used to get the registers from a given register name expression. Some nxpython methods need a list of registers as argument.
Arguments:
Name | Type | Description |
register_name_expression | string | the name expression of the register used to get the list of registers. All regular expressions are allowed and special characters must be escaped. |
Example:
getRegistersByClock(clock_name)
This argument method is used to get all the registers from the same clock domain. Clock must be created before.
Arguments:
Name | Type | Description |
clock_name | string | the name of the created clock. |
Example:
getWFGOutput(wfg_name)
This argument method is used to get the wfg clock from a given wfg name. Some nxpython methods need a clock as argument.
Arguments:
Name | Type | Description |
wfg_name | string | the name of the wfg used to get the valid clock. |
Example:
Full script example:
This chapter presents the full Python script of the provided VHDL 'simple' example.
Example:
Timing Analysis
Timing path
Timing path is the connection between two certain nodes in the design i.e. connection between primary input and output ports, connection between primary input ports/clock pins and data input pins of the sequential elements, and connection between intermediate clock pins and primary output ports.
Data delay
In impulse, 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 impulse, 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 impulse, 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 impulse, 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 impulse, 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 impulse 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 Impulse_NXpython specification document:
Date | Version | Revision |
2022-12-15 | 1.0.1 | Initial draft datasheet. |
© NanoXplore 2022