When choosing Select instances, the available criteria is:

When using Select instances command, user directly accesses information of the current selected instance detailed by Name, if the instance is part of a module or a region, its location in the design, potential configuration information depending of the kind of instances, etc…

1. setSite management when select instances enable

When using command Select instances, setSite management - allows to select and move & place an instance into another site location - is available only at Place 1/5 step through the Selection panel: it allows to dynamically move and place a selected instance through Locking button.

Select an instance to be moved in the floorplan, click on Locking to access the following possibilities:

• Lock in target allows to select a target for the resource to be placed directly into the floorplan

  • In the above example, the instance name selected is GEN_HIER0|GEN_ROW[0].ROW_PIPE|pipe_reg_reg[11][I], originally placed by default into the TILE[15x6] as seen on the location field in the details part of Selection Panel

  • In the right part of Selection panel, dedicated to Locking actions with Unlock, Lock in place & Lock in target actions, the target location is dynamically adjusted as the cursor is moved into the floorplan

  • Once the target location is set for example in TILE[9x6], click on it through the floorplan and the instance will be automatically moved into the targeted resource and the location information in the instance list will be automatically updated as shown below

• The target for a resource previously placed can be edited and modified using Unlock button:

  • the previous target placement will be relaxed

  • you can reuse Lock in target to change the target resource as desired

• When you want to fix a target resource for an instance already defined by the tool in order to be kept through the whole Place & Route flow, click on Lock in place to permanently fix the target for the selected instance

2. Logic Cone manager when select instances enable

When using command Select instances, Logic Cone Manager - available in Tools panel near floorplan - allows for any selected instance - or group of instances as the By argument provides flexibility on the selection process - to visually identify either all incoming logic elements driving the inputs of this instance or all outgoing logic elements driven by this specific chosen instance; that way, the Logic Cone Manager lists all directly connected resources to the desired instance and calculate the delay from the instance to each type or resource connected to it.

The Logic Cone Manager provides worstcase, bestcase and typical conditions choice through a scrolling button.

Reported elements to be analyse for the selected instance can be parsed by a desired type of pin : Clock, Load or Reset.

Useful options to use within the Logic Cone Manager are Depth and Max Depth arguments, which allow to extend from one selected elements analysed with their accumulated timing values to several level of logical instances to be shown and included in the graph. That way, a user can trace back multiple layers of instances back and forward to determine complex dependencies in data paths and how simplification for timing purpose could be useful.

g. Edit focus

The Edit focus command allows user to select which TILE resource Impulse must focus on for Place & Route flow steps, meaning Impulse 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.

h. Edit aperture

The Edit aperture command allows user to edit the size of the aperture around the FPGA resources used for Place & Route steps. By default, the aperture size before launching Impulse flow steps is fitted to the fabric boundaries of the FPGA variant selected, excluding I/O ring.

The size of the aperture can be edited as much as needed (following figure) but user must keep in mind that the current design to be synthesised, 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 Impulse 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, Impulse will be able to place design elements among resources restricted with aperture size (following figure).

i. View obstructions

The View obstructions command allows user to see obstructions created among the resources of the FPGA. Obstructions will be recognized by Impulse as forbidden resources excluded from elements used during flow execution various steps to place and route the logic instances of the design.

Obstructions can be created through nxpython until the execution of Place flow to be taken into account with the dedicated command createObstructiin(). 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

Anchor
candhregions candhregions

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. The purpose of this section is to help user understanding the mechanisms behind the creation of regions through a complete example. Two commands have been designed for this purpose:

• constrainModule()

• constrainPath()

1. constrainModule(hierarchy, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

First, user has to identify which particular logic resources will have to be specifically restricted into a region for timing optimization purpose. NanoXplore design 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 bounded to desired FPGA resources.

constrainModule() has been implemented to create region constraints in order to confine logic instances inside with the following purpose:

• Simplifying logic identification inside the design

• Using only information provided in hierarchy.rpt without handling regular expression pattern detection

• Reduce the number of commands used for region constraining from three dedicated command for the previous process to only one efficient method easy to use for the user

After a first run execution of the synthesis flow step in Impulse, hierarchy.rpt provides all hierarchy design information needed to define constrainModule() commands for the design:

• HDL Modules Hierarchy Detail section

• Default User module detection in the report will only report ‘Module ~’, which is the notation representing the top level HDL module hierarchy when no constraint has been set

• Note this report also provides a precise repartition of the design mapped on the different components of the fabric and Clock generator blocks (CKG):

  • 4-LUT, DFF, XLUT

  • Carry

  • RFB

  • cross domain clock, clock buffer, clock switch

  • DSP, RAM (CGB components)

  • WFG, PLL (CKG components)

Classic examples using hierarchy.rpt to identify logic instances to be constrained into regions ( ‘|->’ is not mandatory but is accepted for hierarchy argument):

project = createProject()

project.constrainModule('|-> INTERP_x2_20M_to_40M [ INT_20_40 ]', 'INT_20_40_MOD', 'Hard', 5, 4, 2, 3, 'INT_20_40', False)
project.constrainModule('|-> INTERP_x2_40M_to_80M [ INT_40_80 ]', 'INT_40_80_MOD', 'Hard', 7, 4, 2, 3, 'INT_40_80', False)
project.constrainModule('|-> SRL_MEM_SYMMETRY_EVEN(X834F2609) [ FIR_MF|MEM|EVEN.MLT.NR[0].FIRST.FIRST_EVEN ]', 'FIRST_EVEN_MOD', 'Hard', 1, 10, 1, 1, 'FIRST_EV_1_R', False)
project.constrainModule('|-> SRL_MEM_SYMMETRY_EVEN(X30E78A1F) [ FIR_MF|MEM|EVEN.MLT.NR[1].OTHE.OTH_EVEN ]', 'OTH_EV_1', 'Hard', 2, 10, 1, 1, 'OTH_EV_1_R', False)

project.constrainModule('|-> nx#NX_DSP_SPLIT(X2C70EFCA) [ FIR_MF|GEN_DSP[0].DSP|G_INST.DSP ]', 'DSP_MOD_1’, Hard', 1, 8, 1, 1, 'DSP_SPLIT_1’, False)
project.constrainModule('|-> nx#NX_DSP_SPLIT(X2C70EFCA) [ FIR_MF|GEN_DSP[2].DSP|G_INST.DSP ]', 'DSP_MOD_3', 'Soft', 3, 8, 1, 2, 'DSP_SPLIT_3', True )

project.save('/rtl/native.nym')
project.synthesise():
project.save('/rtl/synthesised.nym')

Once synthesise step of the flow is executed using region constraints from constrainModule() commands, hierarchy.rpt provides useful information to check preliminary constraints as written by user before flow implementation - specified by Unused (Not yet assigned) - and after usage by the tool for execution.

If the syntax of some constraints is wrong - assuming that if hierarchy argument of constrainModule() is not matching an existing model instance - those will be labelled as unused by Impulse.

A Usage labelled ‘unused’ implies the corresponding constrainModule() cannot be applied to the design flow.

In hierarchy.rpt, successfully created modules by constraints are listed with the list of resources mobilized for each one of the modules.

Before opening the floorplan panel of Impulse, one can easily check how many hierarchy instances are gathered into newly created regions by checking the HDL module hierarchy section of hierarchy.rpt:

And finally, a look a floorplan panel of Impulse offers visual glimpse on how region constraints with the associated logic instances placed inside are placed in delimited resources with colour codes:

2. constrainPath(sourceList, targetList, moduleName, type, leftCol, topRow, width, height, regionName, exclusive)

constrainPath() provides even more precision in identifying logic instances aimed for placement by specifying all elements between selected registers to be confined into a specific region.

This method takes in argument a list of source and destination registers between which all logic elements (LUT, carry) will be constrained into a region specified by the coordinates provided with the dedicated arguments.

constrainPath() allows to identify and constrain at register name level whereas constrainModule() is used to constrain at hierarchical instance levels described in hierarchy.rpt file, so offers more flexibility to identify and confine smaller parts of the design in case touchy timing paths require precise placement.

Registers provided as source and target arguments will also be part of the logic constrained and included into the region; DSP and memory macros - containing pipeline registers - such as RAM and Register Files are also identified as source and target arguments for constrainPath().

During nxpython command execution, constrainPath() has priority over constrainModule() and can be used to constrain specific logic between registers inside a region previously created with constrainModule().

Some examples of command to use constrainPath():

project = createProject()

project.constrainPath(['i_cpt_0|s_cpt_out_reg*'],['i_cpt_1|s_cpt_out_reg*'],'cpt0_to_1_module','Soft',9,6,2,3,'cpt0_to_1_region',False)
project.constrainPath(['i_cpt_1|s_cpt_out_reg*'],['i_cpt_2|s_cpt_out_reg*'],'cpt1_to_2_module','Soft',11,6,2,3,'cpt1_to_2_region',True)
project.constrainPath(['i_cpt_2|s_cpt_out_reg[0]'],['i_cpt_3|s_cpt_out_reg[0]'],'cpt2_to_3_module',13,6,2,3,'cpt2_to_3_region')

project.save('/rtl/native.nym')
project.synthesise():
project.save('/rtl/synthesised.nym')

Attributes

Attributes 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;