Training Package Application Note
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 https://nanoxplore-wiki.atlassian.net/wiki/spaces/~814749387/pages/48660481) and NanoXplore primitives (cf https://nanoxplore-wiki.atlassian.net/wiki/spaces/NAN/pages/35323913) 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
ExportIp
HsslEsistream
R5BootOutTcm
R5Debug
R5TcmBoot
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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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/NAN/pages/56393734 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
100It is equal to the following memory initialization:
0001
0100
0000
…
0000Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
For immediate trigger without pushbutton, replace step 4 and 5 by the following one:
-Launch NxScope capture with the following command in nxbase2 interactive shell:
nxscope capture outfile.vcd 25E6 immediate=1
-> Make sure outfile.vcd has been generated.
For NG-ULTRA, NxScopeV2 IP Core is used instead of NxScope.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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).
Configurations could be set in the python script file thanks to the addPad NXpython method.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
ExportIp
Description:
The user can generate an IP with its design and reuse it in a top project using exportAsIPCore NXpython method.
Exported IP can be genereted encrypted or not depending on set option.
Hereafter an example for this method:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | ExportAsIPCore |
Table: Ip ExportIp environment
Option: There is one option to check the impact of this constraint:
No option: RTL files are directly used.
ExportIp: RTL files are used to generate an encrypted IP and this IP is reused to generate a new project.
NanoXmap check: After project launching, the user can check in hdlfiles.rpt that IP is used to generate the new project.
Simulation check: No simulation environment is available for this testcase.
Board check: No board purpose for this testcase.
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.
The architecture of wrapper_hssl_esistream block is described as below :
Signal | Type | Description |
hssl_clock_i | In | HSSL clock input |
reset_n | In | Global reset for the application |
pma_ck_ref_i | In | Reference clock (for NG-LARGE DevKit, it is coming from an external oscillator (ESIstream 156MHz)) |
tx_rst_n | Out | Transmitter reset |
usr_tx_busy_o | Out | Asserted when reset is in progress |
usr_tx_esistream_sync_i | In | End of multiframe ESIstream synchronization input signal |
usr_tx_ctrl_driver_pwrdwn_i | In | TX driver is deactivated when asserted; output is at high impedance |
usr_tx_data_i | In | 8 data symbols to be sent by TX |
hssl_clock_o | Out | HSSL user clock sent to the fabric (48MHz) |
usr_pll_lock_o | Out | ‘1’: PMA CDR Pll is locked (Async Signal) |
usr_rx_ctrl_not_in_table_o | Out | Indicates presence of a not in table error in the corresponding symbol, when asserted. |
usr_rx_ctrl_dscr_null_o | Out | Indicates which octet is a lane character. The block marks where /A/ character was received, before replacing it based on the character replacement rules. |
usr_rx_ctrl_char_is_aligned_o | Out | Asserted when symbol is aligned. |
usr_rx_busy_o | Out | Asserted when reset is in progress. |
usr_rx_pll_lock_o | Out | Asserted when RX PLL is locked. |
usr_rx_esistream_sync_o | Out | End of multiframe ESIstream synchronization output signal |
Environment:
Here after the table of compliances for this testcase.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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
R5BootOutTcm
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
Table: Ip R5BootOutTcm 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
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 ) and NanoXplore primitives (cf ) 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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
For each testcase of the Training Package, an application note informing about implemented NanoXplore python methods (cf ) and NanoXplore primitives (cf ) 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
ExportIp
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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
ExportIp
Description:
The user can generate an IP with its design and reuse it in a top project using exportAsIPCore NXpython method.
Exported IP can be genereted encrypted or not depending on set option.
Hereafter an example for this method:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | ExportAsIPCore |
Table: Ip ExportIp environment
Option: There is one option to check the impact of this constraint:
No option: RTL files are directly used.
ExportIp: RTL files are used to generate an encrypted IP and this IP is reused to generate a new project.
NanoXmap check: After project launching, the user can check in hdlfiles.rpt that IP is used to generate the new project.
Simulation check: No simulation environment is available for this testcase.
Board check: No board purpose for this testcase.
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
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 ) and NanoXplore primitives (cf ) 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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
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 ) and NanoXplore primitives (cf ) 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
ExportIp
HsslEsistream
R5BootOutTcm
R5Debug
R5TcmBoot
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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
ExportIp
Description:
The user can generate an IP with its design and reuse it in a top project using exportAsIPCore NXpython method.
Exported IP can be genereted encrypted or not depending on set option.
Hereafter an example for this method:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | ExportAsIPCore |
Table: Ip ExportIp environment
Option: There is one option to check the impact of this constraint:
No option: RTL files are directly used.
ExportIp: RTL files are used to generate an encrypted IP and this IP is reused to generate a new project.
NanoXmap check: After project launching, the user can check in hdlfiles.rpt that IP is used to generate the new project.
Simulation check: No simulation environment is available for this testcase.
Board check: No board purpose for this testcase.
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.
The architecture of wrapper_hssl_esistream block is described as below :
Signal | Type | Description |
hssl_clock_i | In | HSSL clock input |
reset_n | In | Global reset for the application |
pma_ck_ref_i | In | Reference clock (for NG-LARGE DevKit, it is coming from an external oscillator (ESIstream 156MHz)) |
tx_rst_n | Out | Transmitter reset |
usr_tx_busy_o | Out | Asserted when reset is in progress |
usr_tx_esistream_sync_i | In | End of multiframe ESIstream synchronization input signal |
usr_tx_ctrl_driver_pwrdwn_i | In | TX driver is deactivated when asserted; output is at high impedance |
usr_tx_data_i | In | 8 data symbols to be sent by TX |
hssl_clock_o | Out | HSSL user clock sent to the fabric (48MHz) |
usr_pll_lock_o | Out | ‘1’: PMA CDR Pll is locked (Async Signal) |
usr_rx_ctrl_not_in_table_o | Out | Indicates presence of a not in table error in the corresponding symbol, when asserted. |
usr_rx_ctrl_dscr_null_o | Out | Indicates which octet is a lane character. The block marks where /A/ character was received, before replacing it based on the character replacement rules. |
usr_rx_ctrl_char_is_aligned_o | Out | Asserted when symbol is aligned. |
usr_rx_busy_o | Out | Asserted when reset is in progress. |
usr_rx_pll_lock_o | Out | Asserted when RX PLL is locked. |
usr_rx_esistream_sync_o | Out | End of multiframe ESIstream synchronization output signal |
Environment:
Here after the table of compliances for this testcase.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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
R5AxiBootOutTcm
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
Table: Ip R5BootOutTcm 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
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 ) and NanoXplore primitives (cf ) 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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
For each testcase of the Training Package, an application note informing about implemented NanoXplore python methods (cf ) and NanoXplore primitives (cf ) 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
ExportIp
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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
ExportIp
Description:
The user can generate an IP with its design and reuse it in a top project using exportAsIPCore NXpython method.
Exported IP can be genereted encrypted or not depending on set option.
Hereafter an example for this method:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | ExportAsIPCore |
Table: Ip ExportIp environment
Option: There is one option to check the impact of this constraint:
No option: RTL files are directly used.
ExportIp: RTL files are used to generate an encrypted IP and this IP is reused to generate a new project.
NanoXmap check: After project launching, the user can check in hdlfiles.rpt that IP is used to generate the new project.
Simulation check: No simulation environment is available for this testcase.
Board check: No board purpose for this testcase.
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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.
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 ) and NanoXplore primitives (cf ) 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.
Variant | All compliant variants from NanoXplore chips family |
Embedded | Embedded variant compliance in case the testcase only needs the fabric |
Simulation | Indicates whether a simulation environment is available or not on Modelsim |
Attributes | All attributes implemented in the VHDL code |
IP | All NanoXplore primitives, hard or soft IP implemented in the VHDL code |
Methods | All NanoXplore python methods implemented in the python script |
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 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes | nx_init |
IP |
|
Methods |
|
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”.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_port |
IP |
|
Methods |
|
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes | nx_use |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_keep syn_noprune |
IP |
|
Methods |
|
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes | syn_preserve |
IP |
|
Methods |
|
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.
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 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 for more details.
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NxScope NxScopeV2 |
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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:
-> 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.
Variant | NG-MEDIUM |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | initRegister |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_CKS NX_GCK |
Methods |
|
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:
NAME | Description |
ADD36 | 36 bits adder |
SUB36 | 36 bits subtractor |
SMUL18 | 18 bits signed multiplicator |
UMUL18 | 18 bits unsigned multiplicator |
ADD36_PIPE | 36 bits adder with input/output pipe stages |
SUB36_PIPE | 36 bits subtractor with input/output pipe stages |
SMUL18_PIPE | 18 bits signed multiplicator with input/output pipe stages |
UMUL18_PIPE | 18 bits unsigned multiplicator with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_DSP_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_IOB |
Methods |
|
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.
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:
NAME | Description |
DELAY | Feedback clock is delayed |
REF_DIVIDED (MEDIUM) / OSC_REF (LARGE/ULTRA) | Input REF is divided as reference clock / Internal oscillator is used and divided as reference clock |
OUT_DIVIDED | All outputs get a not null divider |
EXT_FBK | Feedback is external |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_PLL |
Methods |
|
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:
NAME | Description |
NOECC | 2kx24 memory with rising edge clock without ECC |
FAST | 2kx18 memory with rising edge clock with ECC detection only |
SLOW | 2kx18 memory with rising edge clock with ECC read repairing |
NOECC_PIPE | 2kx24 memory with falling edge clock without ECC with input/output pipe stages |
FAST_PIPE | 2kx18 memory with falling edge clock with ECC detection only with input/output pipe stages |
SLOW_PIPE | 2kx18 memory with falling edge clock with ECC read repairing with input/output pipe stages |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RAM_WRAP |
Methods |
|
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:
NAME | Description |
FALLING | Write and Read accesses are falling edge sensitive |
RISING | Write and Read accesses are rising edge sensitive |
Table: Component RfbConfig configuration description MEDIUM/LARGE
Hereafter the list of available configurations for ULTRA:
NAME | Description |
SPRAM | Single port RFB |
FALLING DPRAM | Dual port RFB falling edge sensitive |
RISING DPRAM | Dual port RFB rising edge sensitive |
WIDTH_EXT | 2 RFB are used for twice larger words |
HIGHT_EXT | 2 RFB are used for twice larger number of words |
2R1W | 2 RFB are used for 2 read ports |
Table: Component RfbConfig configuration description ULTRA
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | NX_RFB_WRAP NX_RFBDP_U_WRAP NX_RFBSP_U_WRAP NX_XRFB_32x36 NX_XRFB_64x18 |
Methods |
|
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SERVICE_WRAP |
Methods | createClock |
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.
Variant | NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SOC_INTERFACE_WRAP |
Methods |
|
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:
NAME | Description |
BYPASS | Input is directly routed to the output |
BYPASS_INVERT | Input is inverted to generate output |
DIV2 | Input is divided by 2 with a pattern to generate output with rising edge generation |
DIV2_FALLING | Input is divided by 2 with a pattern to generate output with falling edge generation |
DIV2_DELAY | Input is divided by 2 with a pattern to generate output with an additional delay |
DIV16 | Input is divided by 16 with a pattern to generate output |
DIV40 (ULTRA) | Input is divided by 16 with a divider to generate output |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | Yes |
Attributes |
|
IP | NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_WFG NX_IOM_CONTROL NX_IOM_DRIVER NX_IOB |
Methods | createClock |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_DSP_SPLIT |
Methods | addDspLocation |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP | NX_TRANSPOSE_FIR |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_BD NX_WFG |
Methods | addModule createRegion confineModule |
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:
NAME | Description |
ROM | Read Only Memory |
SPRAM | Single-Ported Random-Access Memory |
DPRAM | Double-Ported Random-Access Memory |
SPRAM_ECC | Single-Ported Random-Access Memory with Error Code Correction |
DPRAM_ECC | Double-Ported Random-Access Memory with Error Code Correction |
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_ECC |
Methods |
|
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP |
|
Methods | addMemoryInitialization getInstances |
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
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | Yes |
Attributes |
|
IP | IP_CDC FIFO |
Methods | addIp |
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 .
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_DFI |
Methods | addIp |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_HSSL_L_FULL |
Methods | createClock |
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:
-> 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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP NX_SCOPE NX_PLL NX_WFG |
Methods | addMemoryInitialization addMappingDirective |
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.
Variant | NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_R5_L_WRAP |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_SER NX_DES NX_WFG |
Methods |
|
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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | IP_SPW_BANK IP_FIFO_part NX_PLL NX_WFG |
Methods | addIp |
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:
-> 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.
Variant | NG-MEDIUM NG-LARGE |
Embedded | No |
Simulation | No |
Attributes |
|
IP | NX_PLL NX_WFG |
Methods |
|
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels |
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.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMappingDirective getModels getInstances |
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.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
Table: Pad Parameter environment
Option: No option is available for this testcase.
NanoXmap check: After project launching, the user can check in progress.rpt that IOs get the defined parameters.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | No |
Simulation | No |
Attributes |
|
IP |
|
Methods | addPad |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | constrainPath |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addDSPLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setFocus |
Table: PlacingConstraint Focus environment
Option: There is one option to check the impact of this constraint:
No option: A default focus is set by the tool.
Aperture: A focus is set to the tool.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createObstruction |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addBlackBox setAperture |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addRAMLocation |
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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createRegion addModule confineModule constrainModule |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addWFGLocation addPLLLocation addRingLocation |
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | setSite |
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:
Hereafter an example for equivalent SDC constraint:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createClock setClockGroup getClock |
Table: StaConstraint ClockGroup environment
Option: There 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:
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addMaxDelayPath addMinDelayPath addMulticyclePath getRegister |
Table: StaConstraint DelayPath environment
Option: There are several options to check the impact of this constraint:
No option: No delay path is set.
MaxDelayPath: A maximum delay path is set between 2 registers.
MinDelayPath: A minimum delay path is set between 2 registers.
MulticyclePath: A number of clock cycles is set between 2 registers.
MaxDelayPathSdc: A maximum delay path is set between 2 registers. Same constraints using SDC file.
MinDelayPathSdc: A minimum delay path is set between 2 registers. Same constraints using SDC file.
MulticyclePathSdc: A number of clock cycles is set between 2 registers. Same constraints using SDC file.
NanoXmap check: After project launching, the user can check in the DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing log files:
No option: i_cpt_0|s_cpt_out_reg[2].CK to i_cpt_1|s_cpt_out_reg[2].L is the longest path with 0ps of slack and no shortest path is reported.
MaxDelayPath/MaxDelayPathSdc: i_cpt_0|s_cpt_out_reg[0].CK to i_cpt_1|s_cpt_out_reg[1].L is still the shortest path but the slack is now negative.
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.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | addFalsePath getRegister getRegisters getRegistersByClock getPort createClock |
Table: StaConstraint FalsePath environment
Option: There is one option to check the impact of this constraint:
No option: No delay path is set.
FalsePath: A maximum delay path is set between 2 registers.
FalsePathSdc: A maximum delay path is set between 2 registers. Same constraints using SDC file.
NanoXmap check: After project launching, the user can check in the timing log files:
No option:
DOMAIN_clk_to_clk_Routed_[typical;bestcase;worstcase].timing: cpt_in_p_reg[3].CK to i_cpt_0|s_cpt_out_reg[0].L is the longest path.
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
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createClock createGeneratedClock getPort getClockNet getRegisterClock |
Table: StaConstraint GeneratedClock environment
Option: There is one option to check the impact of this constraint:
No option: Required frequency is set.
GeneratedClock: Required frequencies are set.
NanoXmap check: After project launching, the user can check in timing log files that required frequencies are set.
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:
Environment:
Here after the table of compliances for this testcase.
Variant | NG-MEDIUM NG-LARGE NG-ULTRA |
Embedded | Yes |
Simulation | No |
Attributes |
|
IP |
|
Methods | createClock getPort getPorts getClock setInputDelay setOutputDelay |
Table: StaConstraint InputOutputDelay environment
Option: There is one option to check the impact of this constraint:
No option: No created clock and no input or output delay is set.
InputOutputDelay: Input and output delay are set in relationship with a create clock.
NanoXmap check: After project launching, the user can check in timing log files that input and output delays are taken into account in the longest paths and that the maximum frequency is reduced drastically.
Simulation check: No simulation environment is available for this testcase.
Board check: No board purpose for this testcase.
© NanoXplore 2022