Un ASIC (application‐specific integrated circuit, en anglais) est un circuit intégré d’électronique numérique conçu pour une application spécifique et qui ne peut être modifié une fois produit. Un ASIC est à mettre en opposition avec le FPGA qui lui est un circuit intégré d’électronique numérique que l’on peut reconfigurer à l’infini.
Les FPGA sont très liés aux ASIC. En effet, la plupart des outils utilisés en FPGA pour la synthèse HDL, la preuve formelle, le placement routage ou l’analyse des timings sont les mêmes que ceux à destination des ASIC. Seules les bibliothèques et les configurations changent. La grosse différence (de taille) avec les FPGA c’est que l’ASIC n’est pas reconfigurable, et les « frais d’initialisation » sont très élevés. Les délais de production sont également très longs (on parle en trimestres voire en semestres de délais).
Avec de telles contraintes, on comprend pourquoi les développeurs ne se mouillent pas trop avec des logiciels exotiques et restent sur ceux qu’ils connaissent. Vu les tarifs de production, le coût des licences des logiciels est assez négligeable. Pourquoi « grenouiller » avec des outils libres dans ce cas ?
Toutes ces contraintes n’ont pas découragé Tim Edwards de se lancer intégralement avec des outils libres dans la conception et la fabrication d’un microcontrôleur.
C’est comme cela qu’est né le Raven, un microcontrôleur basé sur un cœur picoRV32 (conçu par Clifford Wolf) et réalisé principalement avec les outils qflow d’opencircuitdesign.com :
- synthèse Verilog : yosys et ABC ;
- analyse statique des timings : vesta ;
- placement : graywolf ;
- routage : qrouter ;
- layout & DRC : magic ;
- LVS : netgen ;
- simulation Verilog : Icarus Verilog ;
- cosimulation (pour les parties analogiques) : ngspice et Icarus ;
- génération des masques : magic.
Grande surprise quand on se plonge dans ces outils libres : beaucoup sont très vieux. Les pages Web de ses outils sont encore codés en web95 avec des frames et autre fonds hideux datant de l’époque FrontPage. Pourtant à y regarder de plus près, ces outils semblent toujours activement maintenus. Mais alors pourquoi aucun fondeur FPGA ne les proposent dans leurs IDE ?
Une première série du microcontrôleur gravé en 180 nm a été produite en mai 2018. Le composant est désormais fonctionnel avec les caractéristiques suivantes :
- cadencé à 100 MHz ;
- 16 GPIO ;
- 2 ADC ;
- 1 DAC ;
- 1 comparateur ;
- alarme de température ;
- oscillateur RC de 100 kHz ;
- fonctions configurables pour les sorties GPIO ;
- interruptions configurables sur les entrées GPIO ;
Il n’est pas possible d’acheter le composant pour se faire un montage chez soi pour le moment. En revanche, l’« IP » est disponible dans la bibliothèque du fondeur efabless et peut être utilisée comme base pour réaliser son propre composant selon les besoins.
Aller plus loin
- Présentation du Raven sur hackster.io (328 clics)
- Le picoRV32 de Clifford (157 clics)
- Les outils Qflow du site opencircuit.com (222 clics)
- La fiche « produit » du Raven sur la plate‐forme efabless (131 clics)
# Comme dirait Dave Jones...
Posté par FantastIX . Évalué à 6.
«Isn't it sex on a stick?» ou du porno pour électronicien, si vous me permettez cette traduction libre.
Je suis impatient de développer avec et pour le Raven! Je vois qu'il existe déjà une chaîne de développement pour GCC, basés sur Risc-V RV32! D'après la page sur Github, je ne devine la présence que d'un seul timer, est-ce correct? Ou bien en possède-t-il d'autres?
Cadencé à 100MHz avec tous ses convertisseurs analogiques et numériques, voilà qui fait rêver sur le nombre de possibilités…
[^] # Re: Comme dirait Dave Jones...
Posté par martoni (site web personnel, Mastodon) . Évalué à 8.
C'est pas sûr qu'il y ait une production de masse. Le but du Raven est surtout de faire la pub de la plate-forme de développement collaboratif eFabless.
Mais s'il est possible d'avoir un chip, je suis également impatient de pouvoir jouer avec ;)
J'ai plus qu'une balle
[^] # Re: Comme dirait Dave Jones...
Posté par FantastIX . Évalué à 5.
J'imagine que ça coûte très cher de commencer à lancer une production. J'espère que cette initiative fera décoller les développements de masse mais je ne suis pas certain que les fondeurs actuels soient intéressés — contrats juteux en cours, exclusivités, secrets de fabrication… Je n'ai pas la moindre idée des tenants et aboutissants de ce genre de production mais s'il est possible de contribuer à un financement pour que ce micro soit fondu et commercialisé en masse, je participerai volontiers.
[^] # Re: Comme dirait Dave Jones...
Posté par jtremesay (site web personnel) . Évalué à 9.
Il faut compter au moins 20k€ pour 50 testchips. Mais ça inclut la création le masque lithographique (en quelque sorte le négatif de la puce) (c'est le truc le plus cher dans le process de fabrication) que tu peux réutiliser par la suite.
# Avantages de l'ASIC
Posté par HL . Évalué à 4.
Merci pour la dépêche. Je n'ai pas l'impression que la dépêche montre l'avantage des ASIC sur les FPGAs. Cela devient moins cher à partir d'une certaine quantité produite ?
[^] # Re: Avantages de l'ASIC
Posté par 2PetitsVerres . Évalué à 9.
Tout à fait. Un FPGA, c'est relativement cher pour chaque unité. Un ASIC, c'est extrêmement cher pour la première unité (il faut créer un masque. Et si on si plante, recommencer, et repayer) mais sur le volume, ça peut devenir plus rentable. Autrement dit, le coût marginal d'un ASIC (un chip) est plus faible que celui d'un FPGA.
Il y a aussi d'autre avantages (si je ne me trompe pas), c'est qu'un ASIC peut être plus performant ( en consommation d'énergie par calcul par exemple) qu'un FPGA qui ferait les mêmes calculs.
Note : ce n'est pas mon domaine, mais ce que j'ai compris. N'hésitez pas à corriger si j'ai tort.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Avantages de l'ASIC
Posté par martoni (site web personnel, Mastodon) . Évalué à 6.
C'est exactement ça 2PetitsVerres.
Un ASIC sera plus performant niveau consommation électrique et fréquence d'horloge (modulo la finesse de gravure). De plus il faudra moins de silicium pour réaliser la fonction (puisque seul les fonctions utilisé sont «gravé»).
J'ai plus qu'une balle
[^] # Re: Avantages de l'ASIC
Posté par vpinon . Évalué à 8.
Et un ASIC permet aussi de d'intégrer des fonctions analogiques, des périphériques et interfaces spécifiques (USB, lien RF ou NFC, contrôle de moteur…)
[^] # Re: Avantages de l'ASIC
Posté par Marco . Évalué à 3. Dernière modification le 17 juin 2019 à 15:39.
De mémoire :
Un FPGA aura "trop" de portes logiques (et tu les paies même si tu ne les utilises pas), donc coutent plus cher à grande échelle (vu qu'une partie des portes "ne servent pas")
Un ASIC sera également plus performant (on peut en effet optimiser le placement des portes logiques par ex)
[^] # Re: Avantages de l'ASIC
Posté par gUI (Mastodon) . Évalué à 4.
Merci pour les infos, c'est très intéressant comme sujet.
Est-ce que le FPGA peut être une première étape vers l'ASIC (pour vérifier/valider) ? Ou le développement n'a rien à voir donc dès le début de l'implémentation tu dois choisir ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Avantages de l'ASIC
Posté par flagos . Évalué à 5.
Ça peut effectivement être une étape.
Cela dit, il existe d'autres outils pour tester avant de livrer un ASIC:
- on peut simuler de manière purement logicielle
- on peut également utiliser des émulateurs. Ce sont des machines qui sont a un niveau intermédiaire entre la simulation logicielle et le fpga.
Selon les dimensions de ton projet, il faut s'orienter vers l'outil qui convient pour la stratégie de test.
[^] # Re: Avantages de l'ASIC
Posté par dib2 . Évalué à -3.
Un FPGA n'a pas trop de portes logiques, elle représentent tout au plus 10% de la surface de silicium. Il n'y a quasiment jamais de portes inutilisées. Il n'y en a même jamais assez. Le reste est de la connexion dont une certaine partie est inutilisée.
Par ailleurs, sur un ASIC, les connexions sont toujours plus courtes.
[^] # Re: Avantages de l'ASIC
Posté par Fabrice Mousset (site web personnel) . Évalué à 8.
En fait un ASIC n'a rien a voir avec un FPGA.
Pour faire une analogie informaticienne, cela revient à comparer de la ROM (ASIC) avec de la RAM (FPGA).
Un ASIC c'est un design de logique programmable qui est défini et figé une fois pour toute. Tous les éléments de logique sont placés une fois pour toute avant de partir en gravure. On a ainsi un composant beaucoup plus rapide et avec une consommation énergétique beaucoup moindre qu'avec un FPGA.
Par contre, une fois le design gravé… et bien il est ce qu'il est… pas moyen de changer quoi que ce soit. En cas de bug, il va falloir créer un nouvel ASIC… Bref c'est reparti pour quelques k€ !
Un FPGA, pour faire simple (attention c'est vraiment très grossier), c'est une matrice de plusieurs millier d'éléments logiques identiques ainsi qu'un ensemble "routes" qui quadrillent les éléments logiques. Lorsque l'on créer une design FPGA, on ne fait que définir les interconnexions entre les éléments logiques. Bref, le chemin entre les éléments pourra être plus ou moins long… et donc plus ou moins rapide. De plus tous les éléments logiques sont tjrs présent… Donc ils consomment de l'énergie même s'ils ne sont pas utiles pour le design.
L'avantage, c'est que l'on peut changer le design plus ou moins à volonté.
Ceux sont vraiment 2 mondes différents, qui ne font que partager un certain nombre d'outils.
[^] # Re: Avantages de l'ASIC
Posté par abriotde . Évalué à 0. Dernière modification le 04 juillet 2019 à 14:07.
Ben non pas toujours, enfin du moins c'est plus complexe.
Un FPGA est généralement gravé moins finement, donc cela augmente la consomation.
Un ASIC est dédié à une opération donc évidemment il y a plus d'optimisation, pour une opération donnée (moins de trajet électriques, moins de porte à passer)
Par contre compte tenu qu'un ASIC est très spécifique, beaucoup de processeur doivent installer beaucoup d'unité. Typiquement le CPU/GPU est composé de dizaines (centaines?) d'unité (FPU, Addition, MMU… ) Alors qu'un FPGA peut se contenter d'une seul unité qui s’optimise au fur et a mesure des mises à jour ou se reprogramme en fonction des besoins et la il devient plus efficace qu'une multitude d'unité ASIC…
Exp : Prenons le cas d'un décodeur vidéo. Si on l'implémente pour de l'AV1, et que l'on se retrouve parfois avec une vidéo utilisant d'autres codecs, ou même une version différente du codec, on pourra pas utiliser notre puce ASIC, on sera obligé de passer par le CPU/GPU, ou alors implémenter plusieurs codec. prenons par exemple 10 codecs avec 4 unité et des options sur chacune…. Alors il pourrait être intéressant de pouvoir en gérer une infinité avec un FPGA… Même si pour décoder une vidéo notre FPGA sera moins efficace que l'ASIC, il sera toujours efficace pour toutes les vidéos… Si on le recode, et c'est là que le bâ blesse, il est souvent difficile de trouver des développeur pour ça. A ma connaissance seul la finance fais souvent ce choix.
[^] # Re: Avantages de l'ASIC
Posté par aiolos . Évalué à 2.
À une époque tout au moins, il me semble que beaucoup de BTS de téléphonie mobile (les "antennes relais") étaient implémentées en FPGA plutôt qu'ASIC. Je ne sais pas ce qu'il en est aujourd'hui.
[^] # Re: Avantages de l'ASIC
Posté par flagos . Évalué à 5.
Utiliser un FPGA au lieu d'un ASIC peut sembler effectivement plus sexy, plus évolutif.
Le problème est sur le coût: Un FPGA peut facilement coûter autour de 1000 euros, voire même 10 000 euros. Un ASIC coûte 10 euros en sortie d'usine. On est absolument pas sur la même gamme de prix et, quitte a etre sur des prix pareils, autant prendre un CPU intel et faire ton application dessus, c'est nettement plus simple.
Finalement, étant donne le coût d'un FPGA, il faut vraiment être sur des petites quantités de production avec une certaine valeur ajoutée. Typiquement, on en trouve dans l'aéronautique, le spatial ou le médical.
# Détail de terminologie
Posté par xavier philippon . Évalué à 9.
Petite remarque terminologique qui n'enlève rien à la qualité de l'article et du développement qu'il décrit :
Ce circuit n'est pas un ASIC (Application Specific Integrated Circuit) mais plutôt un ASSP (Application Specific Standard Product)
Si on se réfère aux fonctionnalités proposées, c'est un microcontrôleur comme en propose NXP (Freescale), Infineon (Siemens) ou Microchip(/Atmel).
Maintenant, le fait que ce soit un cœur Risk V est un réel pas en direction de l'open-hardware.
Il ne reste qu'à le monter sur une carte au format Arduino et à l'intégrer dans l'IDE du même nom. À quand le financement participatif ?
[^] # Re: Détail de terminologie
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
C'est du pinaillage de haut vol ;) Il n'y a déjà pas grand monde à comprendre ce que c'est qu'un ASIC mais si en plus on fait la différence entre ASIC et ASSP on risque de perdre tout le monde.
Yèp.
J'attends avec impatience le lancement d'une telle campagne de financement ;)
J'ai plus qu'une balle
[^] # Re: Détail de terminologie
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Je sais que ce n'est sans doute pas la même chose, mais entre 20k€ et 1€24 (frais de port compris chez JIAQISHENG) la carte finie avec un STM32F103C8T6, c'est un peu dur l'équation économique du matériel libre…
Je sais très bien que ali le rapide chinois est sponsorisé au niveau transport par le parti communiste chinois qui ne nous fais pas payer le vrai prix, mais au vu des ordres de grandeur, ça fait un peu suicide économique…
Je ne mets pas le lien pour ne pas faire de pub déloyale à ce beau projet :)
[^] # Re: Détail de terminologie
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Qui a dit qu'open-source signifiait gratuit ? Et à 20k$ t'iras pas pinailler sur les frais de ports je pense ;)
Plus sérieusement, les 20k$ se sont surtout des frais d'init. Si on en produit 1 millions ça sera moins cher que 1€ l'unité (en fonction de la surface utilisée à 180nm tout de même).
J'ai plus qu'une balle
[^] # Re: Détail de terminologie
Posté par Anonyme . Évalué à 3. Dernière modification le 20 juin 2019 à 20:33.
Tu ne fais pas de pub déloyale en parlant d'une carte chinoise à base de STM32.
Ça serait déjà un peu plus raisonnable de comparer avec d'autres microcontrolleurs RISC-V comme ceux de Sifive ou autres entreprises.
De plus, c'est pas le tout de concevoir une carte de développement autour d'une puce. La qualité du design, des composants, de l'assemblage et la tolérance du contrôle qualité ont aussi un rôle à jouer. Pour l'amateur, un clone chinois est envisageable tandis que pour un usage professionnel on part sur une tout autre gamme de contraintes et de prix (par exemple les cartes Nucleo de ST Micro).
# cout logiciel
Posté par gringonz . Évalué à 3. Dernière modification le 04 juillet 2019 à 10:57.
Contrairement à ce qui est écrit, le cout des logiciel de CAO VLSI est très loin d'être négligeable. Les licence pour un logiciel de placement routage ça peut s'élever à plusieurs dizaine de k€ et il te faut la suite complète pour développer un circuit (simulateur, outils de synthèse, placement/routage, vérification au niveau design et au niveau layout…) Bref une dizaine d'outils tous aussi chers les uns que les autres.
Là ou je suis surpris, c'est que le concepteur soit arrivé à placer et router un circuit avec un logiciel "inconnu" (je veux dire par là hors des solutions propriétaires fournies par les gros du secteur, ils ne sont pas si nombreux). Je m'explique : pour router un circuit avec une technologie donnée, le fondeur doit fournir au concepteur ce qu'on appelle un design kit (DK). Ces DK sont très long à développer et les fondeurs le font uniquement pour un voire 2 outils de CAO.
Du coup d'ou vient le design kit utilisé dans ce cas ?
Petit point complémentaire : dans le flot de conception ce qu'on appelle la partie back-end (le placement routage et ce qui suit en gros) est très différente entre un FPGA et ASIC. Un spécialiste de FPGA sera incapable de faire cette partie sans passer un temps énorme en formation (ou auto formation).
En tout cas chapeau pour cette réalisation.
[^] # Re: cout logiciel
Posté par vpinon . Évalué à 4.
Les fondeurs font des efforts depuis longtemps pour se rendre plus indépendants des éditeurs de CAO, en se basant sur des PDK a décliner automatiquement vers divers outils. Même l'industrie CAO essaye de mettre en place des formats "standards" je crois (genre UPF).
Par ailleurs, Tim Edwards travaille pour efabless (pendant des décennies il faisait ça sur son boulot de prof+consultant je crois), c'est son job de fournir cet environnement fonctionnel. La c'est la démo que tout est prêt.
efabless semble dépendre de Xfab comme unique fonderie, ils ont probablement des accords pour avoir accès aux DK et autres corelibs (a moins qu'il n'utilise des DK & corelibs "génériques", non optimisées, comme ils le proposent dans les bouquins)…
C'est gagnant-gagnant ? La CAO devient accessible, et Xfab enrichit son catalogue d'IPs compatibles…
mais cette libéra(lisa)tion ne va-t-elle pas aussi vers une "uberisation" de la conception ?
# Vidéo de conférence
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Pour celles et ceux qui voudraient aller plus loin dans le sujet, je vous recommande chaudement sa conférence à l'ORConf de 2017 (OpenRisc Conference):
J'ai plus qu'une balle
[^] # Re: Vidéo de conférence
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Il y a cette présentation également.
J'ai plus qu'une balle
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.