Copyright

All the contents of this document are protected by the copyright law. They may not be disclosed to third parties or copied or duplicated in any form without 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 /wiki/spaces/~814749387/pages/48660481) and NanoXplore primitives (cf https://nanoxplore-wiki.atlassian.net/wiki/spaces/SANDBOX/pages/202244165) 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, …).

Here after the list of all available categories:

• 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.

• 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

  • DspConfig

  • IoConfig

  • PllConfig

  • RamConfig

  • RfbConfig

  • WfgConfig

• Design

  • DelayIo

  • DspCascaded

  • DspMultAcc

  • DspTranspose

  • LowskewManagement

  • MemInfer

• Init

  • Ram

• Ip

  • CrossDomain

  • Ddr2Dfi

  • HsslEsistream

  • R5AxiMaster

  • R5AxiSlave

  • R5Jtag

  • Serdes

  • SoC

  • SpacewireLoopback

  • SpacewireRoadmap

• MappingDirective

  • Adder

  • BlackBox

  • Memory

• Pad

  • Parameter

  • Registered

• PlacingConstraint

  • Aperture

  • ConstrainPath

  • DspLocation

  • Focus

  • Obstruction

  • PreplaceIp

  • RamLocation

  • Region

  • RingLocation

  • Site

• StaConstraint

  • ClockGroup

  • DelayPath

  • FalsePath

  • GeneratedClock

  • InputOutputDelay

Testcase content

Each testcase of this application note contains the following fields:

• Description: Global description of the aim of the testcase highlighting which method, primitive, IP, … is concerned and illustrated.

• Environment: It informs about all possibilities that can be performed in that testcase in order to help the user to get examples.

Table: Testcase example environment

• 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 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:

attribute NX_INIT: string;
attribute NX_INIT of s_mem: signal is "../initdata.nx";

The initdata.nx can have any extension format.

The file must be described in binary notation.

If there are not enough bits in the word line, it is extended with 0 values on MSB.

If there are not enough words, it is extended with 0 values on highest addresses.

The inidata.nx content in this design is the following one:

001
100

It is equal to the following memory initialization:

0001
0100
0000
…
0000

Environment:

Here after the table of compliances for this testcase.

Table: Attribute NxInit environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in memories.rpt that the target memory is initialized with the file “initdata.nx”.

        |     Ram 'RAM(X6AAF88E9)_s_mem' Analysis:
        |     	Port 0 : 
        |     		Slc  Size: 0
        |     		Addr Size: 4
        |     		Din  Size: 4 (W)
        |     		Dout Size: 4 (RS)
        |     	Array Depth 16
        |     	Array Width 4
        |     	INIT: ../initdata.nx

Simulation check: After simulation launching, the user can check the memory is initialized at the beginning of the simulation.

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:

attribute NX_PORT: string;
attribute NX_PORT of RST     : signal is "(location= IOB11_D09P, turbo= True, inputSignalSlope=20)";
attribute NX_PORT of cout0_a : signal is "[ all :( turbo=True, standard= LVCMOS, inputSignalSlope= 20)" &
                                         "; 0  : ( location= IOB5_D01P, standard= LVCMOS, drive= 2mA  )"            &
                                         "; 1  : ( location= IOB5_D01N, standard= LVCMOS, drive= 4mA  )"            &
                                         "; 2  : ( location= IOB5_D02P, standard= LVCMOS, drive= 8mA  )"            &
                                         "; 3  : ( location= IOB5_D02N, standard= LVCMOS, drive= 16mA )]";

Parameters are exactly the same and with the same available values than in the addPad method (location, standard, drive, …).

Environment:

Here after the table of compliances for this testcase.

Table: Attribute NxPort environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that the defined parameters are set for the corresponding pads.

        |     +-----------------+------+----------------+----------+---------+-------+----------------------+----------+---------------+--------------+-------+
        |     |       Name      |  I/O |    Location    | Standard | Voltage | Drive |      Termination     | SlewRate |   DelayLine   | Differential | Turbo |
        |     |                 |      |                |          |         |       | R / Weak / Reference |          |    In / Out   |              |       |
        |     +-----------------+------+----------------+----------+---------+-------+----------------------+----------+---------------+--------------+-------+
        |     | rst             | In   | IOB2_D08P      | LVCMOS   | 2.5V    | 2mA   |   None / PullUp / -  |   Medium | False / False |        False |  True |
        |     | cout0_a[0]      | Out  | IOB1_D01P      | LVCMOS   | 3.3V    | 2mA   |   None / PullUp / -  |   Medium | False / False |        False |  True |
        |     | cout0_a[1]      | Out  | IOB1_D01N      | LVCMOS   | 3.3V    | 4mA   |   None / PullUp / -  |   Medium | False / False |        False |  True |
        |     | cout0_a[2]      | Out  | IOB1_D02P      | LVCMOS   | 3.3V    | 8mA   |   None / PullUp / -  |   Medium | False / False |        False |  True |
        |     | cout0_a[3]      | Out  | IOB1_D02N      | LVCMOS   | 3.3V    | 16mA  |   None / PullUp / -  |   Medium | False / False |        False |  True |

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

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:

attribute NX_USE: string;
attribute NX_USE of s_mem_0: signal is "RAM";
attribute NX_USE of mult:  signal is "NX_DSP";

Parameters are exactly the same and with the same available values than in the addMappingDirective method. It affects memories (DFF, RF, RAM, RAM_ECC) and operators (LUT, CY, DSP)

Environment:

Here after the table of compliances for this testcase.

Table: Attribute NxUse environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in memories.rpt and operators.rpt that the mapping directives are used for the corresponding inferred instances.

        |     RAM Generation for s_mem_0
        |     Memory s_mem_0
        |     	Will be mapped into NX_RAM elements
        |     	Using 2K x 24 - No_Ecc Ram Configuration
WARNING |     	Mapping of Ram s_mem_0 (size = 32 words) into RAM elements is sub-optimal
        |     	Implementing Memory Array: 32 words of 4 bits
        |     		as 1 x 1 lines of 1 blocks of 2048 words of 1 x 24 bits
        |     		using 1 NX_RAM elements

        |     Operator Group:
        |     		Multiplier:    mult_mult
        |     	Will be collapsed to DSP due to an Hdl pragma on multiplier or adder
        |     Collapsing Operator Group:
        |     		Multiplier:    mult_mult
        |     Into DSP: DSP_mult_mult

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

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:

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;

Environment:

Here after the table of compliances for this testcase.

Table: Attribute SynKeep environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in place.log that signals are kept even though they don’t have any impact on any output.

        |     Setting net 's_keep_it_0_k' as mandatory
        |     Setting net 's_keep_it_1_k' as mandatory

Simulation check: No simulation environment is available 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:

attribute syn_preserve: boolean;

attribute syn_preserve of hier_in_row_p2: signal is true;

Environment:

Here after the table of compliances for this testcase.

Table: Attribute SynPreserve environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in place.log that signals are kept even though they don’t have any impact on any output.

        |   Converting nets
        |     Setting net 'hier_in_row_p2[0]_k' as mandatory
        |     Setting net 'hier_in_row_p2[4]_k' as mandatory
        |     Setting net 'hier_in_row_p2[5]_k' as mandatory
        |     Setting net 'hier_in_row_p2[3]_k' as mandatory
        |     Setting net 'hier_in_row_p2[2]_k' as mandatory
        |     Setting net 'hier_in_row_p2[1]_k' as mandatory

Simulation check: No simulation environment is available 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.

The NxScope IP is generated thanks to NxCore available in NanoXmap releases launching nxcore command and clicking on Generate after setting up all parameters.

Among parameters, the user can set data width, memory capacity and triggers signals. Please check 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.

Data are collected thanks to the JTAG interface using NxBase2 software. Please check NxScope related commands in https://nanoxplore-wiki.atlassian.net/wiki/pages/resumedraft.action?draftId=53215245 for more details.

Environment:

Here after the table of compliances for this testcase.

Table: Board Scope environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI all the connections with the JTAG interface.

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

Board check: The user can program the NanoXplore Evaluation Board and get data through a VCD file with the following steps:

1- Launch the script with the following command:

NXpython script_NG-XXX.py -- depending on your NX target.

-> Make sure the bitstream is successfully generated.

2- Enter in NxBase2 interactive shell with the following command:

nxbase2_cli -s

chip bitstream   load switch_NG-XXX/bitstream.nxb with XXX your NX target.

3- Configure the FPGA with the following command in nxbase2 interactive shell:

chip bitstream load top_NG-XXX/bitstream.nxb --with XXX your NX target.

-> Make sure the LED named "Ready" on the Devkit is turned on

4- Launch NxScope capture with the following command in nxbase2 interactive shell:

nxscope capture outfile.vcd 25E6 immediate=0

-> Check LED1 is not ON.

5- Push on 1st push-button (check pad allocation for io “trig” in sub_scripts/pads_NG-XXX.py with XXX your target) on board in order to active trigger.

-> Make sure outfile.vcd has been generated.

7- Quit nxbase2 interactive shell

8- Launch gtkwave in order to display captured on-board signals with the following command:

 gtkwave outfile.vcd

-> Make sure all signals are displayed with desired behavior.

SwitchBlink

Description:

The user can program a NanoXplore Evaluation board (DevKit) with a simple bitstream using switches and LEDs.

Environment:

Here after the table of compliances for this testcase.

Table: Board SwitchBlink environment

Option: No option is available for this testcase.

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.

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:

NXpython script_NG-XXX.py --depending on your NX target.

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

nxbase2_cli NXmap/switch_NG-XXX/bitstream.nxb --with XXX your NX target.

-> Make sure the LED named "Ready" on the Devkit is turned on

3- Check the 1st LED is blinking, the second switch (check pad allocation for io “in_1” in sub_scripts/pads_NG-XXX.py with XXX your target) drives the 2nd LED and the 1st switch (check pad allocation for io “rst” in sub_scripts/pads_NG-XXX.py with XXX your target) resets both LEDs.

-> 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.

Temperature is composed of 9 bits with the following mapping:

• [8:2]: Data. Data written in binary format in the range [0°C;125°C].

• 1: Overflow. Goes high when temperature is out of range.

• 0: Enable. Set high if the thermal sensor is activated.

Environment:

Here after the table of compliances for this testcase.

Table: Board ThermalSensor 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 THS interface.

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

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.

For NG-MEDIUM and NG-LARGE variants, only NX_CKS exists and can gate a clock. Consequently, a design is provided using NX_CKS to mux clocks.

For NG-ULTRA, NX_GCK is available and is converted to a mux or a clock switch depending on a generic when instantiating it.

The NanoXplore macro cells are glitch free and guarantee a non-disturbed generated signal.

Environment:

Here after the table of compliances for this testcase.

Table: Component ClockSwitch environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that 3 clock switches are counted (NG-MEDIUM + NG-LARGE). Macro cells CKS/GCK are observable in the GUI.

Simulation check: Frequencies of toggle DFF operating on clock switch output and clock mux output are checked.

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:

Table: Component DspConfig configuration description

Note configurations without pipe could be done by setting the generic std_mode to needed mode in the list [ADD_36; SUB_36; SMUL_18; UMUL18; SMUL_EXT; UMUL_EXT].

In addition, NX_DSP_SPLIT is more convenient to instantiate in the design code as raw_config generics are split depending on their mapping.

Environment:

Here after the table of compliances for this testcase.

Table: Component DspConfig environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that 8 DSP are counted. Macro cells are observable in the GUI.

Simulation check: DSP outputs are checked with multiple input values.

Board check: No board purpose for this testcase.

IoConfig

Description:

The user can make operations using NanoXplore IO macro cells in the design code.

6 configurations use as inputs and outputs are set implementing all available values if it is an exhaustive list (ex: standard) or min and max values for ranges (ex: termination).

Be aware some configurations can only me mapped to complex banks and not simple banks (termination, LVDS).

NG-MEDIUM is only suitable with weakTermination set to PullUp

Environment:

Here after the table of compliances for this testcase.

Table: Component IoConfig environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that test IO are listed in a table of configuration with set configuration.

        |     +-----------------+--------+------------+----------+---------+-----------+----------------------+----------+---------------+--------------+-------+
        |     |       Name      |   I/O  |  Location  | Standard | Voltage |   Drive   |      Termination     | SlewRate |   DelayLine   | Differential | Turbo |
        |     |                 |        |            |          |         |           | R / Weak / Reference |          |    In / Out   |              |       |
        |     +-----------------+--------+------------+----------+---------+-----------+----------------------+----------+---------------+--------------+-------+
        |     | data_o_test[14] | In/Out | IOB9_D08P  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |     Slow | False / False |        False | False |
        |     | data_i_test[1]  | In/Out | IOB12_D01N | LVCMOS   | 1.8V    | 16mA      |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_o_test[9]  | In/Out | IOB9_D05N  | LVCMOS   | 1.8V    | 2mA       |  None / PullDown / - |   Medium | False / False |        False | False |
        |     | data_i_test[4]  | In/Out | IOB12_D03P | SSTL     | 1.8V    | CatII     |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[10] | In/Out | IOB12_D06P | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[7]  | In/Out | IOB12_D04N | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_o_test[4]  | In/Out | IOB9_D03P  | SSTL     | 1.8V    | CatII     |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_o_test[11] | In/Out | IOB9_D06N  | LVCMOS   | 1.8V    | 2mA       |   None / Keeper / -  |   Medium | False / False |        False | False |
        |     | data_o_test[3]  | In/Out | IOB9_D10N  | SSTL     | 1.8V    | CatI      |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[5]  | In/Out | IOB12_D03N | HSTL     | 1.8V    | CatI      |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[17] | In/Out | IOB12_D09N | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium |  False / True |        False | False |
        |     | data_o_test[0]  | In/Out | IOB9_D01P  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[14] | In/Out | IOB12_D08P | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |     Slow | False / False |        False | False |
        |     | data_o_test[12] | In/Out | IOB9_D07P  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_o_test[13] | In/Out | IOB9_D07N  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[0]  | In/Out | IOB12_D01P | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[11] | In/Out | IOB12_D06N | LVCMOS   | 1.8V    | 2mA       |   None / Keeper / -  |   Medium | False / False |        False | False |
        |     | data_o_test[1]  | In/Out | IOB9_D01N  | LVCMOS   | 1.8V    | 16mA      |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_o_test[17] | In/Out | IOB9_D09N  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium |  False / True |        False | False |
        |     | data_o_test[8]  | In/Out | IOB9_D05P  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False |  True |
        |     | data_o_test[10] | In/Out | IOB9_D06P  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[12] | In/Out | IOB12_D07P | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[9]  | In/Out | IOB12_D05N | LVCMOS   | 1.8V    | 2mA       |  None / PullDown / - |   Medium | False / False |        False | False |
        |     | data_o_test[2]  | In/Out | IOB8_D02P  | LVDS     | 2.5V    | Undefined |   None / PullUp / -  |   Medium | False / False |         True | False |
        |     | data_o_test[15] | In/Out | IOB9_D08N  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |     Fast | False / False |        False | False |
        |     | data_i_test[2]  | In/Out | IOB7_D02P  | LVDS     | 2.5V    | Undefined |   None / PullUp / -  |   Medium | False / False |         True | False |
        |     | data_o_test[7]  | In/Out | IOB9_D04N  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[16] | In/Out | IOB12_D09P | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium |  True / False |        False | False |
        |     | data_o_test[5]  | In/Out | IOB9_D03N  | HSTL     | 1.8V    | CatI      |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_o_test[16] | In/Out | IOB9_D09P  | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium |  True / False |        False | False |
        |     | data_i_test[13] | In/Out | IOB12_D07N | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[15] | In/Out | IOB12_D08N | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |     Fast | False / False |        False | False |
        |     | data_i_test[8]  | In/Out | IOB12_D05P | LVCMOS   | 1.8V    | 2mA       |   None / PullUp / -  |   Medium | False / False |        False |  True |
        |     | data_i_test[3]  | In/Out | IOB12_D10N | SSTL     | 1.8V    | CatI      |   None / PullUp / -  |   Medium | False / False |        False | False |
        |     | data_i_test[6]  | In/Out | IOB12_D04P | LVCMOS   | 1.8V    | 2mA       |   50 / PullUp / VT   |   Medium | False / False |        False | False |
        |     | data_o_test[6]  | In/Out | IOB9_D04P  | LVCMOS   | 1.8V    | 2mA       |   50 / PullUp / VT   |   Medium | False / False |        False | False |

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

Board check: No board purpose for this testcase.

PllConfig

Description:

The user can generate clocks using NanoXplore PLL macro cells in the design code.

Hereafter the list of available configurations:

Table: Component PllConfig configuration description

There is no internal oscillator in NG-MEDIUM PLL.

Internal oscillator frequency is 200MHz for NG-LARGE and 400MHz for NG-ULTRA.

Environment:

Here after the table of compliances for this testcase.

Table: Component PllConfig environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that 4 PLL are counted. Macro cells are observable in the GUI.

Simulation check: PLL divided outputs frequencies are checked.

Board check: No board purpose for this testcase.

RamConfig

Description:

The user can store data using NanoXplore RAM macro cells in the design code.

Hereafter the list of available configurations:

Table: Component RamConfig configuration description

ECC means there is an Error Code Correction automatic process in order to correct single errors and detect double errors (or more).

In ECC Fast, the user needs to scrub its memory by himself.

In ECC Slow, the memory is automatically scrubbed in order to correct errors inside the memory but it needs an additional 90° phased clock.

Available memory sizes without ECC are [48kx1; 24kx2; 12kx4; 6kx8; 4kx12; 2kx24; 16kx3; 8kx6].

The only available memory size with ECC, fast or slow, is 2kx24;

Environment:

Here after the table of compliances for this testcase.

Table: Component RamConfig environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that 6 RAM are counted. Macro cells are observable in the GUI.

Simulation check: RAM are filled with writing operations and checked reading them back.

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 MEDIUM/LARGE:

Table: Component RfbConfig configuration description MEDIUM/LARGE

Hereafter the list of available configurations for ULTRA:

Table: Component RfbConfig configuration description ULTRA

Environment:

Here after the table of compliances for this testcase.

Table: Component RamConfig environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that RFB are counted. Macro cells are observable in the GUI.

Simulation check: RFB are written with data which are checked after reading.

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.

The service bank is used to spread the USER_0 primary pin as a clock because it is connected to the low-skew network.

Environment:

Here after the table of compliances for this testcase.

Table: Component Service environment

Option: No option is available for this testcase.

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.

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

Board check: The whole design is working on USER_0 service bank pin clock.

Soc

Description:

The user can interface with the Soc using NanoXplore SOC_INTERFACE macro cell in the design code.

The SoC interface is used to communicate with the Network Interconnect APB Master interface.

Environment:

Here after the table of compliances for this testcase.

Table: Component Soc environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, macro cell is observable in the GUI.

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

Board check: No board purpose for this testcase.

WfgConfig

Description:

The user can generate clocks using NanoXplore WFG macro cells in the design code.

Hereafter the list of available configurations:

Table: Component WfgConfig configuration description

Waveform generators are able to generate any pattern but are often used in order to divide clocks coming from a PLL or a PAD.

Environment:

Here after the table of compliances for this testcase.

Table: Component WfgConfig environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that 6 WFG are counted. Macro cells are observable in the GUI.

Simulation check: WFG output frequencies are checked.

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.

Environment:

Here after the table of compliances for this testcase.

Table: Design DelayIo environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, macro cells are observable in the GUI.

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

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.

DSP are cascaded from the right to the left on a Coarse Grain Block row.

The aim of DSP cascading is to use the 0ns routing delay between 2 DSP neighbors.

Environment:

Here after the table of compliances for this testcase.

Table: Design DspCascaded environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that DSP are counted. Macro cells are observable in the GUI.

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

Board check: No board purpose for this testcase.

DspMultAcc

Description:

The user can infer a 12*16+36 operations mapped in DSP.

Environment:

Here after the table of compliances for this testcase.

Table: Design DspMultAcc environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that DSP are counted. Macro cell is observable in the GUI.

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

Board check: No board purpose for this testcase.

DspTranspose

Description:

The user can implement a 6-tap transpose Finite Impulsion Response filter.

Transpose FIR IP can be generated thanks to nxcore NanoXplore software setting up multiple parameters.

Environment:

Here after the table of compliances for this testcase.

Table: Design DspTranspose environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that DSP are counted. Macro cells are observable in the GUI.

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

Board check: No board purpose for this testcase.

LowskewManagement

Description:

The user can interface with the low-skew network through several ways.

Low-skew network is used for signals spread to many registers with a high fanout like clock, reset, enable, …

The possibilities are the following and sorted by relevance and recommendation:

• Using a low-skew dedicated complex pad (highly recommended)

• Using a simple/complex pad and buffer in global_lowskew mode

• Using a simple/complex pad and buffer in local_lowskew mode

• Using 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 mode.

Environment:

Here after the table of compliances for this testcase.

Table: Design LowskewManagement environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.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 testcase.

Board check: No board purpose for this testcase.

MemInfer

Description:

The user can infer memories without instantiating NanoXplore macro cells in the design code.

Hereafter the list of all inferred memories:

Table: Design MemInfer configuration description

For Dual Ported memories, it is read after write processes. In addition, both processes for each port can work simultaneously.

ECC module can be added instantiating the ECC macro cell connected to data LSB.

Environment:

Here after the table of compliances for this testcase.

Table: Design MemInfer environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in memories.rpt that memories are recognized and mapped to NX_RAM. Macro cells are observable in the GUI.

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

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:

p.addMemoryInitialization(getInstances('g_loop_depth4[0].i_RAM_example.s_mem'),'NX','../initdata.nx')
p.addMemoryInitialization(getInstances('g_loop_depth8[0].i_RAM_example.s_mem'),'NX','../initdata.nx')

It can refer to an inferred memory or an instantiated NanoXplore macro cell.

It can refer to any memory mapping (RAM, RFB, DFF).

The initdata.nx can have any extension format.

The file must be described in binary notation.

If there are not enough bits in the word line, it is extended with 0 values on MSB.

If there are not enough words, it is extended with 0 values on highest addresses.

The inidata.nx content in this design is the following one:

001

100

It is equal to the following memory initialization:

0001

0100

0000

…

0000

Environment:

Here after the table of compliances for this testcase.

Table: Init Ram environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in synthesize.log that the target memories are initialized with the file

        |   Reporting Instance Initializers usage
        |     +--------------------------------------+------+----------------+--------------------------------------+
        |     |         Instance Initializer         | Type |     Mapping    |                 Usage                |
        |     +--------------------------------------+------+----------------+--------------------------------------+
        |     | g_loop_depth4[0].i_RAM_example.s_mem |  NX  | ../initdata.nx | g_loop_depth4[0].i_RAM_example|s_mem |
        |     | g_loop_depth8[0].i_RAM_example.s_mem |  NX  | ../initdata.nx | g_loop_depth8[0].i_RAM_example|s_mem |
        |     +--------------------------------------+------+----------------+--------------------------------------+

Simulation check: After simulation launching, the user can check that the memory is initialized at the beginning of the simulation.

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:

• IP_CDC: simple signal data clock domain crossing

• FIFO: data bus clock domain crossing

IP_CDC is included in NanoXplore release.

FIFO IP is generated with NxCore software.

Environment:

Here after the table of compliances for this testcase.

Table: Ip CrossDomain environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that soft IP are synthesized.

Simulation check: Check output of CDC and FIFO IP.

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.

It is a hardware IP as it configures IO and implement PLL and WFG from CKG.

The user has to adapt the pinout file to fit to the project needs.

For additional information, please have a look at NanoXplore_DDR2_DFI_IP documentation available on DDR2 DFI IP.

Environment:

Here after the table of compliances for this testcase.

Table: Ip Ddr2Dfi environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that the IP is synthesized.

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

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.

The HSSL configuration is compliant with ESI stream protocol.

The implemented design is an external loopback.

Environment:

Here after the table of compliances for this testcase.

Table: Ip HsslEsistream environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI macro cells are observable in the GUI.

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

Board check: The user can program the NanoXplore NG-LARGE Evaluation Board with the following steps:

1- Launch the script with the following command:

NXpython script_NG-LARGE.py

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

nxbase2_cli NXmap/switch_NG-LARGE/bitstream.nxb

-> Make sure the LED named "Ready" on the Devkit is turned on

3- Check the following points :

• 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.

R5 Core uses Axi Master port to boot.

Hereafter the architecture of the design:

Environment:

Here after the table of compliances for this testcase.

Table: Ip R5AxiMaster environment

Option: Only mainADD option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI that macro cell is observable.

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

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.

R5 Core uses Axi Slave port to boot on TCM memory.

Hereafter the architecture of the design:

Environment:

Here after the table of compliances for this testcase.

Table: Ip R5AxiSlave environment

Option: Only mainADD option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI that macro cell is observable.

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

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.

R5 Core uses DAP port to boot on TCM memory.

Hereafter the architecture of the design:

Environment:

Here after the table of compliances for this testcase.

Table: Ip R5Jtag environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI that macro cell is observable.

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

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.

Environment:

Here after the table of compliances for this testcase.

Table: Ip Serdes environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI that macro cell is observable.

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

Board check: No board purpose for this testcase.

SpacewireLoopback

Description:

The user can communicate with Spacewire link thanks to the NanoXplore SpaceWire macro cell.

SpaceWire IP can only be implemented in complex banks.

The implemented design is an external loopback.

Environment:

Here after the table of compliances for this testcase.

Table: Ip SpacewireLoopback environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI that macro cells are observable.

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

Board check: The user can program the NanoXplore Evaluation Boards with the following steps:

1- Launch the script with the following command:

NXpython script_NG-XXX.py with XXX the NX target

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

nxbase2_cli NXmap/switch_NG-XXX/bitstream.nxb with XXX the NX target

-> Make sure the LED named "Ready" on the Devkit is turned on

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.

Environment:

Here after the table of compliances for this testcase.

Table: Ip SpacewireRoadmap environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI connections with SPW interface.

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

Board check: No board purpose for this testcase.

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.

The following memory types can be mapped into the associated macro cells:

• ROM: RF/RAM

• SRAM: RF/RAM/RAM_ECC

• TPRAM: RF/RAM/RAM_ECC

• DPRAM: RAM/RAM_ECC

Each port of the declared component has to be mapped to the corresponding memory port.

The constraint has to be set with the following example syntax:

p.addBlackBox('sram','RAM',’RFB’,'CK(clk),AD(addr),DI(din),DO(dout),WE(we),RE(re)')

Environment:

Here after the table of compliances for this testcase.

Table: MappingDirective Blackbox environment

Option: There is one option for each kind of NanoXplore macro cell:

• No option: There is not any black box, VHDL source files are used.

• RF: ROM, SRAM and TPRAM are declared through a blackbox.

• RAM: ROM, SRAM, TPRAM and DPRAM are declared through a blackbox.

• RAM_ECC: SRAM, TPRAM and DPRAM are declared through a blackbox.

NanoXmap check: After project launching, the user can check in memories.rpt that elements are mapped into the desired NanoXplore macro cells.

        |     RAM Generation for i_RAM_top_sub|i_sram|ram
        |     Memory i_RAM_top_sub|i_sram|ram
        |     	Will be mapped into NX_RAM elements
        |     	Using 2K x 18 - Fast_Ecc Ram Configuration
WARNING |     	Mapping of Ram i_RAM_top_sub|i_sram|ram (size = 32 words) into RAM elements is sub-optimal
        |     	Implementing Memory Array: 32 words of 4 bits
        |     		as 1 x 1 lines of 1 blocks of 2048 words of 1 x 18 bits
        |     		using 1 NX_RAM elements

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

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.

The following memory types can be mapped into the associated macro cells:

• ROM: LUT/RF/RAM

• RAM: DFF/RF/RAM/RAM_ECC

In order to get inferred operator instances, the user needs to use getModels method. The name of the associated model or instance is described in the log file memories.rpt. For instance:

| Ram 'RAM_s_ram' Analysis: => Name of the model

In that case, the following constraint can be set:

p.addMappingDirective(getModels('RAM_s_ram'),'RAM',’RAM_ECC’) 

Environment:

Here after the table of compliances for this testcase.

Table: MappingDirective Memory environment

Option: There is one option for each kind of NanoXplore macro cell:

• No option: The mapping is done by the tool.

• FE: The ROM is mapped into LUT and the RAM is mapped into DFF.

• RF: The ROM and the RAM are mapped into RF.

• RAM: The ROM and the RAM are mapped into RAM.

• RAM_ECC: The RAM is mapped into RAM_ECC.

NanoXmap check: After project launching, the user can check in memories.rpt that elements are mapped into the desired NanoXplore macro cells.

        |     RAM Generation for s_ram
        |     Memory s_ram
        |     	Will be mapped into NX_RAM elements
        |     	Using 2K x 18 - Fast_Ecc Ram Configuration
WARNING |     	Mapping of Ram s_ram (size = 64 words) into RAM elements is sub-optimal
        |     	Implementing Memory Array: 64 words of 4 bits
        |     		as 1 x 1 lines of 1 blocks of 2048 words of 1 x 18 bits
        |     		using 1 NX_RAM elements

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

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.

The following operations can be mapped into the associated macro cells:

• Addition: LUT/CY/DSP

• Less than: LUT/CY/DSP

• Multiplication: CY/DSP

In order to get inferred operator instances, the user needs to use getModels or getInstances methods. The name of the associated model or instance is described in the log file operators.rpt. For instance:

| Operator 'LessThan_4u_4u' => Name of the model

| : LessThan_L27 => Name of the instance

In that case, the two following constraints have the same impact:

p.addMappingDirective(getInstances(LessThan_L27'),'LTN',’CY’)

p.addMappingDirective(getModels(LessThan_4u_4u'),'LTN', ‘CY’)

Environment:

Here after the table of compliances for this testcase.

Table: MappingDirective Operator environment

Option: There is one option for each kind of NanoXplore macro cell:

• No option: The mapping is done by the tool.

• LUT: Addition, LessThan are mapped into LUT.

• CY: Addition, LessThan and Multiplication are mapped into CY.

• DSP: Addition, LessThan and Multiplication are mapped into DSP.

NanoXmap check: After project launching, the user can check in operators.rpt that elements are mapped into the desired NanoXplore macro cells.

        |     Operator Group:
        |     		Pre-Adder/Sub: add_L24
        |     		Multiplier:    mult_L26
        |     	Will be collapsed into a DSP
        |     Collapsing Operator Group:
        |     		Pre-Adder/Sub: add_L24
        |     		Multiplier:    mult_L26
        |     Into DSP: DSP_mult_L26

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

Board check: No board purpose for this testcase.

Pad

Parameter

Description:

The user can configure pads with many parameters using addPad NXpython method.

The following parameters can be set by the method:

• Location: Defines the bank and the pad number and the pin number

• Standard: LVCMOS/LVDS/SSTL/HSTL

• Drive: 2mA/4mA/16mA (LVCMOS) / I/II (SSTL/HSTL) / Undefined (LVDS)

• slewRate: Slow/Medium/Fast

• termination: [35;100] (MEDIUM) / [34;102] (LARGE) / [32;92] (ULTRA)

• terminationReference: Floating/VT

• inputDelayOn: False/True

• inputDelayLine: [0;63]

• outputDelayOn: False/True

• outputDelayLine: [0;63]

• differential: False/True

• turbo: False/True

• inputSignalSlope: [0.5;20]

• outputCapacity: [0;40]

If the location is not set, the tool will set it automatically.

For other parameters, there are default values so it is not needed to constrain all parameters if they are equal to default ones.

Hereafter an example of using the method to constrain a pad:

p.addPad('input[0]’,{'location':'IOB10_D09P', 'standard': 'LVCMOS'} )

Environment:

Here after the table of compliances for this testcase.

Table: Pad Parameter environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.

        |     +-----------+------+------------+----------+---------+-----------+------------------------+----------+---------------+--------------+-------+
        |     |    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 |
        |     +-----------+------+------------+----------+---------+-----------+------------------------+----------+---------------+--------------+-------+

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

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.

The parameter registered can be set to the following values depending on the IO type:

• Input: I/IC

• Output: O/OC

• Inout: I/IC/O/OC/IO/IOC

I means the input is registered into the pad.

O means the output is registered into the pad.

C means the tri-state control is registered into the pad.

Hereafter an example of using the method to constrain a register into a NX_DFR:

p.addPad('input[0]’,{'location':'IOB0_D01P','registered' :'I'})

Environment:

Here after the table of compliances for this testcase.

Table: Pad Registered environment

Option: There is one option to check the impact of this constraint:

• No option: The register mapping is done automatically in the tile NX_DFF.

• Registered: The register mapping is done in the pad NX_DFR with an example of each possible value.

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.

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.

Hereafter an example for this method:

p.setAperture(8,1,12,6)

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint Aperture environment

Option: There is one option to check the impact of this constraint:

• No option: A default aperture is set by the tool.

• Aperture: An aperture is set to the tool.

NanoXmap check: After project launching, the user can check in the GUI that all synthesized elements are gathered in the specified area.

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

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.

The method uses a list of registers as sources and destinations.

This method is very useful in order to reach higher frequencies during STA when there are only a few critical paths that decrease the performance because of a too long routing delay.

Hereafter an example for this method:

p.constrainPath(['i_cpt_0|*'],['i_cpt_1|*'],'cpt0_1_m','Soft',9,6,2,3,'cpt0_1_r',False)

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint ConstrainPath environment

Option: There is one option to check the impact of this constraint:

• No option: The registers and logical elements between them are automatically placed by the tool.

• ConstrainPath: The registers and logical elements between them are in the specified region.

NanoXmap check: After project launching, the user can check in the GUI that registers and logical elements are gathered in the specified area.

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

Board check: No board purpose for this testcase.

DspLocation

Description:

The user can place manually a DSP using addDSPLocation NXpython method.

Hereafter an example for this method:

p.addDSPLocation('*DSP_mult_L28*','CGB[8x8]:R')

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint DspLocation environment

Option: There is one option to check the impact of this constraint:

• No option: The DSP is automatically placed by the tool.

• DspLocation: The DSP is placed into the specified CGB and side.

NanoXmap check: After project launching, the user can check in the GUI that the DSP is placed into the specified CGB and side.

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:

p.setAperture(8,1,12,6)

Environment:

Here after the table of compliances for this testcase.

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.

NanoXmap check: After project launching, the user can check in the GUI that all synthesized elements are gathered around the specified point.

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

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.

Consequently, all included resources in the specified regions cannot be used for the design.

Hereafter an example for this method:

p.createObstruction('OBSTR_0', 14, 6, 14, 8)

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint Obstruction environment

Option: There is one option to check the impact of this constraint:

• No option: The whole area is available to place elements.

• Obstruction: The specified region is not available to place elements.

NanoXmap check: After project launching, the user can check in the GUI that the specified area cannot be used.

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

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.

It is necessary to comply with the following rules:

• Set the minimum aperture to the IP.

• Declare the IP as a blackbox in the top project by adding the previous IP files.

• Set starting point Column x Row of the instance to a similar element (ex: TILE) than the IP aperture starting point.

• Save IP project file used in the top project file after end of routing.

In the top project, IP is declared as a module and the aperture and the starting point are used in order to compute the associated region.

Hereafter an example for this method:

p.addBlackBox('switch_counter',IP','../switch_counter_preplaced.nym','g_inst.i_switch_counter_0:1x8')

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint PreplaceIp environment

Option: There is one option to check the impact of this constraint:

• No option: No IP is used, VHDL files are used for synthesis.

• Preplace: Preplaced IP is used.

NanoXmap check: After project launching, the user can check in hierarchy.rpt that the IP is seen as a module.

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

Board check: No board purpose for this testcase.

RamLocation

Description:

The user can place manually a RAM using addRAMLocation NXpython method.

Hereafter an example of using this method:

p.addRAMLocation('g_loop[0].i_RAM_example|s_mem*','CGB[8x8]')

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint RamLocation environment

Option: There is one option to check the impact of this constraint:

• No option: The RAM is automatically placed by the tool.

• RamLocation: The RAM is placed into the specified CGB.

NanoXmap check: After project launching, the user can check in the GUI that the DSP is placed into the specified CGB.

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

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.

It is allowed to constrain several modules in the same region.

This method is very useful in order to reach higher frequencies during STA by confining modules in a region. That way, routing delays between registers can be drastically reduced.

Hereafter an example of using either 3 methods or 1 method which have the same impact:

p.addModule('up_counter','GEN_HIER2.COUNTER0','GEN_HIER2_COUNTER0-%','Soft')

p.createRegion('HIER2_COUNTER0', 13, 6, 14, 8,False)

p.confineModule('GEN_HIER2_COUNTER0-0', 'HIER2_COUNTER0')

or

p.constrainModule(‘|-> up_counter [ GEN_HIER2|COUNTER0 ]

', 'GEN_HIER2_COUNTER0-0','Soft', 13, 6, 14, 8, 'HIER2_COUNTER0',False)

When using the addModule method, the module name and instance name use regular expressions format. Thus, the user has to be careful with special characters.

Also, in case of generics in the module declaration, a hash code is computed by the tool and indicated in brackets after the module. For instance:

timing_pipe(X2A98C8C6)

Consequently, the user can either synthesize the project without constraint in order to get the hash code in hierarchy.rpt and insert it in the module name or use regular expressions to not mind of the computed hash code. The two following constraints can be used:

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

=> This constraint matches only with the synthesized set of generics and will not match if a generic is modified.

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

=> This constraint matches with all set of generics.

When using the constrainModule method, the user has just to copy all characters after the symbol “|->” in hierarchy.rpt and paste it in the constraint.

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint Region environment

Option: There is one option to check the impact of this constraint:

• No option: The whole design is placed automatically by the tool.

• Region: Declared modules are confined into their associated regions.

NanoXmap check: After project launching, the user can check in the GUI that the declared modules are confined into the specified regions.

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

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.

Hereafter an example for this method:

p.addPLLLocation('PLL_WRAPPER_0|NX_PLL_0','CKG4.PLL1')

p.addWFGLocation(‘PLL_WRAPPER_0|NX_WFG_0','CKG4.WFG_C1')

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint RingLocation environment

Option: There is one option to check the impact of this constraint:

• No option: PLL and WFG are automatically placed by the tool.

• RingLocation: PLL and WFG are placed into the specified location.

NanoXmap check: After project launching, the user can check in the GUI that the PLL and WFG are placed into the specified CKG and location.

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

Board check: No board purpose for this testcase.

Site

Description:

The user can place manually a register into a tile using setSite NXpython method.

Only a tile can be set, not a precise spot into this tile.

Hereafter an example of using this method:

p.setSite('*i_cpt_0.s_cpt_out_reg[0]','TILE[2x2]')

Environment:

Here after the table of compliances for this testcase.

Table: PlacingConstraint Site environment

Option: There is one option to check the impact of this constraint:

• No option: All registers are automatically placed by the tool.

• Site: The target register is placed into the specific tile.

NanoXmap check: After project launching, the user can check in the GUI that the DFF is placed into the specified tile. In order to focus to instance, use “Select instances” field and “Scale zoom” button.

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

Board check: No board purpose for this testcase.

StaConstraint

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:

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:

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]

Environment:

Here after the table of compliances for this testcase.

Table: StaConstraint ClockGroup 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 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:

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:

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.

Environment:

Here after the table of compliances for this testcase.

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.

    |   +--------+----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+-------------------------+
    |   |   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.

    |   +--------+--------+----------------------------------+---------------------------------+------------+------------+--------------+--------+-------------------------+
    |   |   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.

    |   |      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

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.

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.

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.

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.

    |   +--------+--------+-------------------------+---------------------------------+------------+------------+----------------+--------+--------+
    |   |   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.

    |   +--------+--------+-------------------------+---------------------------------+------------+------------+----------------+--------+--------+
    |   |   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:

 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

p.createClock(getPort('clk_main'),'clk_main',10000,0,5000) 

=> Clock with 100MHz with 50% duty cycle defined by an IO

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.

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.

        |   +------------------------------------------------+--------------------------+--------------------------------------------+--------------------------------------------+
        |   |                     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 method.

These methods need a created clock to be set.

Hereafter an example for both methods:

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]`]'))

Environment:

Here after the table of compliances for this testcase.

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.

    |   +--------+-----------+----------------------------------+---------------------------------+------------+------------+----------------+--------+--------------------------------+
    |   |   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.