Cosimulation d'Icarus Verilog et NGSpice : comparaison des architectures

Co-simulation de circuits numériques et analogiques : Deux approches pour le pont Icarus Verilog et NGSpice

Les systèmes électroniques modernes nécessitent l'intégration de composants numériques et analogiques, rendant la simulation à signaux mixtes cruciale. Pour relever ce défi, nous avons implémenté un pont entre Icarus Verilog et NGSpice en développant deux architectures. Chacune présente des limitations fondamentales, mais elles permettent déjà de résoudre des tâches réelles allant des SAR ADCs aux modulateurs sigma-delta.

Bases de la simulation à signaux mixtes : Événements vs. Continuité

Les circuits numériques sont modélisés à l'aide d'événements : le simulateur ne s'active qu'en cas de changements de signal (flancs d'horloge, bascule de bascules). C'est ainsi que fonctionnent Icarus Verilog et les autres simulateurs numériques — le système « dort » entre les événements, assurant des performances élevées. Les circuits analogiques nécessitent une modélisation continue : les moteurs SPICE (NGSpice, Spectre) découpent le temps en petites étapes, résolvant des équations différentielles pour chaque intervalle. Cette approche est précise mais gourmande en ressources, en particulier avec des bords raides ou des boucles de rétroaction.

Le défi clé en co-simulation consiste à réconcilier ces paradigmes fondamentalement différents. Le simulateur numérique gère des événements discrets, tandis que celui analogique nécessite un flux temporel fluide. Lors de la combinaison d'un SAR ADC (où un comparateur analogique interagit avec la logique numérique), un dilemme surgit : comment transmettre les données entre les moteurs sans perdre d'événements critiques ?

Architecture du pont : Principes communs

Les deux implémentations utilisent les mêmes technologies de base :

• VPI (Verilog Procedural Interface) pour interagir avec Icarus
• La bibliothèque dynamique libngspice.so
• Un mécanisme de streaming avec sémaphones
• Un thread d'exécution NGSpice séparé

L'élément central est la tâche système $spice_sync(), appelée sur les flancs montants du signal d'horloge. Elle effectue un cycle d'échange complet : transmission de valeurs numériques à SPICE via des commandes alter, interrogation des tensions analogiques, et mise à jour de variables réelles en Verilog. Cela permet d'afficher les signaux analogiques dans GTKWave sur la même ligne de temps que les signaux numériques.

always @(posedge clk_fast) begin
    $spice_sync();
    if (tb.Vcmp > vref_th) begin
        // Reaction to event
        ...
    end
end

Le mécanisme expose_analog_N synchronise automatiquement les variables analogiques, les rendant accessibles à la logique numérique. Des objets wrappers de part et d'autre du pont gèrent les bords et les délais.

Approche classique : Sondage synchrone

Dans cette implémentation, Verilog initie l'échange à chaque appel de $spice_sync(). Le simulateur enregistre l'instant actuel, bloque sur un sémaphore, transmet le contrôle à NGSpice, qui simule jusqu'à ce point et retourne les données.

Avantages :

• Déterminisme total
• Performances prévisibles
• Implémentation simple (environ 2000 lignes de code)

Limitations critiques :

• Invisibilité complète des événements analogiques entre les flancs d'horloge. Par exemple, si un comparateur commute à 5,2 ns et le prochain flanc d'horloge est à 10,0 ns, la logique numérique ne détectera pas le changement pendant 4,8 ns, rendant impossibles les boucles de rétroaction dans les SAR ADCs ou les convertisseurs DC-DC.
• Suréchantillonnage forcé : pour capturer les événements rapides, il faut augmenter artificiellement la fréquence d'horloge (p. ex. à 500 MHz), ce qui pénalise les performances.

Cette approche convient uniquement aux tâches où les événements analogiques coïncident avec les flancs d'horloge ou avec une horloge à haute fréquence pour la synchronisation.

Approche alternative : Analyse en avance (Lookahead)

Pour surmonter les limitations de la méthode classique, nous avons implémenté un mécanisme de lookahead. NGSpice obtient l'autorisation de « courir en avance » sur un intervalle défini, en suivant les événements analogiques via des capteurs configurables. Exemple de règle dans mixed_bridge.cfg :

analog_event_0 = threshold outp rising 1.2 | time_var=tb.analog_event_time id_var=tb.analog_event_id

Lorsque la condition se déclenche, SPICE met en pause et initie un événement en Verilog via le callback cbAfterDelay.

Avantages :

• Capacité à détecter des événements analogiques asynchrones
• Flexibilité configurable (seuils, durées, conditions d'énergie)
• Charge réduite avec des horloges peu fréquentes

Inconvénients fondamentaux :

• Événements manqués entre les pas de SPICE en raison de l'intégration temporelle discrète
• Violations de causalité : les commandes alter (changements de signaux numériques) ne s'appliquent qu'à la phase de simulation suivante, ce qui est critique pour les DACs
• Limite d'un événement par fenêtre d'analyse
• Non-déterminisme issu des heuristiques pour choisir la longueur de l'intervalle lookahead
• Complexité d'implémentation (3500+ lignes de code + analyseur de configuration)

Différences clés en comparaison

Les principaux compromis entre les architectures se manifestent dans cinq aspects :

• Détection d'événements : La méthode classique rate complètement les événements entre horloges, l'alternative les capture partiellement mais risque des omissions
• Causalité : Dans l'approche classique, le lien DAC → analogique est correct ; dans l'alternative, des incohérences temporelles sont possibles
• Performances : La méthode synchrone offre une vitesse stable ; le lookahead peut ralentir dramatiquement avec des intervalles courts
• Déterminisme : Seule l'implémentation classique garantit des résultats reproductibles
• Complexité d'intégration : L'alternative exige un réglage fin des heuristiques et l'analyse du timing du circuit

Enseignements clés

• Pas de solution parfaite : Les deux architectures présentent des limitations inhérentes dues aux différences fondamentales des paradigmes de modélisation
• Choix selon la tâche : La méthode alternative convient aux modulateurs sigma-delta avec des impulsions rares ; la classique avec suréchantillonnage s'adapte aux SAR ADCs à timing strict
• Applicabilité réelle : L'outil est déjà utilisé pour vérifier la logique numérique dans des environnements analogiques et pour le comptage d'impulsions
• Visualisation : Les deux supportent l'affichage combiné des signaux dans GTKWave et gnuplot sur une ligne de temps unifiée
• Perspectives : Intégrer une file d'événements et utiliser cbNextSimTime pourrait atténuer les limitations

Implémentation pratique et exemple d'utilisation

Considérez l'utilisation du pont pour un modulateur sigma-delta. La partie analogique génère de courtes impulsions qu'un compteur numérique doit additionner. Dans l'approche classique, il suffit d'appeler $spice_sync() à une fréquence supérieure à la durée des impulsions. Exemple de code Verilog :

module DSMCounter(
    input i_clk,
    input i_rst,
    input i_Qbar,
    output reg[31:0] o_cntQbar,
    output reg o_ready
);
parameter CNT_CLK = 22;
reg [31:0] cnt;
reg [31:0] cntQbar;

always @(posedge i_clk) begin
    if(i_rst) begin
        cnt <= 0;
        cntQbar <= 0;
        o_cntQbar <= 0;
        o_ready <= 0;
    end else begin
        o_ready <= 0;
        if(i_Qbar == 1) begin
            cntQbar <= cntQbar + 1;
        end
        if(cnt == CNT_CLK-1) begin
            o_cntQbar <= cntQbar;
            o_ready <= 1;
            cnt <= 0;
            cntQbar <= 0;
        end else begin
            cnt <= cnt + 1;
        end
    end
end
endmodule

Dans l'implémentation alternative, vous pouvez réduire la fréquence de synchronisation en utilisant des règles de détection d'impulsions via analog_event. Cependant, cela nécessite un réglage minutieux des paramètres de lookahead pour éviter les omissions.

Pour l'exécution, vous avez besoin de la version partagée de NGSpice (--with-ngshared). La configuration du pont est définie via mixed_bridge.cfg, qui spécifie les points de synchronisation et les règles de détection d'événements. Les deux implémentations sont open-source mais requièrent des tests pour votre tâche spécifique.

Les orientations futures incluent l'implémentation d'une file d'événements au lieu d'un simple drapeau, l'intégration de maxstep dans la configuration du pont, et l'utilisation de cbNextSimTime pour un contrôle précis du temps. Une solution complète nécessiterait l'ajout d'une API d'événements à NGSpice.

— Editorial Team