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 Impulse User Manual) and NanoXplore primitives (cf Impulse Library guide MEDIUM/LARGE) 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.

• 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

  • Serdes

  • SpacewireLoopback

  • SpacewireRoadmap

  • SpacewireRx

• MappingDirective

  • Adder

  • BlackBox

  • Memory

• Pad

  • Parameter

  • Registered

• PlacingConstraint

  • Aperture

  • ConstrainPath

  • ExportSites

  • Focus

  • Obstruction

  • PreplaceI

  • Region

  • RingLocation

  • Site

• ProcessingSystem

  • Interruptions

  • Watchdog

  • SoC AXI test

• StaConstraint

  • CaseAnalysis

  • ClockGroup

  • DelayPath

  • FalsePath

  • GeneratedClock

  • InputOutputDelay

  • ReportPath

  • SpacewireTiming

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.

• 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 Impulse Training Package User Manual 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:

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:

It is equal to the following memory initialization:

Environment:

Here after the table of compliances for this testcase.

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

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:

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.

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.

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:

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.

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.

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:

VHDL:

 Verilog:

Environment:

Here after the table of compliances for this testcase.

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.

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:

VHDL:

Verilog:

Environment:

Here after the table of compliances for this testcase.

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.

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 NanoXplore NXscope User Manual 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 NxBase2 User Manual for more details.

Environment:

Here after the table of compliances for this testcase.

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.

Open

Board Scope illustration

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:

-> Make sure the bitstream is successfully generated.

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

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

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

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

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

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

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:

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

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

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

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.

Open

Board ThermalSensor illustration

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.

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.

Ddfr

Description:

The user can use double data rate input/output using NanoXplore macro cells in the design code.

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.

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:

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.

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.

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.

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:

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.

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:

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.

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:

Hereafter the list of available configurations for ULTRA:

Environment:

Here after the table of compliances for this testcase.

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.

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. The whole design is working on USER_0 service bank pin clock.

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

Board check: 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.

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

Environment:

Here after the table of compliances for this testcase.

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:

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.

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.

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.

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.

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.

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 Common to System Converter (CSC)

• Using a simple/complex pad connected to a WFG

Using low-skew dedicated pads reduces clock skew delays in order to reach best performances during Static Timing Analysis.

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.

Option: No option is available for this testcase.

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

Hereafter the list of all inferred memories:

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.

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:

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:

It is equal to the following memory initialization:

Environment:

Here after the table of compliances for this testcase.

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

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.

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.

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.

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:

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

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

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.

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.

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.

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.

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:

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

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

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

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.

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.

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:

Environment:

Here after the table of compliances for this testcase.

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.

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:

Environment:

Here after the table of compliances for this testcase.

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.

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:

Environment:

Here after the table of compliances for this testcase.

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.

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 or modifyPad 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 addPad to create a pad:

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:

Environment:

Here after the table of compliances for this testcase.

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

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:

Environment:

Here after the table of compliances for this testcase.

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.

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 modifyAperture NXpython method.

Hereafter an example for this method:

Environment:

Here after the table of compliances for this testcase.

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:

Environment:

Here after the table of compliances for this testcase.

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.

ExportSites

Description:

The user can export placing constraints (setSite, …) 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:

Environment:

Here after the table of compliances for this testcase.

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

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

Environment:

Here after the table of compliances for this testcase.

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

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

• Focus: 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 addObstruction and modifyObstruction NXpython method.

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

Hereafter an example for this method:

Environment:

Here after the table of compliances for this testcase.

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:

Environment:

Here after the table of compliances for this testcase.

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.

Region

Description:

The user can confine a module in a region using addModule, addRegion 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:

or

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:

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:

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

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

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:

Environment:

Here after the table of compliances for this testcase.

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 fabric element (LUT, DFF, RF, CY, RAM,DSP) into a TILE/CGB using setSite NXpython method.

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

Hereafter an example of using this method:

Environment:

Here after the table of compliances for this testcase.

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.

ProcessingSystem

Interruptions

Description:

The user can generate interruptions from the Fabric to the SoC through SoC interface.

Environment:

Here after the table of compliances for this testcase.

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.

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 LED associated to the programmed watchdog is switched when watchdog counter limit is reached.

StaConstraint

CaseAnalysis

Description:

The user can specify a case analysis for the STA using setCaseAnalysis NXpython method.

The impact is during STA, constrained net will be interpreted as a constant equal to the specified value.

Hereafter an example for this NXpython method:

Environment:

Here after the table of compliances for this testcase.

Option: There are two options to check the impact of this constraint:

• No option: STA is launched only with createdClock.

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

Hereafter an example for equivalent SDC constraint:

Environment:

Here after the table of compliances for this testcase.

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:

Here after same constraints with SDC format:

The function getRegister gives the ability to get a register instance.

Environment:

Here after the table of compliances for this testcase.

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.

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

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

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

• Path between an input and a register.

• Path between all registers operating on 2 clock domains.

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.

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.

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

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

=> Clock with period of 50MHz with 50% duty cycle with 90° dephasing defined by a net

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

=> Clock is half the reference clock and defined by a register

Here after same constraints with SDC format:

Environment:

Here after the table of compliances for this testcase.

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.

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:

Here after same constraints with SDC format:

Environment:

Here after the table of compliances for this testcase.

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.

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.

Hereafter an example for both methods:

The aim of reportTiming or addReportTimingPath is to check the required frequency is reached between 2 registers.

Hereafter an example for both methods:

Environment:

Here after the table of compliances for this testcase.

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:

• ReportTiming option:

DOMAIN_clk_main_to_clk_main_Routed_worstcase.timing is generated with required timing path:

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.

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.

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:

• CreateClock: Both clocks are created.

For Input to falling edge clock DFF:

For Input to rising edge clock DFF:

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

Board check: No board purpose for this testcase.