Scott Rubelscottrubel0, PhD, ingénieur principal principal, NXP Semiconductors
Todd Jacobs , PhD, ingénieur principal, NXP Semiconductors
James Nelson txnelson , ingénieur logiciel et ceinture noire Six Sigma, entrepreneur indépendant
Introduction
Les conceptions de puces modernes comportent de multiples composants IP présentant des sensibilités différentes aux processus, à la tension et à la température. Ces composants doivent tous fonctionner dans des conditions de fonctionnement très variées, mais certains composants seront plus sollicités à différents niveaux du processus : certains à haute température, d'autres à basse tension, etc. Leurs performances peuvent être prédites avant la fabrication, puis caractérisées lorsque le silicium réel est disponible pour les tests. Plus le nombre de composants IP est élevé, plus le travail de modélisation et de caractérisation est important.
À cela s'ajoutent les exigences de performance propres aux clients : certains peuvent exiger une vitesse de fonctionnement très élevée sans se soucier de la consommation d'énergie, tandis que d'autres peuvent avoir des exigences énergétiques extrêmement strictes, pouvant aller jusqu'à la désactivation complète de certains composants de la puce. Ces exigences ne sont pas satisfaites par des processus ou des versions de produits distincts ; chaque lot de production est un mélange de niveaux de performance différents.Optimiser ce mix pour répondre aux différentes exigences des clients (poubelles) sur l'ensemble du processus de fabrication a un impact énorme sur la marge brute : une quantité trop importante ou trop faible d'un bac donné entraîne un produit invendable, ce qui constitue essentiellement une perte de rendement.
Les simulations de Monte Carlo sont optimales pour simuler ces distributions vitesse-puissance et ces mélanges de bacs dans différentes conditions : elles peuvent gérer les lun grand nombre de paramètres statistiques (généralement 40 à 60, plus une matrice de covariance) et de limites de compartiments (~ 20 à 100) impliqués.L'extraction et la documentation cohérentes des paramètres sont essentielles à leur gestion, c'est là qu'intervient le script JMP : ilfournit les outils statistiques et la capacité de journalisation nécessaires pour garantir des simulations réussies du premier coup. De plus, sonUn temps d'exécution rapide (1 à 5 minutes/exécution) et une documentation cohérente permettent de comparer plusieurs cas commerciaux en temps réel.
Flux de simulation
Le diagramme ci-dessous illustre le déroulement d'une série typique de simulations. Nous partons des caractéristiques de performance prévues ou réelles, puis nous en extrayons les paramètres statistiques sous-jacents décrivant le produit. Nous pouvons ensuite adapter ces paramètres (notamment la variance) pour évaluer différents scénarios. À ce stade, le moteur de Monte-Carlo génère un « nuage » simulé de distributions vitesse-puissance. Les limites des cases (exigences client) y sont superposées. L'intégration numérique du volume du nuage dans les limites détermine la distribution statistique des cases pour ce nuage particulier. Le script répète automatiquement cette opération dans différentes conditions de fabrication afin de déterminer la fenêtre de processus sur laquelle le mélange de cases est acceptable (absence de matrice non commercialisable). À ce stade, nous pouvons envisager différents scénarios, auquel cas nous pouvons réexécuter la simulation avec une échelle et/ou des limites différentes, jusqu'à obtenir la combinaison optimale de processus et de limites pour une demande donnée.
Distributions de vitesse et de puissance et binning
Le graphique ci-dessous présente un graphique vitesse/puissance typique (simulé) pour un domaine IP unique. La fréquence est presque toujours une fonction linéaire de log(courant de fuite statique = SIdd), elle est donc décrite par une pente, une interception et une RMSE (bruit). log(SIdd) lui-même est décrit par une moyenne et un écart type. Comme nous évaluons généralement les variations d'écart type, nous incluons un paramètre d'échelle comme entrée, ce qui signifie que le nuage comporte trois paramètres pour la puissance, plus trois pour chaque test de fréquence à chaque tension et température. Le graphique ci-dessous présente un exemple de limite de compartiment : les puces dont la puissance statique est inférieure à 0,32 logA et dont la fréquence est supérieure à 1 040 MHz (dans le cadre vert) satisfont aux exigences de ce compartiment.
Nous pouvons augmenter le nombre de puces passantes en ajustant la tension d'essai nominale (dans la plage des spécifications client). À des tensions plus élevées, les pièces fonctionnent plus vite, ce qui permet aux puces plus lentes de satisfaire aux exigences de fréquence. Cependant, la pièce consomme également plus d'énergie statique et dynamique, et un budget est prévu pour cela. Pour respecter ce budget, la composante statique autorisée à une tension de référence fixe doit être inférieure. L'encadré vert clair de l'image ci-dessous indique la puce supplémentaire qui satisfait aux exigences de la gamme à haute tension. L'inverse est vrai pour les tensions plus faibles ; l'encadré vert foncé indique la puce supplémentaire capturée dans ce scénario.
Les puces qui ne passent pas un bac, même avec des tensions différentes, peuvent néanmoins passer un autre. Le graphique ci-dessous montre deux bacs supplémentaires qui capturent ces puces aberrantes : un bac basse vitesse et basse consommation (bleu) et un bac haute vitesse et haute consommation (rouge).
Bien sûr, de nombreuses puces peuvent accepter plusieurs spécifications ; le graphique suivant illustre ces zones de chevauchement, la puce située dans le quadrant vert le plus foncé acceptant toutes les tensions pour les limites de spécification verte, ainsi que pour les limites de spécification rouge et bleue. Les zones de binning sont décrites par une combinaison de OU logiques sur la tension, et de ET logiques sur les domaines de température et d'IP. Ces puces permettent de moduler l'alimentation d'un bin à l'autre selon les besoins..
Il existe deux façons de compter les dés pour chaque bac. La première est la distribution maximale , qui compte tous les dés pouvant satisfaire aux exigences de vitesse et de puissance du bac. Il s'agit d'une contrainte d'approvisionnement importante : si la demande dépasse la distribution maximale, l'offre sera toujours insuffisante, ce qui entraînera une perte de rendement (matériau non commercialisable). Pour cette mesure, les dés des régions qui se chevauchent sont comptés pour chaque bac traversé, de sorte que la somme de la distribution entre les bacs peut dépasser 100 %.
La deuxième méthode de comptage des matrices est la répartition des matrices par casier. Avec cette méthodologie, l'utilisateur spécifie l' ordre de tri des matrices pour chaque casier ; une fois qu'une matrice passe par un casier, elle est retirée de la liste des matrices. La somme des répartitions des matrices par casier est donc toujours égale à 100 %, car aucun double comptage n'a lieu. Il s'agit de la deuxième contrainte d'approvisionnement majeure que nous prenons en compte : elle détermine si nous aurons suffisamment de matrices pour répondre à la demande en production réelle. Contrairement à la répartition maximale, la répartition des matrices par casier peut être modifiée en utilisant un ordre de tri différent, et nous évaluons généralement ces options tout au long de la durée de vie d'un produit.
Le tableau ci-dessous montre comment les distributions maximales et de mélange de bacs diffèrent pour un ensemble de cinq matrices :
Si les principes d'affectation et de comptage des cases sont simples, leur mise en œuvre peut s'avérer très complexe. C'est là que les scripts sont d'une aide précieuse : ils garantissent une exécution correcte de la logique pour chaque dé, éliminant ainsi une source potentielle d'erreur majeure pour l'utilisateur.
Le fichier de configuration d'entrée
Nous souhaitons regrouper les multiples entrées d'une simulation dans un seul fichier pour une documentation simple et cohérente. De plus, nous souhaitons une interface de script pour gérer les extractions statistiques et les simulations réelles. Heureusement, JMP prend en charge tout cela dans un seul objet de données, que nous utilisons pour toutes nos entrées. Voici un exemple :
La partie supérieure est utilisée pour diverses routines de script. Les noms de paramètres étant souvent longs et complexes, nous proposons une option permettant de les renommer plus facilement grâce aux commandes d'analyse de texte de JMP. Lors de l'exécution initiale basée sur un fichier de données, le script extrait et stocke tous les paramètres statistiques nécessaires dans le fichier de configuration ; les exécutions ultérieures peuvent simplement utiliser ces paramètres stockés. Les utilisateurs n'ont pas besoin de stocker le fichier de données séparément, ce qui permet à chacun d'exécuter une simulation identique avec le fichier de configuration du produit. Cela évite les incohérences lorsque les utilisateurs basent leurs analyses sur des jeux de données d'entrée différents.
Le script inclut également une option de validation de la table de configuration. Cet outil est essentiel pour des simulations réussies du premier coup, car il détecte une multitude d'erreurs potentielles susceptibles de produire des résultats erronés. Plutôt que de s'appuyer systématiquement sur l'avis d'un utilisateur expert, le script s'assure qu'aucune entrée clé n'est manquante (limites, tests, paramètres de regroupement de température ou de tension, etc.) et détecte également des erreurs plus subtiles susceptibles de produire des simulations erronées (mais réalistes) : paramètres parfaitement corrélés, corrélations non physiques ou combinaisons casiers/motif/regroupement garantissant des distributions nulles ou à 100 % à tout moment.
Sortie du journal
Nous utilisons la fonctionnalité de fichier journal de JMP pour agréger et standardiser nos résultats, garantissant ainsi les meilleures pratiques de documentation. Les principales caractéristiques de la plupart des analyses sont la distribution vitesse-puissance simulée (plusieurs paires de paramètres peuvent être tracées si nécessaire) et les tracés des distributions de capacité maximale et de mixage de compartiments sur l'ensemble du processus de fabrication. Outre les graphiques, le fichier inclut également les paramètres statistiques et toutes les autres entrées du fichier de configuration, ce qui garantit une traçabilité complète de tous les détails de la simulation sous-jacente. Ceci est essentiel lorsque nous sommes au début du cycle de vie d'un produit et que nous envisageons plusieurs scénarios : l'absence de documentation des entrées sous-jacentes peut entraîner une grande confusion, mais en scénarisant les résultats, nous évitons que cela ne se produise.
Modélisation de scénarios
Grâce à l'automatisation de la documentation, nous pouvons nous concentrer sur l'évaluation rapide de différents scénarios. Grâce à la rapidité de la simulation (1 à 5 minutes), les scénarios les plus courants peuvent être évalués en temps réel lors de réunions, ce qui facilite grandement les échanges avec les équipes marketing et design. Voici quelques exemples, en commençant par le plus simple : la mise à l'échelle de la variance du processus. Le premier graphique illustre l'impact sur la distribution maximale d'un seul bac lorsque le contrôle du processus de l'usine s'améliore : la distribution diminue dans certaines régions, mais à la cible optimale, elle est nettement meilleure. Cette situation est si courante que la mise à l'échelle de la variance est un paramètre réglable dans le fichier de configuration.
La deuxième variante, extrêmement courante, consiste à modifier l'ordre de tri des bacs ; cela peut se produire tout au long du cycle de vie d'un produit. Les graphiques ci-dessous illustrent la répartition des bacs tout au long du processus de fabrication lorsque l'ordre de tri est : orange, rouge, vert clair, vert foncé, bleu. (Le graphique de répartition maximale n'est pas représenté ici, car il n'est pas affecté par l'ordre de tri.) Au niveau de la cible du processus (ligne noire verticale), le bac orange domine, avec de faibles quantités de matrices vert clair et rouge, et pratiquement aucune répartition bleue ou vert foncé.
Nous souhaitons maintenant évaluer l'effet de l'inversion de l'ordre de tri des bacs rouge et vert foncé : quelle quantité de moins du premier et de plus du second pourrons-nous désormais expédier ? L'ordre de tri est un paramètre facilement modifiable dans le fichier de configuration ; cette comparaison ne prend donc que quelques minutes ; le graphique ci-dessous illustre le résultat (notez que le bac vert clair est entièrement recouvert par le bac vert foncé, qui est testé en premier dans le nouvel ordre).
Bien que la répartition des bacs orange reste inchangée, une part importante des puces (environ 30 %) se retrouvera désormais dans le bac vert foncé, au lieu du rouge ou du vert clair comme auparavant. Ce résultat peut être comparé à la demande des clients afin de déterminer si le programme de test doit être modifié.
Un autre scénario courant nécessitant une simulation est le tri des puces avant assemblage. Dans ce cas, les produits peuvent être intégrés dans différents boîtiers en fonction de leurs performances. Outre la compréhension du mix global des bacs, nous souhaitons maintenant comprendre le mix pour chaque type de boîtier, ce qui ajoute une complexité supplémentaire. Nous souhaitons également comprendre dans quelle mesure nos tests de préassemblage orientent les puces vers le bon boîtier. C'est facile à réaliser avec le script JMP, car les données de réussite/échec pour chaque test et chaque bac sont incluses pour chaque puce. Le graphique ci-dessous montre que les puces qui échouent au test de vitesse de préassemblage des plaquettes (turquoise) sont effectivement parmi les plus lentes lorsqu'elles sont testées après assemblage à ACSCAN_PLAT_MIN_FMAX, mais la corrélation n'est pas parfaite : la puce turquoise chevauche assez largement les limites des autres bacs (notez que cette simulation utilise des tests et des bacs différents de l'exemple précédent).
La pertinence de cette corrélation pour une utilisation en production dépend de l'acceptabilité des distributions de bacs par package obtenues. Les graphiques ci-dessous illustrent la différence entre la construction de toutes les matrices (à gauche) et de toutes les matrices sauf la matrice turquoise (à droite). Par souci de clarté, les graphiques correspondants pour les distributions de mélange de bacs ne sont pas présentés, mais seront pris en compte dans l'évaluation.
Modélisation de scénarios : limites variables
Une situation courante, mais plus complexe, est celle où nous souhaitons envisager différentes limites de compartiment ; cela se produit le plus souvent lors de la phase de définition du produit. Il peut y avoir une certaine incertitude quant à la puissance à offrir au client, ou l'équipe de conception peut vouloir comprendre les implications d'un fonctionnement plus lent que souhaité d'un élément de propriété intellectuelle. Notre script de simulation offre la flexibilité de faire varier les limites de compartiment par étapes discrètes ; nous pouvons ensuite étudier l'impact sur la distribution. Comme ces analyses peuvent être très différentes, nous ne générons pas de sorties graphiques spécifiques, mais les données de distribution sont facilement enregistrées dans des tables de données distinctes que nous pouvons étudier comme bon nous semble. L'exemple ci-dessous montre la sortie standard pour la distribution maximale « Combo 1 » lorsque la limite de puissance varie en 11 étapes : le pic devient plus bas et se décale vers la droite pour des limites de puissance plus strictes. (Les bacs 2 à 5 n'ont que des courbes simples car leurs limites ne changent pas. À droite, nous montrons un graphique personnalisé qui trace la distribution du bac 1 au niveau du processus cible (ligne noire verticale), en fonction de la limite du bac (étiquetée par le numéro d'étape ; nous pouvons convertir cela en valeurs de puissance réelles si nécessaire). Comme d'habitude, nous pouvons également effectuer cette analyse sur la distribution du mélange de bacs, si vous le souhaitez.
Le graphique de droite montre que nous pouvons resserrer la limite de puissance de 3 à 4 niveaux avant que les distributions du lot 1 ne commencent à chuter brutalement ; à ce stade, l'offre devient très sensible aux variations mineures. Nous transmettrons ces informations à l'équipe marketing afin qu'elle réfléchisse aux spécifications de puissance à proposer au client.
Nous pouvons également évaluer la sensibilité à la vitesse d'un élément IP particulier. Nous déterminons à nouveau les limites des bacs et prenons en compte trois indicateurs. Le premier est la cible optimale du processus (emplacement de la distribution maximale sur l'axe des X) : elle n'est ni réglable à l'infini ni trivialement réalisable, nous ne voulons donc pas que la cible du processus soit sensible à la perte de vitesse. Nous avons également besoin d'une fenêtre de processus raisonnable (la plage sur laquelle l'offre correspond à la demande), et bien sûr, nous devons disposer d'un nombre suffisant de puces traversant ce bac pour répondre aux commandes des clients. Les trois graphiques ci-dessous présentent un tableau similaire : nous pouvons tolérer une perte de vitesse jusqu'à environ 40 MHz, mais au-delà, la cible optimale du processus est très sensible à toute variation de vitesse, la fenêtre de processus se rétrécit rapidement et l'offre du bac commence à s'effondrer. Ces informations fournissent à l'équipe de conception un critère de réussite clair et une idée précise de la marge à inclure dans ses simulations.
Dans des situations particulièrement complexes, les variations de vitesse et de puissance peuvent être prises en compte simultanément ; par exemple, si l'amélioration de la marge de vitesse entraîne un coût énergétique. La journalisation intégrée de l'outil de script est particulièrement importante ici, car elle documente automatiquement toutes les modifications d'entrée.
Résumé
L'utilisation d'un script JMP a considérablement amélioré nos capacités de modélisation des performances de nos produits. Nous pouvons gérer des entrées complexes grâce à une validation intégrée afin d'éviter les erreurs courantes des utilisateurs. Le script gère les calculs mathématiques sous-jacents à la simulation Monte Carlo, permettant aux utilisateurs de se concentrer sur les résultats à valeur ajoutée plutôt que sur les détails statistiques. Il garantit également des résultats cohérents intégrant nos meilleures pratiques, de sorte que chaque analyse est soigneusement documentée, sans nécessiter de révision par un expert ni de documentation détaillée.
L'outil peut être utilisé avec des données silicium ou enrichi d'estimations de performances avant même la mise en production des produits. C'est là que réside sa plus grande valeur : nous pouvons influencer les produits très tôt dans leur cycle de vie et fournir un retour pertinent aux équipes Design et Marketing avant la finalisation des spécifications. Cela permet un meilleur engagement client et garantit que, dès le lancement de nos produits, toutes les puces fonctionnelles sont commercialisables. Enfin, nous pouvons réaliser rapidement des analyses de sensibilité qui garantissent une fenêtre de processus robuste. Les produits qui répondent à ces critères dès leur lancement sont plus rentables, garantissent une fabrication fluide et répondent mieux aux besoins des clients tout au long de leur cycle de vie.
