Table of figures

NanoXplore design flow

Rejected pattern for user module detection

HDL Modules Hierarchy Detail

Correct definitions for user modules detection

Wrong order for addModule() constraints

Correct order for addModule() constraints

View regions in nxmap

Zooming into a specific region through nxmap

Reporting regions

nxmap main window

NX Menu description

New project directory

Variant selection

HDL files, library selection, top cell library & top cell name

Generic parameters

Load project

Close project

Save project

Synthesize constraints

Placement constraints

Configure ring

Bitstream generation

Settings

About nxmap

Confirm on Exit

Edit Project

Edit options

View representation

Progress bar

View dashboard

Synthesize step

Map step

Synthesize and Mapping step options

Place and Route toolbar execution

Global place options

Static Timing Analysis options

Command bar options

List of matching elements

Select instances

Inspect option available with Select instances command

Instance info provided by Inspect

Edit Focus

Design resources placed around focus point

Default size of aperture

Edit aperture

Design resources placed after defining an accurate aperture

View obstructions

Hierarchy report providing user modules detection

Unused pattern reported due to incorrect addModule arguments

Output tables from reportInstances() method

Report region

Data and clock delay between a source and destination register

Examples of timing domains D1, D2, D3 in a simple design

Hold/Setup time relationship for active high launch and active high latch clocks

Hold/Setup time relationship for acitve high launch and active low latch clocks

Hold/Setup time relationship for active low launch and active high latch clocks

Hold/Setup time relationship for active low launch and active low latch clocks

Summary.timing example

Example 1 of critical paths table

Example 2 of critical paths table

Example of path detail table

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

Introduction

This document is intended to guide users of NanoXplore nxmap software through all the steps involved in the design flow and the options available in NanoXplore design suite:

• nxmap is a graphical interface that allows user to view and compile an existing project.

• nxpython is a wrapper around Python executable that allows user to control nxmap software as a wrapper. It fully supports Python syntax, structures and external modules.

• The creation of a new project can be performed with both nxmap and nxpython tools.

All commands described in this document for nxpython can be applied to the provided VHDL examples in example folder.

Currently, nxmap is provided to be run on a 64 bits Linux workstation running one of the following distributions:

• CentOS 7

• CentOS 8

• RedHat Enterprise Linux 7

• RedHat Enterprise Linux 8

nxmap needs Python but does not provide its own version to prevent conflicts. Thus, Python is required to be installed on user's workstation. Compatible Python versions start with 3.6 and upper ones.

For any other distribution or platform, please contact NanoXplore team at support@nanoxplore.com.

Package description

The provided nXmap archive contains the following directories:

• bin       folder contains binary files for each supported Linux distribution

• doc      folder contains documentation files in pdf format

• example folder contains several examples of different projects with design sources in VHDL

• lib64 folder contains dynamic libraries and Python modules for each supported Linux distribution and associated Python version

• share folder contains additional files (vhdl libraries, simulation libraries, etc...)

Installation

To install nxmap, the user needs to unpack nxmap-VERSION.tar.gz file into the installation directory (e.g. /opt/NanoXplore) using the following command:

$> tar xzf nxmap-VERSION.tar.gz -C /opt/NanoXplore

To set the license, it is required to export the following shell variable:

$> export LM_LICENSE_FILE=27000@servername

Where servername is the hostname of the server running the license daemon and 27000 is the port the daemon listens to.

Run Nxmap

To run nxmap, use the following command:

$> /opt/NanoXplore/nxmap/VERSION/bin/nxmap

Run nxpython

To run nxpython, use the following command:

$> /opt/NanoXplore/NXmap3/VERSION/bin/nxpython

To use the nanoxmap module in python, user must first call the following command in nxpython:

from nxmap import *

NanoXplore design flow

The complete NanoXplore design flow can be performed either through NX graphical user interface tool, nxmap, either through NX Python command-line tool, nxpython.

 NXmap supports vhdl and verilog files.

nxmap provides a graphical interface that helps user to create a project, investigate and inspect the design at various stages. For more information about nxmap, please refer to section Nxmap (Graphical User Interface).

nxpython is a Python wrapper that allows user to control nxmap software; it fully supports Python syntax, structures and external modules. User can employ nxpython for the entire design flow at once or specify the targeted steps to be performed.

 Both nxpython and nxmap are fully compatible with each other in a way that any file generated by one tool can be used by the other during any stage of the design flow.

Create project

Creating a new project starts from scratch, meaning defining a project directory with various sources and configuring several required and optional settings. NanoXplore tools allows to create a new project either from python commands within nxpython tool either by GUI with nxmap tool:

•  refer to section Nxmap (Graphical User Interface)  to create a project within the nxmap GUI interface.

•  refer to section Nxpython specification to create a project within the nxpython command interface.

Synthesize

Synthesis translates the design hardware description into a gate level netlist using FPGA resources.

The Synthesize step of design flow can be executed in both nxmap and nxpython environments (please refer to sections Synthesize and synthesize().

Place and route

The Place and Route steps are performed on the synthesized design generated in the previous step.

In these steps, solutions for implementation are found to fit user's design to the FPGA physical architecture:

• the placement task computes the positions of the basic instance elements based on design and user defined constraints.

• then the routing process assign signals of the design to routing resources in order to successfully route all nets while achieving a given overall performance.

 The Place and Route steps of design flow can be executed in both nxmap and nxpython environments:

•  refer to section Place & Route to launch corresponding states through nxmap GUI interface.

•  refer to sections place() and route() to launch corresponding steps through nxpython command interface.

Bitstream generation

The bitstream data format is used to program the FPGA. This step can only be launched after a successful routing step. Refer to sections Export bitstream and generateBitstream(file) for more details.

Design netlist generation and Simulation

In nxpython, it is possible to generate post-synthesis, post-place and/or post-route design netlists (Verilog or VHDL) which can be useful for simulation purposes (see section save(file)). In nxmap, intermediate netlists are automatically generated.

For design verification, third-party simulation tools can be employed on post-synthesis, place and/or route files. Generated design netlist is given along with the FPGA elements library. This library is provided to the user in VHDL protected format. The library file can be found at the following directory path:

$> /opt/NanoXplore/NXmap3/VERSION/share/modelsim/nxLibrary.vhdp

Static Timing Analysis

Static Timing Analysis (STA) can be performed by using its Timing Analyzer tool to analyze, debug, and validate the timing performance of the design.

This feature produces a detailed report on the timing characteristics of the design, i.e. timing domains in the design, longest/shortest paths in the domain, path delay, data arrival time, clock skew, etc.

Static Timing Analysis can be performed by nxmap (see section Static Timing Analysis) and nxpython (see section Static Timing Analysis related methods).

Logging

All messages generated by the application such as generic information, warning and error messages or reports are stored into several log and report files.

When using nxpython, “logsPython” subdirectory is created into the working directory and log files are created inside it during flow execution. nxpython provides several commands to print error, waning or texting user defined messages (see section Export bitstream).

When using the GUI, “logs” subdirectory is created into the working directory and log files and reports are saved inside.

Several log files are created:

Report generation

Several reports are generated during the design processing to give information about resources utilization such as instances, ports, regions or timing.

Hdlfiles report

nxpython lists in hdlfiles.rpt report all HDL source files provided to Verific tool and also reports in which source file the Top Cell is declared.

Hdlanalysis report

nxpython lists in hdlanalysis.rpt report the messages issued by Verific tool during the analysis of HDL source files. This files provides the name of all modules which have been compiled.

Fsmachines report

nxpython lists in fsmachines.rpt detailed information about finite state machines (FSM) identified in the design. If no FSM has been found, the file will be empty.

Hierarchy report

nxpython reports in hierarchy.rpt all instances for each module specifically kept by user with the command addModule(). By default, the file reports only the top level module, written ‘~’, if no module has been declared by user. See section addModule(model, instance, format) for description of this nxpython command and check carefully section Creating and handling regions for a complete and detailed example on the best way to keep modules.

Instances report

User has the possibility to generate instances report utilization of the design mapped on the current variant. For more information about generating instances report with nxpython, please refer to section reportInstances().

Latches report

nxpython lists in latches.rpt all latch elements synthesized during flow execution.

Maplogic report

nxpython prints in maplogic.rpt information issued during the mapping step for the standard logic processing such as flattening design, analyzing memory or analyzing dsp information. This files contains important information which can help for debug purpose.

Memories report

The memories.rpt file is organized in two sections:

• Memory Cells analysis reports all memory elements used during synthesis step. Models and instance names are provided.

• Memory Instances processing reports how memories are processed.

Operators report

The operators.rpt file is organized in two sections:

• Operator Cells analysis reports all operators (adder, subtractor, multiplier, comparator, etc…) used during synthesis step. Models and instance names are provided.

• Operator Instances processing reports how operators are transformed.

The first section is useful to identify names for command.

The second section is useful to verify that addMappingDirective commands have been properly identified and taken into account by nxpython.

Ports report

User has the possibility to generate report on the ports found in HDL source and the ones manually set by user in the project. For more information about generating ports report with nxpython, please refer to section reportPorts().

Region report

User has the possibility to generate report on the regions manually defined and distributed by user in the project. For more information about generating regions report with nxpython, please refer to section reportRegions().

Registers report

nxpython lists in registers.rpt all DFF elements without reset. It also indicates the number of DFF without HDL init info, which means without any initial context.

Timing report

The Timing analysis process creates several report files (.timing), each one containing information about a specific clock domain. For more information about timing report, refer to section Timing reports.

Unconnected report

nxpython prints in maplogic.rpt the list of unconnected nets processed during Synthesis flow execution. The information reported in this file depend on specific options of setOptions() command (see section setOption(name, value) for more details): ManageUnconnectedSignals and ManageUnconnectedOutputs. By default, the severity of these two options is set to Error, which means Synthesis flow execution will stop if any incorrect net implementation is encountered. In this case, details of invalid nets will be reported in the report.

Creating and handling regions

nxpython provides a set of commands that allows to create specific regions among the current FPGA target variant in which some user-defined logic can be restricted during Place and Route execution steps. In order for commands and constraints to be fully efficient and to produce expected results, user has to be vigilant on writing arguments and how syntax is interpreted, especially regular expressions, and impacts the behavior of the tool. The purpose of this section is to help user understanding the mechanisms behind the creation of regions through a complete example.

Adding modules

First, user has to define the particular logic resources that will have to be specifically restricted into a region. NanoXplore flow through nxpython tool provides a specific approach that consists in gathering logic elements and resources into identified modules through the existing design hierarchy and then confine these modules within regions created among the FPGA resources.

 To do so, it is important to identify the different hierarchies in the design where logic resources are located in order to add the corresponding module gathering all these elements requested by the user. User has to use the addModule() command that is described with details in section addModule(model, instance, format). Modules must be added before launching the execution of synthesis flow:

project = createProject()
project.addModule('up_counter',  'GEN_HIER2|COUNTER0',    'GEN_HIER2_COUNTER0-%') #incorrect
project.addModule('up_counter',  'GEN_HIER2|COUNTER1',    'GEN_HIER2_COUNTER1-%') #incorrect
project.save('/rtl/native.nym')
project.synthesize():
project.save('/rtl/synthesized.nym')

In this example, we want to add two different modules, called with GEN_HIER2_COUNTER0-% and GEN_HIER2_COUNTER1-% arguments, receiving each one a different instance, respectively COUNTER0 and COUNTER1, of the design logic identified with the up_counter model name. We can verify in the hierarchy.rpt report if the commands have been accepted by nxpython:

These lines report what has been performed with module definitions provided by the user during the execution of Synthesis flow steps. The User Modules Detection part of the Modules Hierarchy analysis section of the file reports the patterns used successfully or not for adding module. We see in previous that the GEN_HIER2|COUNTER0 pattern matches two different instances instead of one as expected whereas the second pattern was rejected as nxpython reports ‘Is Unused’. Let’s see the full design hierarchy reported in the HDL Modules Hierarchy Detail section of the same file in the following figure. 

The report confirms the hierarchy for both instances is correct:

-> up_counter [ GEN_HIER2|COUNTER0 ]
-> up_counter [ GEN_HIER2|COUNTER1 ]

But if the hierarchy is correct, keep in mind that instance and model arguments of addModule() function require regular expression patterns, meaning the ‘|’ operator acts as an ‘OR’ and that implies all instances inside GEN_HIER2 have already been identified with the first pattern. This explains why the second pattern reports ‘Is Unused’: the second instance we wanted to add in a second dedicated module previously matched with the first pattern. 

So, in order for the arguments to parse the exact hierarchy described in the report, we must use the ‘.’ operator as shown below:

project = createProject()
project.addModule('up_counter', 'GEN_HIER2.COUNTER0',    'GEN_HIER2_COUNTER0-%') #correct
project.addModule('up_counter', 'GEN_HIER2.COUNTER1',    'GEN_HIER2_COUNTER1-%') #correct
project.save('/rtl/native.nym')
project.synthesize():
project.save('/rtl/synthesized.nym')

And both addModule() commands match a result in hierarchy.rpt showed in the following figure.

The design hierarchy described in Figure 3 is described with a specific syntax. Let’s take GEN_HIER0 instance for example: The HDL design module name of GEN_HIER0 instance is labelled as row_col_pipe(X212B9C19), which is composed of the module name with an additional code. This code corresponds to the HASH code of all generics chosen on this module. This module contains several sub-instances:

|   ~

|   |-> LOGIC [ LOGIC ]

|   |-> row_col_pipe(X212B9C19) [ GEN_HIER0 ]

|   |   |-> timing_pipe(X2A98C8C6) [ GEN_HIER0|GEN_COL[0].COL_PIPE ]

|   |   |-> timing_pipe(X2A98C8C6) [ GEN_HIER0|GEN_COL[1].COL_PIPE ]

|   |   |-> timing_pipe(X2A98C8C6) [ GEN_HIER0|GEN_ROW[0].ROW_PIPE ]

|   |   |-> timing_pipe(X2A98C8C6) [ GEN_HIER0|GEN_ROW[1].ROW_PIPE ]

|   |   |-> up_counter [ GEN_HIER0|COUNTER0 ]

To add only a bunch of selected instances, carefully use the complete module name with HASH code, watch out regular expressions that may need to disable special operators with ‘\’ and use as much as possible the complete hierarchy for instance argument:

project = createProject()
project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0.GEN_COL[0].COL_PIPE', 
                      'GEN_HIER0_COL-%') #identify a module with parameters using its HASH code
project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0.GEN_COL[1].COL_PIPE', 
                     'GEN_HIER0_COL1-%') #identify a module with parameters using its HASH code
project.save('/rtl/native.nym')
project.synthesize():
project.save('/rtl/synthesized.nym')

Another point to address is to be careful of the constraints and the order they are written in the script. Let’s pursue with GEN_HIER0 instance, which instantiates five sub-instances as shown above. If an instance must be restricted to a specific region whereas the other ones at the same global level hierarchy must be placed in another region, it is important to respect the order in the declaration of the constraints.

If we declare the constraints like this:

project = createProject()
project.addModule('timing_pipe\(X2A98C8C6\)',  'GEN_HIER0*',    'GEN_HIER0_COL1-%')
project.addModule('timing_pipe\(X2A98C8C6\)',  'GEN_HIER0.GEN_COL[0].COL_PIPE',          
                      'GEN_HIER0_COL-%')p.save('/rtl/native.nym')
project.synthesize():

Hierarchy.rpt will report the following result in the following figure.

The ‘*’ regular expression took all instances inside GEN_HIER0 and once an instance has been placed with addModule(), it cannot be moved into another module definition. This is why the next pattern were rejected by nxpython. To have a valid set of constraints, here is the correct way to declare:

project = createProject()
project.addModule('timing_pipe\(X2A98C8C6\)',  'GEN_HIER0.GEN_COL[0].COL_PIPE',          
                      'GEN_HIER0_COL-%')
project.addModule('timing_pipe\(X2A98C8C6\)',  'GEN_HIER0.GEN_ROW[0].ROW_PIPE',
                      'GEN_HIER0_ROW-%')
project.addModule('timing_pipe\(X2A98C8C6\)',  'GEN_HIER0*',    'GEN_HIER0_COL1-%')
project.save('/rtl/native.nym')
project.synthesize():

The constraints are identical but the order of the declarations will perform what is expected as shown in the following figure.

For HDL modules instantiating generic instances, the HASH code of the module name has a direct impact on how to write the constraints:

project.addModule('timing_pipe',  'GEN_HIER0.GEN_COL[0].COL_PIPE',          
                  'GEN_HIER0_COL-%') #incorrect syntax, pattern won’t match

The model argument is incomplete and the pattern will not match during synthesis. To identify one specific instance having a HASH code, the following syntax must be respected:

project.addModule('timing_pipe\(X2A98C8C6\)',  'GEN_HIER0.GEN_COL[0].COL_PIPE',          
                 'GEN_HIER0_COL-%') #correct syntax with HASH code

Creating regions

Once logic resources have been kept within user-added modules and Synthesis flow step execution is over, we can now start to create regions in which we want to confine our specific modules. The following example uses modules defined and verified in the previous section. See section createRegion(name, column1, row1, column2, row2, exclusive) for detailed information about the command.

project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0.GEN_COL[0].COL_PIPE',   
                  'GEN_HIER0_COL-%')
project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0.GEN_ROW[0].ROW_PIPE',   
                  'GEN_HIER0_ROW-%')
project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0*',    'GEN_HIER0_COL1-%')
project.addModule('up_counter',      'GEN_HIER2.COUNTER0',    'GEN_HIER2_COUNTER0-%')
project.addModule('up_counter',      'GEN_HIER2.COUNTER1',    'GEN_HIER2_COUNTER1-%')

project.save('/rtl/native.nym')

# Synthesis
project.synthesize():
project.save('/rtl/synthesized.nym')
# Create regions once Synthesis is done 
project.createRegion('HIER2_COUNTER0',   14, 6, 13, 6)
project.createRegion('HIER2_COUNTER1',   22, 6, 23, 6)
project.createRegion('GEN_HIER0_COL',     6, 6,  7, 6)
project.createRegion('GEN_HIER0_COL1',   4, 6,  3, 6)
project.createRegion('GEN_HIER0_ROW',   10, 6,  9, 6)

Confining modules into regions

Once regions are successfully created, we just have to confine the modules previously added with the logic inside into the newly created regions, using confineModule() command. See section confineModule(name, region) for detailed information about the command.

project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0.GEN_COL[0].COL_PIPE',   
                  'GEN_HIER0_COL-%')
project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0.GEN_ROW[0].ROW_PIPE',   
                  'GEN_HIER0_ROW-%')
project.addModule('timing_pipe\(X2A98C8C6\)',     'GEN_HIER0*',    'GEN_HIER0_COL1-%')
project.addModule('up_counter',      'GEN_HIER2.COUNTER0',    'GEN_HIER2_COUNTER0-%')
project.addModule('up_counter',      'GEN_HIER2.COUNTER1',    'GEN_HIER2_COUNTER1-%')

project.save('/rtl/native.nym')

# Synthesis
project.synthesize():
project.save('/rtl/synthesized.nym')

# Create regions once Synthesis is done and confine modules in them
project.createRegion('HIER2_COUNTER0',   14, 6, 13, 6)
project.createRegion('HIER2_COUNTER1',   22, 6, 23, 6)
project.createRegion('GEN_HIER0_COL',     6, 6,  7, 6)
project.createRegion('GEN_HIER0_COL1',   4, 6,  3, 6)
project.createRegion('GEN_HIER0_ROW',   10, 6,  9, 6)

project.confineModule('GEN_HIER2_COUNTER0-1',      'HIER2_COUNTER0')
project.confineModule('GEN_HIER2_COUNTER1-1',      'HIER2_COUNTER1')
project.confineModule('GEN_HIER0_COL-1',      'GEN_HIER0_COL')
project.confineModule('GEN_HIER0_COL1-1',    'GEN_HIER0_COL1')
project.confineModule('GEN_HIER0_ROW-1',     'GEN_HIER0_ROW')

project.place()
project.reportRegions()
project.route()

Once the Place and Route flow steps are executed, we can check in nxmap through the graphical View where the regions have been placed in and how the logic inside modules have been confined in the followinf figure.

Zooming inside the region HIER2_COUNTER1 will give us a visual overview of the logic elements confined inside, as it is shown in the following figure.

The region HIER2_COUNTER1 is delimited with yellow outlines and the logic elements confined inside are visually reported in the same color than the one used for the region outlines. Each region created is represented in nxmap with a different color and so are the logic resources confined into the different regions whereas unconfined elements remained in the classic color used to represent logic instances implemented in the FPGA variant target.

To go further, the reportRegions() method can be used within the nxpython script to generate a report with the amount and the percentage of logic resources confined into the different regions. See section reportRegions() for more information on this command. The regions.rpt file generated will prints the following information related to every region created during the flow execution (see the following figure).

Attributs

Attributs can be set to signals in the design code in order to tag this signal and affect some configurations.

Nx_init

NX_INIT attribute is used to initialize an inferred memory with a file.

Example:

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

Nx_port

nx_port attribute is used to configure an IO pad.

Example:

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 )]";

Nx_use

nx_use attribute is used to add a mapping directive to a memory or an operator.

Example:

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

Syn_keep

syn_keep or syn_noprune attributes are used to set a net as mandatory disabling signal optimization.

Example:

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;

Syn_preserve

syn_preserve attribute is used to set a register as mandatory disabling signal optimization.

Example:

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

Nxmap (Graphical User Interface)

Main window

Launching nxmap opens the main window of the tool within the graphical interface (following figure).

The nxmap main window is composed of:

• a vertical toolbar menu displaying major tool functionalities around NX Menu, Edit Project, View & Timing Analyzer buttons

• a horizontal progress bar presenting Synthesize, Place & Route flow steps

• a python console showing script instruction equivalencies for nxmap commands

• a log console printing command and flow execution

Toolbar menu

The toolbar menu is organized around:

• NX Menu, a global menu allowing user to manage environment and project settings

• Edit Project, which handles design parameters and sources of the current project

• View, which shows graphical representation of the loaded project fitted to selected FPGA

• Timing Analyzer, which launches static timing analysis for a placed & routed design

Each functionality of the toolbar is developed through detailed examples in the following subsection.

NX Menu

Selecting NX menu section allows user to access various a set of options for project management (following figure).

NX Menu provides the following tasks:

• New Project creates a project from scratch

• Load Project can open an existing project from several flow steps

• Close Project closes current project without saving

• Save Project saves data of the current project

• Synthesis Constraints allows to check defined mapping directives, memory initializations, black box & module declarations

• Placement Constraints allows to check defined focus, aperture, regions and obstructions for current project

• Configure Ring allows to assign and check I/O pads, banks and CKG configurations based on resources available from selected FPGA variant

• Report Instances lists resources based on the FPGA variant used for current project to map HDL elements of the design

• Export Bitstream generates a bitstream file at nxb format

• Settings allows to define and change user’s preferences for nxmap if needed

• About gets information about the current version of nxmap tool

• Quit closes the current gui session

New Project

By selecting New Project, nxmap will launch a succession of several wizard windows to configure settings in order to create a project environment from scratch. The project name consists in the directory name of the folder where scripts, files and reports will be included. It is different from the Top Cell name of the HDL top level of the design, which is defined in Source and top level entity wizard window (see Source and top level entity)).

Directory

Define or create the directory in which all design, report and log files will be generated during flow steps (following figure)

User can navigate among existing directories through the graphical interface or create a new one if needed:

	icon Go to parent directory
	icon Go to home directory
	icon Go to current working directory
	icon Create a new directory

Choose Next when the project directory has been set or Cancel to quit

Variant

Variant wizard window is used to select the target chip among available NanoXplore products. Variants are organized through FPGA devices and embedded FPGA (eFPGA) devices (following figure). Specifications, resources and technology for each target are provided through:

• Logic Modules gathering the amount of ASIC gates, DFF, LUT-4 and Carry elements

• Embedded RAM gathering the amount of DPRAM and Core Register File elements

• Additional Features gathering the amount of DSP, SpaceWire PHY & Codec, SERDES Tx/Rx, Hard IP processor core and SOC peripheral elements

• Clock/PLL gathering the amount of Clock and PLL elements

• I/O Banks gathering the amount of Simple and Complex Banks in the selected variant

Choose Next when the project variant has been set, Previous to return to previous wizard window or Cancel to quit.

Source and top level entity

Select HDL files or directories containing HDL files to be added to the sources of the current project (following figure). Selecting a directory on the left board will add all files in it to the right board when clicking on corresponding right arrow icon. Selected HDL files, using available keyboard shortcuts ctrl+A or ctrl+left click, among the sources of the right board can be removed when clicking on corresponding left arrow icon.

You also have the ability to create or remove any library directory from the right board with the corresponding Add and Remove icons.

Top cell name field must respect the name of top cell as it is declared in the top level HDL file of the project.

Top cell library field is used to specify the library in which the top cell is defined.

Choose Next when sources and top cell name have been set, Previous to return to previous wizard window or Cancel to quit.

Generic parameters

Specify HDL parameters for top level design. Whether you declare parameters or not, choose create to exit the wizard manager and finish project creation (following figure). Choose Create to finish and create the current project, Previous to return to previous wizard window or Cancel to quit. nxmap/nxpython can also assign generic parameters to the top level of the user’s design. For assignment of parameters by nxpython, see the commands addParameter(name, value) or addParameters(parameters).

Load project

To load a project, user has to select Load Project tab in NX Menu toolbar.

In the Load Project content section (following figure), each state Synthesize, Place & Route with their associated flow steps can be loaded if a file at nym format has been generated during flow execution of the corresponding step. Detailed information about the corresponding Variant, Top cell and State of the current design are visually provided when selecting a file.

Close project

The current project can be closed by clicking on the Close Project icon in the NX Menu without exiting nxmap. Closing the current project will remove all design information related to Edit Project, View and Timing Analyzer toolbar buttons; meaning these functions will remain unusable until a new project is created or an existing one is loaded (following figure)

Save Project

User can save a current project state in the NX Menu at any flow step in nym format (following figure).

Synthesis Constraints

Wizard window Checking mapping directives, memory initializations, black box & module declarations set for the current project (following figure). A module is a feature used by nxpython/nxmap to identify specific HDL instances which should be kept during the execution of the flow, in order to be placed in selected user-defined resources of the current FPGA target for example. This feature can be used for placement constraints (see section Creating and handing regions).

Synthesis Constraints

Wizard window Checking focus, aperture, regions and obstructions defined for the current project (following figure): 

• Focus is a target point placed in a TILE to define a central resource around where the HDL logic elements will be mapped and placed (see setFocus(column, row)).

• Aperture represents the border limits where resources kept inside aperture should be used by the tool for map and place (see setAperture(column1, row1, column2, row2)).

•  Regions are a user-defined set of delimited FPGA resources inside which should be confined specific HDL logic elements (see Creating and handing regions).

• Obstructions are a user-defined set of delimited FPGA resources which will not be used by the tool for mapping, placing and routing resources (see createObstruction(name, column1, row1, column2, row2)). These user-defined resources are removed from the design implementation.

Synthesis Constraints

Configure Ring wizard window allows user to check and modify configuration for I/O pads, banks and CKG devices used to map design elements. All top entity inputs/outputs of user’s design will automatically be added to this window with aleatory pad, bank and CKG assignments if no configuration has been specified previously within user’s script during nxpython execution.

I/O pads, banks & CKG configuration

The Configure Ring wizard window is divided into several sections (following figure):

• the I/O configuration section describes how inputs/outputs ports of the current design are mapped on specific pads with associated features (location, standard, drive, weak termination, slew rate, termination, input delay line, output delay line, differential, termination reference, turbo, signal slope, output capacity & register type). Pad features are described in addPad(name, parameters) command section.

• Banks section describes which banks with associated voltage are configured for the inputs/outputs of the top entity design.

• CKG configuration section describes which CKG are used to control clock distribution into the design.

Export

I/O configuration, Banks and CKG configuration contents can be automatically exported into an external file. The user can choose to export this content either in a python script either in a csv file.

Import

The user also has the ability to import an external set of pads assignment to Configure Ring, which can be defined either in a dedicated python script or in a csv file.

Report instances

Report Instances shows the amount and percentage of resources used in the FPGA to map the current design. The information is gathered into an array printed into the general log file. Occupied resources are reported as the following items: 4-LUT, DFF, XLUT, Carry, Register file block, Cross domain clock, clock buffer, Clock switch, Digital signal processor, WFG (WaveForm Generator) and PLL.

Export bitstream

Export Bitstream opens a wizard window to generate a bitstream file at nxb format. Generation of a bitstream file is only available once all the Synthesize, Place & Route flow steps of nxmap have been successfully executed. A various set of options are available to generate the bitstream file (following figure).

Settings

The Settings tab allows user to edit some parameters and preferences of nxmap (following figure).

The General subsection allows user to change the graphical theme, define the default filename save format used during flow execution. The save format field is set by default to %S-auto.nym with %S taking current flow step name like Synthesize, Place and Route). Last option choose whether or not to create project after destroying, this mean is automatically called when the project is destroyed.

The View subsection allows user to change parameters about the view. User can change the mouse button associated to Zoom Button action, invert zoom direction associated to the Mouse wheel zoom option and Use dynamic filter for selection.

The Confirmation subsection allows user to choose whether to be warned when exiting the application, closing or regressing a project and overwriting a file.

About

The About tab shows information of the nxmap Version, Libraries, License and Copyright statements (following figure).

Quit

Quit closes the current gui session. By default, a wizard window asking confirmation for exit will show. This window can be directly disabled by selecting Never as again option (following figure) or by selecting Confirm on Exit: Never option in Settings wizard window (Figure Settings).

Edit Project

The Edit Project toolbar tab allows user to access basic elements of the current project located in the directory path such as source files and more. Selecting this tab will open a window with fields which can be edited (following figure).

Path

Path defines the current project directory. All design, log and report files are be generated inside this directory.

Variant

Variant selects among current available NanoXplore products which FPGA or embedded FPGA component is set for the current project.

Sources

Sources allows the user to add all required design files for the current project. Currently supported design files are at .vhd, .vhdl or .v format.

The left window allows user to navigate in folders and select files to add in the project. The right window shows the selected project files and library used as sources for current project. Following actions can be performed (Figure 26):

• Add button allows to create a Library folder into the source list added to the project

• Remove button allows to delete a selected library from the source list. Be careful, deleting a selected  library will erase all files included in it

• right arrow adds any HDL file or directory containing multiple HDL files selected in the left window to the project in the current selected library in the right window

• left arrow removes any selected HDL file from the sources used for the current project

Top cell name & Top cell library

Top cell name defines the name of top cell as it is declared in the top level HDL file of the project.

Top cell library is used to specify the library in which the top cell is defined.

Parameters

Parameters defines top‘s parameters or generic values to be used in current project.

Edit options

Edit options button gives access to configure options set for Synthesize, Place & Route step flows (following figure). Details for the following options are available in setOption(name, value) part.

View

The View toolbar tab provides a graphical representation of the FPGA target and the HDL elements of the current design in the content section (following figure).

View offers several functionalities to interact with the graphical representation of the design.

Progress bar

The Progress bar (following figure) shows the state of the project and is organized around three main flow states with their associated steps:

• Synthesize flow is organized around two steps

• Place flow is organized around five steps

• Route flow is organized around three steps.

Completed steps are progressively filled in green during flow execution whereas uncompleted ones remain in blue when moving the mouse cursor over the steps. By clicking on a step, the user can launch flow execution up to a selected finishing state, by clicking on a state that is not already completed

Dashboard

The dashboard section of the View provides an overview of the architecture (following figure). User can interact with the dashboard by scrolling and zooming in/out with the mouse cursor. When scrolling and zooming into the dashboard, the main graphical view is scrolled/zoomed in the same way.

When the cursor is on the view widget or the dashboard, the mouse has the following behavior:

• Left click selects an element based on the current command

• Right click centers the view on the cursor position

• Right click + drag zooms on the selected area

• Middle click + drag scrolls the view

• Wheel up/down zooms out/in the view

• Ctrl + Wheel up/down scrolls up/down the view

• Ctrl + Shift + Wheel up/down scrolls right/left the view

Below the view widget, a horizontal board of visual options is available:

	allows to show or hide lobes
	allows to show or hide focus
	allows to show or hide aperture
	allows to show or hide obstructions
	allows to show or hide regions

Command lines

There are several ways to start nxmap software:

$> nxmap

will run the graphical user interface and let the user load a project.

$> nxmap file.nym

will run the graphical user interface and open the project file passed as argument.

$> nxmap –clear	

will restore default user settings and run the graphical interface.

$> nxmap -version or –v	

prints nxmap version and exits.

$> nxmap -help or –h	

prints nxmap help and exits.

Keyboard shortcuts

nxmap software provides the following keyboard shortcuts:

Design flow

Synthesize

In NXmap graphical View, once a project has been created and populated with HDL design sources, Synthesize flow is available for execution.

            Synthesize global flow is divided into Synthesize and Map steps:

Clicking on Synthesize button in Progress bar will open a dedicated wizard window to set options for synthesis (following figure). All Synthesis options are described in details in section setOption(name, value).

If user wants to execute only Synthesize step by clicking on corresponding progress step, NXmap will open a wizard window with only options associated to the corresponding steps. If user wants to execute several flow steps at once, NXmap will open a wizard window with all associated options per step available for configuration. Default values for options are highlighted in blue.

            To launch Synthesize step from nxpython, please refer to section synthesize().

Place & Route

In NXmap, if a project is already synthesized, user can launch place and route steps by clicking on Place and Route in the progress bar respectively (following figure). Otherwise clicking on any advanced step automatically performs the previous undone steps as well.

Selecting Place global flow steps in the NXmap toolbar will open a wizard window with associated options to be set by user before launching (following figure). All Place options are described in details in section setOption(name, value).

Dedicated options for Route flow steps are also available when selecting the corresponding steps in the progress toolbar. All Route options are described in details in section setOption(name, value).

To launch Place and Route steps from NXpython, please refer to section place() and route() respectively.

Static Timing Analysis

In NXmap, static timing analysis can be launched after the successful routing of the design by selecting Timing Analyzer in the toolbar menu. Selecting this option will open a dedicated window (following figure) to set several options (conditions, maximum slack allowed and search paths limit) to launch timing analysis.

NXmap provides different environment conditions to run static timing analysis:

• Typical case with a temperature of 25°C and a typical core voltage.

• Worst case with a temperature of 125°C and a worst case core voltage (typical - 0.1V).

• Best case with a temperature of -40°C and a worst case core voltage (typical + 0.1V).

Search paths limit field allows to delimit the maximum number of violating paths to be reported.

Maximum slack field fixes the violating slack limit used to parse violating paths, Max is default value.

Timing constraints section shows current timing constraints used to launch Static Timing Analysis. These constraints must be declared and evaluated through a NXpython script associated to the current project to be used in NXmap.

To perform a Static Timing Analysis from NXpython, please refer to section Static Timing Analysis related methods.

Graphical inspection

User can select or inspect the design in the View window of NXmap.

            The command bar allows user to interact with the graphical view of the design (following figure).

The command menu provides several select and edition options for graphical inspection:

• Select nets

• Select instances

• Edit focus

• Edit aperture

• View obstructions

All Commands with their associated options are described in the following sections.

Select nets

The command Select nets command allows user to select nets on the View window based on different criteria.

When choosing Select nets, the available criteria are:

When setting Command drop-down menu to Select nets, By drop-down menu to Plane and then clicking on the architecture representation in View section, all matching nets for the selected menu will be added in the Name field of the Selection section with the number of results found given current criteria. Selected items in Name list are highlighted in the View section upon selection (following figure).

Once a group of elements has been selected in the View window, the user has the ability to filter information with Combine, Select and Filter options of Selection section in order to navigate through matching elements printed in Name field.

The Filter field allows to enter any string or regular expression to filter the matching elements, all finding results are printed in the Name field below and the number of matching results is also shown below. Various options of Combine and Select fields allow to choose one or several matching elements based on some criteria to be highlighted in the View window. Note that you can scale zoom to fit selected elements and clear all selected items in Name field with according options.

Select instances

The Select instances command allows user to select one or several design instances based on different criteria and print corresponding name instance information in Selection section.

When setting Command drop-down menu to Select instances, By drop-down menu to Plane and then clicking on the architecture representation in View section, all matching instances for the selected menu will be added in the Name field  with the number of results found given current criteria. Selected items in Name list are highlighted in the View section upon Selection (following figure).

When choosing Select instances, the available criteria is:

When using Select instances command, user can access information of the current selected instance with Inspect option provided in Selection section (following figure)

Clicking on Inspect option will open in the View window available information for the current selected instance (following figure).

Edit focus

The Edit focus command allows user to select which TILE resource nxmap must focus on for Place & Route flow steps, meaning nxmap will place various elements of the current design going to fabric resources around the focus point. By default, the focus point is placed in the middle of the FPGA but user can choose where to place it (following figure). Clicking on Apply will validate the choice of the TILE element chosen to place the focus point.

Once Place flow steps have been executed, resources of the current design are mapped around the chosen focus point (following figure).

Edit aperture

The Edit aperture command allows user to edit the size of the aperture among the FPGA resources used for Place & Route steps. By default, the aperture size before launching nxmap flow steps is fitted to the fabric boundaries of the FPGA (following figure).

The size of aperture can be edited as much as needed (following figure) but user must keep in mind that the current design to be synthesized, placed & routed in the FPGA will have to use a minimum of resources to be correctly mapped. In other words, user can’t define a size for aperture which is too small to map the full design requested otherwise nxmap will generate an error during Place step, preventing the tool to execute all subsequent steps for current design.

As long as aperture is fitted to design needs, nxmap will be able to place design elements among resources restricted with aperture size (following figure).

View obstructions

The View obstructions command allows user to see obstructions created among the resources of the FPGA. Obstructions will be recognized by nxmap as resources that must not be used during flow execution various steps.

Obstructions can be created through nxpython until the execution of Place flow to be taken into account with the dedicated command 5.3.39. Here is a brief example with some nxpython command lines:

project = createProject("/path/to/working/directory/")
project.createObstruction('OBSTRUC1', 4, 6, 5, 6)
project.createObstruction('OBSTRUC2', 13, 6, 14, 6)
project.save('native.nym')    ## obstructions created and saved before launching synthesis steps

This widget allows to show obstructions in the View window (following figure)