Known Issues and Limitations

The following table lists known issues and limitations associated with Libero SoC v2021.2.

Table 1. Known Issues and Limitations Associated with Libero SoC v2021.2
Family Description
Libero
All families

HDL_LANGUAGE: GLOBAL_INCLUDE_PATH:

When a module is present in an include file, the file is shown as a linked file inside the project. When 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 displays correctly. If the Global Include path under Project Settings is changed, two links are shown for include file inside the project:
  • One with the new Global Include Path, as shown inside the project.
  • The other is the broken link with the previous Global Include Path.
There are no functionality issues, but an extra broken link appears in the project. Remove this link when the Global Include Path in Project Settings is changed.
All families In SmartDesign, the copy and paste functions for HDL+ core instances within the same or different SmartDesign may not work properly with respect to parameter configuration.

Workaround: Instead of using copy and paste functions for HDL+ core instances, instantiate new instances of HDL+ core in your SmartDesign from the Design Hierarchy directly and configure them as needed.
All families In Libero flow, when multiple identify implementations are created and run initially, the error message only appears in the Synthesis log. It does not propagate to the Libero error log. The error message should appear as follows in the Libero window:
No instrumentation file found for Identify implementation.
Please open SynplifyPro interactively to launch Identify Instrumentor
All families When Identify implementation is created through Libero -> Synthesis -> Configure Options, before running any Synthesis or creating any new implementation, open SynplifyPro interactively, instrument the design, and run Synthesis. Then return to Libero to create any new Synthesis/Identify implementation.
All families In Libero -> Synthesis -> Configure Options -> Active Implementation drop-down list, if any existing Synthesis/Identify implementation is not visible, open SynplifyPro interactively and re-run the intended implementation. Upon re-run, the active implementation will appear in the Libero -> Synthesis -> Configure Options dialog -> Active Implementation drop-down list.
All families If multiple implementations are created in Libero/Synplify flow, each time the active implementation is switched, Synthesis must be rerun for Libero to fetch the intended .vm netlist (for active implementation).
PolarFire

Since the Synplify 2020.09MSP1 release (Libero v20201.1), an enhancement to Synthesis Compiler is related to the initial value support for memory initialization and is not technology specific. Testcases with MiV core fail 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 -> Synthesis -> Configure Option -> Additional Parameters box, add:

set_option -looplimit 4000

OR

Add the following SYNPLIFY_OPTIONS options:

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:}

Set this option and run Synthesis. It should pass.
PolarFire Incorrect PUFT timing is reported when SPI Flash is using as Initialization client.
PolarFire, PolarFire SoC PF_DRI had a PCIe tab indicating that DRI could access PCIe registers. However, DRI is needed to access only the related XCVR lane used with a PCIe controller. The latest version of PF_DRI v1.1.104 does not have the options to enable the PCIe DRI interface. Moreover, the Tcl parameters to enable the same have been removed from the core. Migration succeeds, but the old Tcl scripts must be updated to delete the corresponding Tcl parameters from the core configuration.
RTG4 Libero hangs or crashes on IP component generation for RTG4 FCC with Enhanced PLL calibration for some specific configurations. This issue has been seen since the Libero SoC v12.5 release.
RTG4 This issue affects designs where the Output Re-sync after Lock option is configured to Held Output in Reset (output low) after power-up. Released and resynchronized with the PLL reference clock after the PLL locked. If the CCC_#_GL# in BYPASS MODE is used to source the 50 MHz ECALIB clock, a deadlock occurs and there is no toggling of the output clocks or having the LOCK signal go high. A cyclic dependency is observed between ECALIB and the PLL IPs. The PLL is configured for outputs held in reset after power-up and is not released until the PLL locks, without sending output clock to ECALIB. This results in ECALIB not generating the proper lock enable signal that the PLL requires to generate the output signals.
RTG4 When the Held output in reset (output low) after power-up. Released and resynchronized with the PLL reference clock after the PLL locked option is set, clock appears at the output before the LOCK signal is asserted.

Possible Solution: The synchronizer used for LOCK signal should not use the GLx output clock. A free-running clock can be used (for example, CLK_50MHz). The output of the three-stage synchronizer should be used to drive both the LOCK signal and the GLx_Yx_EN signal.
SmartFusion2

For SmartFusion2 devices, when the firmware is exported from Libero SoC v2021.1, the tool generates a Top_hw_platform.h file. Importing this file into SoftConsole may result in several errors similar to the following:

......
In file included from ../main.c:13:
D:\Del\HW_Platform\Test_Hw\drivers\CoreUARTapb/core_uart_apb.h:175:1: note:
declared here
    175 | UART_init
        | ^~~~~~~~~
make: *** [subdir.mk:20: main.o] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
......

This is a new bug with the exported Top_hw_platform.h file in the current Libero release. Customers must fix this error manually by replacing #define TOP_SB_0/COREUARTAPB_0_0 0x5000_0000U with #define COREUARTAPB_0_0 0x50000000U.
RTG4 I/O Editor display resistor pull for P and N pin when LVDS failsafe (Dynamic ODT) is enabled. For RTG4, the resistor pull information for P and N pin are both shown as pull up or pull down. They should be shown as pull up for one pin and pull down for the other pin.
Synthesis/Simulation
PolarFire CoreQDR_PF: Low data rate 500 Mbps/250 MHz fails in QDR II + Xtreme Device in simulation, but passes on the board.
PolarFire

When automatic compile point is enabled, Synthesis passes successfully, but Place and route errors our pointing 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: Either turn off (uncheck) Automatic Compile Point while running Synthesis through the Libero > Synthesis > Configure Options dialog box. Keep the remaining options and all constraints as they are.

OR

Keep everything the same, but update the line below in the file *derived_constraints.sdc to use get_pins instead of get_nets.

set_false_path -through [ get_pins { AXI4_Interconnect_0/ARESETN* } ]
All families This issue was seen with the SynplifyPro R2021.03M release. On Ubuntu platform, when Synplfiy Pro is invoked, it lists packages and libraries on the terminal. This message can be safely ignored. Similarly, choosing Libero -> Edit Profile -> Synthesis displays a list of packages and libraries on the Ubuntu platform. Click OK and everything will work fine.
Timing/Power
PolarFire The max clock frequency on the regional clocks (RX_CLK_R/TX_CLK_R on the serdes and RX_CLK on lanectrl) in MPF300XT do not match the datasheet.
PolarFire The violation report shows violations (red cross), but the timing report does not (green check). This indicates there is indeed a timing violation and the red cross is correct.
SmartFusion2 On Linux, the timing tool crashes when trying to verify that paths exist between the specified -from and -to when using [ all_registers -clock some_clock ].

Workaround:Use [ get_clocks some_clock ] instead of all_register -clock some_clock.
SmartDebug
PolarFire, PolarFire SoC

When a dual-mode PCIe design is considered in SmartDebug, the following issues are observed in the PCIe debug feature:

  • For dual-PCIe designs with PCI0 and PCIe1 controllers, only PCIe1 appears in the UI. PCIe0 is not shown.
  • When PCIe0 Lane is selected, only the LTSSM state is shown for PCIe1. The LTSSM state for PCIe0 is not shown.
  • Data Rate, Link Width, and other settings are shown only for PCIe1, but not for PCIe0.
Programming
All families When performing any action with FlashPro 6, the following error might occur:

Error: Linux FP6 programmer - cyusb_bulk_transfer error.

This error could be caused by the programmer being out of sync with the software application.

Workaround: Unplug the USB cable from either the programmer or the host PC, and then reconnect it to reset the programmer.
All families When performing any action with the iCicle kit, the following error might occur:

Error: Failed to open eFP6 HID handle.

This error could be caused by the programmer being out of sync with the software application.

Workaround: Unplug the USB cable from either the programmer or the host PC, and then reconnect it to reset the programmer.
PolarFire SoC eFP6: Some testcases 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.
PolarFire SoC

For PolarFire SoC Libero designs that contain eNVM, running VERIFY_DIGEST, the device will fail after programming with the error message eNVM digest verification: FAIL.

Workaround: Deselect the procedure DO_ENABLE_ENVM in the VERIFY_DIGEST action.
PolarFire SoC For PolarFire SoC Libero designs that generate or export eNVM-only bitstreams, the generated bitstream file/job will include an ERASE action that is not applicable and does nothing. Affected releases are Libero v12.4 and later. For Libero v12.6, this issue applies for eNVM only cases with no eNVM sanitization option configured.
PolarFire SoC For Libero designs with sNVM clients configured with no custom user security options selected and program this design on device, modifying an sNVM client content and sNVM client Fabric/MSS read/write permissions and running VERIFY action fails with the error message Failed to verify Security instead of Failed to verify SNVM. Affected releases are Libero v12.4 and later.
SmartFusion2, IGLOO2, RTG4, PolarFire, PolarFire SoC

Some users 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. If for some reason the connection is interrupted, this error occurs.

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 is “General device IO error.”
SmartFusion2, IGLOO2 Export Bitstream with SVF checked may fail in the Libero v2021.2 release. The actions do_read_prog_info() and dump_programming_interface() are not defined for SVF in the programming algorithm, but are always referenced in the PROGRAM action. Do not reference either function in the PROGRAM action when the file exported is SVF.
Installation and System Limitations
All families

The following link provides information about FlexNet error codes:

https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/Common-FlexNet-error-codes.html
Linux Package Required 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
All families

Many antivirus and Host-based Intrusion Prevention System (HIPS) tools flag executables and prevent them from running. To avoid this block, modify your security setting by adding exceptions for specific executables in the antivirus tool. For assistance, contact the tool provider.

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, Libero SoC, ModelSim ME, and/or Synplify Pro ME operation may or may not be affected.

To ensure that all public releases of Libero software are not infected, each software package is tested with several antivirus applications before being released. To ensure further security, the Microchip software development and testing environment is protected by antivirus tools and other security measures.