Copyright

All the contents of this document are protected by the copyright law. They may not be disclosed to third parties or copied or duplicated in any form without consent of NanoXplore.

Introduction

Aim of document

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

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

Content

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

Test plan

List of categories

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

Here after the list of all available categories:

Attribute: Attributes can be inserted in the design in order to add a constraint on a register, a memory, …
Board: Designs to program NanoXplore evaluation boards (DevKit / BringUp).
Component: Multiple configurations for NanoXplore primitives.
Design: Various types of designs without any specific IP.
Init: Memory initialization
Ip: Designs implementing NanoXplore Ips.
MappingDirective:Directive of elements mapping in NanoXplore primitives.
Pad: Pad configurations.
PlacingConstraint: Constraints for manual placing of NanoXplore primitives.
ProcessingSystem: Communication between Programmable Logic and Processing System.
StaConstraint: Constraintsfor static time analysis.

List of testcases

Hereafter the list of all available testcases for each category:

Attribute:
- NxInit
- NxPort
- NxUse
- SynKeep
- SynPreserve
Board:
- Scope
- SwichBlink
- ThermalSensor
Component
- ClockSwitch
- Ddfr
- DspConfig
- IoConfig
- PllConfig
- RamConfig
- RfbConfig
- Service
- Soc
- WfgConfig
Design
- DelayIo
- DspCascaded
- DspMultAcc
- DspTranspose
- LowskewManagement
- MemInfer
Init
- Ram
Ip
- CrossDomain
- Ddr2Dfi
- HsslEsistream
- R5AxiMaster
- R5AxiSlave
- R5Jtag
- Serdes
- SpacewireLoopback
- SpacewireRoadmap
- SpacewireRx
MappingDirective
- Adder
- BlackBox
- Memory
Pad
- Parameter
- Registered
PlacingConstraint
- Aperture
- ConstrainPath
- ExportSites
- Focus
- Obstruction
- PreplaceI
- Region
- RingLocation
- Site
ProcessingSystem
- Interruptions
- Watchdog
- SoC AXI test
StaConstraint
- CaseAnalysis
- ClockGroup
- DelayPath
- FalsePath
- GeneratedClock
- InputOutputDelay
- ReportPath
- SpacewireTiming

Testcase content

Each testcase of this application note contains the following fields:

Description: Global description of the aim of the testcase highlighting which method, primitive, IP, … is concerned and illustrated.
Environment: It informs about all possibilities that can be performed in that testcase in order to help the user to get examples.

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/SANDBOX/pages/202244782 for more information.
NanoXmap check: What the user can observe after launching the NanoXmap project.
Simulation check: What the user can observe after launching the Modelsim simulation in case of available simulation environment.
Board check: What the user can observe after programming the bitstream on an DevKit Evaluation Board.

Testcase Description

Attribute

NxInit

Description:

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

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

The initdata.nx can have any extension format.

The file must be described in binary notation.

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

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

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

001
100

It is equal to the following memory initialization:

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

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

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

Board check: No board purpose for this testcase.

NxPort

Description:

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

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

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

Environment:

Here after the table of compliances for this testcase.

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.

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

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

Board check: No board purpose for this testcase.

NxUse

Description:

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

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

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

Environment:

Here after the table of compliances for this testcase.

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.

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

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

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

Board check: No board purpose for this testcase.

SynKeep

Description:

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

VHDL:

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

Verilog:

(*synthesis,syn_keep="true"*)    reg s_keep_it_0;
(*synthesis,syn_noprune="true"*) reg s_keep_it_1;

Environment:

Here after the table of compliances for this testcase.

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.

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

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

Board check: No board purpose for this testcase.

SynPreserve

Description:

By using syn_preserve attribute, the user can avoid any optimization of a register signal directly in the design code. The syntax is the following one:

VHDL:

attribute syn_preserve: boolean;
attribute syn_preserve of hier_in_row_p2: signal is true;

Verilog:

(*synthesis,syn_preserve="true"*) wire hier_in_row_p2;

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.

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

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

Board check: No board purpose for this testcase.

Board

Scope

Description:

The user can use NxScope IP by implementing it in the design code in order to check signals on a NanoXplore Evaluation board.

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

Among parameters, the user can set data width, memory capacity and triggers signals. Please check https://nanoxplore-wiki.atlassian.net/wiki/spaces/SANDBOX/pages/202244570 for more details.

In this example, the IP is already generated so the user can directly launch the project without opening NxCore.

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

Environment:

Here after the table of compliances for this testcase.

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.

Board Scope illustration

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

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

1- Launch the script with the following command:

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

-> Make sure the bitstream is successfully generated.

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

nxbase2_cli -s

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

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

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

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

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

nxscope capture outfile.vcd 25E6 immediate=0

-> Check LED1 is not ON.

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

-> Make sure outfile.vcd has been generated.

7- Quit nxbase2 interactive shell

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

gtkwave outfile.vcd

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

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

out_0 is inverted each period of 2^23 clock cycles.
out_1 is the inverted signal of in_1.

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

1- Launch the script with the following command:

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

-> Make sure the bitstream is successfully generated.

2- Configure the FPGA with the following command:

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

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

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

-> Make sure all this check points are OK.

ThermalSensor

Description:

The user can interface with the internal thermal sensor in order to retrieve the junction temperature.

Temperature is composed of 9 bits with the following mapping:

[8:2]: Data. Data written in binary format in the range [0°C;125°C].
1: Overflow. Goes high when temperature is out of range.
0: Enable. Set high if the thermal sensor is activated.

Environment:

Here after the table of compliances for this testcase.

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.

Board ThermalSensor illustration

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

Board check: Temperature bus is displayed on LEDs.

Component

ClockSwitch

Description:

The user can gate and mux clocks using NanoXplore macro cells in the design code.

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

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

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

Environment:

Here after the table of compliances for this testcase.

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.

Component ClockSwitch illustration NG-MEDIUM/NG-LARGE

Component ClockSwitch illustration NG-ULTRA

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

Board check: No board purpose for this testcase.

Ddfr

Description:

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

For input double data rate, macro cell NX_IDDFR generates 2 single data rate from 1 double data rate.

For output double data rate, macro cell NX_ODDFR generates 1 double data rate from 1 single data rate.

Environment:

Here after the table of compliances for this testcase.

Variant	NG-ULTRA
Embedded	No
Simulation	Yes
Attributes
IP	NX_IDDFR NX_ODDFR
Methods

Table: Component Ddfr environment

Option: No option is available for this testcase.

NanoXmap check: After project launching, the user can check in the GUI the DDFR cells close to the pad.

Component Ddfr illustration output

Component Ddfr illustration input

Simulation check: NanoXplore macro cells manage double data rate

Board check: No board purpose for this testcase.

DspConfig

Description:

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

Hereafter the list of available configurations:

NAME	Description
ADD36	36 bits adder
SUB36	36 bits subtractor
SMUL18	18 bits signed multiplicator
UMUL18	18 bits unsigned multiplicator
ADD36_PIPE	36 bits adder with input/output pipe stages
SUB36_PIPE	36 bits subtractor with input/output pipe stages
SMUL18_PIPE	18 bits signed multiplicator with input/output pipe stages
UMUL18_PIPE	18 bits unsigned multiplicator with input/output pipe stages

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.

Component DspConfig illustration

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.

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

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

Board check: No board purpose for this testcase.

PllConfig

Description:

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

Hereafter the list of available configurations:

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.

Impulse 23.3 Training Package : Application Note

Copyright

Introduction

Aim of document

Content

Test plan

List of categories

List of testcases

Testcase content

Testcase Description

Attribute

NxInit

NxPort

NxUse

SynKeep

SynPreserve

Board

Scope

SwitchBlink

ThermalSensor

Component

ClockSwitch

Ddfr

DspConfig

IoConfig

PllConfig