Manufacturer Part #
FPGA - Field Programmable Gate Array IGLOO 2
Description of Change:Implement Microchip Part Aging Policy, Recertification and Combination rules, Labels and Packing Changes for selected Microsemi Field Programmable Gate Array (FPGA) and Mixed Signal and ASIC(MSA) products.Pre Change: Using Microsemi’s packing processPost Change:Using Microchip’s packing processPre and Post Change Summary:NOTE: See attached Packing Pre and Post Changes for the changes Impacts to Data Sheet:NoneChange Impact:NoneReason for Change:To improve productivity by standardizing the packing method as part of the integration of Microsemi and Microchip.Change Implementation Status:In ProgressEstimated Implementation Date: February 15, 2021 (date code: 2108)Note: The earliest implementation date is the earliest date that we may implement any combination of the changes listed in this PCN as we will not implement any of the proposed changes prior to this date. After the earliest implementation date these changes may occur to any product over the course of many months depending on inventory levels and business conditions.Time Table Summary: see attachedRevision History:January 18, 2021: Issued final notification. Provided estimated first ship date to be on February 15, 2021.The change described in this PCN does not alter Microchip’s current regulatory compliance regarding the material content of the applicable products.
Description of Change: Implement Microchip Top marking changes for selected Microsemi Field-Programmable Gate Arrays (FPGAs) products available in various packages.Pre Change: Microsemi top marking format and traceability codePost Change: Microchip top marking format and traceability codePre and Post Change Summary: see attachedImpacts to Data Sheet: Where applicableChange Impact: NoneReason for Change:To improve manufacturability and traceability by standardizing marking format for selected Microsemi products as part of the integration of Microchip and Microsemi.Change Implementation Status: In ProgressEarliest Implementation Date: March 1, 2021 (Date code: 2110)Note: The earliest implementation date is the earliest date that we may implement any combination of the changes listed in this PCN as we will not implement any of the proposed changes prior to this date. After the earliest implementation date these changes may occur to any product over the course of many months depending on inventory levels and businessconditions.Time Table Summary:
Ongoing Software Quality Testing on Libero SoC Has Found a Static Timing Analysis (STA) Coverage Issue for Specific Scenarios for SmartFusion2, IGLOO2, RTG4, and PolarFire Product Families.Description:With Libero SoC v12.5, Libero SoC v12.5 SP1, and Libero SoC v11.9 SP6, netlist tie-off information is now correctly being passed to SmartTime for a complete static timing analysis.Reason for Change:Post-Layout timing database information for combinational cells inputs with constant tie-offs ("1" or "0") was incorrectly passed to SmartTime, preventing complete analysis of the path through the combinational cell.
Customer Notification CN20003 PolarFire, SmartFusion2, & IGLOO2 Customer Notifications for Libero SoC v12.4 The document describes various changes to Libero SoC 12.4 Summarized here: · PolarFire FPGA System Controller Suspend Mode · Net list generated for W32xR2 and W32xR1 LSRAM asymmetric Two-port RAMs · "Configure I/O states during JTAG programming" tool · PolarFire FPGA PCIE Register Update Notification · Certain unused IOs were not tristated when programmed · Minor Update to PolarFire LSRAM CLK-to-OUT delays
Libero 12.2 Timing and P&R ChangesDescription of Change:Minor changes have been made to the timing parameters of sequential elements and select routing resources, including a tightening of the clock skew.These changes result in a minor impact on timing margins of existing designs.Reason for ChangeOur ongoing QA process highlighted the need to reclaim built-in timing margins to bring the timing model to the required quality levels.
Addendum to PCN1309 and PCN1309A - Synopsys Synplify Pro Software Bug Regarding Safe State Machine RecoveryDescriptionMicrosemi and Synopsys have recently become aware of a scenario that can result in a state machine design not being implemented with logic circuits which force the state machine into a reset state if an illegal state is detected.Description of the ProblemWhen a design is synthesized with the one-hot state machine encoding style and includes state machines with only two states, Synplify Pro may not recognize them as state machines. If the state machine is marked for "safe" implementation, and this bug affects the design, then the inferred extra logic that forces a reset during an illegal state condition will not be added. This problem can occur only when all of the following conditions are true.The design is synthesized with the "safe" encoding style for the state machine (the user has specified syn_encoding=�safe�).The state machine is instructed to use "onehot" encoding through the Implementation Options > VHDL setting.The state machine has only two states.The state machine does not have a syn_state_machine="true" attribute.