Versions Compared

Old Version 1

changes.mady.by.user Kévin Chopier

Saved on

compared with

New Version Current

changes.mady.by.user Kévin Chopier

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add removeSoftModules + modifyRegion to PlacingConstraint/Region

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 consent of NanoXplore.

Introduction

Aim of document

This document is intended to guide users on Training Package testcases.

In order to be more familiar with the Training Package environment, please refer to TrainingPackage_UserManual. For any kind of help, please contact NanoXplore support team at support@nanoxplore.com.

Content

For each testcase of the Training Package, an application note informing about implemented NanoXplore python methods (cf Impulse User Manual) and NanoXplore primitives (cf https://nanoxplore-wiki.atlassian.net/wiki/spaces/~814749387SANDBOX/pages/48660481) and NanoXplore primitives (cf Library guide202244165) is provided in this document.

Test plan

List of categories

Testcases are grouped by category depending on the aim of the testcase (python method, primitive, …).

...

  • Attribute: Attributes can be inserted in the design in order to add a constraint on a register, a memory, …

  • Board: Designs to program NanoXplore evaluation boards (DevKit / BringUp).

  • Component: Multiple configurations for NanoXplore primitives.

  • Design: Various types of designs without any specific IP.

  • Init: Memory initialization

  • Ip: Designs implementing NanoXplore Ips.

  • MappingDirective:Directive of elements mapping in NanoXplore primitives.

  • Pad: Pad configurations.

  • PlacingConstraint: Constraints for manual placing of NanoXplore primitives.

  • ProcessingSystem: Communication between Programmable Logic and Processing System.

  • StaConstraint: Constraintsfor static time analysis.


List of testcases

Hereafter the list of all available testcases for each category:

  • Attribute:

    • NxInit

    • NxPort

    • NxUse

    • SynKeep

    • SynPreserve

  • Board:

    • Scope

    • SwichBlink

    • ThermalSensor

  • Component

    • ClockSwitch

    • Ddfr

    • DspConfig

    • IoConfig

    • PllConfig

    • RamConfig

    • RfbConfig

    • Service

    • Soc

    • WfgConfig

  • Design

    • DelayIo

    • DspCascaded

    • DspMultAcc

    • DspTranspose

    • LowskewManagement

    • MemInfer

  • Init

    • Ram

  • Ip

    • CrossDomain

    • Ddr2Dfi

    • HsslEsistream

    • R5AxiMaster

    • R5AxiSlave

    • R5Jtag

    • SerdesSoC

    • SpacewireLoopback

    • SpacewireRoadmap

    • SpacewireRx

  • MappingDirective

    • Adder

    • BlackBox

    • Memory

  • Pad

    • Parameter

    • Registered

  • PlacingConstraint

    • Aperture

    • ConstrainPath

    • DspLocation

    • ExportSites

    • Focus

    • Obstruction

    • PreplaceIp

    • RamLocation

    • Region

    • RingLocation

    • Site

  • ProcessingSystem

    • Interruptions

    • Watchdog

  • StaConstraint

    • CaseAnalysis

    • ClockGroup

    • DelayPath

    • FalsePath

    • GeneratedClock

    • InputOutputDelay

    • ReportPath

 


Testcase content

Each testcase of this application note contains the following fields:

...

  • Option: Project can be launched with or without an option when launching the python script in order to stress the difference if option is set or not. Please have a look at the Training Package User Manual https://nanoxplore-wiki.atlassian.net/wiki/spaces/SANDBOX/pages/202244782 for more information.

  • NanoXmap check: What the user can observe after launching the NanoXmap project.

  • Simulation check: What the user can observe after launching the Modelsim simulation in case of available simulation environment.

  • Board check: What the user can observe after programming the bitstream on an DevKit Evaluation Board.

Testcase Description

Attribute

NxInit

Description:

By using nx_init attribute, the user can initialize an inferred memory directly in the design code. It is an alternative way from using the addMemoryInitialization NXpython method in the python script. The syntax is the following one:

...

Board check: No board purpose for this testcase.


 

NxPort

Description:

By using nx_port attribute, the user can add parameters to the design top IOs directly in the design code. It is an alternative way from using the addPad NXpython method in the python script. The syntax is the following one:

...

Board check: No board purpose for this testcase.

 


NxUse

Description:

By using nx_use attribute, the user can add directive for inferred elements directly in the design code. It is an alternative way from using the addMappingDirective NXpython method in the python script. The syntax is the following one:

...

Board check: No board purpose for this testcase.

 


SynKeep

Description:

By using syn_keep attribute, the user can avoid any optimization of a combinatorial signal directly in the design code. syn_keep attribute can be replaced by syn_noprune attribute with exactly the same impact. The syntax is the following one:

VHDL:

Code Block
attribute syn_keep: boolean;
attribute syn_keep of s_keep_it_0: signal is true;
attribute syn_noprune: boolean;
attribute syn_noprune of s_keep_it_1: signal is true;

...

 Verilog:
 Code Block
(*synthesis,syn_keep="true"*)    reg s_keep_it_0;
(*synthesis,syn_noprune="true"*) reg s_keep_it_1;
Environment:
Here after the table of compliances for this testcase.
...
Board check: No board purpose for this testcase.
 

SynPreserve
Description:
By using syn_preserve attribute, the user can avoid any optimization of a register signal directly in the design code. The syntax is the following one:
VHDL:
 Code Block
attribute syn_preserve: boolean;

attribute syn_preserve of hier_in_row_p2: signal is true;
Verilog:
 Code Block
(*synthesis,syn_preserve="true"*) wire hier_in_row_p2;
Environment:
Here after the table of compliances for this testcase.
...
Board check: No board purpose for this testcase.
 

Board
Scope
Description:
The user can use NxScope IP by implementing it in the design code in order to check signals on a NanoXplore Evaluation board.
...
Among parameters, the user can set data width, memory capacity and triggers signals. Please check NXscope user manual for more details. https://nanoxplore-wiki.atlassian.net/wiki/spaces/SANDBOX/pages/202244570 for more details.
In this example, the IP is already generated so the user can directly launch the project without opening NxCore.
...
For NG-ULTRA, NxScopeV2 IP Core is used instead of NxScope.
Description:
The user can program a NanoXplore Evaluation board (DevKit) with a simple bitstream using switches and LEDs.
...
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
No
Simulation
NoTrue
Attributes
 
IP
 
Methods
 
Table: Board SwitchBlink environment
...
NanoXmap check: After project launching, the user can check in the GUI all connections between pads are made.
 
Simulation check: No simulation environment is available for this testcase
  • out_0 is inverted each period of 2^23 clock cycles.
  • out_1 is the inverted signal of in_1.
 
Board check: The user can program the NanoXplore Evaluation Board and get data with the following steps:
1- Launch the script with the following command:
 Code Block
NXpythonnxpython script_NG-XXX.py --depending on your NX target.
...
2- Configure the FPGA with the following command:
 Code Block
nxbase2_cli NXmap/switch_NG-XXX/bitstream.nxb --with XXX your NX target.
...
-> Make sure all this check points are OK.

ThermalSensor
Description:
The user can interface with the internal thermal sensor in order to retrieve the junction temperature.
...
Board check: Temperature bus is displayed on LEDs.
 

Component
ClockSwitch
Description:
The user can gate and mux clocks using NanoXplore macro cells in the design code.
...
Board check: No board purpose for this testcase.
 
...
Ddfr
Description:
The user can make operations use double data rate input/output using NanoXplore DSP macro cells in the design code.
Hereafter the list of available configurations:
...
NAME
...
Description
...
ADD36
...
36 bits adder
...
SUB36
...
36 bits subtractor
...
SMUL18
...
18 bits signed multiplicator
...
UMUL18
...
18 bits unsigned multiplicator
...
ADD36_PIPE
...
36 bits adder with input/output pipe stages
...
SUB36_PIPE
...
36 bits subtractor with input/output pipe stages
...
SMUL18_PIPE
...
18 bits signed multiplicator with input/output pipe stages
.
For input double data rate, macro cell NX_IDDFR generates 2 single data rate from 1 double data rate.
For output double data rate, macro cell NX_ODDFR generates 1 double data rate from 1 single data rate.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-ULTRA
Embedded
No
Simulation
Yes
Attributes
 
IP
NX_IDDFR NX_ODDFR
Methods
 
Table: Component Ddfr environment
Option: No option is available for this testcase.
 
NanoXmap check: After project launching, the user can check in the GUI the DDFR cells close to the pad.
...
Simulation check: NanoXplore macro cells manage double data rate
 
Board check: No board purpose for this testcase.
DspConfig
Description:
The user can make operations using NanoXplore DSP macro cells in the design code.
Hereafter the list of available configurations:
NAME
Description
ADD36
36 bits adder
SUB36
36 bits subtractor
SMUL18
18 bits signed multiplicator
UMUL18
18 bits unsigned multiplicator
ADD36_PIPE
36 bits adder with input/output pipe stages
SUB36_PIPE
36 bits subtractor with input/output pipe stages
SMUL18_PIPE
18 bits signed multiplicator with input/output pipe stages
UMUL18_PIPE
18 bits unsigned multiplicator with input/output pipe stages
...
Board check: No board purpose for this testcase.
 

IoConfig
Description:
The user can make operations using NanoXplore IO macro cells in the design code.
...
Board check: No board purpose for this testcase.
 
 

PllConfig
Description:
The user can generate clocks using NanoXplore PLL macro cells in the design code.
...
Board check: No board purpose for this testcase.
 

RamConfig
Description:
The user can store data using NanoXplore RAM macro cells in the design code.
...
Board check: No board purpose for this testcase.
 

RfbConfig
Description:
The user can store data using NanoXplore Register File macro cells in the design code.
...
Hereafter the list of available configurations for ULTRA:
NAME
Description
SPRAM
Single port RFB
FALLING DPRAM
Dual port RFB falling edge sensitive
RISING DPRAM
Dual port RFB rising edge sensitive
WIDTH_EXT
2 RFB are used for twice larger words
HIGHT_EXT
2 RFB are used for twice larger number of words
2R1W
2 RFB are used for 2 read ports
RISING_FIFO_WIDTH_EXT
FIFO: 2 RFB are used for twice larger words
RISING_FIFO_HEIGHT_EXT
FIFO: 2 RFB are used for twice larger number of words
Table: Component RfbConfig configuration description ULTRA
...
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
Yes
Attributes
 
IP
NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 MethodsNX_XFIFO_64x18 NX_XFIFO_32x36
Methods
 
Table: Component RamConfig environment
...
Board check: No board purpose for this testcase.

Service
Description:
The user can interface with the Bitstream Manager and the Service bank using NanoXplore Service macro cell in the design code.
...
Variant
NG-ULTRA
Embedded
No
Simulation
NoYes
Attributes
 
IP
NX_SERVICE_WRAP
Methods
createClock
...
NanoXmap check: After project launching, the user can check in lowskew.rpt that the clock is coming from the NX_SERVICE_WRAP instance. Macro cell is observable in the GUI. The whole design is working on USER_0 service bank pin clock.
...
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: The whole design is working on USER_0 service bank pin clock No board purpose for this testcase.
 

Soc
Description:
The user can interface with the Soc using NanoXplore SOC_INTERFACE macro cell in the design code.
...
Board check: No board purpose for this testcase.
 
 

WfgConfig
Description:
The user can generate clocks using NanoXplore WFG macro cells in the design code.
...
Board check: No board purpose for this testcase.

Design
DelayIo
Description:
The user can drive delays on IO statically or dynamically using NanoXplore macro cells in the design code.
...
Board check: No board purpose for this testcase.
 

 
DspCascaded
Description:
The user can cascade DSP using NanoXplore DSP macro cells in the design code in order to compute large operations.
...
Board check: No board purpose for this testcase.
 

DspMultAcc
Description:
The user can infer a 12*16+36 operations mapped in DSP.
...
Board check: No board purpose for this testcase.
 

DspTranspose
Description:
The user can implement a 6-tap transpose Finite Impulsion Response filter.
...
Board check: No board purpose for this testcase.
 

LowskewManagement
Description:
The user can interface with the low-skew network through several ways.
...
  • Using a low-skew dedicated complex pad (highly recommended)
  • Using a simple/complex pad and buffer in global_lowskew modeCommon to System Converter (CSC) 
  • Using a simple/complex pad and buffer in local_lowskew modeUsing a simple/complex pad connected to a WFG (not recommended)
Using low-skew dedicated pads reduces clock skew delays in order to reach best performances during Static Timing Analysis.
Global_lowskew mode has to be used in case of registers from different tiles are on low-skew signal destination. Otherwise, if registers are in the same tile, it is enough to use local_lowskew For NG-MEDIUM/NG-LARGE, CSC is instantiated thanks to NX_BD in global_lowskew mode.
For NG-ULTRA, CSC is instantiated thanks to NX_GCK in CSC mode.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
No
Simulation
No
Attributes
 
IP
NX_BD NX_GCK NX_WFG
MethodsaddModule createRegion confineModule
Table: Design LowskewManagement environment
...
NanoXmap check: After project launching, the user can check in progresslowskew.rpt that 2 clock buffers and 2 WFG are counted. Routing ways are observable in the GUI.
...
 
Simulation check: No simulation environment is available for this testcaseand in the GUI that clocks are inserted in the lowskew through multiple ways.
 
...
Simulation check: Clocks go through different ways without impact.
 
Board check: No board purpose for this testcase.
 

MemInfer
Description:
The user can infer memories without instantiating NanoXplore macro cells in the design code.
...
Board check: No board purpose for this testcase.
 

Init
Ram
Description:
The user can initialize a memory using the addMemoryInitialization NXpython method in the python script. The syntax is the following one:
...
Board check: No board purpose for this testcase.

Ip
CrossDomain
Description:
The user can cross clock domain properly thanks to NanoXplore IP. Implemented IP are:
...
Board check: No board purpose for this testcase.

 
Ddr2Dfi
Description:
The user can interface with a DDR2 memory thanks to the NanoXplore DDR2 DFI IP.
...
Board check: Switches and leds allow to control and receive data.

HsslEsistream
Description:
The user can interface with HSSL links thanks to the NanoXplore HSSL macro cell.
...
Variant
NG-LARGE
Embedded
No
Simulation
No
Attributes
 
IP
NX_HSSL_L_FULL
MethodscreateClock
addHSSLLocation constrainModule 
Table: Ip HsslEsistream environment
...
  • ERROR FLAG deactivated on J15 PIN1
  • HSSL_CLK at 48MHz on J15 PIN3
  • ESISTREAM SYNC RX/TX activated on J15 PIN 5
  • RX_PLL_LOCKED activated on J15 PIN7
  • PMA RX CLOCK on on J15 PIN13

R5AxiMaster
Description:
The user can interface with R5 Core thanks to the NanoXplore R5 interface macro cell.
...
Board check: No board purpose for this testcase.

R5AxiSlave
Description:
The user can interface with R5 Core thanks to the NanoXplore R5 interface macro cell.
...
Board check: No board purpose for this testcase.

R5Jtag
Description:
The user can interface with R5 Core thanks to the NanoXplore R5 interface macro cell.
...
Board check: No board purpose for this testcase.

Serdes
Description:
The user can send and receive data at high speed thanks to the NanoXplore SERDES macro cells.
...
Board check: No board purpose for this testcase.

SpacewireLoopback
Description:
The user can communicate with Spacewire link thanks to the NanoXplore SpaceWire macro cell.
...
2- Configure the FPGA with the following command:
 Code Block
nxbase2_cli NXmap/switch_NG-XXX/bitstream.nxb with XXX the NX target
...
3- Check data is displayed on LED.

SpacewireRoadmap
Description:
The user can communicate with Spacewire link and Roadmap protocol thanks to the NanoXplore SpaceWire macro cell.
...
NanoXmap check: After project launching, the user can check in the GUI connections with SPW interfaceall instances are in the fabric part..
...
 
Simulation check: No simulation environment is available for this testcase.
...
Board check: No board purpose for this testcase.
SpacewireRx
Description:
The user can retrieve data from a Spacewire Link generating the recovery clock.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
No
Simulation
No
Attributes
 
IP
spw_rx
Methods
 
Table: Ip SpacewireRx environment
Option: No option is available for this testcase.
 
NanoXmap check: After project launching, the user can check in the GUI all instances are in the fabric part (except pads).
 
...
Simulation check: No simulation environment is available for this testcase.
 
Board check: Data are routed to output LED (falling edge data on LED1 + rising edge data on LED2).

MappingDirective
BlackBox
Description:
The user can declare a component which is a blackbox and map it into the desired NanoXplore macro cell using addBlackbox NXpython method.
...
Board check: No board purpose for this testcase.

Memory
Description:
The user can map inferred operations into the desired NanoXplore macro cell using addMappingDirective NXpython method.
...
Board check: No board purpose for this testcase.
 
Operator
Description:
The user can map inferred operations into the desired NanoXplore macro cell using addMappingDirective NXpython method.
...
Board check: No board purpose for this testcase.

Pad
Parameter
Description:
The user can configure pads with many parameters using addPad or modifyPad NXpython method.
The following parameters can be set by the method:
...
Hereafter an example of using the method addPad to constrain create a pad:
 Code Block
p.addPad('input[0]’,{'location':'IOB10_D09P', 'standard': 'LVCMOS'} )
Environment:
Here after the table of compliances for this testcase.
User is also able to modify the pad parameters once the pad is created.
Hereafter an example of using the method modifypad to modify a pad:
 Code Block
p.modifyPad('input[0]',{'standard': 'SSTL', 'drive' :'I'})
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
No
Simulation
No
Attributes
 
IP
 
Methods
addPad
Table: Pad Parameter environment
Option: No option is available for this testcase There is one option to check the impact of this constraint:
  • No option: Final parameters are the one defined before first progress steps.
  • Modifypad: Final parameters are the one modified before routing.
 
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters. Initial ones or modfied if option is set.
 Code Block
        |     +-----------+------+------------+----------+---------+-----------+------------------------+----------+---------------+--------------+-------+
        |     |    Name   |  I/O |  Location  | Standard | Voltage |   Drive   |       Termination      | SlewRate |   DelayLine   | Differential | Turbo |
        |     |           |      |            |          |         |           |  R / Weak / Reference  |          |    In / Out   |              |       |
        |     +-----------+------+------------+----------+---------+-----------+------------------------+----------+---------------+--------------+-------+
        |     | input[2]  | In   | IOB10_D03N | SSTL     | 2.5V    | CatI      |    None / PullUp / -   |     Fast | False / False |        False | False |
        |     | input[3]  | In   | IOB11_D04P | HSTL     | 1.8V    | CatII     |    None / PullUp / -   |   Medium | False / False |        False | False |
        |     | input[5]  | In   | IOB10_D04N | LVCMOS   | 2.5V    | 16mA      |    None / PullUp / -   |   Medium | False / False |        False | False |
        |     | input[4]  | In   | IOB10_D09N | LVCMOS   | 2.5V    | 8mA       |    None / PullUp / -   |   Medium | False / False |        False | False |
        |     | output[4] | Out  | IOB5_D05P  | LVCMOS   | 1.5V    | 8mA       |    None / PullUp / -   |   Medium | False / False |        False | False |
        |     | output[5] | Out  | IOB4_D07P  | LVCMOS   | 2.5V    | 16mA      |    None / PullUp / -   |   Medium | False / False |        False | False |
        |     | output[2] | Out  | IOB4_D03P  | SSTL     | 2.5V    | CatI      |    None / PullUp / -   |     Fast | False / False |        False | False |
        |     | output[3] | Out  | IOB5_D05N  | HSTL     | 1.5V    | CatII     |    None / PullUp / -   |   Medium | False / False |        False | False |
        |     | input[0]  | In   | IOB10_D09P | LVCMOS   | 2.5V    | 2mA       | 35 / PullUp / Floating |     Slow |  False / True |        False |  True |
        |     | input[1]  | In   | IOB10_D10P | LVDS     | 2.5V    | Undefined |    100 / PullUp / VT   |   Medium |  True / False |         True | False |
        |     | output[0] | Out  | IOB4_D01P  | LVCMOS   | 2.5V    | 2mA       | 35 / PullUp / Floating |     Slow |  False / True |        False |  True |
        |     | output[1] | Out  | IOB4_D06P  | LVDS     | 2.5V    | Undefined |    100 / PullUp / VT   |   Medium |  True / False |         True | False |
        |     +-----------+------+------------+----------+---------+-----------+------------------------+----------+---------------+--------------+-------+

...
Board check: No board purpose for this testcase.

Registered
Description:
The user can map registers, mapped by default in NX_DFF and located in tiles, into NX_DFR located in the pad using addPad NXpython method and registered parameter.
...
NanoXmap check: After project launching, the user can check in the GUI that NX_DFR are instantiated if the option Registered is set. Otherwise, NX_DFF are instantiated.
...
 In the port report, user can observe the applied registered requirements:
...
Simulation check: No simulation environment is available for this testcase.
...
Board check: No board purpose for this testcase.
 

PlacingConstraint
Aperture
Description:
The user can focus its design into a defined area using setAperture NXpython method.
...
Board check: No board purpose for this testcase.

ConstrainPath
Description:
The user can confine the path between registers in a region using constrainpath NXpython method.
...
Board check: No board purpose for this testcase.

DspLocation
Description:
The user can place manually a DSP using addDSPLocation NXpython method.
...
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
addDSPLocation clearFabricPrePlaceConstraints addPins
Table: PlacingConstraint DspLocation environment
...
Board check: No board purpose for this testcase.
...
ExportSites
Description:
The user can focus its design around a point using setFocus export placing constraints (setSite, addRAMLocation,…) using exportSites NXpython method.
The exported file can be executed in another project in order to keep placing constraint of the project constraints were exported.
Hereafter an example for this method:
 Code Block
p.setApertureexportSites(8,1,12,6'p','exportSitesFile.py')
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
setFocus
exportSites
Table: PlacingConstraint Focus ExportSites environment
Option: There is one option to check the impact of this constraint:
  • No option: A default focus is set Project is executed without placing constraints.
  • ExportSites: Exported constraints are used.
 
NanoXmap check: After project launching, the user can check in the GUI constraints impact the design placing.
 
Simulation check: No simulation environment is available for this testcase.
Board check: No board purpose for this testcase.
Focus
Description:
The user can focus its design around a point using setFocus NXpython method.
Hereafter an example for this method:
 Code Block
p.setAperture(8,1,12,6)
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
setFocus
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
  • No option: A default focus is set by the tool.
  • Aperture: A focus is set to the tool.
...
Board check: No board purpose for this testcase.
Obstruction
Description:
The user can remove regions from available area in the tool using createObstruction NXpython method.
...
Board check: No board purpose for this testcase.
PreplaceIp
Description:
The user can preplace an IP and declare IP as a blackbox using addBlackBox NXpython method.
...
Board check: No board purpose for this testcase.

RamLocation
Description:
The user can place manually a RAM using addRAMLocation NXpython method.
...
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
addRAMLocation clearFabricPrePlaceConstraints
Table: PlacingConstraint RamLocation environment
...
Board check: No board purpose for this testcase.

Region
Description:
The user can confine a module in a region using addModule, createRegion and confineModule or directly constrainModule NXpython methods.
...
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
createRegion modifyRegion addModule confineModule constrainModule removeSoftModules
Table: PlacingConstraint Region environment
...
Board check: No board purpose for this testcase.

RingLocation
Description:
The user can place manually PLL and WFG into a CKG using respectively addPLLLocation and addWFGLocation NXpython methods. The method addRingLocation can be used too in both cases.
...
Board check: No board purpose for this testcase.

Site
Description:
The user can place manually a register into a tile using setSite NXpython method.
...
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
setSite clearFabricPrePlaceConstraints
Table: PlacingConstraint Site environment
...
Board check: No board purpose for this testcase.
...
ProcessingSystem
...
Interruptions
Description:
The user can specify unrelated clocks using setClockGroup NXpython method or calling SDC constraint.
The impact is during STA, no timing file is generated between the 2 clock domains.
The available values are:
  • Asynchronous: 2 completely unrelated clocks
  • Exclusive: 2 clocks never used simultaneously.
Hereafter an example for this NXpython method:
 Code Block
p.createClock(getClockNet('clk_1'), 'clk1', 10000)
p.createClock(getClockNet('clk_2'), 'clk2', 12000)
p.setClockGroup(getClock('clk1'),getClock('clk2'),'asynchronous')
Hereafter an example for equivalent SDC constraint:
 Code Block
create_clock -period 10 -name "clk1" [get_ports clk_1]
create_clock -period 12 -name "clk2" [get_ports clk_2]
set_clock_groups -asynchronous -group [get_clocks clk1] -group [get_clocks clk2]
Clocks need to be created before used in setClockGroup method.
generate interruptions from the Fabric to the SoC through SoC interface.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-ULTRA
Embedded
No
Simulation
No
Attributes
 
IP
 NX_SOC_INTERFACE
Methods
Table: ProcessingSystem Interruptions environment
Option: No option is available for this testcase.
 
NanoXmap check: After project launching, the user can check in the GUI all connections with the SOC interface.
 
Simulation check: No simulation environment is available for this testcase.
Board check: Check interruptions are received by the SoC when using switches.
Watchdog
Description:
The user can use watchdogs from processing system cores.
There are 1 watchdogs containing 2 signals by CPU Core.
When watchdog counter limit is reached, associated signal from SoC interface is raised.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-
MEDIUM NG-LARGE NG-
ULTRA
Embedded
Yes
No
Simulation
No
Attributes
 
IP
 
 NX_SOC_INTERFACE
Methods
createClock setClockGroup getClock
Table: StaConstraint ClockGroup ProcessingSystem Interruptions environment
Option: There is one option to check the impact of this constraint:
  • No option: A clock domain crossing timing files are generated.
  • ClockGroup: No clock domain crossing timing file is generated for specified clock groups.
  • ClockGroupSdc: No clock domain crossing timing file is generated for specified clock groups. Same constraints using SDC file.
 
NanoXmap check: After No option is available for this testcase.
 
NanoXmap check: After project launching, the user can check in the log directory that there is no timing file between specified clock groupsGUI all connections with the SOC interface.
 
Simulation check: No simulation environment is available for this testcase. 
Board check: No board purpose for this testcase.
...
 Check LED associated to the programmed watchdog is switched when watchdog counter limit is reached.
StaConstraint
CaseAnalysis
Description:
The user can specify path delays between registers by using addMinDelayPath, addMaxDelayPath and addMulticyclePath NXpython methods or calling SDC constraintsa case analysis for the STA using setCaseAnalysis NXpython method.
The impact is during STA, a timing violation occurs if the constraint is not compliant with the constraint.
addMinDelayPath and addMaxDelayPath specify a time duration whereas addMulticyclePath specifies a number of clock cycles.
constrained net will be interpreted as a constant equal to the specified value.
Hereafter an example for each this NXpython method:
 Code Block
breakoutModewide
p.addMinDelayPath(getRegister('i_cpt_0|s_cpt_out_reg[0]'),getRegister('i_cpt_1|s_cpt_out_reg[1]'),2500)
p.addMaxDelayPath(getRegister('i_cpt_0|s_cpt_out_reg[0]'),getRegister('i_cpt_1|s_cpt_out_reg[1]'),2300)
p.addMulticyclePath(getRegister('i_cpt_0|s_cpt_out_reg[2]'),getRegister('i_cpt_1|s_cpt_out_reg[2]'),2)
Here after same constraints with SDC format:
 Code Block
set_min_delay -from [get_registers i_cpt_0|s_cpt_out_reg\[0\]] -to [get_registers i_cpt_1|s_cpt_out_reg\[1\]] 8000  
set_max_delay -from [get_registers i_cpt_0|s_cpt_out_reg\[0\]] -to [get_registers i_cpt_1|s_cpt_out_reg\[1\]] 4000  
set_multicycle_path -from [get_registers i_cpt_0|s_cpt_out_reg\[2\]] -to [get_registers i_cpt_1|s_cpt_out_reg\[2\]] 2

The function getRegister gives the ability to get a register instance.
It is possible to match with several register instances using getRegisters function and regular expressions format.
Environment:
Here after the table of compliances for this testcase.
...
Variant
...
NG-MEDIUM NG-LARGE NG-ULTRA
...
Embedded
...
Yes
...
Simulation
...
No
...
Attributes
...
 
...
IP
...
 
...
Methods
...
addMaxDelayPath addMinDelayPath addMulticyclePath getRegister
Table: StaConstraint DelayPath environment
...
setCaseAnalysis(value = '0', netList= getNet('cmd'))
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
setCaseAnalysis createClock setClockGroup getClockNet getNet
Table: StaConstraint ClockGroup environment
Option: There are two options to check the impact of this constraint:
  • No option: No delay path is setSTA is launched only with createdClock.
  • MaxDelayPath: A maximum delay path is set between 2 registers.
  • MinDelayPath: A minimum delay path is set between 2 registers.
  • MulticyclePath: A number of clock cycles is set between 2 registers.
  • MaxDelayPathSdc: A maximum delay path is set between 2 registers. Same constraints using SDC file.
  • MinDelayPathSdc: A minimum delay path is set between 2 registers. Same constraints using SDC file.
  • MulticyclePathSdc: A number of clock cycles is set between 2 registers. Same constraints using SDC file.
  • CaseAnalysis0: cmd net is considered as a 0 for STA.
  • CaseAnalysis1: cmd net is considered as a 1 for STA.
 
NanoXmap check: After project launching, the user can check in the DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing log files:
  • No option: i_cpt_0|s_cpt_out_reg[2].CK to i_cpt_1|s_cpt_out_reg[2].L is the longest path with 0ps of slack and no shortest path is reported.
  • MaxDelayPath/MaxDelayPathSdc: i_cpt_0|s_cpt_out_reg[0].CK to i_cpt_1|s_cpt_out_reg[1].L is still the shortest path but the slack is now negative.
...
wich domain appear in STA reports.
  • No option: Both clk1 and clk2 domains are reported
  • CaseAnalysis0: only clk2 domain is reported
  • CaseAnalysis1: only clk1 domain is reported
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.
ClockGroup
Description:
The user can specify unrelated clocks using setClockGroup NXpython method or calling SDC constraint.
The impact is during STA, no timing file is generated between the 2 clock domains.
The available values are:
  • Asynchronous: 2 completely unrelated clocks
  • Exclusive: 2 clocks never used simultaneously.
Hereafter an example for this NXpython method:
 Code Block
p.createClock(getClockNet('clk_1'), 'clk1', 10)
p.createClock(getClockNet('clk_2'), 'clk2', 12)
p.setClockGroup(getClock('clk1'),getClock('clk2'),'asynchronous')
Hereafter an example for equivalent SDC constraint:
 Code Block
create_clock -period 10 -name "clk1" [get_ports clk_1]
create_clock -period 12 -name "clk2" [get_ports clk_2]
set_clock_groups -asynchronous -group [get_clocks clk1] -group [get_clocks clk2]
Clocks need to be created before used in setClockGroup method.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
createClock setClockGroup getClock
Table: StaConstraint ClockGroup environment
Option: There are two option to check the impact of this constraint:
  • No option: A clock domain crossing timing files are generated.
  • ClockGroup: No clock domain crossing timing file is generated for specified clock groups.
  • ClockGroupSdc: No clock domain crossing timing file is generated for specified clock groups. Same constraints using SDC file.
 
NanoXmap check: After project launching, the user can check in the log directory that there is no timing file between specified clock groups.
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.

DelayPath
Description:
The user can specify path delays between registers by using addMinDelayPath, addMaxDelayPath and addMulticyclePath NXpython methods or calling SDC constraints.
The impact is during STA, a timing violation occurs if the constraint is not compliant with the constraint.
addMinDelayPath and addMaxDelayPath specify a time duration whereas addMulticyclePath specifies a number of clock cycles.
Hereafter an example for each NXpython method:
 Code Block
breakoutModewide
p.addMinDelayPath(getRegister('i_cpt_0|s_cpt_out_reg[0]'),getRegister('i_cpt_1|s_cpt_out_reg[1]'),8.0)
p.addMaxDelayPath(getRegister('i_cpt_0|s_cpt_out_reg[0]'),getRegister('i_cpt_1|s_cpt_out_reg[1]'),4.0)
p.addMulticyclePath(getRegister('i_cpt_0|s_cpt_out_reg[2]'),getRegister('i_cpt_1|s_cpt_out_reg[2]'),2)
Here after same constraints with SDC format:
 Code Block
set_min_delay -from [get_registers {i_cpt_0|s_cpt_out_reg[0]}] -to [get_registers {i_cpt_1|s_cpt_out_reg[1]}] 8
set_max_delay -from [get_registers {i_cpt_0|s_cpt_out_reg[0]}] -to [get_registers {i_cpt_1|s_cpt_out_reg[1]}] 4
set_multicycle_path -from [get_registers {i_cpt_0|s_cpt_out_reg[2]}] -to [get_registers {i_cpt_1|s_cpt_out_reg[2]}] 2
The function getRegister gives the ability to get a register instance.
It is possible to match with several register instances using getRegisters function and regular expressions format.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
addMaxDelayPath addMinDelayPath addMulticyclePath getRegister
Table: StaConstraint DelayPath environment
Option: There are several options to check the impact of this constraint:
  • No option: No delay path is set.
  • MaxDelayPath: A maximum delay path is set between 2 registers.
  • MinDelayPath: A minimum delay path is set between 2 registers.
  • MulticyclePath: A number of clock cycles is set between 2 registers.
  • MaxDelayPathSdc: A maximum delay path is set between 2 registers. Same constraints using SDC file.
  • MinDelayPathSdc: A minimum delay path is set between 2 registers. Same constraints using SDC file.
  • MulticyclePathSdc: A number of clock cycles is set between 2 registers. Same constraints using SDC file.
 
NanoXmap check: After project launching, the user can check in the DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing log files:
  • No option: i_cpt_0|s_cpt_out_reg[2].CK to i_cpt_1|s_cpt_out_reg[2].L is the longest path with 0ps of slack and no shortest path is reported.
  • MaxDelayPath/MaxDelayPathSdc: i_cpt_0|s_cpt_out_reg[0].CK to i_cpt_1|s_cpt_out_reg[1].L is still the shortest path but the slack is now negative.
 Code Block
    |   +--------+----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+-------------------------+
    |   |   No.  |   Slack  |              Source              |              Target             | Data Delay | Clock Skew | Setup/Recovery |  Depth |           Note          |
    |   +--------+----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+-------------------------+
    |   |      1 | -4.473ns | Pin: i_cpt_0|s_cpt_out_reg[0].CK | Pin: i_cpt_1|s_cpt_out_reg[1].L |    7.285ns |      -97ps |        1.091ns |      3 |  MaxDelay: 4.000ns (RR) |

  • MinDelayPath/MinDelayPathSdc: i_cpt_0|s_cpt_out_reg[0].CK to i_cpt_1|s_cpt_out_reg[1].L is reported in shortest paths.
 Code Block
    |   +--------+--------+----------------------------------+---------------------------------+------------+------------+--------------+--------+-------------------------+
    |   |   No.  |  Slack |              Source              |              Target             | Data Delay | Clock Skew | Hold/Removal |  Depth |           Note          |
    |   +--------+--------+----------------------------------+---------------------------------+------------+------------+--------------+--------+-------------------------+
    |   |      1 | -531ps | Pin: i_cpt_0|s_cpt_out_reg[0].CK | Pin: i_cpt_1|s_cpt_out_reg[1].L |    6.928ns |       97ps |       -638ps |      3 |  MinDelay: 8.000ns (RR) |

  • MulticyclePath/MulticyclePathSdc: i_cpt_0|s_cpt_out_reg[2].CK to i_cpt_1|s_cpt_out_reg[2].L is no longer the longest path.
 Code Block
    |   |      1 |    0ps | Pin: i_cpt_0|s_cpt_out_reg[2].CK | Pin: i_cpt_1|s_cpt_out_reg[3].L |    7.423ns |      -97ps |        1.091ns |      3 |   (RR) |
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.

FalsePath
Description:
The user can specify path to be ignored by the STA by using addFalsePath, NXpython method or calling SDC constraint.
The impact is all paths between the source registers and the destination registers will be ignored by the STA and consequently will not be reported in the timing log files. The constraint can also refer to a path between registers and ports (input, output, inout).
Hereafter examples for this method:
  • Path between 2 registers
 Code Block
p.setFalsePath(source=getRegister('cpt_in_p_reg[0]'), target=getRegisters('*'))
set_false_path -from [get_registers {cpt_in_p_reg[0]}] -to [get_registers *]
  • Path between an input and a register.
 Code Block
p.setFalsePath(source=getPort('cpt_in[0]'), target=getRegisters('cpt_in_p_reg[`[0-3]`]'))
set_false_path -from [get_ports {cpt_in[0]}] -to [get_registers {cpt_in_p_reg[`[0-3]`]}]
  • Path between all registers operating on 2 clock domains.
 Code Block
p.addFalsePath(getRegistersByClock('clk'),getRegistersByClock('clk2')) 
 
The function getRegister gives the ability to get a register instance. It is possible to match with several register instances using getRegisters function and regular expressions format.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
addFalsePath getRegister getRegisters getRegistersByClock getPort createClock 
Table: StaConstraint FalsePath environment
Option: There is one option to check the impact of this constraint:
  • No option: No delay path is set.
  • FalsePath: A maximum delay path is set between 2 registers.
  • FalsePathSdc: A maximum delay path is set between 2 registers. Same constraints using SDC file.
 
NanoXmap check: After project launching, the user can check in the timing log files:
  • No option:
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is the longest path.
 Code Block
    |   +--------+--------+-------------------------+---------------------------------+------------+------------+----------------+--------+--------+
    |   |   No.  |  Slack |          Source         |              Target             | Data Delay | Clock Skew | Setup/Recovery |  Depth |  Note  |
    |   +--------+--------+-------------------------+---------------------------------+------------+------------+----------------+--------+--------+
    |   |      1 |    0ps | Pin: cpt_in_p_reg[0].CK | Pin: i_cpt_0|s_cpt_out_reg[0].L |    7.313ns |      -58ps |        1.091ns |      4 |   (RR) |

  • DOMAIN_clk2_to_clk3_Routed_[typical;bestcase;worstcase].timing: path are reported in the longest path.
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in[3].O to cpt_in_p_reg[3].I is the longest path.
  • FalsePath:
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is no longer the longest path.
 Code Block
    |   +--------+--------+-------------------------+---------------------------------+------------+------------+----------------+--------+--------+
    |   |   No.  |  Slack |          Source         |              Target             | Data Delay | Clock Skew | Setup/Recovery |  Depth |  Note  |
    |   +--------+--------+-------------------------+---------------------------------+------------+------------+----------------+--------+--------+
    |   |      1 |    0ps | Pin: cpt_in_p_reg[1].CK | Pin: i_cpt_0|s_cpt_out_reg[0].L |    6.760ns |      -58ps |        1.091ns |      4 |   (RR) |

  • DOMAIN_clk2_to_clk3_Routed_[typical;bestcase;worstcase].timing: none path is reported in the longest path.
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in[3].O to cpt_in_p_reg[3].I is no longer the longest path.
  • FalsePathSdc:
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is no longer the longest path.
    • DOMAIN_clk2_to_clk3_Routed_[typical;bestcase;worstcase].timing: none path is reported in the longest path.
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.

GeneratedClock
Description:
The user can create a clock directly or specifying its relationship with another clock using respectively createClock and createGenerateClock NXpython method.
When creating a clock directly, the user has to specify the period, the rising time and the falling time (so indirectly the duty cycle).
When creating a generated clock, the user has to specify the period relation and the duty cycle relation with another clock. Relation characteristics can be set by different parameters.
Hereafter an example for both methods in several uses:
 Code Block
 p.createClock(getClockNet('clk_second'),'clk_second',20,5,15)
=> Clock with period of 50MHz with 50% duty cycle with 90° dephasing defined by a net
 Code Block
p.createClock(getPort('clk_main'),'clk_main',10,0,5) 
=> Clock with 100MHz with 50% duty cycle defined by an IO
 Code Block
breakoutModewide
p.createGeneratedClock(getClock('clk_main'),getRegisterClock('i_clock_0|counter_reg[0]'), 'clk_fabric',{'DivideBy': 2}) 
=> Clock is half the reference clock and defined by a register
Here after same constraints with SDC format:
 Code Block
create_clock -period 20 -waveform {5 15} -name "clk_second" [get_ports clk_second]
create_clock -period 10 -waveform {0 5} -name "clk_main" [get_ports clk_main]
create_generated_clock -name "clk_fabric" -source [get_clocks clk_main] -divide_by 2 [get_registers  {i_clock_0|counter_reg[0]}]
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
createClock createGeneratedClock getPort getClockNet getRegisterClock
Table: StaConstraint GeneratedClock environment
Option: There is one option to check the impact of this constraint:
  • No option: Required frequency is set.
  • GeneratedClock: Required frequencies are set.
  • GeneratedClockSdc: Required frequencies are set with SDC file.
 
NanoXmap check: After project launching, the user can check in timing log files that required frequencies are set.
 Code Block
        |   +------------------------------------------------+--------------------------+--------------------------------------------+--------------------------------------------+
        |   |                     Domain                     |         Frequency        |            Hold/Removal Summary            |           Setup/Recovery Summary           |
        |   +------------------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+
        |   |         Source         |         Target        |  Required  |   Maximum   |   Slack  | Minimum Data | Minimum Required |   Slack  | Maximum Data | Maximum Required |
        |   |                        |                       |            |             |          | Arrival Time |   Relationship   |          | Arrival Time |   Relationship   |
        |   +------------------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+
        |   +------------------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+
        |   | clk_fabric_1 (Rising)  | clk_fabric_1 (Rising) | 25.000 MHz | 407.000 MHz |  2.012ns |      2.012ns |              0ps | 37.543ns |      2.457ns |         40.000ns |
        |   +------------------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+
        |   | clk_fabric (Rising)    | clk_fabric (Rising)   | 50.000 MHz | 445.434 MHz |  1.808ns |      1.808ns |              0ps | 17.755ns |      2.245ns |         20.000ns |
        |   +------------------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+

 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.

InputOutputDelay
Description:
The user can apply a minimum and a maximum data arrival time on inputs and outputs using respectively setInputDelay and setOutputDelay NXpython methods.
These methods need a created clock to be set.
Hereafter an example for both methods:
 Code Block
p.setInputDelay(getClock('CLK_MAIN'),'rise',1,10,getPorts('cpt_in[`[0-3]`]'))  
p.setOutputDelay(getClock('CLK_MAIN'),'rise',1,10,getPorts('cpt_out[`[0-3]`]'))
getPorts method use regular expression format whereas getPort method use standard format.
Here after same constraints with SDC format:
 Code Block
set_input_delay -clock [get_clocks "CLK_MAIN"] -min 1.0 [get_ports {cpt_in[`[0-3]`]}]
set_input_delay -clock [get_clocks "CLK_MAIN"] -max 10.0 [get_ports {cpt_in[`[0-3]`]}]
set_output_delay -clock [get_clocks "CLK_MAIN"] -min 1.0 [get_ports {cpt_out[`[0-3]`]}]
set_output_delay -clock [get_clocks "CLK_MAIN"] -max 10.0 [get_ports {cpt_out[`[0-3]`]}]
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
createClock getPort getPorts getClock setInputDelay setOutputDelay
Table: StaConstraint InputOutputDelay environment
Option: There is one option to check the impact of this constraint:
  • No option: No created clock and no input or output delay is set.
  • InputOutputDelay: Input and output delay are set in relationship with a create clock.
  • InputOutputDelaySdc: Input and output delay are set in relationship with a create clock with SDC file.
 
NanoXmap check: After project launching, the user can check in timing log files that input and output delays are taken into account in the longest paths and that the maximum frequency is reduced drastically.
 Code Block
    |   +--------+-----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+--------------------------------+
    |   |   No.  |   Slack   |              Source              |              Target             | Data Delay | Clock Skew | Setup/Recovery |  Depth |              Note              |
    |   +--------+-----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+--------------------------------+
    |   |      1 | -17.951ns | Pin: i_cpt_2|s_cpt_out_reg[0].CK | Pin: cpt_out[0].I               |   20.240ns |   -7.711ns |              - |      1 |  setOutputDelay: 10.000ns (RR) |
    |   |      2 | -14.913ns | Pin: i_cpt_2|s_cpt_out_reg[2].CK | Pin: cpt_out[2].I               |   17.202ns |   -7.711ns |              - |      1 |  setOutputDelay: 10.000ns (RR) |
    |   |      3 | -13.769ns | Pin: i_cpt_2|s_cpt_out_reg[1].CK | Pin: cpt_out[1].I               |   16.058ns |   -7.711ns |              - |      1 |  setOutputDelay: 10.000ns (RR) |
    |   |      4 | -13.678ns | Pin: i_cpt_2|s_cpt_out_reg[3].CK | Pin: cpt_out[3].I               |   15.967ns |   -7.711ns |              - |      1 |  setOutputDelay: 10.000ns (RR) |
    |   |      5 |  -5.233ns | Pin: cpt_in[1].O                 | Pin: i_cpt_0|s_cpt_out_reg[3].L |   21.756ns |    7.614ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |
    |   |      6 |  -5.233ns | Pin: cpt_in[1].O                 | Pin: i_cpt_0|s_cpt_out_reg[2].L |   21.756ns |    7.614ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |
    |   |      7 |  -5.233ns | Pin: cpt_in[1].O                 | Pin: i_cpt_0|s_cpt_out_reg[1].L |   21.756ns |    7.614ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |
    |   |      8 |  -5.233ns | Pin: cpt_in[1].O                 | Pin: i_cpt_0|s_cpt_out_reg[0].L |   21.756ns |    7.614ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |
    |   |      9 |    -963ps | Pin: cpt_in[3].O                 | Pin: i_cpt_0|s_cpt_out_reg[3].L |   17.486ns |    7.614ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |
    |   |     10 |    -963ps | Pin: cpt_in[3].O                 | Pin: i_cpt_0|s_cpt_out_reg[2].L |   17.486ns |    7.614ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |

 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.
ReportPath
Description:
The user can generate timing reports between two pins or two registers with respectively reportPath or addReportPath and reportTiming or addReportTimingPath NXpython methods.
The aim of reportPath or addReportPath is to indicate the detailed path between 2 pins of 2 instances and all the instances within the path with associated delay for each step.
reportPath or addReportPath expect a Port or a Pin as an argument
Hereafter an example for both methods:
 Code Block
breakoutModewide
Timing_analysis = p.createAnalyzer()
Timing_analysis.reportPath(maximumSlack = 500, searchPathsLimit = 10, source = getPort('in_1'), target = getPin('i_clock_0|out_1_reg.I'))

Timing_analysis = p.createAnalyzer()
Timing_analysis.addReportPath(source = getPin('i_clock_0|counter_1_reg[1].CK'), target = getPin('i_clock_0|counter_1_reg[1].I'))
Timing_analysis.launch({'maximumSlack': 500, 'searchPathsLimit': 10, 'conditions': sta_condition})
The aim of reportTiming or addReportTimingPath is to check the required frequency is reached between 2 registers.
reportTiming or addReportTimingPath expect a Port or a Register as an argument
Hereafter an example for both methods:
 Code Block
breakoutModewide
Timing_analysis = p.createAnalyzer()
Timing_analysis.reportTiming(maximumSlack = 500, searchPathsLimit = 10, source = getRegister('i_clock_0|clk_fabric_reg'), target = getRegister('i_clock_0|counter_reg[0]'))

Timing_analysis = p.createAnalyzer()
Timing_analysis.addReporTimingPath(source = getRegister('i_clock_0|clk_fabric_reg'), target = getRegister('i_clock_0|clk_fabric_reg'))
Timing_analysis.launch({'maximumSlack': 500, 'searchPathsLimit': 10, 'conditions': sta_condition})
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
createClock reportPath addReportPathRequest reportTiming addReportTimingRequest removeReportPathRequest removeReportTimingRequest clearTimingConstraints getRegister getPin getPort getProject getAnalyzer
Table: StaConstraint ReportPath environment
Option: There are two options to check the impact of these constraints:
  • No option: No created clock and no report.
  • ReportPath: Clock are created and path reports generated
  • ReportTiming: Clock are created and timing reports generated
 
NanoXmap check: After project launching, the user can check there is a report generated for the required paths.
  • ReportPath option:
REPORTER_path_0_worstcase_Prepared.timing and REPORT_path_2_worstcase_Prepared.timing are generated with respective required path:
 Code Block
        | Reporting longest paths for REPORTER_path_0
        |   +--------+--------+-------------+----------------------------+------------+------------+----------------+--------+--------+
        |   |   No.  |  Slack |    Source   |           Target           | Data Delay | Clock Skew | Setup/Recovery |  Depth |  Note  |
        |   +--------+--------+-------------+----------------------------+------------+------------+----------------+--------+--------+
        |   |      1 |      - | Pin: in_1.O | Pin: i_clock_0|out_1_reg.I |   10.145ns |          - |              - |      0 |        |
        |   +--------+--------+-------------+----------------------------+------------+------------+----------------+--------+--------+
        |   | Total                         |                                                                              1 |        |
        |   +-------------------------------+--------------------------------------------------------------------------------+--------+
 
 Code Block
        | Reporting longest paths for REPORTER_path_2
        |   +--------+--------+------------------------------------+-----------------------------------+------------+------------+----------------+--------+--------+
        |   |   No.  |  Slack |               Source               |               Target              | Data Delay | Clock Skew | Setup/Recovery |  Depth |  Note  |
        |   +--------+--------+------------------------------------+-----------------------------------+------------+------------+----------------+--------+--------+
        |   |      1 |      - | Pin: i_clock_0|counter_1_reg[1].CK | Pin: i_clock_0|counter_1_reg[1].I |    1.961ns |          - |              - |      2 |        |
        |   +--------+--------+------------------------------------+-----------------------------------+------------+------------+----------------+--------+--------+
        |   | Total                                                |                                                                                     1 |        |
        |   +------------------------------------------------------+---------------------------------------------------------------------------------------+--------+
  • ReportTiming option:
DOMAIN_clk_main_to_clk_main_Routed_worstcase.timing is generated with required timing path:
 Code Block
        | Summary of DOMAIN_clk_main_to_clk_main
        |   +---------------------------------------+--------------------------+-------------------------------------------+--------------------------------------------+
        |   |                 Domain                |         Frequency        |            Hold/Removal Summary           |           Setup/Recovery Summary           |
        |   +-------------------+-------------------+------------+-------------+---------+--------------+------------------+----------+--------------+------------------+
        |   |       Source      |       Target      |  Required  |   Maximum   |  Slack  | Minimum Data | Minimum Required |   Slack  | Maximum Data | Maximum Required |
        |   |                   |                   |            |             |         | Arrival Time |   Relationship   |          | Arrival Time |   Relationship   |
        |   +-------------------+-------------------+------------+-------------+---------+--------------+------------------+----------+--------------+------------------+
        |   | clk_main (Rising) | clk_main (Rising) | 25.000 MHz | 368.460 MHz | 1.588ns |      1.588ns |              0ps | 37.286ns |      2.714ns |         40.000ns |
        |   +-------------------+-------------------+------------+-------------+---------+--------------+------------------+----------+--------------+------------------+
        |   | Total                                 |                                                                                                                 1 |
        |   +---------------------------------------+-------------------------------------------------------------------------------------------------------------------+
        | 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.
SpacewireTiming
Description:
The user must be able to get all needed timing in case of recovery clock like Spacewire one.
Spacewire recovery clock is generated by a XOR between DIN and SIN, data and strobe input signals.
The architecture looks like the following:
...
Spacewire clock creation must be done as follows as the tool will separate it in 2 clock signals with one inverted.
 Code Block
breakoutModewide
        p.createClock(target=getRegisterClock('din_r_reg'), name='input_xor_rising', period=10.0, rising=0.0, falling=5.0)
        p.createClock(target=getRegisterClock('din_f_reg'), name='input_xor_falling', period=10.0, rising=0.0, falling=5.0)
However, in order to get timings before the XOR output, STA must be launched without these clock creation constraints.
Environment:
Here after the table of compliances for this testcase.
Variant
NG-MEDIUM NG-LARGE NG-ULTRA
Embedded
Yes
Simulation
No
Attributes
 
IP
 
Methods
createClock
Table: StaConstraint SpacewireTiming environment
Option: There is one option to check the impact of this constraint:
  • No option: no clock creation.
  • CreateClock: Both clocks are created.
 
NanoXmap check: After project launching, the user can get all needed timing paths in timing log files.
  • No option: no clock creation.
For Input to DIN:
 Code Block
breakoutModefull-width
        |       Clock network delay to destination register:
        |         +-----------------------------------------+----------------------------------------+---------------+----------------+-----------------+
        |         |                  Source                 |               Target/Net               | Routing delay | Internal delay | Cumulated delay |
        |         +-----------------------------------------+----------------------------------------+---------------+----------------+-----------------+
        |         | Pin: spw_din.O                          | Net: spw_din              Source             |       7.329ns |              - |         7.329ns |
    Target    |         | Pin:  | Data Delay | Clock Skew | Setup/Recovery |  Depth |    LOGIC|lut_1[D]~csc~lut~exp[6:1].I2 | Pin: LOGIC|lut_1[D]~csc~lut~exp[6:1].O |             - |          318ps |         7.647ns |
        |       Note  | Pin: LOGIC|lut_1[D]~csc~lut~exp[6:1].O  | Net: input_xor  |     |   +--------+----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+-------------------------+     |   |      1 | -4.473ns | Pin: i_cpt_0|s_cpt_out_reg[0].CK | Pin: i_cpt_1|s_cpt_out_reg[1].L.078ns |       7.285ns |      -97ps |        1 8.091ns725ns |
     3 |  MaxDelay:| 4.000ns (RR) | 
  • MinDelayPath/MinDelayPathSdc: i_cpt_0|s_cpt_out_reg[0].CK to i_cpt_1|s_cpt_out_reg[1].L is reported in shortest paths.
 Code Block
    |   +--------+--------+-------------------------+---------+---------------------------------+------------+------------+--------------+--------+-------------------------++
        |         | Total      No.                    |  Slack |              Source              |              Target     |       8.407ns | Data Delay | Clock Skew | Hold/Removal |  Depth318ps |         8.725ns |
Note         | |     |   +--------+--------+----------------------------------+---------------------------------+------------+------------+--------------+--------+-------------------------+
    |   |      1 | -531ps | Pin: i_cpt_0|s_cpt_out_reg[0].CK | Pin: i_cpt_1|s_cpt_out_reg[1].L |    6.928ns |       97ps |       -638ps |      3 |  MinDelay: 8.000ns (RR) |

  • MulticyclePath/MulticyclePathSdc: i_cpt_0|s_cpt_out_reg[2].CK to i_cpt_1|s_cpt_out_reg[2].L is no longer the longest path.
 Code Block
    |   |      1 |    0ps | Pin: i_cpt_0|s_cpt_out_reg[2].CK | Pin: i_cpt_1|s_cpt_out_reg[3].L |    7.423ns |      -97ps
  • CreateClock: Both clocks are created.
For Input to falling edge clock DFF:
 Code Block
breakoutModefull-width
        |       RPath summary:
        |         +---------+----------------+------------------+------------+-------------------+--------------+--------+--------+
        |        1.091ns |  Slack    3 |   (RR) |
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.
FalsePath
Description:
The user can specify path to be ignored by the STA by using addFalsePath, NXpython method or calling SDC constraint.
The impact is all paths between the source registers and the destination registers will be ignored by the STA and consequently will not be reported in the timing log files. The constraint can also refer to a path between registers and ports (input, output, inout).
Hereafter examples for this method:
  • Path between 2 registers
 Code Block
p.addFalsePath(getRegister('cpt_in_p_reg[0]'),getRegister('i_cpt_0|s_cpt_out_reg[1]'))
set_false_path -from [get_registers cpt_in_p_reg[0]] -to [get_registers i_cpt_0|s_cpt_out_reg\[0\]]
  • Path between an input and a register.
 Code Block
p.addFalsePath(getPort('cpt_in[0]'),getRegisters('cpt_in_p_reg[`[0-1]`]'))
set_false_path -from [get_ports cpt_in\[0\]] -to [get_registers cpt_in_p_reg\[0\]]   
  • Path between all registers operating on 2 clock domains.
 Code Block
p.addFalsePath(getRegistersByClock('clk'),getRegistersByClock('clk2')) 
 
The function getRegister gives the ability to get a register instance. It is possible to match with several register instances using getRegisters function and regular expressions format.
Environment:
Here after the table of compliances for this testcase.
...
Variant
...
NG-MEDIUM NG-LARGE NG-ULTRA
...
Embedded
...
Yes
...
Simulation
...
No
...
Attributes
...
 
...
IP
...
 
...
Methods
...
addFalsePath getRegister getRegisters getRegistersByClock getPort createClock
Table: StaConstraint FalsePath environment
Option: There is one option to check the impact of this constraint:
  • No option: No delay path is set.
  • FalsePath: A maximum delay path is set between 2 registers.
  • FalsePathSdc: A maximum delay path is set between 2 registers. Same constraints using SDC file.
 
NanoXmap check: After project launching, the user can check in the timing log files:
  • No option:
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is the longest path.
 Code Block
    |   |     Source     |      Target      | Data Delay | Latch Clock Delay | Hold/Removal |  Depth |  Note  |
        |         +--------+--------+-------------------------+---------------------+------------+------------+------------+----------------+--------+--------+
 
  |   |   No.  |  Slack |      | 6.764ns |  Source    Pin: spw_din.O | Pin: din_f_reg.I |    7.647ns |           1.167ns |  Target     -284ps |      1 | Data Delay | Clock Skew (-R) |
Setup/Recovery |  Depth |  Note  |      |   +--------+--------+-------------------------+---------------------+------------+------------+------------+----------------+--------+--------+
    |   |      1 |  
 0ps | Pin: cpt_in_p_reg[0].CK | Pin: i_cpt_0|s_cpt_out_reg[0].L |    7.313ns |      -58ps |
       1.091ns |      4 |Clock network delay (RR)to |

  • DOMAIN_clk2_to_clk3_Routed_[typical;bestcase;worstcase].timing: path are reported in the longest path.
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in[3].O to cpt_in_p_reg[3].I is the longest path.
  • FalsePath:
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is no longer the longest path.
 Code Block
destination register:
        |      +--------+--   +------+-------------------------+-------------+--------------------+------------+------------+----------------+--------+--------+

   |   |   No.  |  Slack |       |   Source         | Source            | Target/Net | Routing           delay | DataInternal Delaydelay | ClockCumulated Skewdelay |
Setup/Recovery |  Depth |  Note  |     |    +--------+--------+-------------------------+------------------+---------------+------------+------------+----------------+--------+--------++
     |   |      1 |    0ps | Pin: cpt_in_p_reg[1].CKLOGIC|lut_0[D]~csc~lut.O | PinNet: i_cpt_0|s_cpt_out_reg[0].L n15   |       1.167ns |    6.760ns |          -58ps |         1.091ns167ns |
       4 |      (RR)  |

  • DOMAIN_clk2_to_clk3_Routed_[typical;bestcase;worstcase].timing: none path is reported in the longest path.
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in[3].O to cpt_in_p_reg[3].I is no longer the longest path.
  • FalsePathSdc:
    • DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is no longer the longest path.
    • DOMAIN_clk2_to_clk3_Routed_[typical;bestcase;worstcase].timing: none path is reported in the longest path.
 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.
GeneratedClock
Description:
The user can create a clock directly or specifying its relationship with another clock using respectively createClock and createGenerateClock NXpython method.
When creating a clock directly, the user has to specify the period, the rising time and the falling time (so indirectly the duty cycle).
When creating a generated clock, the user has to specify the period relation and the duty cycle relation with another clock. Relation characteristics can be set by different parameters.
Hereafter an example for both methods in several uses:
 Code Block
 p.createClock(getClockNet('clk_second'),'clk_second',20000,5000,15000)
=> Clock with period of 50MHz with 50% duty cycle with 90° dephasing defined by a net
 Code Block
p.createClock(getPort('clk_main'),'clk_main',10000,0,5000) 
=> Clock with 100MHz with 50% duty cycle defined by an IO
 Code Block
breakoutModewide
p.createGeneratedClock(getClock('clk_main'),getRegisterClock('i_clock_0|counter_reg[0]'), 'clk_fabric',{'DivideBy': 2}) 
=> Clock is half the reference clock and defined by a register
Environment:
Here after the table of compliances for this testcase.
...
Variant
...
NG-MEDIUM NG-LARGE NG-ULTRA
...
Embedded
...
Yes
...
Simulation
...
No
...
Attributes
...
 
...
IP
...
 
...
Methods
...
createClock createGeneratedClock getPort getClockNet getRegisterClock
Table: StaConstraint GeneratedClock environment
Option: There is one option to check the impact of this constraint:
  • No option: Required frequency is set.
  • GeneratedClock: Required frequencies are set.
 
NanoXmap check: After project launching, the user can check in timing log files that required frequencies are set.
 Code Block
        |   + +-------------------------------+------------+---------------+----------------+-----------------+
        |         | Total                                      |       1.167ns |            0ps |         1.167ns |
        |         +--------------------------------------------+---------------+----------------+-----------------+
        |       
        |       Data path detail:
        |         +------------------+-------------------+--------+--------+---------------+----------------+-----------------+--------------+-------------------+
        |         |      Source      |     Target/Net    | Module | Region | Routing delay | Internal delay | Cumulated delay | Hold/Removal | Latch Clock Delay |
        |         +------------------+-------------+------+--------+--------+----+-----------+----------------+-----------------+--------------+------------------------------++
        |         | Pin: spw_din.O   | Net: spw_din      |      ~ |      ~ |  Domain     7.647ns |              - |         Frequency7.647ns |              |               Hold/Removal Summary   |
        |         |  Setup/Recovery SummaryPin: din_f_reg.I | Pin: din_f_reg.CK |      ~ |      ~ |             - |          +-----    - |         7.647ns |       -284ps |                   |
        |         +-------------------+-----------------------+------------+--------+-----+----------+--------------+-----------+-------+----------+--------------+-------------------+
        |         | Total         Source         |         Target        |  Required  |   Maximum   |   Slack  |  Minimum  Data | Minimum Required7.647ns |   Slack    | Maximum Data | Maximum Required0ps |         7.647ns |   |            |           1.167ns |
        |              |  +--------------------------------------------------------+---------------+----------------+-----------------+--------------+-------------------+
         |             |
For Input to rising edge clock DFF:
 Code Block
breakoutModefull-width
          | Arrival Time |   Relationship   |          | Arrival Time |RPath summary:
     Relationship   |         |   +--------+----------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+
        |         |  Slack |     Source     |      Target      | Data Delay | Latch Clock Delay | Setup/Recovery |  Depth |  Note  |
        |         +--------+----------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+
        |     | clk_fabric_1 (Rising)  | clk_fabric_1 (Rising) | 25.0000ps MHz| | 407.000 MHzPin: spw_din.O |  2.012nsPin: din_r_reg.I |      27.012ns784ns |           1.078ns |  0ps | 37.543ns |     337ps 2.457ns| |     1 |   40.000ns(-R) |
        |   +------------------------+----------      +--------+-----+------------+-------------+----------+-------------+-+------------------+----------+------+--------+------------------+
        |   | clk_fabric (Rising)    | clk_fabric (Rising)   | 50.000 MHz | 445.434 MHz
|  1.808ns |      1.808ns |       Clock network delay to destination register:
 0ps | 17.755ns |      2.245ns |         20.000ns |         |   +------------------------+-----------------------+------------+-------------+----------+--------------+------------------+----------+--------------+------------------+

 
Simulation check: No simulation environment is available for this testcase.
 
Board check: No board purpose for this testcase.
InputOutputDelay
Description:
The user can apply a minimum and a maximum data arrival time on inputs and outputs using respectively setInputDelay and setOutputDelay NXpython method.
These methods need a created clock to be set.
Hereafter an example for both methods:
 Code Block
p.setInputDelay(getClock('CLK_MAIN'),'rise',1000,10000,getPorts('cpt_in[`[0-3]`]'))  
p.setOutputDelay(getClock('CLK_MAIN'),'rise',1000,10000,getPorts('cpt_out[`[0-3]`]'))
getPorts method use regular expression format whereas getPort method use standard format.
Environment:
Here after the table of compliances for this testcase.
...
Variant
...
NG-MEDIUM NG-LARGE NG-ULTRA
...
Embedded
...
Yes
...
Simulation
...
No
...
Attributes
...
 
...
IP
...
 
...
Methods
...
createClock getPort getPorts getClock setInputDelay setOutputDelay
Table: StaConstraint InputOutputDelay environment
Option: There is one option to check the impact of this constraint:
  • No option: No created clock and no input or output delay is set.
  • InputOutputDelay: Input and output delay are set in relationship with a create clock.
 
NanoXmap check: After project launching, the user can check in timing log files that input and output delays are taken into account in the longest paths and that the maximum frequency is reduced drastically.
 Code Block
---------------+
        |         |                 Source                 |   Target/Net   | Routing delay | Internal delay | Cumulated delay |
        |         +--------+-----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+--------------------------------+
     |   |   No.  |   Slack | Pin: LOGIC|lut_1[D]~csc~lut~exp[6:1].O | Net: input_xor |       1.078ns |  Source            -  |              Target             | Data Delay | Clock Skew | Setup/Recovery |  Depth1.078ns |
        |              Note              |
    |   +--------+-----------+----------------------------------+-------+--------------------------+------------+------------+----------------+--------+--------------------------------+
    |
  |      1 | -17.951ns | Pin: i_cpt_2|s_cpt_out_reg[0].CK | Pin: cpt_out[0].I               |   20.240ns |   -7.711ns |      | Total        - |      1 |  setOutputDelay: 10.000ns (RR) |
    |   |      2 | -14.913ns | Pin: i_cpt_2|s_cpt_out_reg[2].CK | Pin: cpt_out[2].I                      |   17.202ns |   -7.711ns |              - |       1.078ns |  setOutputDelay: 10.000ns (RR) |     |  0ps |      3  | -131.769ns078ns |
Pin: i_cpt_2|s_cpt_out_reg[1].CK | Pin: cpt_out[1].I    |           |   16.058ns |   -7.711ns+---------------------------------------------------------+---------------+----------------+-----------------+
        |       
      -  |      1 |Data path setOutputDelaydetail:
10.000ns (RR) |        |   |      4 | -13.678ns | Pin: i_cpt_2|s_cpt_out_reg[3].CK | Pin: cpt_out[3].I   +------------------+-------------------+--------+--------+---------------+----------------+-----------------+----------------+-------------------+
        |         |      Source      |     Target/Net   15.967ns | Module | -7.711nsRegion | Routing delay | Internal delay | Cumulated delay | Setup/Recovery | Latch Clock -Delay |
       1 |  setOutputDelay: 10.000ns (RR) | |         +------------------+-------------------+--------+--------+---------------+----------------+-----------------+----------------+-------------------+
        |   |      5 |  -5.233nsPin: spw_din.O   | PinNet: cpt_in[1].Ospw_din      |      ~ |    | Pin: i_cpt_0|s_cpt_out_reg[3].L ~ |   21.756ns |    7.614ns784ns |        1.091ns |     - 2 |   setInputDelay: 10.000ns (RR) |    7.784ns |   |      6 |  -5.233ns | Pin: cpt_in[1].O  |                | Pin: i_cpt_0|s_cpt_out_reg[2].L |
  21.756ns |    7.614ns |        1.091ns | Pin: din_r_reg.I | Pin:  2 |din_r_reg.CK |    setInputDelay: 10.000ns (RR) ~ |     |  ~ |      7 |  -5.233ns | Pin: cpt_in[1].O   - |             | Pin: i_cpt_0|s_cpt_out_reg[1].L |- |    21.756ns |    7.614ns784ns |        1.091ns  337ps |      2 |          setInputDelay: 10.000ns (RR) |
    |    |      8 |  -5.233ns | Pin: cpt_in[1].O       +------------------+-------------------+--------+--------+---------------+----------------+-----------------+----------------+-------------------+
            | Pin: i_cpt_0|s_cpt_out_reg[0].L |   21.756ns |    7.614ns |    Total    1.091ns |      2 |   setInputDelay: 10.000ns (RR) |     |   |      9 |    -963ps | Pin: cpt_in[3].O                 | Pin: i_cpt_0|s_cpt_out_reg[3].L |   17.486ns |    7.614ns784ns |        1.091ns |      2 |   setInputDelay: 10.000ns (RR) |
    |   |     10 |    -963ps | Pin: cpt_in[3].O0ps |         7.784ns |       | Pin: i_cpt_0|s_cpt_out_reg[2].L |   17.486ns |  |  7.614ns |        1.091ns078ns |
     2   |     setInputDelay: 10.000ns (RR) |

...
 +--------------------------------------------------------+---------------+----------------+-----------------+----------------+-------------------+
Simulation check: No simulation environment is available for this testcase.
...