Manufacturer Part #
FPGA, 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.
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
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.