Jump to main content

# 14 Known Issues and Limitations

(Ask a Question)

This section lists Libero SoC Design Suite known issues and limitations.

## 14.1 Libero SoC v2026.1 – v12.0

(Ask a Question)

The following table lists the known issues and limitations associated with Libero SoC v2026.1 – v12.0.

### 14.1.1 Libero

(Ask a Question)

The following table lists the known issues and limitations associated with Libero.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
All | When invoking Libero® SoC Design Suite executables such as libero, FPExpress, or pfsoc_mss on Ubuntu 22.04.3 LTS servers, the following warning message may appear: `cat: /etc/redhat-release: No such file or directory` Workaround: UI mode: this message is informational only and can be safely ignored. Batch mode: If the message interferes with script execution, use the -ignorestderr option with the Tcl exec command when invoking Libero® SoC Design Suite executables such as libero, FPExpress, or pssoc_mss. This prevents output written to stderr from being treated as an execution failure. | 2026.1 | --- | Open
All | Customers may be unable to download IP cores from the catalog due to an SSL certificate problem. Workaround: We recommend installing the 'Amazon Root CA 1' certificate in the native Windows certificate store under 'Trusted Root Certification Authorities.' | 2025.1 | N/A | Open
All | Libero does not support monitors with 4K or 8K display resolutions. When using a 4K monitor alongside a 1080p monitor, the display of fonts and dialog boxes in Libero may appear distorted. Workaround: In display setting of the laptop/desktop, make one of the 1080p monitors as your main display. Close the laptop lid which has display resolution higher than 1080p. Disable the laptop display/screen | 12.0 | — | Open
PolarFire | When configuring/generating the latest versions of the IP cores CORERSDEC and COREEDAC, users may encounter errors(printed to the Linux terminal window) related to missing shared libraries. The IP core configurator window doesn’t open, and the core cannot be generated. Users cannot upgrade from the older versions to the latest versions too. This issue occurs because these IP cores require to launch packaged executables viz., CoreRSDECConfigurator.exe and CoreEDACConfigurator.exe which depend on wxWidgets v2.8.x, which is not available by default on Linux, especially the newer Linux distributions such as RHEL 8.x / AlmaLinux 8.x. Workaround: Copy the prebuilt wxWidgets 2.8.12 package from a working system (e.g. /cad/tools/mchp/wxWidgets-2.8.12) to a local directory on the target machine (example: /integ/tmp/wxWidgets-2.8.12). Set the following environment variables before running the executable: setenv PATH /integ/tmp/wxWidgets-2.8.12/bin:$PATH setenv LD_LIBRARY_PATH /integ/tmp/wxWidgets-2.8.12/lib setenv DISPLAY <display_name> Configure or generate the IP cores CORERSDEC or CORERSDEC again. For more information, refer to the Knowledge Base (KB) article linked below: https://support.microchip.com/s/article/Missing-wxWidgets-2-8-Dependency-in-IP-cores-CORERSDEC-and-COREEDAC | 2025.1 | 2025.2 | Fixed
All | On Ubuntu® 20.04.6 LTS, the following error message appears when launching Libero: `Download error: error setting certificate verify locations CA file : /etc/pki/tls/certs/ca-bundle.crt CA path: none` This error also occurs in the following scenarios: Reloading the IP catalog Changing the vault location Attempting to download cores using the Download them now button in the IP catalog While a few cores may download successfully, the majority of downloads fail due to this error. Workaround: Run the following commands as `sudo/root`: `mkdir -p /etc/pki/tls/certs/ ln -s /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt` | 2025.1 | — | Open
PolarFire and PolarFire SoC | I/O Bank Setting does not reflect available I/O standards correctly for mixed voltage I/Os. Workaround: Check I/O Editor's Port View and confirm that appropriate I/O standards are assigned based on Mixed voltage I/O standard assignments. For additional information, see Article Number 000016039. | 12.5 | — | Open
All | After executing the `download_latest_core` command without an internet connection, a message indicates that all cores are up to date. It is important to inform you when there is an issue with your internet connection. | 2022.2 | 2025.1 | Fixed
RTG4 | When creating and configuring the RTG4 INIT cores (NPSS_SERDES_IF_INIT, PCIE_SERDES_IF_INIT, and RTG4FDDR_INIT) and SmartFusion2/IGLOO2 System Builder cores, trying to generate the components by calling the TCL command `generate_component` might cause the IDE to crash. Workaround: Instead of importing a previously configured IP catalog core component (.CXF plus .SDB) and generating the component using the `generate_component` TCL command to generate IP cores, use the Tcl component description to recreate and generate the core using the following procedure: After creating and configuring the IP core using the Configurator GUI, navigate to the Components or Design Hierarchy tab. Right-click your component, and then select Export Component Description (Tcl). Specify the file path and click OK. Use the exported file in your Tcl scripted build flow to regenerate or recreate the IP core with the same configurations. Note: If the core is already created and needs only regeneration, remove the `create_and_configure_core` command from the exported script file. | 2023.2 | N/A | Will Not Fix
PolarFire and PolarFire SoC | If you use BIBUF_DIFF or TRIBUFF_DIFF in your design and set the default IOSTD to be LVCMOS33, these I/Os will take the LVDS33 IOSTD by default, which is not supported. Workaround: The best practice is to set the IOSTD for each I/O explicitly in the PDC file. Do not use the LVCMOS33 IOSTD as a default when BIBUF_DIFF or TRIBUFF_DIFF is in your design. | 12.0 | — | Open
RTG4 | A corner case existed where a CLKINT was instantiated with its input tied to a static '1' and then routed using only a half-chip Global Buffer (GBL or GBR). A user signal routed on the corresponding other half GB might be output from the CLKINT tied to a static '1'. Workaround: In the unlikely event that a CLKINT has been instantiated and tied to a static `1`, either remove such a scenario from the design, or manually instantiate a BUFD buffer with its input tied to `1` and its output connected to the CLKINT. | 11.6 | 2024.1 | Fixed in version noted. For issue status on v11.x tools, see the v11.x Known Issues list
RTG4 | Instantiating the RTG4_ODT_DYN macro for an I/O bank causes Libero SoC to mark three extra I/Os on that bank as User Reserved and physically configure them as unused I/O. The three I/O pins reserved are always the same for a given I/O bank, as shown below: If the design requires assigning a user signal to any of these reserved pins when RTG4_ODT_DYN is instantiated, upgrade to Libero SoC v2024.1 or later. | 12.0 | 2024.1 | Fixed
All | The Memory Map report does not appear correctly if the AHBL_READ_INITIATOR and AHBL_WRITE_INITIATOR pins are exposed in the MIV_ESS v2.0.100 core. | 2024.1 | — | Open
IGLOO2, SmartFusion2, RTG4, PolarFire, PolarFire SoC | If the Synthesis step is bypassed in the Design Flow project settings, block components published with VHDL language mode enabled may fail to compile when instantiated in the top-level project. If this occurs, the compile step reports the following error: `Error: Unknown HDL or mixed HDL types for HDL sources files` Workaround: Publish all block components with Libero project settings set to Verilog language. Alternatively, re-run Synthesis on the top-level project so that a mapped Verilog (.vm) is used during Compile. | 12.0 | N/A | Will not fix
PolarFire | Multipass Place and Route intermittently reports `“Error: Muli-Pass: Cannot read file “<root>_iteration_summary.rpt”.` The mutlipass Place and Route run completes successfully, and the best result is saved into the project. However, the summary table showing the results across all seeds is not displayed. Note: This issue does not occur for all starting seed indexes in the Place and Route options. | 2022.3 | 2024.2 | Fixed
PolarFire | The memory map functionality (exporting Memory Map or viewing it in SmartDesign) is not supported for the MIV_ESS v2.0.200 core. | 2024.1 | — | Open
All | If an MSS or MiV processor interrupt pin is connected to a 1-bit slice pin through a connection hierarchy, incorrect information might appear in the exported Interrupt Map Report file. Workaround: If the Interrupt Map Report is not correct for your design, replace the one-bit slices with regular scalar connections when entering or exiting the hierarchy. | 2023.1 | 2023.2 | Fixed
PolarFire SoC | If you set the default I/O standard to 2.5V (which sets the bank voltage of the I/Os to 2.5V automatically) in the Libero project setting, assigning MSS I/O Bank voltage to 3.3V (that is, VCCI =3.3V) using PDC constraint generates following error message: `Error: [19137311]: PDC-124: This bank has some locked macros not compatible with this voltage. Ignore this setting at PDC Line : set_iobank Bank2 -vcci 3.30 -fixed yes` Workaround: Change the default I/O standard in Libero project setting to LVCMOS33 or LVTTL and update other I/Os to accommodate the change. | 2022.1 | — | Open
PolarFire, PolarFire SoC | PF_CCC: PLL outputs are not phase aligned consistently after multiple Power Cycle/toggling of the powerdown pin. | 2021.1 | 2022.2 | Fixed
RTG4 | If the RTG4FCCCECALIB core is configured for external feedback mode with FB_CLK sourced from a CCC GLx output, and if the CCC outputs are configured to remain low until PLL lock is acquired, a deadlock condition occurs because the FB_CLK input never toggles, preventing the PLL from locking. If external feedback is selected in the standard RTG4FCCC core, Libero ignores the user option to hold CCC outputs low until the PLL locks to prevent such a deadlock. The RTG4FCCCECALIB core will be updated in a future release to remove the deadlock condition by ignoring the option to hold CCC outputs low when external feedback is selected. Workaround: If using external feedback mode, allow the CCC outputs to operate even before PLL lock is acquired (default). Alternatively, edit the generated RTG4FCCCECALIB core HDL manually so that the GL#_Y#_EN input to the CCC primitive is tied to ‘1’ for the CCC GLx output used to drive the FB_CLK input. | 2021.3 | 2022.2 | Fixed
RT PolarFire, PolarFire | RT PolarFire, MPF500T: Design contains encrypted blocks and Synthesis (or Compile) fails with the following message. `Error: NETLIST:011 Module or UDP : (some_module) is not defined. FILE <null> LINE 0` Possible reasons: Encrypted blocks contain more than one top-level module. An encrypted module instantiates another encrypted module. Workaround: Execute the following Tcl command before executing the Synthesis or Compile tool: `defvar_set -name RWNETLIST_32_64_MIXED_FLOW -value 0` | 2021.3 | 2022.3 | Fixed
All | If there is no MSS or a MiV processor in a SmartDesign, exporting an interrupt map report causes Libero to crash. | 2022.3 | 2023.1 | Fixed
All | If two different VHDL files have the same signature (same inputs, outputs, and architecture), the modules are not detected as duplicate modules in the Design Hierarchy. | 12.4 | — | Open
All | If a module is present in an include file, the file appears as a linked file inside the project. If there is a broken Global Include Path for such projects, the include file is also shown with a broken link. If the project is closed and re-created, the correct Global Include Path appears properly. If the Global Include path under Project Settings is changed, two links are shown for the include file inside the project: One with the new Global Include Path, as shown inside the project, and Another that is the broken link with the previous Global Include Path. There is no issue with functionality, but an extra broken link is shown in the project. Remove this link when the Global Include Path in Project Settings is changed. | 12.5 | — | Open
All | Linux CentOS7.9 UI test: Users cannot view help topics. Workaround: In Firefox, go to about:config > security.fileuri.strict_origin_policy and change the value to False. Then reopen the help. | 2022.1 | N/A | Will not fix
PolarFire and PolarFire SoC | In Project Settings > Design Flow, Libero 2022.3 users who check Enable FPGA Hardware Breakpoint Auto Instantiation and then hover over the i near the GUI option should ignore the following message that appears beside the FHB check mark because the new FHB compile implementation allows the FHB to be instantiated on any CLKINTs: `FHB will be instantiated only if the fabric logic is driven by a gated clock output of an FCCC.` | 2022.3 | 2023.1 | Fixed
PolarFire and PolarFire SoC | Incorrect PUFT timing is reported when SPI Flash uses an Initialization client. | 2021.2 | N/A | Will not fix
PolarFire and PolarFire SoC | To invoke FHB auto-instantiation flows with PolarFire and PolarFire SoC, you must create your own NDC file using auto_instantiate_fhb commands. If the NDC file is named with the postfix fhb_auto_generated.ndc, the flow deletes the file and crashes. Workaround: Do not name or use files with the postfix fhb_auto_generated.ndc when using FHB auto-instantiation flows in PolarFire and PolarFire SoC. | 2022.3 | 2023.1 | Fixed
RTG4, PolarFire, and PolarFire SoC | I/O Editor shows resistor pull for P and N pins when LVDS failsafe (Dynamic ODT) is enabled. For RTG4, PolarFire, and PolarFire SoC families, the resistor pull information for P and N pins are shown as pull up or both as pull down. They should be pull up for one pin and pull down for the other pin. This is a display issue only that existed in the I/O Editor and the pin report since v11.9 SP3. Due to a software infrastructure limitation, the P and N sides cannot have different values. Regardless of the display issue, both P and N sides program correctly: If the RES_PULL is Up on both sides, it means the N side is programmed as Down. If the RES_PULL is Down on both sides, it means the N side is programmed as Up. | 12.4 | — | Open
RTG4 | In the PLL Options tab under Output Resynchronization After Lock, when the option Held output in reset (output low) after power-up. Released and resynchronized with the PLL reference clock after the PLL locked is set for the RTG4FCCCECALIB core, the output clock appears at the CCC output slightly before the LOCK output is asserted. Workaround: When synchronizer is used for the LOCK signal, do not use the GLx output clock. For example, use the free-running clock CLK_50 MHz to clock the synchronizer circuit. Use the output of the three-stage synchronizer to drive both the LOCK signal and the GLx_Yx_EN signal. For more information, see the RTG4 FCCC Enhanced PLL Calibration Configurator User Guide . | 2021.2 | — | Open
PolarFire and PolarFire SoC | A new FHB implementation allows FHBs to be added to any CLKINT/RCLKINT/GCLKINT/RGCLKINT of a design. However, there are some limitations about the kind of topologies allowed. With SmartBERT, the RCLKINTs connected to output RX_CLK_R and TX_CLK_R are considered illegal instances for FHB instantiation. These instances are considered to be illegal because FHB instantiations create an additional CLKINT and connect it to the same driver as the RCLKINT; however, the RX_CLK_R and TX_CLK_R nets are considered dedicated lines and allow only one connection. As a result, the additional CLKINT cannot make the connection and causes the flows to error-out. | 2022.3 | 2023.1 | Fixed

### 14.1.2 Synthesis/Simulation

(Ask a Question)

The following table lists the known issues and limitations associated with Synthesis/Simulation.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
RTG4 | Some designs with divide ratios of 3, 6, or 12 that worked in ModelSim-ME may not function as expected in QuestaSim-ME. Workaround: Customers encountering this issue should continue to use ModelSim-ME. | QuestaSim-ME 2025.3 | --- | N/A
All | On Linux, using FlashPro6 to program a device and then launching the Identify Debugger interactively will fail with the following error: `ERROR: Unable to Enable Programmer: (Error: Failed to enable FlashPro6 programmer)` This issue is specific to FlashPro6 on Linux. Workaround: If you are using FlashPro6 on Linux, do not launch the Identify Debugger from within Libero. Instead, open the Identify Debugger in standalone mode by invoking the debugger from:
    ${Libero_installation_directory}/Identify/bin/identify_debugger
Open the project file located:
    ${libero_project_folder}/synthesis/*.prj
| 2026.1 | --- | Open
All | Starting with SynplifyPro Y-2026.03M, Synplify reports multiple-driver errors when the same variable is assigned in two different always blocks and the logic is not inferred as memory. In these cases, the errors are intentional and expected. However, false multiple-driver errors can also occur in memory-related scenarios when assignments that are correctly inferred as memory writes are followed by assignments that cannot be inferred as memory writes. For example,
    Example 1
    input [31:0] comm_address;
    reg [31:0] m_comm_address [0:2];
    input [5:0] comm_burst;

    always @(posedge clock) begin
        if (!comm_queue_in) begin
            m_comm_address[m_comm_index] <= comm_address; // First write is a candidate for memory inference
        end
        else if (!comm_queue_out) begin
            m_comm_address[0] <= m_comm_address[1]; // Second write is not a candidate for memory inference
        end
    end
    Example 2
    reg [dwidth-1:0] ram_ff [0:memsize-1];
    always @(`PICO_CLOCK_EDGE `PICO_CLOCK_SENSITIVITY) begin
        if (mreq0 && mmode0)
            ram_ff[maddr0] <= moutdata0; // First write is a candidate for memory inference
        for (i = 0; i < memsize; i = i + 1) begin
            if (raw_datain_enable[i])
                ram_ff[i] <= raw_datain[(i*dwidth) +: dwidth]; // Second write is not a candidate for memory inference
        end
    end
Workaround: As a workaround for such memory cases, please apply the synthesis attribute disable_early_mem_extraction and rerun the flow. For example,
    reg [31:0] m_comm_address [0:2] /* synthesis disable_early_mem_extraction=1 */;
| 2026.1 | --- | Open
PolarFire SoC | The current PFSoC MSS Simulation User Guide indicates that the default value is 0; however, the simulation library sets the default value to 1. Workaround: Specify -gBFM_SELECT=1'b0 in the vsim command line to select the QoS AXI Initiator. | 2025.2 | 2026.1 | Fixed
PolarFire | If your RTL design includes arithmetic operations such as modulus calculation for single-precision 32-bit floating-point numbers, and utilizes clocking resources, the synthesis tool may infer extensive combinational logic and carry chains, while generating very few registers. As a result, the timing-driven placer tool spends significant time analyzing paths through the large combinational logic, which can cause the Place and Route tool to become stuck. Workaround: Disable the timing-driven option to enable Place and Route (P&R) to complete with minimal delay. | 2025.1 | 2025.2 | Fixed
All | The netlist produced by the synthesis tool is inaccurate when the RTL includes a division operation in which the numerator is a real number and the denominator is an integer. In these cases, the synthesis tool incorrectly outputs an integer instead of a real number. As a result, certain connections are assigned a value of zero and remain unconnected in the generated netlist, leading to incorrect functionality. Workaround: Ensure that both the numerator and the denominator are real numbers for division operations | 2024.2 | 2025.2 | Fixed
All | The Libero SoC tool is unable to recognize Synopsys all-vendor tools such as Synplify Elite and Synplify Apex, starting with Synplify version T-2022.09. As a result, synthesis fails when these tools are selected from Tool Profiles > Synplify Pro from Synopsys in Libero SoC version 2023.1 and later. Workaround: None | 2023.1 | 2025.1 | Fixed
All | The Synplify TMR report does not report arch-level TMR. Workaround: The SynplifyPro tool performs the TMR implementation accurately. However, the TMR report is not generated correctly. The TMR implementation can be confirmed either by referring to the *.srr log file or examining the generated VM netlist. | 2022.1 | 2024.1 | Fixed
RTG4 | If a module from one VHDL file instantiates another module defined in a different VHDL file located in a separate library, the Stimulus Hierarchy may not display correctly. Additionally, if the same VHDL modules are defined in multiple VHDL libraries, the hierarchies may not build correctly and a "?" might be shown for modules are that are not found. Workaround: If the Design Hierarchy is not correctly understood by the tool, either re-organize the way the VHDL modules and libraries are defined to avoid the scenario described, or right-click the Synthesize step in the design flow to select Organize Input Files > Organize Source Files..., and then create a manual file organization by telling Libero SoC which source files should be used for Synthesis and in which order. | 2022.1 | — | Open
SmartFusion2 | The SmartFusion2 MSS DDR Fabric Interface Controller (FIC) AXI port exhibits incorrect read channel behavior during simulation. If the read address channel operates independently from the read data response channel, it can lead to incorrect ARREADY behavior. Additionally, depending on the clock ratio between the DDR and fabric interfaces, misaligned read data may occur on the fabric AXI bus. Workaround: Please contact Microchip Technical Support to request pre-compiled libraries tailored to your specific simulator to address this issue. Kindly refer to Case Number 01019123. | 2022.1 | — | Open
All | Synplify Pro versions S-2021.09-SP2, S-2021.09M, and S-2021.09M-SP1 can incorrectly synthesize Verilog RTL using increment/decrement operations (++ / --) while indexing into an array on the right-hand side (RHS) of an assignment statement. Workaround: The Verilog can be modified to perform the increment/decrement operation in a for loop instead of during array indexing Note: For additional details, see PCN BLAS-18JFVA747. | 2022.1 | 2022.3 | Fixed
All | Prior to Synplify Pro ME version S-2021.09M-SP2 and all-vendor version T-2022.09, Synplify Pro synthesis software could incorrectly implement VHDL expressions containing a subtraction with a real constant number operand, and an additional division/multiplication operation that uses a variable. The issue occurs when the division/multiplication using a variable occurs in either the minuend or subtrahend terms of the subtraction operation. Workaround: Upgrade the synthesis tools and re-synthesize the design using Synplify Pro ME version S-2021.09M-SP2, or Synplify Pro standalone version T-2022.09, or later. Note: For additional details, see PCN RMES-14NRSU939. | All | 2022.3 | Fixed
PolarFire, PolarFire SoC | Simulating encrypted IP CORE10GMAC designs with QuestaSim ME Pro 2023.1 optimizes the design in a way that causes the APB interface PREADY signal to go undefined. Workaround: Disable the optimization in encrypted code by adding the `-voptargs="+acc -noprotectopt"` option to the `vsim` command. | 2023.2 | — | Open
All | Siemens does not support ModelSim Windows 10 on I7-11th generation machine. | 2022.1 | N/A | Will not fix
PolarFire | If automatic compile point is enabled, synthesis passes successfully, but Place and Route errors-out and points to the derived constraint file: `Error: SDC0025: C:\validate\PF_Mi_V_Tut\constraint\PROC_SUBSYSTEM_derived_constraints.sdc:17: Invalid false path constraint: the - through value [get_nets {AXI4_Interconnect_0/ARESETN* }] is incorrect.` Workaround: Perform one of the following steps: Uncheck Automatic Compile Point to turn it off while running synthesis through the Libero > Synthesis > Configure Options dialog. Do not modify the rest of the options and all constraints. Update the *derived_constraints.sdc file to the following (use `get_pins` instead of`get_nets)set_false_path -through [ get_pins { AXI4_Interconnect_0/ARESETN* } ]` | 12.9 | N/A | Will not fix
N/A | Identify debugger 2021-03M with Libero 2021.2 crashes on 11th generation Windows 10 machines. | 2021.2 | 2022.1 | Fixed
All | The vdir command used with ModelSim ME Pro 2021.3 for pre-compiled libraries on tess delivers the incorrect result of unknown version. | 2021.3 | 2022.2 | Fixed
All | In a Libero flow, when multiple identify implementations are created and run initially, an error message appears only in the synthesis log and does not propagate to the Libero error log. The following error message appears in the Libero window: `No instrumentation file found for Identify implementation. Please open SynplifyPro interactively to launch Identify Identify Instrumentor.` | 2021.2 | — | Open
All | If an Identify implementation was created through a Libero project before another synthesis implementation (synthesis_1) is created using Libero > Synthesis > Configure Options, the next run synthesis_1 command fails. Checking the Active implementation dialog, confirming that there is no implementation in the pull-down menu, and then rerunning the Libero project places Libero in an unexpected stage. Workaround: When Identify implementation is created using Libero > Synthesis > Configure Options, open SynplifyPro interactively, instrument the design, and run synthesis before running any synthesis or creating new implementation. Then return to Libero and create a new synthesis/identify implementation. | 2021.2 | — | Open
All | With the SynplifyPro R2021.03M release, when Synplfiy Pro is invoked on the Ubuntu platform, it lists packages/libraries on the terminal. This message can be safely ignored. Similarly, choosing Libero > Edit Profile > Synthesis lists packages/libraries on the Ubuntu platform. When prompted, click OK to proceed. | 2021.2 | — | Open
All | If multiple implementations are created in Libero/Synplify flows, rerun synthesis each time the active implementation is switched to have Libero fetch the intended `.vm netlist` for active implementation. | 2021.2 | — | Open
PolarFire | The following enhancement to Synthesis Compiler in this SynplfiyPro 2020.09MSp1 release (Libero v2021.1 release) is related to the initial value support for memory initialization. This is not technology specific. Test cases with MiV core fails in synthesis with following error message: @E: `CS162 :"./component/work/MIV_RV32IMA_L1_AXI_C0/MIV_RV32IMA_L1_AXI_C0_0/core/ miv_rv32ima_l1_axi_data_arrays_0_ext.v":81:24:81:38|Loop iteration limit 2000 exceeded - add '// synthesis loop_limit 4000' before the loop construct` Workaround: In the Libero GUI, select Synthesis > Configure Option > Additional Parameters box and set the -looplimit option to 4000. OR Add the following `SYNPLIFY_OPTIONS` options, and then set this option and run synthesis. `configure_tool -name {SYNTHESIZE} -params {BLOCK_MODE:false} -params {BLOCK_PLACEMENT_CONFLICTS:ERROR} -params {BLOCK_ROUTING_CONFLICTS:LOCK} -params {CLOCK_ASYNC:800} -params {CLOCK_DATA:5000} -params {CLOCK_GLOBAL:2} -params {PA4_GB_COUNT:24} -params {PA4_GB_MAX_RCLKINT_INSERTION:16} -params {PA4_GB_MIN_GB_FANOUT_TO_USE_RCLKINT:1000} -params {RAM_OPTIMIZED_FOR_POWER:0} -params {RETIMING:false} -params {SEQSHIFT_TO_URAM:0} -params {SYNPLIFY_OPTIONS: set_option -looplimit 4000} -params {SYNPLIFY_TCL_FILE:}` | 2021.1 | — | Open
PolarFire | A low data rate of 500Mbps/250Mhz fails with the QDR II + Xtreme device in simulation, but passes on the board. | 2021.1 | — | Open

### 14.1.3 Timing/Power

(Ask a Question)

The following table lists the known issues and limitations associated with Timing/Power.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
PolarFire SoC | Mixed mode is not supported for the LVCMOS standard in MSSIO. Workaround: Users may manually select the respective LVCMOS model from generic IBIS file and include it in the exported IBIS file | 2025.2 | 2026.1 | Fixed
PolarFire | The analysis and reporting for the non-SDC standard constraints, set_external_check and set_clock_to_output, do not take clock jitter into account. Workaround: To prevent this issue, avoid using the set_external_check and set_clock_to_output constraints. Instead, it is recommended to use the standard set_input_delay and set_output_delay constraints. | 2023.2 | 2024.2 | Fixed
PolarFire and PolarFire SoC | The device is not programmed correctly when the "Enable RX_CLK_ODT_EN for LVDS failsafe" option is selected in combination with the "Clock to data relationship" setting configured as Dynamic, Centered, or Aligned in the IOD Generic RX configurator. Workaround: You can achieve the same functionality as "Dynamic" by using "Fractional Dynamic" and setting the "Input Clock Ratio" to 1. | 12.2 | 2025.1 | Fixed
IGLOO2, SmartFusion2 | SmartFusion2 (M2S150) and IGLOO2 (M2GL150) designs using clocks routed to the global network through RCLKINT macros may experience a skew-induced timing violation that is not reported during Static Timing Analysis. This issue can occur when multiple Row Global Buffers (RGBs) are cascaded to reach loads spanning a large FPGA fabric area per Customer Notification 19024.2. Workaround: Upgrade to Libero SoC v12.2 or later. For M2S150/M2GL150 designs already in production, contact Microchip Technical Support to obtain the timing analysis script referenced in CN19024.2 | 12.0 | 12.2 | Fixed
All | When writing SDC timing exceptions, such as false path, multicycle path, or set max/min delay constraints, using the [get_clocks {…}] construct applies the timing exception on the clock domain’s register-to-register paths only, and not to the clock domain’s paths related to inputs or outputs with associated set_input_delay or set_output_delay constraints, respectively. For example, false path constraints set between clock objects referenced using `get_clocks` disables only the register-to-register paths and not the I/O-related paths. Workaround: Avoid using `get_clocks` in timing exception SDC commands. Paths between clock domains can be disabled using appropriate clock group constraints instead of false paths between clock domains. In other cases, consider whether `get_clocks` can be omitted, or replaced by `get_ports` on the clock port or `get_pins` on the instance pin. For additional information, contact Microchip FPGA Technical Support. | Libero IDE v8.0 | 2025.1 | Fixed
SmartFusion2 | The clock constraints generated by the software for oscillators internal to SmartFusion2 and Igloo2 devices use the oscillator typical clock period and not their worst case. Workaround: You can override these clock constraints using the worst-case period listed in the datasheet. | 12.4 | — | Open
RTG4 | Libero SoC’s Verify Timing design flow step reports a timing violation in the multi-corner timing reports and Timing Report Explorer tabs. However, when opening the SmartTime GUI, the violation cannot be seen, even after confirming that SmartTime analysis operating conditions have been set to match the conditions used to identify the violation in the Verify Timing reports. The SmartTime GUI has an issue where the path list does not correctly account for the clock generation delay, even though the expanded path detail correctly accounts for the clock generation delay. Workaround: Always use the multi-corner timing violation reports to determine if there are timing violations. Use the Timing Report Explorer to review the violating path list graphically, until the SmartTime GUI issue is fixed. | 2024.1 | 2025.1 | Fixed
RTG4 | You might encounter errors during Net Delay Calculation when running Place and Route or Timing Verification if starting a Libero SoC project with an EDIF (.edn) netlist as the design source file. Workaround: Use the Synplify Pro mapped Verilog netlist (.vm file) as the source file instead of the EDIF (.edn) netlist. | 2023.1 | N/A | Will not fix
PolarFire SoC | TGrade2 for the MPFS460 devices is not supported. Remove the following parts from the software: MPFS460T-1FCG1152_EvalT2 MPFS460T-FCG1152_EvalT2 | 2021.3 | 2024.1 | Fixed
RTG4 | If a generated clock constraint is set on an unused CCC output, SDC processing fails during timing analysis and all following constraints are ignored. Workaround: Use derived constraints. | 2023.2 | N/A | Will not fix
RTG4 | Errors on clock names for `set_input_jitter` are not reported. `set_input_jitter` constraints with erroneous clock names are simply ignored. | 2023.2 | 2024.1 | Fixed
PolarFire and PolarFire SoC | Prior to Libero SoC v2023.2, designs targeting MPFS025xx and MPFS025xx devices could have placed High-Speed I/O Clock (HS_IO_CLK) instances at locations that are not routable. Required Action: Microchip recommends upgrading to Libero SoC v2023.2 and re-running Place and Route to ensure that HS_IO_CLK instances are not placed in non-routable locations | 2021.3 | 2023.2 | Fixed
PolarFire SoC | An MPFS160 design with a connection between an HS_IO_CLK and an ICB may fail during timing analysis with the following error message: `Error: Cannot find hardwired track ICB_BANKCLK_* - Error during net delay calculations` Workaround: Move the HS_IO_CLK to the next available location | 2023.1 | 2023.2 | Fixed
IGLOO2/SmartFusion2 | Prior to Libero SoC v2022.3, the Static Timing Analysis (STA) clock-to-output delay used for SmartFusion2 and IGLOO2 LSRAM RAM1K18 ports configured to use write feed-through mode (WMODE=1) could be optimistic when reading (WEN=0). For more information, refer to the latest IGLOO2 or SmartFusion2 datasheet revision history effective on or after PCN SYST-09ERAC80. The datasheet revision history links to the detailed CN explanation found at: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/can/CN_SF2_IGLOO2_FPGA_LSRAM_Write-Feedthrough_Timing.pdf Workaround: Review the required actions found in the CN explanation found at: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/can/CN_SF2_IGLOO2_FPGA_LSRAM_Write-Feedthrough_Timing.pdf | 2022.1 | 2022.3 | Fixed
All | The SSN Analyzer tool does not sort pins properly when determining I/O adjacency, resulting in the SSO analysis being incorrect. For RTG4, PolarFire, PolarFire SoC, and RT PolarFire, adjacent pin number sorting should be done by I/O pair number per I/O bank using pin assignment tables posted on the Microchip website. For SmartFusion2 and IGLOO2 devices, contact Microchip Technical Support for more details. For SSN analysis, see device-specific documentation such as the SSO application note. | 2022.2 | 2023.1 | Fixed
PolarFire | Core version of 160 MHz oscillator generates the clock name `OSC_0/OSC1_0/I_OSC_160/CLK` in derived constraints, but FHB SDC constraints are not applied correctly. Workaround: Manually modify the derived constraints clock name to `osc_rc160mhz` instead. | 2022.3 | 2023.1 | Fixed
PolarFire | The maximum clock frequency on the regional clocks (`RX_CLK_R/TX_CLK_R` on serdes and `RX_CLK` on lanectrl) in PA5M300XT do not match the frequency on the datasheet. | 12.5 | — | Open
PolarFire | The violation report shows violations (red cross), but the timing report does not (green check). In this case, there is indeed a timing violation and the red cross is correct. | 12.5 | 2023.1 | Fixed
PolarFire | The Power Estimator does not support ES devices and EVAL packages. | 2021.2 | N/A | Will not fix
PolarFire SoC | MPFS250 MIL Timing Reports Data State is marked Preliminary instead of Production. | 2022.3 | 2023.1 | Fixed

### 14.1.4 SmartDebug

(Ask a Question)

The following table lists the known issues and limitations associated with SmartDebug.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
PolarFire, PolarFire SoC | Eye Monitor results between the initial and subsequent XCVR debug plots are inconsistent. Workaround: These steps preserve repeatability when capturing multiple eye plots: Read theDES_DFEEM_CTRL_1 register and save its current value. Generate the eye plot. After the plot is generated, note that theDES_DFEEM_CTRL_1 register value changes to0x00000000. Restore the register value saved in Step 1. Generate the eye plot again. Repeat Steps 2 through 5 before each additional eye plot to maintain consistent results. | 2025.2 | --- | Open
RTG4, PolarFire, PolarFire SoC, RT PolarFire, RT PolarFire SoC | In an auto-construct project flow, if a device is programmed using a PPD bitstream file that includes security keys, UPROM client data and other memory blocks may not be readable afterward. In this condition, attempts to read memory from the device can fail with the following message: “UPROM Client data could not be retrieved from the device. The memory block could not be read.” This issue can occur when the following sequence is used: Create an auto-construct project while the programmer is connected. Open the Programmer Connectivity and Interface dialog box. Load a PPD bitstream programming file generated with security keys included. Run the Program action. Load a DDC file generated either without a bitstream or with a bitstream that includes pass keys. Close the Programming Connectivity Interface. Attempt to read UPROM or another memory block from the device. Workaround: To avoid this issue, create the project by importing the DDC file that already includes the bitstream, and then use the PPD file that includes the security keys for programming. With this flow, the device can be programmed successfully, and UPROM and other memory blocks remain readable. | 2026.1 | --- | Open
All | If multiple programmers are connected to the same local machine with identical target devices, and any of those programmers are not reserved or already in use by another user or application, Active Probe bitstream programming may run on all matching target devices. Workaround: To avoid unintentionally programming a design with Active Probe insertion, make sure only the intended target device is available before starting the programming operation. You can do this by using one of the following methods: Power off the board connected to any device that should not be programmed. Unplug any unnecessary programmer connected to a matching device. Disconnect any matching device that should not be accessible for programming. | 2026.1 | --- | Open
PolarFire and PolarFire SoC | The FHB arm trigger does not function as intended when the trigger edge is set to negative and the delay cycles before halt are set to a positive value. Workaround: There is currently no workaround for this issue. The trigger operates as expected only when the delay cycles before halt are set to zero. | 2025.2 | — | O
PolarFire | In Standalone SmartDebug, when creating a project using the automatic construction feature, importing a PPD file, and attempting to program the device, the following error message is displayed: `“The device with name 'MPF300T' doesn'texist.”` This issue occurs on Linux systems when working with the PolarFire 300T device. Workaround: Close the project and reopen it. This will enable debugging of the design from the imported DDC file. | 2025.2 | 2026.1 | Fixed
PolarFire | In Standalone SmartDebug, if you create a project using the automatic construction method, import a PPD file, and execute the program action, loading a DDC file that does not contain a PPD file will result in the following error: `“No device is selected for debugging.”` Workaround: Close the project and reopen it. This will enable debugging of the design from the imported DDC file. | 2025.2 | 2026.1 | Fixed
All | In Standalone SmartDebug, when a project is created using the automatic construction method and a DDC file is imported to program the device, the debug options are displayed; however, it is not possible to debug any components. When attempting to read Active Probes from the device, a pop-up message appears stating: `“Instance database is not set. There was an error while loading the tree.”` Workaround: To resolve this issue, open the Program Connectivity interface and reload the DDC file that was used for programming. This action will display the design features available for debugging. Alternatively, you can create a project by directly importing the DDC file and then program the device to enable debugging capabilities. | 2025.2 | 2026.1 | Fixed
All | If a FlashPro6 programmer is connected to a Linux workstation and you select Refresh/Rescan Programmers, SmartDebug returns the following error message: `Error: No programmers found. Please check the programmer connection to the computer and ensure the drivers are properly installed.` If this occurs, SmartDebug displays the following message until you follow the published workaround: `Error: Failed to perform cyusb_bulk_transfer = -1` `Error: Unable to read device information for the selected device: Internal error: Algo action 'dbg_read_device_info' execution failed: FP6: Set Pre DR error. Check the programmer connection to the computer and try "Rescan Programmer" button from the SmartDebug main window.` Workaround: Disconnect the programmer and reconnect to PC. | 2023.2 | 2024.2 | Fixed
All | Exporting component description of HDL+ core causes Libero® SoC to crash. | 2022.2 | 2022.3 | Fixed
PolarFire® | Designs using DDR controller with FHB enabled may crash during the compiling stage with the following error message: `Internal Error:` `Assertion Failed in: “F:/release/sn/capture_sjsrvts05_mica_jen_sn/ nsrc/hld/lib/gdevbase/src/gdev/gdevchip.cxx”, line 1598. Please call technical support for assistance, providing the above diagnostic information` | 12.8 | 2022.3 | Fixed
PolarFire | Using SmartDebug > Transceiver View > Register Access generates the following error message if you try to access register lane on Quad 4 and Quad 5 for the MPF500 devices: `Error: Added Register List is empty.` | 2022.2 | 2022.3 | Fixed
PolarFire, PolarFire SoC | PolarFire SoC MSS register access: MSS read error occurs on the `CFG_DDR_SGMII_PHY` group of registers with the following error message: `AXIERR is set to 1` Currently, there is no workaround for this issue. | 2021.1 | 2024.2 | Fixed
PolarFire SoC | If Dual mode PCIe design is considered in SmartDebug, the PCIe debug feature shows Data Rate, Link Width, and other parameters for PCIe1, but not for PCIe0. | 12.5 | — | Open

### 14.1.5 SmartHLS™

(Ask a Question)

The following table lists the known issues and limitations associated with SmartHLS.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
PolarFire SoC | When generating reference Libero designs for the iCicle board in SmartHLS on Ubuntu 22.04.3 LTS, the following warning message may appear: `cat: /etc/redhat-release: No such file or directory` Workaround: For more information, refer to the Knowledge Base (KB) article linked below: https://support.microchip.com/s/article/SmartHLS-v2026-1-Generate-Libero-Design-Fails-on-Ubuntu-22-04-3-LTS | 2026.1 | --- | Open
All | In Eclipse, when you add a picture to the existing project by dragging the picture to the project explorer, Eclipse crashes. If you want to add a picture, you can right-click the project and add it by importing from the File System. | 2025.1 | — | Open
All | Currently, SmartHLS™ does not support checking Installation History. Opening this tab displays the following error message: | 2025.1 | — | Open
All | After the project is created, the first time you right-click to build or clean, the following message appears. This does not impact functionality. | 2025.1 | — | Open
All | Currently, if you use `shls -g` on the Linux command line without having valid licenses, the following error message appears and you cannot launch IDE:
    ERROR:root:Info: Checking for Libero license.
    [LicenseHelper.cpp:129: getLicenseStatus] Error: There is a problem with your Libero license.
    Your current environment variable is: LM_LICENSE_FILE=
    Please modify your LM_LICENSE_FILE environment variable and restart SmartHLS.
    Unable to find a valid tool license for: ACTEL_EVALSOC, ACTEL_BASESOC, ACTEL_VISTA, or ACTEL_SUMMIT

    [LicenseHelper.cpp:129: getLicenseStatus] Error: SmartHLS has exited due to an error. For support, please visit
    https://onlinedocs.microchip.com/v2/keyword-lookup?keyword=techsupport&redirect=true&version=latest.
You can still compile and run software from the command line using `shls sw_compile` and `shls sw_run`. | 2025.1 | — | Open
All | On Ubuntu, Eclipse does not support external browsers installed by `Snap`. Make sure your default browser is not installed by `Snap`, or you can set the external browser from Window > Preferences > Web Browser > General. Select the browser of your choice and click Apply. | 2025.1 | — | Open
All | In the SmartHLS IDE, you might see red underlines on function calls, with the message that the function could not be resolved, as shown in the following figure: Figure 14-1.Indexing Error To fix the red underlines, select Project > C/C++ Index > Rebuild. This fixes any Eclipse indexing issues that result in library functions being underlined in red. Figure 14-2.Fix for Indexing Error For additional information about this known issue and the figures, click here: https://github.com/MicrochipTech/fpga-hls-examples/tree/main/Training1 | 2024.1 | — | Open
All | When you use the SmartHLS IDE in the Ubuntu environment, switching tabs while adding source files at the SmartHLS C/C++ project creation stage stops the IDE from responding and requires you to quit the IDE: Figure 14-3.Known Issue in Ubuntu Environment To avoid this issue, do not switch tabs while adding source files to the new project being created. | 2024.1 | — | Open
All | When `ap_int/ap_uint` type is used in the conditional operator ( `?:` ), explicit target type casting is needed in conditional expression that contains primitive operand. For example:
    ap_int<12> a, b, c;

    a = (b > 0)? a : (ap_int<12>)(a+1);
    c = (b == 2)? (ap_int<12>)0 : (ap_int<12)(a+1);
Missing explicit target type casting in the above statements generates the following compiler error message:
    error: conditional expression is ambiguous;
| 2024.1 | — | Open
- All | While C++ template is generally supported in SmartHLS, there are two known scenarios of using templated top-level functions where SmartHLS may still be able to generate the Verilog code but co-simulation will fail: Non-void returning templated top-level functions For example:
      template <typename SRC_TYPE>
      int cast_top (SRC_TYPE src) {
      #pragma HLS function top
          ....
          return ...;
      }

      int main() {
          int rtn = cast_top<float>(...);
          ....
      }
- Multiple top-level functions instantiated from the same templated class For Example:
      template <typename SRC_TYPE>
      void cast_top (SRC_TYPE src, int &rtn) {
      #pragma HLS function top
          ....
          rtn = ...;
      }

      int main() {
          cast_top<float>(..., rtn_f);
          cast_top<double>(...., rtn_d);
      }
| 2024.1 | — | Open

### 14.1.6 Programming

(Ask a Question)

The following table lists the known issues and limitations associated with Programming and Debug tools.

Family | Description | Version Found | Version Fixed | Status
--- | --- | --- | --- | ---
PolarFire SoC, RT PolarFire SoC | The label for the "Disable bitstream programming actions" section in the Update Policy of the Configure Security tool incorrectly states that it impacts only JTAG and SPI-Slave; it also affects IAP services. Workaround: None. The issue is caused by an incorrect text label. | 12.4 | --- | Open
PolarFire, PolarFire Soc, RT PolarFire and RT PolarFire SoC | Programming of SPI Flash images in STP format is not functional in FlashPro Express. The generation of SPI Flash images in STP format is not impacted. Workaround: The customer should use a third-party STAPL player to program SPI flash images in STP format. Alternatively, they may use the FP6 with FPExpress to program the SPI flash using a job file. | 2026.1 | --- | Open
All | When DO_VERIFY is enabled under the PROGRAM action, the expected verification log entry is not shown when using embedded FlashPro6 or FlashPro6 programmers. This log entry appears as expected when using FP5. Workaround: There is no functional impact from the missing log entry. If confirmation through this log output is required, use an FlashProP5 programmer. | 12.0 | --- | Open
RTG4 | The Design Version and Silicon Signature values configured in the "Configure Programming Options" tool are not being propagated to the bitstream generation step. As a result, the final bitstream shows the Design Version as 0 and the Silicon Signature as an empty string. | 12.0 | --- | Open
PolarFire, PolarFire SoC, RT PolarFire, RT PolarFire SoC | When using the security-only component, the Design Name shown in programming action logs may contain invalid or unexpected characters. Workaround: This occurs because the Design Name is only programmed when the Fabric is programmed and remains unchanged until the Fabric is erased. After erasure, the device may display residual memory values. To avoid this issue, program the Fabric so the Design Name is updated with valid data. | 12.0 | 2026.1 | Fixed
All | The ERASE programming action is determined by the most recently executed tool setting—either Generate Bitstream or Export Bitstream —rather than by the Generate Bitstream settings alone. As a result, if the Export tool is run last and the Sanitize all eNVM/sNVM pages option is not selected there, the ERASE action will not be available, even if it was previously available after running Generate Bitstream. Workaround: Before performing any programming action in Libero, run Generate Bitstream using the desired configuration, including whether the sanitize option should be enabled or disabled. This ensures that the programming actions are updated to reflect the intended settings before proceeding with device programming. | 12.0 | 2026.1 | Fixed
PolarFire, PolarFire SoC, RT PolarFire, RT PolarFire SoC | Design version doesn't update when bitstreams without Fabric is used for Auto-Update. Workaround: Include Fabric component with other components in Auto-update bitstream. | 12.0 | N/A | Will not fix
PolarFire and PolarFire SOC | Programming a security-only bitstream disables the fabric if it has already been programmed on the device and causes the VERIFY_DIGEST operation to fail. This issue affects the FP6 programmer, SPI Slave interface, and Direct-C solution. Workaround: Use a security-only bitstream only on a blank device, or program a bitstream that includes both security and fabric. | 12.0 | --- | N/A
PolarFire SoC | We identified an issue in the programming data generated for PolarFire SoC devices that can cause incorrect boundary scan register (BSR) information when transceiver (XCVR) pins are used in the design. As a result, some I/Os may not behave as intended during programming. The issue is limited to the G5SoC family and is associated with designs using XCVR RX, TX, or REFCLK pins; designs that do not use XCVR resources are not expected to be affected. Workaround: Upgrade to Libero 2026.1 and re-run the design flow starting from 'Generate FPGA Array Data' to regenerate the programming data with the fix included. | 12.0 | 2026.1 | Fixed
PolarFire SoC and RT PolarFireSoC | In the Update Policy GUI, disabling "Erase/Write Fabric and eNVM" automatically selects the "Disable Auto Programming and IAP Services" option. However, the One-Way Passcode (OWP) protocol requires Auto Programming and IAP Services to be enabled. If these services are disabled, OWP will not function. Workaround:. To ensure proper operation of OWP, users must manually deselect the "Disable Auto Programming and IAP Services" option | 2022.3 for PolarFire SoC 2025.1 for RT PolarFireSoC | 2026.1 | Fixed
All | In rare cases, bitstream generation may fail with the error message: `“Failed to instantiate FpdataHeader"` Workaround: Please delete the existing header file from your design directory and then rerun the Generate Bitstream tool. | 12.6 | — | Open
PolarFire and PolarFire SoC | If the bitstream is configured with the default key (KLK) and Stage 3 SPI flash binding is set to UEK1 in the Configure Design Initialization Data and Memories tool, the following error message appears in the log during job file export: `Error: SPI-Flash - Binding Encrypted with UEK1 is used for third stage initialization, but UEK1 is not set. Please set it using the Configure Security tool and then try again.` The primary issue occurs when Stage 3 SPI-Flash binding (within the "Configure Design Initialization Data and Memories" tool) is set to UEK1 or UEK2, while the bitstream security (configured via the Configure Security tool) remains set to the default security. In this scenario, no error message is generated, which may result in a RAM initialization failure. Workaround: Manually confirm that Bitstream security configuration (using the Configure Security tool) and SPI-Flash-Binding configuration (under Configure Design Initialization Data and Memories tool) are the same. | 12.0 | 2025.1 | Fixed
RT PolarFireSoC | During multiple device programming actions, the log under Security Locks and Configuration Settings displays User Security (DPK1/DPK2) is unlocked instead of User Security (UPK1/UPK2) is unlocked. Workaround: None | 2025.1 | 2025.2 | Fixed
PolarFire and PolarFire SoC | The digest information reported during programming with FP6 acceleration (Turbo) mode does not match the output reported by other programmers or job files generated with the STAPL format. Workaround: Use FlashPro4 or FlashPro5 programmer or generate the FlashPro Express job file using STAPL format. | 2024.2 | 2025.1 | Fixed
SmatFusion2/IGLOO2 | Exporting SVF bitstream files from Libero for SmartFusion2/IGLOO2 devices with eNVM sanitization option turned ON will fail when running ERASE action using the *_ERASE.svf file. Workaround: Create eNVM client(s) with all zeros filling the entire eNVM memory space and use *_PROGRAM.svf file to sanitize the eNVM. | 2021.1 | — | Open
PolarFire SoC | In PolarFire SoC, which uses the One-Way Passcode (OWP) feature, Libero crashes on Linux operating systems if you select Generate HWM from UTC under Advanced Options for *.spi files in the Export Bitstream dialog. | 2022.3 | 2025.1 | Fixed
RTG4 | The DSN value reported at the end of the programming action with FP6 acceleration (Turbo) mode is invalid. Workaround: Use FP4 or FP5 programmer or generate the Flash Pro Express job file using STAPL format. | 2024.2 | 2025.1 | Fixed
IGLOO2 | For M2S060 devices only, the Erase action might fail after generating a bitstream with the Sanitize ENVM on Erase option enabled. Workaround: Program the device by adding an ENVM client with a size equivalent to the previously programmed ENVM content, filled with all zeros. | 12.6 | 2025.1 | Fixed
SmartFusion2 and IGLOO2 | For SmartFusion2 and Igloo2, bitstream generation fails when using eNVM client with zero’s as content with sizes 126 KB and up with following error message: `This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Error: Error running TCL script Generating Bitstream File Failed` Workaround: Create file that programs zeros in intended pages in one of supported formats (Intel-Hex, Motorola, etc.,). | 2024.1 | 2025.1 | Fixed
SmartFusion2 and IGLOO2 | Exporting SVF bitstream file format fails for devices belonging to SmartFusion2 and IGLOO2 families with following error message: `Error: The identifier 'DO_READ_DESIGN_INFO' is used before or without declaration.` Workaround: None. The alternative is to use earlier releases of Libero SoC (v2024.1 or older). | 2024.2 | 2025.1 | Fixed
IGLOO2 and SmartFusion2 | Depending on the design, you might experience an I/O glitch when exiting programming mode, typically following program or verification actions. | 2023.2 | 2024.1 | Fixed
RTG4 | Insufficient wait time while exiting programming action runs can cause System Controller to come out of suspend mode in some cases when FlashPro programmer is still connected. Workaround: Disconnect Flashpro programmer and while keeping JTAG TRSTB low, power cycle the board to make sure System Controller remains in suspend mode. | 11.6 | 2024.1 | Fixed in version noted. For issue status on v11.x tools, see the v11.x Known Issues list
All | If Libero SoC or Program & Debug tools are installed on a Linux machine with no sudo access, some configuration files are not copied properly causing the software to crash if programmer access is needed; this includes loading an FPExpress project. Workaround: Install the software in SUDO mode. | 12.0 | 2024.1 | Fixed
All | Multiple applications cannot access the programming hardware (FlashPro4, FlashPro5, FlashPro6, or eFlashPro6) simultaneously including scanning/refreshing programmers. For example, if Libero is actively running programming actions, do not try to perform any operations in FlashPro Express, including opening a project. The software behavior is unpredictable. Workaround: Use only one application—Libero, FlashPro Express, SmartDebug, Identify, or SoftConsole—at a time. | 12.0 | N/A | Will not fix
PolarFire SoC | Even though the UI shows the option Keep MSS in operational state during programming for IAP/Auto Update using system services is selected, the generated bitstream does not configure it properly. Therefore, MSS will not be operational during programming. | 2021.1 | 2024.1 | Fixed
All | During chain programming, Libero crashes if the second device is a different family from the target device when you try to load a PPD file into the second device. Workaround: Use STP files instead of PPD files. | 2022.3 | 2024.1 | Fixed
All | If Libero SoC is installed in a Linux environment without sudo access, request the admin to install the FlashPro6 libraries after installation. Otherwise, the Libero SoC, FlashPro Express and SmartDebug tools will crash. Workaround: Ask Linux admin to install FlashPro6 libraries by executing ./bin/fp6_env_install. See installation guide for more details. | 2023.2 | N/A | Will not fix
PolarFire SoC | USB library access issue prevents the support of multiple eFP6 programmers with Libero, FlashPro Express, and SmartDebug. Workaround: Use a single eFlashPro6 programmer per workstation. | 12.6 | N/A | Will not fix
PolarFire, PolarFire SoC | If the bitstream is exported in SPI format, the Memory Initialization data stored is always encrypted and binded using the Default KLK regardless of the user-selected binding. | 2023.1 | 2023.2 | Fixed
PolarFire, PolarFire SoC | Changing security settings doesn’t invalidate generated bitstream in some cases. Running programming action uses a bitstream file generated with previous security settings. Workaround: If using Libero v2023.1 or earlier, re-run generate bitstream regardless of the state of the Generate Bitstream tool. | 2023.1 | 2023.2 | Fixed
SmartFusion2, IGLOO2, PolarFire, PolarFire SoCC | FlashPro Express fails to perform any programming action using FlashPro6 using the SPI Slave interface. The JTAG interface is not affected. Workarounds: Use the Libero SoC tool to perform the programming action. Use FlashPro5 with FlashPro Express for SmartFusion2 or IGLOO2 devices. Note: FlashPro5 does not support SPI Slave programming on PolarFire and PolarFire SoC devices. If FlashPro Express is required, generate a FlashPro Express job file using v2021.3 release and use an older version of FlashPro Express to run the job file | 2021.3 | 2022.2 | Fixed
All | Libero crashes when you try to switch between programmers using the Select Programmer tool. Workaround: Use only a single programmer per workstation, or Use the TCL command `select_programmer` to switch between multiple programmers. | 2023.1 | 2023.2 | Fixed
SmartFusion2, Igloo2 | BP and Silicon Sculptor 3 programmers error-out with hardware timeout when programming SmartFusion2/IGLOO2 devices using STAPL file. | N/A | 2023.1 | Fixed
PolarFire, PolarFire SoC | The following SPI bitstreams for devices cannot be used as SPI bitstream clients in Libero 2022.2 using a Silver and Gold license. Silver license – affected devices: MPF300TS MPF300TS_ES MPF300T MPFS250T_ES MPFS250T Gold license – affected devices: MPF300TS MPF300TS_ES MPF300T | 2022.2 | 2022.3 | Fixed
PolarFire, PolarFire SoC | SPI bitstreams exported prior to Libero v2021.1 cannot be used as SPI bitstream clients. Libero returns the following error: `Software Version is not available.` | 2022.2 | 2022.3 | Fixed
PolarFire, RT PolarFire, PolarFire SoC | Libero shows the incorrect warning/summary message that the SPI Slave interface is disabled. All SPI pins are disabled when disabling the SPI Slave interface in the Update Policy in the Configure Security tool. The second statement is incorrect, the SPI pins are not disabled. | 2022.1 | 2022.3 | Fixed
PolarFire, RT PolarFire, PolarFire SoC | Protected components in the custom security are exported in the SPI bit stream. | 2022.2 | 2022.3 | Fixed
SmartFusion2, IGLOO2 | If Programming Recovery is enabled in the Configure Programming options tool and is using custom security in Configure Security tool, the DAT bitstream file generated will be incorrect and will not erase the security completely on the device when running ERASE action. | 11.9 | 2022.3 | Fixed in version noted. For issue status on v11.x tools, see the v11.x Known Issues list
PolarFire, PolarFire SoC | If setting permanently write protect fabric in the Configure Permanent Locks tool, the exported bitstream file/job will also program sNVM update protection to be locked for update (i.e., protected by Flashlock/UPK1), even though sNVM updates were allowed without Flashlock/UPK1 in Configure Security tool. | 12.4 | 2022.2 | Fixed
PolarFire, PolarFire SoC | If Authenticate action is disabled in the Update Policy of Configure Security tool, the ENC_DATA_AUTHENTICATION action will fail in Libero and FlashPro Express, even when Flashlock/UPK1 is included in the bitstream file. If external zeroization through JTAG/SPI Target is disabled in the JTAG/SPI Target Commands Policy of Configure Security tool, ZEROIZE_LIKE_NEW and ZEROIZE_UNRECOVERABLE actions fail in Libero and FlashPro Express, even when Flashlock/UPK1 is included in the bitstream file. | 12.0 | 2022.2 | Fixed
PolarFire SoC | For PolarFire SoC Libero designs that contain eNVM, running VERIFY_DIGEST after programming the device will fail with the message eNVM digest verification: FAIL. Workaround : Deselect the procedure DO_ENABLE_ENVM in the VERIFY_DIGEST action | 12.9 | 2022.2 | Fixed
PolarFire, PolarFire SoC | Non-recoverable zeroization mode is not programmed with Libero design, which does not have any POR digest configured and no custom security. | 2021.3 | 2021.3 | Fixed
PolarFire, PolarFire SoC | In Libero designs containing SPI bitstream clients (IAP, Auto Update, or Recovery/Golden) along with a STAGE3 initialization client in the SPI Flash tab of the Configure Design Initialization Data and Memories tool, the output of the Export SPI Flash Image tool does not contain data for the STAGE3 initialization clients. Workaround: If possible, use the Generate SPI Flash Image and program in Libero or Export FlashPro Express job with SPI Flash and program via FlashPro Express. | 2021.2 | 2022.2 | Fixed
All | Performing READ_SPI_IMAGE using large-density flash devices is not recommended and can cause Flash Pro Express to become unresponsive. | 2022.3 | N/A | Will not fix
All | Programming actions with FlashPro6 will fail when connected to Windows 10 computers with 11th-generation Intel core processors. Workaround: Use FlashPro5 programmers. | 2021.1 | N/A | Will not fix
All | When performing any action with FlashPro6, the following error message could appear: `Error: Linux FP6 programmer - cyusb_bulk_transfer error.` Workaround: This error could be caused by the programmer being out of sync with the software application. To resolve this issue, unplug the USB cable from either the programmer or the host PC, and then reconnect it to reset the programmer. | 2021.2 | N/A | Will not fix
PolarFire | If you want to reprogram the Fabric/sNVM with UEK1/UEK2 bitstreams, and the program action is disabled in update policy, manually enable the plaintext pass keys when exporting the UEK1/UEK2 bitstreams. Currently, this option is unselected by default. | 2022.3 | 2023.1 | Fixed
PolarFire SoC | The plaintext pass keys are included in the bitstream even in the cases where protected components are not selected. The following two conditions apply: If Fabric/sNVM are locked for updates and eNVM is open for updates, you cannot unselect exporting the plaintext pass keys in export bitstream, but you can unselect this option when exporting the FlashPro Express job. If Fabric/sNVM are open for updates and eNVM is locked for updates, manually unselect exporting the plaintext pass keys. Manually enable exporting the plaintext pass keys in the export bitstream tool if the Fabric/sNVM and eNVM are open for updates and the Program action is disabled in the Update Policy. Otherwise, you will not be able to run the Program action with UEK1/UEK2. | 2022.3 | 2023.1 | Fixed
PolarFire, PolarFire SoC | Using SPI-Slave method with FlashPro6, verify digest action performs a check on all available components rather than the selected ones. | 2022.3 | — | Open
PolarFire SoC | Some test cases fail with the following error message: `Error: Failed to send data to eFP6. Err = -4|Error: eFP6 connection failed.` Workaround: Power cycle the Icicle board and rescan the programmers. | 12.6 | N/A | Will not fix
PolarFire SoC | If an Icicle kit is connected to one or more USB hubs, you may receive the following error message: `Error failed to open eFP6 HID handle.` | 2021.1 | — | Open
SmartFusion, RTG4, PolarFire, PolarFire SoC | You might see the following error message during programming: `Error: programmer 'S201QVCGH' : device 'RT4G150' : FP5 Scan: JTAG_ExecuteCommandSequence FP5: Error code = 4 - General device IO error. Error: programmer 'S201QVCGH' : device 'RT4G150' : Executing action VERIFY FAILED. Error: programmer 'S201QVCGH' : FP5 SyncWithProgrammerAtPort: OpenSpecifiedHiSpeedDeviceBySerialNumber - PortB FP5: Error code = 2 - Device not found.` This is most likely a USB connection issue. This error also appears if the connection is interrupted. The error message may be different, depending on where the packet is dropped during verify. However, the error code will always be set to 4, which indicates a general device I/O error. | 12.6 | N/A | Will not fix
SmartFusion2, IGLOO2 | FlashLock/UPK1 cannot be used to allow debug access through JTAG (1149.1) if it is disabled in the Debug Policy in Configure Security tool. | 2022.1 | 2023.1 | Fixed
SmartFusion2, IGLOO2 | If all the keys (UEK1/UEK2/UEK3) are disabled in keymode policy, ERASE and VERIFY actions fail with the following error message: `The action ‘ERASE' is not supported. You must select the programming action from this list: 'DEVICE_INFO, ENC_DATA_AUTHENTICATION, PROGRAM, READ_DEVICE_CERTIFICATE, READ_IDCODE'. The action 'VERIFY' is not supported. You must select the programming action from this list: 'DEVICE_INFO, ENC_DATA_AUTHENTICATION, PROGRAM,READ_DEVICE_CERTIFICATE, READ_IDCODE'.` Workaround: Do not run ERASE and VERIFY actions when all the keys (UEK1/UEK2/UEK3) are disabled in keymode policy. | 2021.3 | — | Open

### 14.1.7 Remote Debug/Programming Access

(Ask a Question)

The following table lists the known issues and limitations associated with Remote Debug/Programming Access tools.

Family | Description | Version Found | Version Fixed | Status
--- | --- | --- | --- | ---
All | In SmartDebug, the Active Probe action does not work correctly with remote programmers. If only a remote programmer is available, the action fails with a “programmer not found” error. If both local and remote programmers are available, the Active Probe action executes on the local programmer instead of the selected remote programmer. Workaround: None | 2026.1 | --- | Open
All | In Libero, if a project was previously used with a remotely connected programmer and is later reopened, directly running the Program action can remove the saved remote server entry from the project. If this happens, when the user later opens the Select Programmer window to reconnect to the remote programmer, the previously configured remote server entry is no longer available. Workaround: After reopening the project, open the Select Programmer window first instead of directly clicking Program. Opening the dialog preserves the remote server entry in the project, even if a local programmer is then selected and used. | 2026.1 | --- | Open
All | FPExpress may become unresponsive if the connection to the remote server is interrupted while a programming operation is in progress. In this case, the network interruption only affects the client - the programming action continues and completes successfully on the server. After the server completes the action, it closes the session and releases the programmer. However, the FPExpress client may remain unresponsive, requiring the user to close FPExpress manually and restart the session. Workaround: None | 2026.1 | --- | Open
All | On Linux, SIGTERM is a standard request to terminate a process gracefully. It allows an application time to save its state and perform cleanup before closing. Common commands that send SIGTERM include killall <process_name>, kill , and pkill . If Libero SoC, SmartDebug, or FlashPro Express is closed manually using one of these commands, local processes such as prgsrvdmn, prgservapp, or dbgservapp may remain active. Workaround: Force-terminate the main application by using kill -9 instead of a command that sends SIGTERM. If any related background processes remain after the application closes, terminate them manually. | 2026.1 | --- | Open

### 14.1.8 Installation and System Limitations

(Ask a Question)

The following table lists the known installation and system issues and limitations.

Description | Version Found | Version Fixed | Status
--- | --- | --- | ---
The following log message may appear when running Libero SoC on Windows 11 machines: `“TBBmalloc: skip allocation functions replacement in ucrtbase.dll: unknown prologue for function _msize”` This is informational and does not affect the operation of Libero SoC. Workaround: Running Libero with the environment variable TBB_MALLOC_DISABLE_REPLACEMENT=1 prevents the above message from appearing and results in consistent checksums. | 2022.3 | — | Open
With the introduction of new QT installers in the Libero SoC 2025.1 release, all standalone installations are now consolidated within the Libero SoC Design Suite. As a result, each standalone tool is listed as Libero SoC in the Windows Add/Remove Programs menu. Workaround: The size information displayed in the Add/Remove Programs entries differentiates the installations. An installation with default components, that is, Libero SoC, SmartHLS and Megavault takes up larger space (35GB) compared to the standalone installations (Standalone PFSoC MSS Configurator ~0.5GB and Standalone Program & Debug ~2GB). | 2025.1 | 2025.2 | Fixed
The ScintillaTk package for Questasim ME Pro is incorrectly placed in the Libero 2025.1 installation. Workaround: Move the "ScintillaTk" folder up one directory level, from: .\Libero_SoC_2025.1\Libero_SoC\QuestaSim_Pro\win64\Tclxml2.6\ScintillaTk to .\Libero_SoC_2025.1\Libero_SoC\QuestaSim_Pro\win64\ScintillaTk The "ScintillaTk" folder should be located at the same directory level as the "Tclxml2.6" folder within the "win64" directory. | 2025.1 | 2025.2 | Fixed
When running the Libero 2024.2 installer in Windows 10 or 11, you might encounter the following error message: `The JVM used for this installer seems to have been installed in a unsecured location (non-admin user folder). Installer would now exit. Please reach out to your vendor for more details.` Workaround: Perform the following procedure: Uninstall all existing Libero SoC installations. Uninstall all Java Virtual Machine (JVM) installations. Restart the Libero 2024.2 installation process. If the installer fails to launch, create a local user account with full administrative privileges. Use the Shift + Right-click method to run the Libero installer executable as the local PC's Administrator account. | 2024.2 | 2025.1 | Fixed
Customers using a Libero node locked license might encounter the following error message: `Invalid (inconsistent) license key` `The license key and data for the feature do not match.` `This usually happens when a license file has been altered.` `Feature: synplifypro_actel License path: c:\flexlm\license.dat; FlexNet Licensing error:-8,234` Workaround: If you are using free evaluation and Silver license, generate and install a new license from microchipDIRECT If you are using Gold, Platinum, Standalone and Archival licenses, install the updated license available on your microchipDIRECT account. To obtain the latest Libero license, follow these steps: Log in to https://www.microchipdirect.com/ Visit the FPGA Software Products page on microchipDIRECT at https://www.microchipdirect.com/fpga-software-products Click the Download License button to download the updated active Libero Gold, Platinum, Standalone and Archive licenses. If you still encounter the issue, create a tech support case on the Microchip Technical Support Portal at https://microchip.my.site.com/s/. | 2024.1 | 2024.1 | Fixed
The stand-alone Program and Debug Linux installer (v2022.2) does not install FlashPro 6 libusb libraries automatically. Workaround: Execute fp6_env_install located in ./Program_Debug_Tool/bin/ | 2022.2 | 2022.3 | Fixed
The Libero SoC online help reports JavaScript errors when you click microchip.com links. Workaround: The default browser for help files is Internet Explorer. To avoid this issue, copy the desired link and open it in a supported browser, such as Chrome, Firefox, or Edge. | 2022.2 | — | Open
The following link provides information about FlexNet error codes: https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/Common-FlexNet-error-codes.html. | N/A | N/A | N/A
If the installer does not boot in graphical mode, additional X window system libraries might be required. For RHEL/CentOS, the following system package is recommended: `$ sudo yum install -y libXau libX11 libXi libxcb libXext libXtst libXrender` | N/A | N/A | N/A
Many antivirus and Host-based Intrusion Prevention System (HIPS) tools flag executable and prevent them from running. To avoid this problem, modify your security setting by adding exceptions for specific executable. This is configured in the antivirus tool. Contact the tool provider for assistance. Many users run Libero SoC PolarFire successfully with no modification to their antivirus software. Microchip is aware of issues for some antivirus tool settings that occur when using Symantec®, McAfee®, Avira™, Sophos®, and Avast™ tools. The combination of operating system, antivirus tool version, and security settings all contribute to the end result. Depending on the environment, the operation of Libero SoC, ModelSim ME, and/or Synplify Pro ME may or may not be affected. All public releases of Libero software are tested with several antivirus tools before they are released to ensure that they are not infected. In addition, the Microchip software development and testing environment is also protected by antivirus tools and other security measures. | N/A | N/A | N/A

## 14.2 Known Issues and Limitations for Libero SoC v11.x

(Ask a Question)

The following table lists the known issues and limitations associated with Libero SoC v11.x.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
IGLOO2/SmartFusion2 | Prior to Libero SoC v2022.3, the Static Timing Analysis (STA) clock-to-output delay used for SmartFusion2 and IGLOO2 LSRAM RAM1K18 ports configured to use write feed-through mode (WMODE=1) could be optimistic when reading (WEN=0). For more information, refer to the latest IGLOO2 or SmartFusion2 datasheet revision history effective on or after PCN SYST-09ERAC80. The datasheet revision history links to the detailed CN explanation found at: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/can/CN_SF2_IGLOO2_FPGA_LSRAM_Write-Feedthrough_Timing.pdf Workaround: Review the required actions found in the CN explanation found at: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/can/CN_SF2_IGLOO2_FPGA_LSRAM_Write-Feedthrough_Timing.pdf | It affects all v11.x designs targeting the affected devices that use the LSRAM RAM1K18 in write feed-through mode (WMODE=1) | N/A | Fixed in v2022.3 onwards
All A3P*, AGL*, AFS*, A2F* devices | In Libero SoC v11.x tools, the Tcl command for run_tool -name VERIFYTIMING doesn’t support the -script argument for the device families listed. For these devices, the SmartTime Static Timing Analysis (STA) tool is run within the Designer sub-tool, called by Libero SoC. Workaround: For a Libero SoC v11.x design targeting an affected device family, after Place and Route is completed there will be a Designer ADB file located in the <path_to_project_folder>/designer/impl<#>/<root>.adb path. The Tcl script containing commands for reporting timing and SmartTime Tcl commands starting with “st_” can be converted to a Designer script by adding a line to open the ADB using Tcl command: “open_design <path_to_project>/designer/impl<#>/<root>.adb”. Once updated, the Tcl script can be passed directly to the Designer executable using batch mode command (Linux example provided, use designer.exe on Windows): “<path_libero_install>/bin/designer script:report_timing.tcl” | It affects all Libero SoC v11.x designs targeting the listed device families. | N/A | Open
All | Libero does not support monitors with 4K or 8K display resolutions. When using a 4K monitor alongside a 1080p monitor, the display of fonts and dialog boxes in Libero may appear distorted. Workaround: In display setting of the laptop/desktop, make one of the 1080p monitors as your main display. Close the laptop lid which has display resolution higher than 1080p. Disable the laptop display/screen. | 11.0 | N/A | Open
A3P*, AGL*, AFS*, A2F* | The Libero SoC v11.x constraint coverage report for the affected device families reports unconstrained setup and hold checks on pins of hard IP blocks, such as fabric RAM blocks, even though they are statically tied to a constant, such as logic-0. This occurs because the static tie-off is made via an interface buffer that connects the fabric hard-IP block to user logic in the fabric, and the constraint coverage report for the affected device families does not recognize that these pins are statically tied off beyond these interface buffers. Workaround: The user can review all pins listed as unconstrained and manually exclude the pins of hard IP blocks that are statically tied off, such as those tied to GND (logic-0) in the netlist—like unused RAM ADDR and DIN pins—from the list of pins that require additional timing constraints. The Netlist Viewer schematic of the post-layout optimized netlist can be used to confirm whether the pins are statically tied, or the post-layout netlist can be exported and reviewed in a text editor. | It affects all Libero SoC v11.x designs targeting the listed device families. | N/A | Open
All | Users may encounter the following error when setting Synplify/Identify tool profiles in Tool Profiles ->Add Profile dialog box on linux platforms. `Error creating "Internal Error – Unsupported format used in message."` Workaround: These errors can be safely ignored. | 11.10 | N/A | Open
IGLOO, ProASIC3, Fusion, SmartFusion | Synthesis may fail for a design if the clock path contains a BUFD-INV loop, as illustrated below. In these cases, the synthesis tool can become trapped in an infinite loop during the mapping stage, ultimately resulting in synthesis failure for the design. Workaround: None. | 11.9 | 11.10 | Fixed
All | If your RTL includes complex index conversion functions, such as `unsigned()` or `conv_integer()`, the synthesis tool may encounter a crash and display the following error message: `@E:Internal Errorin c_vhdl.exe.` The crash occurs due to a problem with constant optimization. The use of conversion functions, such as `unsigned()` and `conv_integer()`, leads to the addition of buffers that hinders the full evaluation of expressions within the index operation. This issue typically arises in large designs and may not be replicated in unit tests. Workaround: To resolve the issue, modify the RTL by relocating the more complex index computation expression outside of the index expression, as demonstrated below: Original RTL Causing Crash: `in_reg(conv_integer(unsigned(X"F" - count))) <=temp;` Workaround RTL:`process (count, temp)variable intval: integer;beginintval := conv_integer(unsigned(X"F" - count));in_reg(intval) <= temp;end process;` | 11.9 | 11.10 | Fixed
ProASIC3, IGLOO, Fusion, SmartFusion | The timing paths are not calculated between CLKA and DOUTA (or CLKB and DOUTB) when the RAM4K9 fabric RAM blocks are used with both pipelined read mode (PIPEA/PIPEB = ‘1’) and pass-through write mode (WMODEA/WMODEB = ‘1’). This configuration, which requires pipelined read data output while simultaneously enabling pass-through write mode, is not considered standard for RAM. At this time, there are no plans to address or modify this behavior. Workaround: Avoid configuring the RAM block for both both pipelined read mode and pass-through write mode. For example, use pipeline read mode with the write mode where the existing data is held at the output. Alternatively, use non-pipelined read mode with pass-through write mode, if it is more important to the application that the data being written into the write port immediately appear on the read port. | 11.3 | — | Open
IGLOO2, SmartFusion2 | SmartFusion2 (M2S150) and IGLOO2 (M2GL150) designs using clocks routed to the global network through RCLKINT macros may experience a skew-induced timing violation that is not reported during Static Timing Analysis. This issue can occur when multiple Row Global Buffers (RGBs) are cascaded to reach loads spanning a large FPGA fabric area per Customer Notification 19024.2. Workaround: Upgrade to Libero SoC v12.2 or later. For M2S150/M2GL150 designs already in production, contact Microchip Technical Support to obtain the timing analysis script referenced in CN19024.2 | — | — | Open
All | When exporting the BSDL file in Libero 11.10, the file extension is missing. Workaround: Manually enter the file extension .bsd during export. | 11.10 | N/A | Will not fix
All | FlashPro6 programmers are not supported in Libero 11.x releases. If a FlashPro6 device is connected to the host machine and any programming tools are used, the software may become unresponsive. Workaround: Disconnect Flashpro6 and use FlashPro4 or FlashPro5 programmers instead. | 11.0 | N/A | Will not fix
All | When a Libero project is accessed from deeply nested parent directories, it can result in excessively long file paths. This may cause bitstream generation tools to fail with a segmentation fault, as the software assumes a maximum file path length of 256 characters. Workaround: Either copy the project to a location with a shorter directory path, or use a symbolic (soft) link to shorten the path to the Libero project. | 11.10 | N/A | Will not fix
RTG4 | A corner case existed where a CLKINT was instantiated with its input tied to a static '1' and then routed using only a half-chip Global Buffer (GBL or GBR). A user signal routed on the corresponding other half GB might be output from the CLKINT tied to a static '1'. Workaround: In the unlikely event that a CLKINT has been instantiated and tied to a static `1`, either remove such a scenario from the design, or manually instantiate a BUFD buffer with its input tied to `1` and its output connected to the CLKINT. | 11.6 | N/A | Not fixed in v11.x tools. Fixed in v2024.1
RTG4 | Insufficient wait time while exiting programming action runs can cause System Controller to come out of suspend mode in some cases when FlashPro programmer is still connected. Workaround: Disconnect Flashpro programmer and while keeping JTAG TRSTB low, power cycle the board to make sure System Controller remains in suspend mode. | 11.6 | N/A | Not fixed in v11.x tools. Fixed in v2024.1
SmartFusion2, IGLOO2 | If Programming Recovery is enabled in the Configure Programming options tool and is using custom security in Configure Security tool, the DAT bitstream file generated will be incorrect and will not erase the security completely on the device when running ERASE action. | 11.9 | N/A | Not fixed in v11.x tools. Fixed in v2022.3

## 14.3 Known Issues and Limitations for Libero IDE v9.x

(Ask a Question)

The following table lists the known issues and limitations associated with Libero IDE v9.x.

Family | Description | Version Identified | Version Fixed | Status
--- | --- | --- | --- | ---
All | The Inspect Device function in FlashPro fails with the following message: `“Error: Cannot initialize debug engine: Unsupported device family: xxx”` Despite this error, device programming is not affected and continues to function as expected. | Libero IDE v9.2 SP4 | — | Open
All | Libero does not support monitors with 4K or 8K display resolutions. When using a 4K monitor alongside a 1080p monitor, the display of fonts and dialog boxes in Libero may appear distorted. Workaround: In display setting of the laptop/desktop, make one of the 1080p monitors as your main display. Close the laptop lid which has display resolution higher than 1080p. Disable the laptop display/screen | 9.0 | — | Open
Axcelerator (AX),RTAX-S/SL, RTAX-DSP | When using SmartGen DDR core or manually instantiating DDR_REG macro to implement a double-data rate input signal from a top-level I/O input buffer, a specific corner-case usage scenario can result in a stuck-high DDR_REG output to the fabric. In the affected scenario, the DDR_REG falling-edge output pin, QF, is left unconnected and not used by the user design. Instead, only the DDR_REG rising-edge output pin, QR, is used by the user design. Furthermore, in the affected scenario, the I/O PAD selected to input the external signal to the DDR_REG macro is assigned to an N-side I/O pin, such as IOxxNBxFx. Workaround: Make sure to place the DDR input signal on a P-side I/O PAD if the DDR_REG QF pin will be left unconnected in the user logic. Alternatively, use a normal input register (INREG) instead of DDR_REG, by selecting “use register” I/O attribute or specifying the “-register yes” argument to the “set_io” PDC command. | 9.0 | 9.3 | Fixed
RTAX-S/SL, RTAX-DSP, and AX devices | The constraints coverage report will only provide the pin name for the first 100 unconstrained pins per type of timing check, even though the report tabulation might list more than 100 unconstrained pins per timing check. Workaround:The user can add constraints to address the 100 unconstrained pins listed and then re-run the analysis to identify the next 100 pins. Alternatively, the user can run the Back-Annotate step in the Designer tool to obtain the back-annotated netlist and SDF files. These files, along with the design and user SDC timing constraints, can then be imported into standalone Synopsys PrimeTime static timing analysis tools for constraint coverage analysis. | It affects all Libero IDE v9.x versions for the affected devices listed. | — | Open

Rev: 2026.1

The online versions of the documents are provided as a courtesy. Verify all content and data in the device’s PDF documentation found on the device product page.