La libération des FPGA s’accélère à grands pas, il devient presque difficile de suivre toutes les nouvelles sur le sujet. Mais les FPGA ne doivent pas nous faire oublier leurs grands frères que sont les ASIC.
Un FPGA est un composant ayant un silicium déjà « gravé » mais où il est possible de reconfigurer les connexions entre les éléments logiques à volonté. Dans le cas d’un ASIC, on va cette fois graver directement les transistors sur un silicium vierge et les relier via des couches métaliques une fois pour toutes. Il ne faut surtout pas se planter à l’étape de conception car on ne pourra pas modifier les interconnexions une fois la production lancée.
Pour réaliser un ASIC, il faut fournir un plan des masques de chaque couche de dopage du silicium ainsi que des couches métaliques. Voici par exemple la représentation d’une bascule D :
Pour ce faire, on va partir d’une description RTL (Register Transfert Level) du composant, similaire aux descriptions utilisées pour les FPGA – la plupart du temps du Verilog ou du VHDL — que nous allons « synthétiser » en une Netlist. La suite va ressembler (de loin) à du placement‐routage et de la simulation analogique‐numérique, comme on peut le voir avec la conception de carte électronique.
Le flot de conception typique du monde du matériel est donné dans une des diapositives de la présentation de Tim Ansell ci‑dessous :
La partie langage de description du matériel et simulation est déjà largement libérée. Il existe des tas de composants open source décrits en VHDL et/ou en Verilog à présent. Les outils de synthèse libres arrivent aujourd’hui à maturité avec Yosys, bien sûr, pour le Verilog (et bientôt mature pour le VHDL grâce au greffon GHDL-yosys), mais aussi Alliance pour le VHDL.
Les trois piliers logiciels (EDA pour les outils, PDK les données et RTL le design) permettant de réaliser un ASIC sont donnés dans une autre diapo de Tim ci‑dessous :
Une fois la description « RTL » du composant synthétisée, il nous reste beaucoup d’étapes à franchir avant d’obtenir une description des masques de gravure permettant la fabrication proprement dite. Toutes ces étapes nécessitent l’utilisation de logiciels spécifiques pour réaliser les masques, construire l’arbre d’horloge, simuler en analogique certaines parties, concevoir les alimentations… Beaucoup de logiciels libres existent pour cela, tous ne sont pas matures ou restent très universitaire dans leur version open source. Mais il est possible de les utiliser tout de même pour réaliser un composant, comme l’a démontré Tim Edwards avec le Raven (un microcontrôleur RISC‑V à base de PicoRV32).
Cependant, même s’il n’a utilisé que des logiciels libres pour réaliser le Raven, Tim n’a pas pu accéder à la description physique des composants numériques qu’il utilisait. Il a dû se contenter de « boîtes noires » représentant chaque fonction logique à assembler pour réaliser le microcontrôleur. En effet, tous ces logiciels libres demeurent quasiment inutiles si l’on n’a pas accès à la description physique de la technologie cible utilisée. Les fondeurs de silicium fournissent un PDK (process design kit) contenant des bibliothèques de composants avec la description physique de leurs technologies, ainsi que la géométrie de chaque transistor et les modèles de simulations spice permettant de valider le comportement analogique. Et pour avoir accès à ces PDK, la vente de vos deux reins ne suffira pas, même si vous signez les triples NDA (accord de non‑divulgation) avec votre sang. Ce PDK reste le gros frein à la libération du matériel, un caillou dans la chaussure du matériel libre. C’est ce que Google a bien compris en finançant le développement d’un PDK libre via la société SkyWater : le SKY130.
La publication du SKY130 vient d’être annoncée cette semaine par Tim Ansell lors d’un « dial‑up » de la FOSSi Foundation. Comme son nom l’indique, ce PDK cible la technologie 130 nm. Cette taille de gravure peut sembler obsolète quand on sait qu’AMD fabrique de plus en plus en 7 nm, et commence même à tester le 4 nm. Mais les chaînes de fabrication de silicium avec cette finesse de gravure permettent un coût de production très raisonnable pour des performances qui ne sont pas non plus ridicules. SiFive, par exemple, a sorti un microcontrôleur 32 bits RISC‑V (E310) gravé en 180 nm et tout de même cadencé à 320 MHz. Il est donc possible de réaliser beaucoup de chose avec du 130 nm.
Et pour promouvoir son PDK et fédérer une communauté de passionnés, hobbyistes, universitaires, « startupeuses », etc., Google a décidé de produire quarante projets à base de ce PDK tous les six mois et gratuitement. Le premier « shuttle » est prévu pour novembre. Pour être dans le wagon, il faut que son projet soit open source et le soumettre au site en ligne efabless.com. Visiblement, la méthode de choix des projets retenus n’est pas encore bien définie ; mais si vous êtes retenu, vous aurez une réponse par courriel.
Il est temps pour LinuxFr.org de faire passer TapTempo dans une autre sphère que le simple programme en Brainfuck et de proposer un composant électronique TapTempoASIC !
Et pourquoi ne pas proposer un FPGA en 130 nm ? Même si aujourd’hui les FPGA sont plus proches du 40 nm, un FPGA open source comme le kFPGA de killruana, ça aurait la classe.
Aller plus loin
- Le dépôt GitHub du PDK (178 clics)
- La vidéo de Tim Ansell présentant le projet (112 clics)
- Les diapositives de la présentation de Tim Ansell (50 clics)
# La taille ça compte (ou pas)
Posté par dj_ (site web personnel) . Évalué à 6.
Bon article, juste une petite remarque
Les Comet Lake-S annoncé le mois dernier sont en 14 nm.
Le 7 nm est annoncé pour 2021 (normalement)
C'est AMD qui produit en 7 nm
[^] # Re: La taille ça compte (ou pas)
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Mais si j'ai bien compris (en fait j'ai rien compris), les nm d'Intel et le nm d'AMD ne seraient pas comparable et en gros, les deux graveraient à la même échelle…
[^] # Re: La taille ça compte (ou pas)
Posté par Anonyme . Évalué à 9. Dernière modification le 05 juillet 2020 à 20:46.
AMD ne grave rien. AMD est un fabless : une boite qui conçoit mais ne fabrique pas. C'est devenu la norme au fur et à mesure que la gravure s'est miniaturisée (machines plus complexes donc plus chères et plus difficiles à rentabiliser).
AMD a longtemps fait appel à GloFo (Global Foundry, anciennement la fabrique d'IBM située en Allemagne), maintenant elle fait aussi appel à TSMC (Taiwan Semiconductor Machin Chose) et c'est l'un des processus de gravure 7nm de TSMC auquel on fait implicitement référence quand on dit que AMD est passé au 7nm.
Ensuite, les "fondeurs" n'ont pas la même appréciation de ce qu'il considère comme une finesse de gravure, c'est en fait assez marketing parce que ça n'indique pas grand chose (un processeur basse consommation ne sera pas gravé avec le même processus qu'un processeur orienté haute performance et l'architecture interne joue aussi dans les comparaisons entre puces). Dans les faits, les processus 10nm d'Intel (utilisés sur CannonLake et IceLake) correspondent grosso modo à la finesse des 7nm de TSMC.
Martoni a bluffé en faisant une conversion.
[^] # Re: La taille ça compte (ou pas)
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Je n'avais plus qu'une balle ;)
Merci pour toutes ces précisions. Après si AMD fait appel à TSMC en 7nm, dire qu'AMD «grave en 7nm» n'est pas non plus totalement du bluff (pour intel j'ai fait un raccourci un peu rapide). Sachant que si l'on réuni TSMC et GlobalFoundry on obtient à peu près la totalité de la production de semiconducteurs mondiale.
Si j'ai bien tout suivi d'ailleurs, efabless fait fabriquer chez GlobalFoundry.
J'ai plus qu'une balle
[^] # Re: La taille ça compte (ou pas)
Posté par Anonyme . Évalué à 4.
En fait on devrait dire qu'AMD «fait graver» en 7nm, mais la plupart du temps je lis "Zen2 est gravé en 7nm", le passif retire cette nuance.
Oui ce sont les deux grosses boites. Il y a quelques petits pour des semi-conducteurs moins critiques (genre une bonne vieille diode PN ou un transistor BJT classique on s'en fiche d'avoir une densité de fou, même en CMS) ou plus exotiques (les transistors utilisés dans la recherche sur les ordinateurs quantiques) mais oui Intel est bien seul dans son cas à ne pas avoir externalisé. Puis c'est aussi le seul relativement gros fabricant à ne pas proposer de service à des boites extérieures, donc à ne pouvoir compter que sur ses propres ventes pour amortir le matériel de fabrication, ce qui explique que quand son process 10nm est moins bon il n'y a pas beaucoup d'autre choix que de se rabattre sur des améliorations du 14nm en attendant la prochaine évolution.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 06 juillet 2020 à 05:23.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La taille ça compte (ou pas)
Posté par tao popus . Évalué à 2.
ARM et TSMC annoncent faire ensemble du 7 nm à la fin 2019.
Mais d'après Wikipédia (en), le 7 nm a commencé en 2017 chez le taïwanais TSMC pour de la RAM et Samsung (je crois qu'ils ont aussi leur propres fonderies, comme Intel, mais l'article en lien est bloqué aux abonnés) en produit également depuis 2018. En tout cas, au moins Huawei (Kirin 980), Apple (A12 Bionic) et AMD ("Rome"(Epyc 2), avec la partie I/O en 14 nm, et Radeon RX 5000 series) font faire du 7 nm par TSMC depuis 2018 :
[^] # Re: La taille ça compte (ou pas)
Posté par Maclag . Évalué à 7.
Ouh là! Attention quand même. GF a abandonné la course au dernier nœud technologique depuis un petit moment déjà:
https://www.bloomberg.com/news/articles/2018-08-27/globalfoundries-gives-up-on-advanced-chip-production-technology
En passant, GF, ce n'est pas que les anciennes fab d'IBM, c'est la fusion des activités fab d'AMD et d'IBM réunis par un fonds d'investissement.
Mais là vous oubliez un peu vite Samsung, qui est toujours dans cette course:
https://www.gizmochina.com/2020/07/30/samsung-5nm-chipset-mass-production/
Samsung a ouvert ses fabs aux clients externes (à commencer par Apple) afin d'avoir le volume nécessaire pour rester en lice.
C'est que là, les tout derniers steppers (les machines qui "dessinent" les circuits via un procédé photolithographique) d'ASML en EUV se facturent déjà à 100M$ pièce. Et il faut plus que juste le stepper pour fabriquer les puces.
Soit tu es à la pointe de la techno ET tu as un volume de folie pour rentabiliser des investissements qui atteignent les milliards pour développer le prochain nœud, soit tu rejoins la cohorte des fabs qui abandonnent cette course effrénée et sans fin.
Ils ne sont donc plus que 3 sur la piste: TSMC (Taiwan Semiconductor Manufacturing Company), Intel et Samsung. Mais Intel semble commencer à perdre du terrain.
Bientôt plus que 2?
[^] # Re: La taille ça compte (ou pas)
Posté par Foutaises . Évalué à 2.
Samsung investirait d'ailleurs dans GlobalFoundries.
https://www.techpowerup.com/270221/samsung-rumored-to-make-investment-in-globalfoundries
https://www.tomshardware.fr/samsung-investirait-dans-globalfoudries/
[^] # Re: La taille ça compte (ou pas)
Posté par EdB . Évalué à 7.
AMD fait aussi beaucoup appel à GloFo parce qu'historiquement c'est leur ancienne fabrique avant qu'ils ne deviennent fabless et qu'en échange de la prise en charge de la dette liée ont été mis en place des contrats contraignant de volume.
Ça a pénalisé AMD qui ne pouvait pas exploiter comme ils le souhaitaient des gravures plus fine ailleurs (GloFo était souvent en retard de ce côté là) et devait souvent payer des indemnités pour volume non atteint.
La position d'AMD ne lui a pas permis de bonne négo à l'époque.
[^] # Re: La taille ça compte (ou pas)
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Bien vu, si un des modérateurs peux amender la dépêche je veux bien ;)
Mais l'idée reste là : le 130nm c'est quand même beaucoup plus gros que les processeurs du marché aujourd'hui.
J'ai plus qu'une balle
[^] # Re: La taille ça compte (ou pas)
Posté par karteum59 . Évalué à 7.
Les premiers Pentium M étaient en 130nm.
Donc oui OK c'est obsolète, mais pas ridicule malgré tout et pas du tout limité à du microcontrôleur (il n'y a pas si longtemps, j'ai retapé / recyclé grâce à Linux des machines de cet âge là !)
[^] # Re: La taille ça compte (ou pas)
Posté par tao popus . Évalué à 3.
Tout est relatif. Il faut déjà commencer modeste, et si ça marche, faire plus performant. En dessous de certaines quantités, les 7 nm doivent être aujourd'hui hors de prix, et en grande quantité, il faut être sûr de pouvoir les vendre. Le FGPA est aussi moins performant que l'ASIC, mais c'est aussi une première étape.
D'autre part, rares sont les fabricants de processeurs qui veulent bien vendre leurs processeurs en petite quantité pour des cartes de hackers. En ARM, on doit trouvé 3 ou 4 marques sur celles-ci (AllWinner, AMLogic, RockChip (peut-être MediaTek et Realtek, mais je n'en ai pas en tête), j'ai l'impression que le Néerlandais NXP accepte, mais pas sûr. il y avait bien Texas Instrument, il y a quelques années, mais ils sont un peu à la ramasse au niveau technologies. Il y a quelques cas particuliers, comme, Samsung, seulement chez le Coréen ODroid, et Broadcom pour les Raspberry (Eben Upton, un co-fondateur travaillant chez eux), le franco-italien STMicroelectronics (plus pour ses microcontrôleurs STM32 qui dominent largement ce marché), et après c'est plus ouvert chez différents modèles de RISC-V.
[^] # Re: La taille ça compte (ou pas)
Posté par flavien75 . Évalué à 5.
Ça fait quelques temps que j'ai pas suivi l'actualité des iMx de NXP, mais on peut trouver en vente chez Mouser (du style Cortex-A53).
Freescale était également pas mal abordable à l'époque, mais vu qu'il a été racheté par NXP…
A l'époque, on avait effectivement des soucis à approvisionner chez certains fabricants qui refusent catégoriquement de vendre en dessous de quelques dizaines de milliers de pièces, mais on arrivait généralement à se rabattre sur un autre.
Pour Broadcom et Samsung, ils ne visent visiblement pas les PME, à vrai dire je n'ai jamais eu l'occasion de les croiser sur un salon.
Les vrais naviguent en -42
[^] # Re: La taille ça compte (ou pas)
Posté par Anonyme . Évalué à 3.
À nuancer parce que le XU4 date pas mal et Hardkernel n'a rien sorti utilisant de nouveaux SoC de Samsung, contrairement à ce qu'ils font avec Amlogic.
[^] # Re: La taille ça compte (ou pas)
Posté par Anonyme . Évalué à 4.
Pour donner un ordre d'idée, le 130nm c'était à la pointe il y a un peu moins de vingt ans (la majorité des Athlon XP, les derniers Pentium 3, les premiers Pentium 4 et Athlon64).
[^] # Re: La taille ça compte (ou pas)
Posté par ZeroHeure . Évalué à 4.
Ce qui n'a rien de ridicule, mon bi-pentium3 800MHZ est encore très performant ;-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: La taille ça compte (ou pas)
Posté par Anonyme . Évalué à 4.
Personne n'a dit que c'était ridicule et personne n'a parlé de performances.
La différence avec ton Raspberry Pi (parce que je te vois venir avec tes gros sabots) c'est la taille de la mémoire cache, la vitesse de la RAM, des bus de données et la partie graphique.
Sans compter que son processus de gravure est optimisé pour la consommation, pas pour la montée en fréquence comme sur un processeur de bureau.
Si ton Rpi était gravé en 130nm il serait bien plus gros et aussi consommateur qu'un Tualatin ou un Barton.
Donc oui le 130nm c'est un bon début, mais en pratique son utilisation sera assez limitée et peu probablement destinée à faire des SoC de ce gabarit.
[^] # Re: La taille ça compte (ou pas)
Posté par xavier philippon . Évalué à 6.
Petite remarque en passant :
Plus la gravure est fine, plus la sensibilité aux perturbations extérieures et aux rayonnements ionisants est grande.
Dans le spatial, le nucléaire ou le militaire, on préfèrera des gravures plus grossières qui sont intrinsèquement moins sensibles aux perturbations.
Dans le cas d'une gravure trop fine, un rayonnement peut définitivement endommager une porte logique ou une connexion, alors que dans le cas d'un motif plus grossier, la détérioration sera partielle et le circuit restera fonctionnel.
[^] # Re: La taille ça compte (ou pas)
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Dans le spatial, ils sont justes trop pauvres.
Il existe des lib avec registres tripliqués pour evité ca.
"La première sécurité est la liberté"
[^] # Re: La taille ça compte (ou pas)
Posté par Maclag . Évalué à 2. Dernière modification le 30 juillet 2020 à 21:56.
Dans le spatial, ils sont surtout extrêmement conservateurs, alors ils utilisent rarement des technos qui ne sont pas éprouvées depuis 10ans (et je crois qu'en fait c'est plutôt 20).
Si tu t'énerves quand tu te fais livrer un processeur défectueux ou qu'on doit remplacer une carte électronique sur ta voiture en panne, demande-toi si ça fait moins mal si tu t'en rends compte après avoir claqué 50M€ pour mettre le même composant sur orbite sans opportunité de le remplacer avant plusieurs semaines ou mois.
[^] # Re: La taille ça compte (ou pas)
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Cela commence à dater mais j'ai bossé 6 ans dans un laboratoire de conception numérique pour le spatial, on y faisait des asic et des FPGA.
A l'époque, on restait sur le .35µm, parce que en .18 le jeu de masque coutaient 1M€ contre 300k€ en 0.35.
Plus la taille baissait plus la techno est sensible, donc plus l’industrie "grand publique" doit en tenir compte. D'ailleurs, cela fait un moment que les CPU utilisent des codes correcteurs d'erreurs pour leurs caches.
Et de toute façon, la techno "spatialisé" utilisait simplement une triplication des registres, c'était bien plus simple car il n'existait (n'existe ?) pas d'outils de synthèse qui prend en compte une correction d'erreur.
Ensuite, ce qui posait problème, c'était plus les latchup (destruction de transistor) et la "dose" minimum qui bloquait les transitions des transistors. Et ce n'était pas lié à la finesse mais à la techno utilisé. C'est pour ça qu'il y avait des campagnes de tests pour trouver des DRAM commercial utilisable.
"La première sécurité est la liberté"
[^] # Re: La taille ça compte (ou pas)
Posté par vpinon . Évalué à 7.
Je ne crois pas, pour des satellites basse orbite au moins nous avons envoyé du 28nm (en SOI, vendu pour son épaisseur de silicium active bien inférieure aux longueurs d'ondes des rayonnements présents à des puissances non négligeables)
# Plus aucune raison de ne pas pouvoir faire un processeur 100% Open-Hardware?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 05 juillet 2020 à 22:28.
Tu dis qu'en gros le PDK était la dernière grosse étape avant d'avoir tous les outils pour fabriquer un processeur ASIC 100% Open-Source. Mais tu dis en même temps que tous les outils ne sont pas 100% opérationnels (je ne parle pas de bug mais de fonctionnalité plus ou moins vital). En fait si j'ai bien compris, on ne pourrait pas fabriquer n'importe quel processeur 100% Open-hardware mais un certain type bien limité (Le Raven). Peux tu préciser quels sont les principales limitations qui existent encore à faire tomber pour faire un plus processeur plus complet?
PS : Je suis un informaticien dont les connaissance hardware sont limités. Je connais mieux le fonctionnement d'un OS que d'un processeur.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Plus aucune raison de ne pas pouvoir faire un processeur 100% Open-Hardware?
Posté par Ronan BARZIC . Évalué à 10.
C'est un peu compliqué à expliquer mais je vais essayer. La conception d'un ASIC requiert l'emploi de plusieurs outils dont les principaux sont :
- Un simulateur pour s'assurer que le code Verilog ou VHDL représente le comportement attendu du circuit
- un outil de synthèse qui convertit le code Verilog ou VHDL en une représentation à base d'élément logique de bases (dont une grande partie vient du PDK)
- Un outil de "placement" - pour décider de la position physique de chaque élément sur la puce final
- Un outil de routage, pour calculer comment réaliser les interconnections entre les différents élements en utilisant les ressources disponibles du process de fabrication (typiquement un certain nombe de couche de metaux)
- un outils de construction d'"arbre d'horloge", pour s'assure de la bonne propagation des signaus d'horloge
- un outil d'"extraction" - pour extraire (après placement et routage) les caractéristiques électriques des interconnections entre les éléments
- Un outil d'analyse de temps de propagation, qui utilise les résultat de l'outil d'extraction pour analyser les caractéristiques temporelles du circuit (fréquence maximum, etc..)
Des outils open-source pour chacune de ces taches étaient disponible depuis pas mal de temps mais c'est seulement depuis l'apparition de Yosys et de la suite d'outils OpenRoad que l'on commence à avoir une famille d'outils qui tient la route et surtout qui s'interfacent entre eux relativement bien en utilisant les formats de fichiers standard de l'industrie (.lib/.lef/.spef/.def etc). Auparavant, c'était un peu le bazar
Néanmoins, les outils comme Yosys et la suite OpenRoad sont loin de supporter toutes les possibilités des outils commerciaux (par exemple la possibilité d'avoir des tensions différentes dans différentes portions du circuit). Il y a aussi des manquent concernant le "design for Test", c'est à dire le support de méthode qui permettent de vérifier que chaque puce en sortie de production fonctionne (c'est essentiel pour une production commerciale). Et à ma connaissance, on manque d'un simulateur de netlist supportant la rétro-annotation des informations temporelles pour vérifier la fonctionnalité du circuit après placement/routage
Mais je pense que l'on assiste à un tournant et si OpenRoad arrive à fédérer les développements des différents équipes de recherches travaillant dans le domaine partout dans le monde, on aura un outil vraiment viable d'ici quelque temps.
[^] # Re: Plus aucune raison de ne pas pouvoir faire un processeur 100% Open-Hardware?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4.
En tous cas merci, c'est absolument passionnant. J'ai l'impression de me retrouver 15-20 ans en arrière lors que je suivais les évolution de Linux sans bien connaître trop le fonctionnement précis.
A la fois j'apprends comment ça fonctionne, ce qui est intéressant d'un point de vue culture personnelle.
Et à la fois je suis l'évolution d'un secteur qui se libéralise (s'open-sourcise devrais-je dire) avec tous les défis à relever.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Liste des étapes de conception d'une puce numérique
Posté par Olivier LEMAIRE (site web personnel) . Évalué à 7.
Bonjour,
je pense que ton titre est vraiment pertinent car dans la dépêche on parle quasi exclusivement de dev asic numérique; or, ce n'est qu'une facette du développement d'asic. Il y a aussi le monde analogique où on va concevoir des amplificateurs, des PLLs, des ADC, des références de tension, des bandgap par exemple et où la très peu de choses sont automatiques. Quasiment tout se fait à la main, transistor par transistor, pas de code hdl. On crée des structures pour lesquelles on va pouvoir donner des dimensions différentes à chacun de nos transistors… Tout se fait "à la main", ll faut faire attention à tout… Un design peut fonctionner au niveau du schéma et pas du tout une fois fondu car le placement des composants les uns par rapports aux autres est important, les interconnexions et les parasites que ca ajoute change le comportement du circuit… et c'est sans compter sur les variations de 2 à 20% au moment de la fabrication.
Bref je vais pas tout expliquer ici mais il n'y a pas que le numérique :)
Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée
[^] # Re: Liste des étapes de conception d'une puce numérique
Posté par gringonz . Évalué à 1.
Un DK complet permet de concevoir de l'analogique et du numérique. en fait je me demande ce que va faire google, car google n'est pas un fondeur. Du coup faire un DK sur une techno qu'on ne possède pas, soit c'est la techno d'un fondeur et le fondeur en question risque de ne pas être d'accord et si le fondeur est d'accord, alors il peut lui directement distribuer son DK à qui il veut. soit ça correspond à aucune techno et il ne sera pas possible de faire fabriquer l'ASIC.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 06 juillet 2020 à 19:23.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3. Dernière modification le 01 août 2020 à 01:11.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.