NXmap design flow
- 1 Table of figures
- 2 Copyright
- 3 Introduction
- 4 Package description
- 4.1 Installation
- 4.2 Run Nxmap
- 4.3 Run nxpython
- 5 NanoXplore design flow
- 5.1 Create project
- 5.2 Synthesize
- 5.3 Place and route
- 5.4 Bitstream generation
- 5.5 Design netlist generation and Simulation
- 5.6 Static Timing Analysis
- 5.7 Logging
- 5.8 Report generation
- 5.8.1 Hdlfiles report
- 5.8.2 Hdlanalysis report
- 5.8.3 Fsmachines report
- 5.8.4 Hierarchy report
- 5.8.5 Instances report
- 5.8.6 Latches report
- 5.8.7 Maplogic report
- 5.8.8 Memories report
- 5.8.9 Operators report
- 5.8.10 Ports report
- 5.8.11 Region report
- 5.8.12 Registers report
- 5.8.13 Timing report
- 5.8.14 Unconnected report
- 5.9 Creating and handling regions
- 5.9.1 Adding modules
- 5.9.2 Creating regions
- 5.9.3 Confining modules into regions
- 5.10 Attributs
- 5.10.1 Nx_init
- 5.10.2 Nx_port
- 5.10.3 Nx_use
- 5.10.4 Syn_keep
- 5.10.5 Syn_preserve
- 6 Nxmap (Graphical User Interface)
- 6.1 Main window
- 6.2 Toolbar menu
- 6.2.1 NX Menu
- 6.2.1.1 New Project
- 6.2.1.1.1 Directory
- 6.2.1.1.2 Variant
- 6.2.1.1.3 Source and top level entity
- 6.2.1.1.4 Generic parameters
- 6.2.1.2 Load project
- 6.2.1.3 Close project
- 6.2.1.4 Save Project
- 6.2.1.1 New Project
- 6.2.2 Synthesis Constraints
- 6.2.3 Synthesis Constraints
- 6.2.4 Synthesis Constraints
- 6.2.4.1 I/O pads, banks & CKG configuration
- 6.2.4.2 Export
- 6.2.4.3 Import
- 6.2.4.4 Report instances
- 6.2.4.5 Export bitstream
- 6.2.4.6 Settings
- 6.2.4.7 About
- 6.2.4.8 Quit
- 6.2.4.9 Edit Project
- 6.2.4.9.1 Path
- 6.2.4.9.2 Variant
- 6.2.4.9.3 Sources
- 6.2.4.9.4 Top cell name & Top cell library
- 6.2.4.9.5 Parameters
- 6.2.4.9.6 Edit options
- 6.2.5 View
- 6.2.5.1 Progress bar
- 6.2.5.2 Dashboard
- 6.2.6 Command lines
- 6.2.7 Keyboard shortcuts
- 6.2.1 NX Menu
- 6.3 Design flow
- 6.3.1 Synthesize
- 6.3.2 Place & Route
- 6.3.3 Static Timing Analysis
- 6.4 Graphical inspection
- 6.4.1.1 Select nets
- 6.4.2 Select instances
- 6.4.3 Edit focus
- 6.4.4 Edit aperture
- 6.4.5 View obstructions
Table of figures
Rejected pattern for user module detection
Correct definitions for user modules detection
Wrong order for addModule() constraints
Correct order for addModule() constraints
Zooming into a specific region through nxmap
HDL files, library selection, top cell library & top cell name
Synthesize and Mapping step options
Place and Route toolbar execution
Static Timing Analysis options
Inspect option available with Select instances command
Instance info provided by Inspect
Design resources placed around focus point
Design resources placed after defining an accurate aperture
Hierarchy report providing user modules detection
Unused pattern reported due to incorrect addModule arguments
Output tables from reportInstances() method
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
Example 1 of critical paths table
Example 2 of critical paths 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.
When a command's argument is surrounded by brackets ([argument]), it means that this argument is optional.
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.
NanoXplore design environment dose NOT include any simulation tool. However, user can decide to use a third-pary tool to simulate or verify the design by using HDL files generated by NanoXplore 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:
general.log | contains all messages printed during the execution of nxmap steps: full tool log. |
synthesize.log | contains all messages printed during the execution of the two synthesis steps. These information are also generated into the general.log file. |
place.log | contains all messages printed during the execution of the five placement steps. These information are also generated into the general.log file. |
route.log | contains all messages printed during the execution of the three routing steps. These information are also generated into the general.log file. |
bitstream.log | contains all messages printed during the execution of the bitstream generation step. These information are also generated into the general.log file. |
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.
An instance identified with addModule() cannot be moved furing the further flow steps and Synthesis must be relaunched each time an addModule() constraint is modified to be taken into account by nxpython. The Synthesis step can take time so user should verify right after synthesis if all patterns providing for various addModule() commands are correct before launching next steps of the flow.
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.
Always keep in mind the order of the commands when constraining regions
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
Always keep in mind the syntax used for patterns will be strictly interpreted during synthesis when constraining regions. Double check the result of adding module at the end of Synthesis step before going further in the creation of regions
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)
Watch out for the coordinates when creating regions: it must be valid coordinates from TILES or CGB elements of the FPGA variant target
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.
Importing an external set of pads assignment can only be performed after Synthesize flow execution and before the execution of first step of Place flow. Otherwise, the tool will provide automatic pad configuration to execute Place & Route flow steps.
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.
In order for the theme change to be taken into account, user must restart nxmap. Others parameters are applied immediately
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.
All paremeters can be reset by clicking on the Restore defaults button of by launching nxmap with the -clear option.
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:
Nxmap option | Keyboard shortcut |
Close project | ctrl + W |
Exit | ctrl + Q |
Scroll up | ↑ |
Scroll down | ↓ |
Scroll left | ← |
Scroll right | → |
Zoom in | Z |
Zoom out | shift ⇑ + Z |
Zoom back | B |
Zoom full | F |
nxmap help | F1 |
nxpython help | F2 |
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.
Currently Static Timing Analysis can only be performed after a successful routing of the design.
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:
By | Filters the type of architecture's element the net is connected to [Plane, Zone, Instance or Pin]. Place lists all nets od the design in whole FPGA variant, Zone restricts nets to selected TILE or CGB elements, Instance allows to list and select nets connected to any chosen instance (LUT, DFF, RAM, DSP, etc…) and Pin shows the net connected to current selected pin. |
Scope | Filters the nets of the design following specific criteria [All, Exterior, Interior, Incoming, Outgoing or Crossing]. All lists all nets computed by the tool, Exterior lists only nets outside of the Fabric (connecting current IOs and CKG elements), Interior lists only nets inside the Fabric (connecting TILE and CGB elements), Incoming lists nets connecting input pads to Fabric elements, Outgoing lists nets connecting Fabric elements to output pads and Crossing lists nets coming from input pads and going to output pads. |
Fanout | parses the number of nets of the design based on fanout criteria [All from 10+, 20+, 30+, 40+, 50+, 60+, 70+, 80+, 90+, 100+] |
Sector | filters the nets of the design by number of sectors impacted [Any, None, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 1+, 2+, 3+, 4+, 5+, 6+, 7+, 8+, 9+, 10+]. The number of sectors in which nxmap will divide the nets depend on the size and the complexity of the design, which affect how the resources are spread and distributed around the sectors. For small designs, a small number of sectors could be enough as few logic elements need to be placed. |
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:
By | Selects the level among FPGA resources in which instances are listed and reported in Selection [Plane, Zone or Instance]. Plane option lists all instances used to map the current design on resources of the FPGA including instances locating inside CKG or iobanks for example. Zone option reduce the scale of printed instances to the current selected zone, which can be an iobank, a CKG, a TILE, etc… Instance option lists instance name at lower level such as pads, PLLs, LUTs, DFFs, etc... |
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).
Selecting focus point placement on View can only be performed launching Place flow
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)
Obstructions can only be created before launching Place flow during the execution of global steps. Obstructions created during next and further flow steps will not be accepted by the tool.
© NanoXplore 2022