5.6 Implementing Designs

You can set or change synthesis configuration options using the Synthesize Options dialog box in the Synthesis tool.

To display this dialog box, expand Implement Design in the Design Flow window, right-click Synthesize, and choose Configure Options.

SynplifyPro ME is the default Synthesis tool for Libero SoC.

To run synthesis using SynplifyPro ME and its default settings, right-click Synthesize and choose Run.

For custom settings, use the following procedure to run Synplify interactively.

1. If Synplify is your default Synthesis tool, right-click Synthesize in the Libero SoC Design Flow window and choose Open Interactively. Synplify starts and loads the appropriate design files with preset default values.
2. From Synplify’s Project menu, choose Implementation Options.
3. Set your specifications and click OK.
4. Deactivate synthesis of the defparam statement. The defparam statement is only for simulation tools and is not intended for synthesis. Embed the defparam statement between the translate_on and translate_off synthesis directives:

   /* synthesis translate_off */
   defparam M0.MEMORYFILE = "meminit.dat"
   /*synthesis translate_on */
   // rest of the code for synthesis

5. Click the Run button. Synplify compiles and synthesizes the design into an HDL netlist. The resulting *.vm files appear under Synthesis Files in the Files list.

   If errors appear after you click the Run button, use the Synplify editor to edit the file. Double-click the file name in the Synplify window showing the loaded design files. Your changes are saved to the original design file in your project.

6. To close Synplify, from the File menu, choose Exit. When prompted to save changes you made, click Yes.
   Note: For a list of attributes related to Microchip devices, see the Microchip Attribute and Directive Summary in the Synplify online help.
   Note: To add a clock constraint in Synplify, add n:<net_name> in your SDC file. If you omit the n:, the constraint will not be added.

Libero SoC integrates the Identify RTL debugger tool. Identify debugging software allows you to probe and debug your FPGA design directly in the source RTL. Use the software if the design behavior after programming is not in accordance with the simulation results.

The following list summarizes the Identify key features:

• Instrument and debug your FPGA directly from RTL source code.
• Internal design visibility at full speed.
• Incremental iteration permit design changes made to the device from the Identify environment using incremental compile operations. This allows you to iterate in a fraction of the time it takes route the entire device.
• Debug and display results allow you to collect only the data you need using unique and complex triggering mechanisms.

To open the Identify RTL debugger, in the Design Flow window, under Debug Design, double-click Instrument Design.

The following procedure describes how to use the Identify Instrumentor and Debugger. To run the following debugging flow, you must have the Identify RTL Debugger and the Identify Instrumentor.

1. Create your source file and run pre-synthesis simulation.
2. Optional: Perform an entire flow (Synthesis - Compile - Place and Route - Generate a Programming File) without starting Identify.
3. Right-click Synthesize and choose Open Interactively in Libero SoC to launch Synplify.
4. In Synplify, click Options > Configure Identify Launch to setup Identify.
5. In Synplify, create an Identify implementation by clicking Project > New Identify Implementation.
6. In the Implementations Options dialog box, make sure that the Implementation Results > Results Directory points to a location under <libero project>\synthesis\; otherwise, Libero SoC will not detect your resulting Verilog Netlist file.
7. From the Instrumentor UI, specify the sample clock, the breakpoints, and other signals to probe. Synplify creates a new synthesis implementation. Synthesize the design.
8. In Libero SoC, run Synthesis, Place and Route and generate a programming file.
   Note: Libero SoC works from the edit netlist of the current active implementation, which is the implementation you created in Synplify for Identify debug.
9. In the Design Flow window, double-click Identify Debug Design to launch the Identify Debugger.

To work properly, the Identify RTL Debugger, Synplify, and FlashPro must be synchronized. For more information about which versions of the tools work together, see the Release Notes.

To perform functional simulation:

1. Back-annotate your design and create your testbench.
2. In the Design Flow window, click Implement Design.
3. Right-click Simulate and choose Organize Input Files > Organize Stimulus Files.

   In the Organize Files for Source dialog box, all stimulus files in the current project appear in Source Files in the Project list box. Files associated with the block appear in the Associated Source Files list box.

   In most cases, you will have one testbench associated with your block. However, if you want simultaneous association of multiple testbench files for one simulation session, as in the case of PCI cores, add multiple files to the Associated Source Files list.
4. To add a testbench, select the testbench you want to associate with the block in the Source Files in the Project list box and click Add to add it to the Associated Source Files list.
5. To remove a testbench or change the files in the Associated Source Files list box, select the files and click Remove.
6. To order testbenches, use the up and down arrows to define the order in which you want the testbenches compiled. The top level-entity must be at the bottom of the list.
7. When you are satisfied with the Associated Simulation Files list, click OK.
8. To start ModelSim ME, right-click Simulate in the Design Hierarchy window and choose Open Interactively. ModelSim starts and compiles the appropriate source files. When the compilation completes, the simulator runs for 1ps and the Wave window shows the simulation results.
9. Scroll in the Wave window to verify the logic works as intended. Use the cursor and zoom buttons to zoom in, zoom out, and measure timing delays.
10. When you are done, click Quit from the File menu.

The following table describes the uRAM/LSRAM State options.

The lower the frequency, the lower the power. However, some peripherals, such as SPI or MMUART, can remain active. In these cases, you might need a higher MSS clock frequency (for example, to meet the baud rate for MMUART).

An initial Configuration Lock Bit file can be generated from the Design Flow window by clicking Generate FPGA Array Data.

The initial (default) file is named <proj_location>/designer/<root>/<root>_init_config_lock_bits.txt. Edit this file to ensure that the lock bits are set to “0” for all register bits you want to lock. After editing the file, save it as a *.txt file with a different name, and then import the file into the project using the Register Lock Bit Settings dialog box (Design Flow window > Configure Register Lock Bits).

A valid entry in the Lock Bit Configuration file is defined as a <lock_parameters> < lock bit value> pair.

• If the lock bit is for a register, the parameter name is defined as: <Physical block name>_<register name>_LOCK
• If the lock bit is for a field, the parameter name is defined as: <Physical block name>_<register name>_<field name>_LOCK

The physical block name can vary with device family and device (see the following table).

Setting the lock bit value to ‘1’ indicates that the register can be written. Setting it to “0” indicates that the register cannot be written (locked). Lines starting with “#” or “;” are comments. Empty lines are permitted in the Lock Bit Configuration file.

During Map File generation (Design Flow window > Generate FPGA Array Data), Libero SoC validates the Register Lock Bit Configuration file and displays the following error messages if it encounters an issue.

The Libero SoC Design Flow window displays status icons to indicate the status of the design state. For any status other than a successful run, the status icon is identified with a tooltip to give you additional information.

Table 5-45. Design Flow Window Status Icons and Tooltips

Status Icon	Tooltip	Description	Possible Causes/Remedy
N/A	Tool has not run yet.	NEW state.	Tool has not run or it has been cleaned.
	Tool runs successfully.	Tool runs with no errors. PASS state.	N/A
	Tool forced by user to complete state.	Force updates the tools state to PASS state.	Only for Synthesize/Compile and Place and Route tools. The remaining tools do not change states
	Varies with the tool.	Tool runs but with Warnings.	Varies with the tool (For example, for the Compile Netlist step, not all I/Os are assigned and locked).
	Tool Fails.	Tool fails to run.	Invalid command options or switches, invalid design objects, invalid design constraints.
	Design State is Out of Date.	Tool state changes from PASS to OUT OF DATE.	Since the last successful run, design source design files, constraint files or constraint file/tool association, constraint files order, tool options, and/or project settings have changed.
	Timing Constraints have not been met.	Timing Verification runs successfully but the design fails to meet timing requirements.	Design fails Timing Analysis. Design has either set-up or hold time violations or both. See PolarFire FPGA Timing Constraints User Guide on how to resolve the timing violations.

A tool in the Design Flow changes from a PASS state (green check mark) to an OUT OF DATE state when a source file or setting affecting the outcome of that tool has changed.

The out-of-date design state is identified by the

• HDL sources (for Synthesis), gate level netlist (for Compile), and Smart Design components

• Design Blocks (*.cxz files) – low-level design units that might have completed Place and Route and re-used as components in a higher level design
• Constraint files associated with a tool
• Upstream tools in the Design Flow:
  • If the tool state of a Design Flow tool changes from PASS to OUT OF DATE, the tool states of all the tools below it in the Design Flow, if already run and are in PASS state, also change to OUT OF DATE with appropriate tooltips. For example, if the Synthesis tool state changes from PASS to OUT OF DATE, the tool states of Place and Route tool as well as all the tools below it in the Design Flow change to OUT OF DATE.
    • If a Design Flow tool is CLEANED, the tool states of all the tools below it in the Design Flow, if already run, change from PASS to OUT OF DATE.
    • If a Design Flow tool is rerun, the tool states of all the tools below it in the Design Flow, if already run, are CLEANED.
  • Tool Options
    • If the configuration options of a Design Flow tool (right-click the tool and choose Configure Options) are modified, the tool states of that tool and all the other tools below it in the Design Flow, if already run, are changed to OUT OF DATE with appropriate tooltips.
  • Project Settings:
    • Device selection
    • Device settings
    • Design Flow
    • Analysis operating conditions

When a constraint file is checked, the Constraint Checker does the following:

• Checks the syntax
• Compares the design objects (pins, cells, nets, ports) in the constraint file versus the design objects in the netlist (RTL or post-layout ADL netlist). Any discrepancy (For example, constraints on a design object which does not exist in the netlist) are flagged as errors and reported in the *_sdc.log file.

Constraints can be checked only when the design is in the right state.

A pop-up message appears when the check is made, and the design flow has not reached the right state.

Click the Edit with I/O Editor/Chip Planner/Constraint Editor button to edit existing and add new constraints. Except for the Netlist Attribute constraints (*.fdc and *.ndc) file, which cannot be edited by an interactive tool, all other constraint types can be edited with an Interactive Tool. The *.fdc and *.ndc files can be edited using the Libero SoC Text Editor.

• The I/O Editor is the interactive tool to edit I/O Attributes, Chip Planner is the interactive tool to edit Floorplanning Constraints, and the Constraint Editor is the interactive tool to edit Timing Constraints.
• For Timing Constraints that can be associated to Synthesis, Place and Route, and Timing Verification, you need to specify which group of constraint files you want the Constraint Editor to read and edit:
  • Edit Synthesis Constraints - reads associated Synthesis constraints to edit.
  • Edit Place and Route Constraints - reads only the Place and Route associated constraints.
  • Edit Timing Verification Constraints - reads only the Timing Verification associated constraints.

For the three SDC constraints files (a.sdc, b.sdc, and c.sdc, each with Tool Association as shown in the following table) when the Constraint Editor opens, it reads the SDC file based on your selection and the constraint file/tool association.

• Edit Synthesis Constraints reads only the b.sdc and c.sdc when Constraint Editor opens.
• Edit Place and Route Constraints reads a.sdc, b.sdc, and c.sdc when Constraint Editor opens.
• Edit Timing Verification Constraints reads a.sdc and c.sdc when Constraint Editor opens.

Constraints in the SDC constraint file that are read by the Constraint Editor and subsequently modified by you will be written back to the SDC file when you save the edits and close the Constraint Editor.

When you add a new SDC constraint in the Constraint Editor, the new constraint is added to the c.sdc file, because it is set as target. If no file is set as target, Libero SoC creates a new SDC file to store the new constraint.

The number of 4LUTs in the report is the total number used for your design, regardless of whether they are combined with the DFFs. Similarly, the number of DFFs in the report is the total number used for your design, regardless of whether they are combined with 4LUT’s.

In the following report, a total of 473 LEs are used for the design.

• 300 of the 473 LEs have DFFs inside, which means 173 (473-300) of them have no DFFs in them. These 173 LEs use only the 4LUTs portion of the LE.
• 400 of the 473 LEs have 4LUTs inside, which means 73 (473-400) of them have no 4LUTS in them. These 73 LEs use only the DFF portion of the LE.

In the following figure, the area where the two circles overlap represents the overlapped resources in the Resource Usage report.

The Fabric to GB Connections section lists all the nets originating from the fabric to the Global Resources/Instance name of the macro. The From Location column refers to the X-Y coordinates of the driver pin of the net. The nets are routed nets, not hardwired.

The CCC to GB Connections section lists the nets originating from the Clock Conditioning Circuitry (CCC) outputs (GLx) to the Global Resources/instance name of the macro. To minimize clock skew, CCC clock outputs usually are hardwired dedicated connections to Global resources (GB).

The CCC Input Connections section lists the nets from the I/O pins to the CCC inputs.

Net type can be routed or hardwired. Hardwired net types are dedicated wiring resources and have lower insertion delays. Routed net types are implemented using fabric routing resources and the insertion delay (generally higher than that of hardwired nets), varies from iteration to iteration.

The Global Clock Nets to RGB Connections section lists all nets from Globals (GBs) to Row Globals (RGBs).

Table 5-54. Columns in the Global Clock Nets to RGB Connections Section

Column	Description
From	Hardwired to different RGBs each with different local fanout.
From Location	X-Y coordinates on the chip. The Fanout column gives the total fanout of the net.
Local Fanout	Fanout local to RGB.

The Warning section is available in RTG4 devices only. It gives warnings about clock or reset nets which are not radiation protected and recommends ways to protect the nets from radiation. Some warning examples are:

• Clocks or reset nets that are routed are not radiation protected.
• Hardwired connections from DDRIO bank are not radiation protected.
• For radiation protection, Microchip recommends using dedicated global clocks that come with built-in radiation protection.

  

• Local resets that are not driven by three separate logic cones are not radiation protected.

  

• For radiation protection, Microchip recommends that each of the three inputs of every RGRESET be driven by three separate logic cones replicating the paths from the source registers. See the descriptions of RGRESET macro in the Macro Library User Guide for RTG4 .

The *ba.v/.vhd file is a post-layout flattened netlist used for back-annotated timing simulation. The file can contain low-level macros to improve design performance.

This step allows you to select Export Enhanced min delays for best case. Checking this option exports your enhanced minimum delays to include the best-case timing results in your back annotated file.

The back-annotation functions are used to extract timing delays from your post layout data. These extracted delays are placed into a file for use by your CAE package’s timing simulator. The default simulator for Libero SoC is ModelSim ME. You can change your default simulator in your Tool Profile.

To perform pre-layout simulation, in the Design Flow window, under Verify Pre-Synthesized design, double-click Simulate.

To perform timing simulation:

The following figures show an example of the Verify Timing Configuration dialog box.

The reports can be generated in XML or text format. The following table lists the report settings.

Note: If any options are left blank in the Report Settings tab, a tooltip error icon appears as shown in the following figure.

Table 5-55. Verify Timing Configuration Dialog Box Settings

Report	Setting	Description
Timing Report	Limit the number of reported paths per section	Number of reported paths under each section. Range: 1–20000
	Limit the number of expanded paths per section	Number of expanded paths under each section. Range: 1–20000
	Limit the number of parallel paths per expanded path to	Number of parallel paths for each expanded path. Range: 1–20000
Timing Violations Report	Limit the number of reported paths per section	Number of reported paths under each section. Range: 1–20000
	Limit the number of expanded paths per section	Number of expanded paths under each section. Range: 0–20000
	Limit the number of parallel paths per expanded path to	Number of parallel paths for each expanded path. Range: 1–20000
	Maximum Slack	Maximum slack threshold value in nanoseconds. Paths are filtered based on the slack threshold value in Timing Violation reports.
Timing Report Explorer	Limit the max number of paths in Explorer	Number of input paths in Timing Report Explorer. Range: 1–10000 Timing Report Explorer can also be opened from Design Tab > Timing Report Explorer. After generating a report, the Timing Report Explorer appears in Path View as shown in the following figure.

In the preceding figure, click any path and select the UI control view from the settings drop-down list to display a detailed view similar to the one in the following figure.

Observe the following guidelines:

• The following warning message appears if there are no paths for a selected filter:

  No paths were found to match your filter. Choose another filter or try modifying your search criteria.

• Cross Probing between Timing Report Explorer and Chip Planner is supported for nets and cells.

• Mousing over the Source/Destination clock combo boxes displays tooltips as shown in the following figures:

  

  

Insights: This option provides an insight into the graphical view of slack distribution across the selected filter, cell vs. net delays, and logic level distribution.

Click Insights > Slack Distribution to view the slack distribution. The following figure shows an example of positive slack distribution.

The following figure shows an example of negative slack distribution.

Click Insights > Cell vs Net Delays to view a delay breakdown of the top 100 paths in the form of a stacked bar chart, percentage chart, and pie chart.

Stacked Bar Chart

The stacked bar chart shows the net and cell delay for a path. Radio buttons at the top of the chart allows you to toggle between value and percentage (%) views. Buttons at the bottom of the chart allow you to select the number of paths from the path range: NEG_Slack, 10p, 20p, 50p, and 100p (default is 10p). Hovering over the bar of a data chart displays a tooltip with From, To, Net Delay, and Cell Delay information.

Percentage (%) View

Every stack bar in the percentage chart represents net and cell delay for a path in terms of percentage. Buttons at the bottom of the chart allow you to select the number of paths from the path range: NEG_Slack, 10p, 20p, 50p, and 100p (default is 10p).

Clicking a bar in the chart displays a pop-up chart with expanded path information, similar to the following.

Pie Chart

The pie chart shows the sum of total net delay and cell delay for a selected path range. Buttons at the bottom of the chart allow you to select the number of paths from the path range: NEG_Slack, 10p, 20p, 50p, and 100p (default is 10p).

Click Insights > Logic Level Distribution to view a distribution chart that represents the number of paths having a logic count equal to the bar number. Hovering over a bar in the distribution chart displays a tooltip that shows the total number of path information. The following figure shows an example of logic level distribution.

From the Design Flow > Verify Timing, you can generate the following reports. The following reports organize timing information by clock domain. Four types of timing reports are available. To configure which reports to generate, use the Verify Timing Configuration dialog box (Design Flow > Verify Timing > Configure Options).

Table 5-56. Types of Timing Reports

Report	Description
Timing reports	The following reports can be generated: Max Delay Static Timing Analysis report based on Slow process, Low Voltage, and High Temperature operating conditions. Min Delay Static Timing Analysis report based on Fast process, High Voltage, and Low Temperature operating conditions. Max Delay Static Timing Analysis report based on Fast process, High Voltage, and Low Temperature operating conditions. Min Delay Static Timing Analysis report based on Slow process, Low Voltage, and High Temperature operating conditions. Max Delay Static Timing Analysis report based on Slow process, Low Voltage, and Low Temperature operating conditions. Min Delay Static Timing Analysis report based on Slow process, Low Voltage, and Low Temperature operating conditions.
Timing violations reports	Organizes timing information by clock domain. You can configure which reports to generate using the Verify Timing Configuration dialog box. The following reports can be generated: Max Delay Analysis Timing Violation report based on Slow process, Low Voltage, and High Temperature operating conditions. Min Delay Analysis Timing Violation report based on Fast process, High Voltage, and Low Temperature operating conditions. Max Delay Analysis Timing Violation report based on Fast process, High Voltage, and Low Temperature operating conditions. Min Delay Analysis Timing Violation report based on Slow process, Low Voltage, and High Temperature operating conditions. Max Delay Analysis Timing Violation report based on Slow process, Low Voltage, and Low Temperature operating conditions. Min Delay Analysis Timing Violation report based on Slow process, Low Voltage, and Low Temperature operating conditions.
Constraints coverage report	Displays the overall coverage of the timing constraints set on the current design. <root>_timing_constraints_coverage.xml (generated by default)

The following table describes the icons associated with reports.

Table 5-57. Report Listing Icon Legend

Icon	Definition
	Timing requirements met for this report.
	Timing requirements not met (violations) for this report.
	Timing report is available but not selected/configured for generation.

SmartTime is the Libero SoC gate-level static timing analysis tool. With SmartTime, you can perform complete timing analysis of your design to ensure that you meet all timing constraints and that your design operates at the desired speed, with the right amount of margin across all operating conditions.

For information about creating and editing timing constraints, see the Timing Constraints Editor User Guide .

SmartPower is the Microchip SoC state-of-the-art power analysis tool. SmartPower allows you to visualize power consumption and potential power consumption problems within your design globally and in-depth, so you can adjust to reduce power consumption.

SmartPower provides a detailed and accurate way to analyze designs for Microchip SoC FPGAs. From a top-level summary, you can analyze specific functions within the design, such as gates, nets, I/Os, memories, clock domains, blocks, and power supply rails.

You can analyze the hierarchy of block instances and specific instances within a hierarchy. Each analysis can be viewed in different ways to show the respective power consumption of the component pieces.

SmartPower allows you to analyze power by functional modes, such as Active, Flash*Freeze, Shutdown, Sleep, or Static, depending on the specific FPGA family used. You can also create custom modes created in the design. Custom modes can also be used for testing "what if" potential operating modes.

SmartPower allows you to create test scenario profiles. Using a profile, you can create sets of operational modes to understand the average power consumed by a combination of functional modes, such as a combination of Active, Sleep, and Flash*Freeze modes used over time in an application.

SmartPower generates detailed hierarchical reports of the power consumption of a design for easy evaluation. This allows you to find power consumption sources and take appropriate action to reduce power.

SmartPower supports the Value-Change Dump (VCD) file format, as specified in the IEEE 1364 standard, generated by the simulation runs. Support for this format allows you to generate switching activity information from ModelSim or other simulators, and then use the switching activity-over-time results to evaluate average and peak power consumption for your design.

For more information, see the SmartPower User Guide .

Simultaneous Switching Noise (SSN) is the Libero SoC voltage noise analysis tool. It provides a detailed analysis of the noise margin about each I/O pin in the design, based on the pin information and other active pins placed in the same I/O bank of the design. The tool computes the noise margin based on I/O standards, drive strength, and pin placement. The SSN Analyzer helps you achieve the desired voltage noise margin, resulting in improved signal integrity.

To open the SSN Analyzer, right-click SSN Analyzer in the Design Flow window and select Open Interactively.