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.
Conversion to Cu Wire for SmartFusion, IGLOO2, and SmartFusion2DescriptionMicrosemi SoC group is currently performing qualification runs to convert SmartFusion in FG/FGG256 and IGLOO2/SmartFusion2 devices in TQ/TQG144 from Au wire to Gold Coated Palladium Copper wire (AuPdCu, also known as AuPCC). Qualification run is in-process. Expected completion is on or before June 15, 2020.There is no change in assembly site location. SmartFusion devices in FG/FGG256 will remain at UTAC in Dongguan China. IGLOO2/SmartFusion2 devices in TQ/TQG144 assembly support will remain at Amkor Philippines.Reason for ChangeConversion to AuPdCu (AuPCC) wire is aligned with the current industry trend. Our assembly vendors have extensive experience in copper bond wire assembly. There is no expected impact in product moisture sensitivity level (MSL), product functionality, performance, quality, or reliability. Products assembled with copper wire only use halogen-free materials.Production Shipment ScheduleMicrosemi may begin shipping parts by June 30, 2020.Microsemi reserves the right to continue the shipment of devices with Au wire following the change of implementation date.Customers may receive a mix of pre-conversion products with Au wire and products with AuPdCu (AuPCC) wire interchangeably, following the change of implementation date. Customers may receive a mix of pre-conversion products with Au wire and products with AuPdCu (AuPCC) wire interchangeably, following the change of implementation date.Application ImpactThere is no change in form, fit, function, quality, or reliability of the devices.
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
Subject: Libero SoC Timing Change and IO Glitch NotificationCAN 19010.1 Clock Source Latency CalculationDescription of the IssueDue to an error introduced in Libero SoC v11.7-SP1, when a clock source latency constraint is applied to a generated clock, an additional delay (= late � early) is incorrectly added to the net driven by the clock source and impacting the required time calculation. As a result, the clock source latency constraint is ignored on the generated clock. Up until Libero SoC v12.0, this constraint has been recommended as a way to capture clock jitter information and pass it on to be used by the static timing analysis tool, SmartTime, during its Max Delay Analysis.Reason for NotificationLibero SoC v11.9 SP2 and beyond restores the correct value for the data required time calculation. This correction is alsoaddressed in Libero SoC v12.0. The respective software release notes include a reference to this change. In addition, startingwith Libero SoC v12.0, jitter can also be modeled using simple clock uncertainty constraints.Action RequiredRe-run static timing analysis with SmartTime using Libero SoC v11.9 SP2 or later, if you are setting a clock source latencyconstraint on a generated clock and the margin you have is less than the constraint window (for example, jitter window).CAN 19010.2 IO Glitches During Auto-UpdateDescription of ChangeAuto-update is a method to automatically update the FPGA image on a power-up. If enabled, the system controller will check the design version of a bitstream in an external SPI flash and compare it to the programmed version. If the external bitstream is newer than the programed bitstream, then the system controller will use the new bitstream to program the device.If autoupdate is enabled, an auto-update action will occur. Under these conditions during device power-up or the de-assertion ofDEVRST_N, an IO glitch will occur on banks 0, 1, and 2 of the the M2S005/010/025 or M2GL005/010/025 devices. If autoupdate is not enabled, the glitch does not occur. The amplitude of the glitch correlates to the VDDI bank voltage level. Reason for NotificationIO glitches on banks 0, 1, and 2 of the the M2S005/010/025 or M2GL005/010/025 devices during auto-update programming mode.WorkaroundUtilize In-Application Programming (IAP) in place of auto-update.Move sensitive outputs to a non-glitch bank.
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.