Siemens și NVIDIA: un agent EDA trece de la 55% la 95% după corecturi ghidate de verificarea fișierelor Liberty

Pe 14 octombrie 2026, NVIDIA a publicat pe blogul său tehnic un studiu de caz scris împreună cu Siemens EDA. Studiul arată cum a fost evaluat și îmbunătățit un agent AI care generează fișiere Liberty (.lib), modelele de timp și putere ale celulelor standard din care se construiesc cipurile digitale. Unealta de evaluare este NVIDIA NeMo Gym, o bibliotecă open source. Agentul nu a fost notat după codul sau comenzile pe care le scrie, ci după fișierele .lib produse la final, comparate cu fișiere de referință. Sursa: blogul NVIDIA Developer.

După mai multe runde de corecturi în instrucțiunile agentului și în descrierile uneltelor, scorul mediu de verificare a crescut de la aproximativ 55% la 95%, iar agentul a ajuns la rezultat în 53 de ture în loc de 155. Articolul verifică rezumatul care circulă despre studiu, explică ce conține un fișier Liberty, pe un exemplu dintr-un PDK open source, și arată ce măsoară de fapt scorul de 95%.

Cifrele principale

Valorile sunt din blogul NVIDIA. Numărul de celule și colțurile PVT publicate le-am verificat în depozitul bibliotecii de celule GF180MCU.

Verificarea afirmațiilor

Rezumatul care circulă spune: Siemens și NVIDIA arată că agenții EDA ating 95% acuratețe prin verificarea automată a rezultatelor. Într-un studiu tehnic publicat pe 14 octombrie, Siemens a folosit NVIDIA NeMo Gym pentru evaluarea agenților care generează fișiere Liberty. Prin validarea rezultatelor finale și optimizarea descrierilor MCP și a instrucțiunilor agenților, scorul de verificare a crescut de la 55% la 95%, iar numărul de iterații a scăzut de la 155 la 53. Rezumatul este ilustrat cu o imagine Siemens–NVIDIA despre soluții EDA „construite pe NVIDIA NIM și modelele Nemotron”.

• „Studiu tehnic publicat pe 14 octombrie”. Data este corectă. Textul este însă un articol pe blogul tehnic NVIDIA, nu o lucrare științifică. Nu are recenzie și nu publică datele rulărilor.
• „Siemens a folosit NeMo Gym pentru evaluarea agenților care generează fișiere Liberty”. Confirmat. Este vorba de un singur agent, cel al suitei Solido Characterization Suite.
• „Agenții EDA ating 95% acuratețe”. Incorect formulat. 95% este media unui scor compus, nu o acuratețe. Acuratețea, adică procentul de valori aflate în toleranță, este doar unul dintre factorii scorului. Rezultatul este obținut pe un benchmark de dezvoltare, pe o singură sarcină, cu două celule per rulare. Nu descrie agenții EDA în general.
• „Prin validarea rezultatelor finale și optimizarea descrierilor MCP și a instrucțiunilor agenților”. Confirmat. Echipa a mai simplificat uneltele pentru fișiere și shell care se suprapuneau și a definit intrările uneltelor prin scheme JSON explicite.
• „Scorul de verificare a crescut de la 55% la 95%”. Confirmat. NVIDIA dă valorile ca aproximative: „~55% → ~95%”.
• „Numărul de iterații a scăzut de la 155 la 53”. Inexact. 155 și 53 sunt ture ale agentului într-o rulare, adică pașii lui de lucru, nu iterații ale optimizării. Optimizarea a avut în total aproximativ 25 de rulări.
• Imaginea cu NIM și Nemotron. Nu corespunde experimentului. Rulările au folosit Claude Opus 4.8 în Claude Code, nu un model NVIDIA. Contribuția NVIDIA la acest studiu este unealta de evaluare, NeMo Gym.

Rezumatul redă corect cifrele, dar le dă alt sens: 95% nu este acuratețe, iar 155 → 53 nu sunt iterații.

Ce conține un fișier Liberty

Un cip digital este asamblat din celule standard: porți logice, bistabile, buffere, fiecare desenată o singură dată și apoi repetată de milioane de ori. Uneltele de sinteză și de analiză statică a timpilor (STA) nu simulează tranzistoarele din fiecare celulă. Ele citesc un model gata calculat al celulei, scris în formatul Liberty. Fișierul .lib spune, pentru fiecare celulă, ce funcție logică are, ce capacitate are fiecare intrare și cât întârzie semnalul, în funcție de cât de repede comută intrarea și de câtă sarcină are ieșirea.

Exemplul de mai jos este un fragment simplificat din biblioteca publică GF180MCU: inversorul de cea mai mică putere, la 25 °C și 3,3 V.

cell(gf180mcu_fd_sc_mcu7t5v0__inv_1) {
  area : 8.780800 ;
  pin(I) {
    direction : input ;
    capacitance : 0.004623 ;
  }
  pin(ZN) {
    direction : output ;
    function : "(!I)" ;
    timing() {
      related_pin : "I" ;
      timing_sense : negative_unate ;
      cell_rise(tmg_ntin_oload_10x10) {
        index_1("0.02, 0.07922, 0.2871, 0.6841, ...");    /* tranziția intrării, ns */
        index_2("0.001, 0.003411, 0.01187, 0.02804, ..."); /* sarcina ieșirii, pF */
        values("0.07315, 0.107, 0.2224, 0.4406, ...", ...);
      }
    }
  }
}

Celula ocupă 8,78 µm², intrarea are 4,6 fF, iar ieșirea este negata intrării. Tabelul cell_rise dă întârzierea frontului crescător al ieșirii pe o grilă de 10 × 10 puncte: 10 valori ale tranziției intrării, între 0,02 și 8,6 ns, și 10 valori ale sarcinii, între 0,001 și 0,35 pF. Același arc mai are tabele pentru frontul descrescător, pentru durata tranzițiilor ieșirii și pentru energia consumată la comutare. Un fragment din tabelul cell_rise, în ns:

Unealta STA interpolează între punctele grilei. Pentru o tranziție a intrării de 0,2871 ns, care cade exact pe grilă, și o sarcină de 0,04 pF, care nu cade, calculul este:

Fiecare punct al grilei vine dintr-o simulare SPICE tranzitorie a celulei. Caracterizarea înseamnă tocmai rularea acestor simulări pentru toate celulele, toate arcele și toate punctele, în fiecare colț PVT, adică fiecare combinație de proces (tt, ss, ff), tensiune și temperatură. Când fabrica publică un PDK nou sau actualizează modelele tranzistoarelor, bibliotecile trebuie regenerate.

Volumul de date este mare. Am numărat valorile din biblioteca publicată: într-un singur colț PVT, cele 229 de celule au 3 596 de grupuri de timp și aproximativ 1,39 milioane de valori în tabele de întârziere, tranziție, constrângeri și putere. La cele 36 de colțuri folosite de Siemens rezultă în jur de 50 de milioane de valori. Numărătoarea este a noastră.

De ce erorile trec neobservate

NVIDIA scrie că erorile agentului produc, de cele mai multe ori, rezultate plauzibile, nu eșecuri vizibile: praguri de tranziție greșite, colțuri PVT lipsă, celule incomplete. Un fișier Liberty cu valori greșite rămâne un fișier Liberty valid, care se încarcă fără erori în unelte.

Pragurile de tranziție sunt un exemplu bun. Biblioteca GF180MCU măsoară durata fronturilor între 30% și 70% din tensiunea de alimentare și declară slew_derate_from_library : 0.5. Valorile din tabele sunt deci durata 30–70% împărțită la 0,5, echivalentul unei rampe 10–90%. Dacă agentul scrie direct durata 30–70%, dar păstrează factorul de 0,5 din antet, toate tranzițiile ies de două ori mai mici decât cele reale. Fișierul arată normal, dar fiecare întârziere calculată de STA pentru celula următoare, care citește această tranziție la intrare, este greșită. Exemplul este al nostru și arată cum se propagă eroarea: NVIDIA nu spune ce praguri greșite a ales agentul.

Și invers, valori care par greșite pot fi corecte. În același colț, 4 680 din cele aproximativ 409 000 de valori de întârziere, adică 1,1%, sunt negative, aproape toate la frontul descrescător al ieșirii. La inversorul de mai sus, întârzierea frontului descrescător ajunge la −0,506 ns pentru o tranziție a intrării de 8,6 ns și o sarcină de 0,001 pF. Întârzierea se măsoară de la momentul în care intrarea trece prin 50% până la momentul în care ieșirea trece prin 50%. Când intrarea comută foarte lent și sarcina e mică, ieșirea poate trece prin 50% înainte ca intrarea să ajungă acolo, pentru că pragul de comutare al celulei nu este exact la jumătatea tensiunii. O regulă simplă de tipul „întârzierea trebuie să fie pozitivă” ar respinge date bune. De aceea verificarea are nevoie de un fișier de referință, nu doar de reguli de bun-simț.

Etapele fluxului depind una de alta. Agentul citește intrările, configurează condițiile de lucru, validează pe o celulă-pilot, extinde calculul pe toate celulele și colțurile, apoi generează și compară fișierele. O eroare de configurare făcută la început ajunge în toate etapele următoare. Verificarea pas cu pas, după fiecare apel de unealtă, nu o prinde: fiecare apel reușește, dar rezultatul final este greșit.

Cum notează NeMo Gym agentul

NeMo Gym este o bibliotecă Python a NVIDIA, sub licență Apache 2.0, pentru evaluarea și antrenarea modelelor și a agenților în medii (environments). Un mediu are patru componente:

• setul de sarcini;
• harness-ul, programul care rulează modelul și îi dă acces la unelte, aici Claude Code;
• verificatorul, care notează rezultatul;
• starea fiecărei sarcini.

Fiecare rulare pornește dintr-o stare curată, deci rulările se pot compara între ele. NeMo Gym înregistrează raționamentul modelului, mesajele și fiecare apel de unealtă, ca inginerii să poată reconstitui unde a greșit agentul.

Verificatorul construit de Siemens notează fișierele .lib finale după cinci criterii:

Primele patru criterii din formula de mai jos sunt porți de tip da/nu. Acuratețea este o fracțiune:

Fiecare indicator \mathbf{1}[\cdot] valorează 1 dacă poarta trece și 0 dacă nu. X_{tol} este numărul de valori din toleranță, iar X_{total} numărul total de valori. Dacă o singură poartă pică, nota rulării este zero, oricât de bune ar fi valorile.

Criteriul de integritate are un motiv practic. GF180MCU publică deja fișiere Liberty pentru toate cele 229 de celule, în 15 colțuri PVT. Un agent cu acces la fișiere poate copia sau reformata valori existente în loc să ruleze simulările, iar fără această poartă ar primi o notă bună. Legătura cu PDK-ul public este observația noastră. Este aceeași problemă pe care am descris-o la agenții care repară vulnerabilități: o verificare prea îngăduitoare răsplătește un rezultat care doar trece testul.

Formula schimbă și felul în care se citește media. Scorul de ~55% nu înseamnă neapărat că 55% din valori erau corecte. Un exemplu ipotetic: dacă din 10 rulări 4 pică o poartă și primesc 0, iar celelalte 6 au 92% din valori în toleranță, media este 0,6 × 0,92 = 55%. Același scor îl dau și 10 rulări care trec toate porțile, dar au câte 55% din valori în toleranță. NVIDIA nu publică distribuția notelor, deci nu știm care dintre situații seamănă mai mult cu realitatea.

Ce s-a schimbat la agent

Bucla de lucru descrisă de NVIDIA are șase pași: rulări de bază cu o sarcină și un verificator versionate, citirea traseelor și a apelurilor eșuate, identificarea instrucțiunilor ambigue și a uneltelor alese greșit, corectarea instrucțiunilor și a descrierilor uneltelor, repetarea acelorași sarcini în aceleași condiții și compararea rezultatelor verificate.

Modelul și harness-ul au rămas aceleași în toate rulările: Claude Opus 4.8 în Claude Code. Tabelul NVIDIA se numește chiar „rezultate înainte și după optimizarea harness-ului”. Câștigul nu vine deci dintr-un model mai bun, ci din trei modificări ale interfeței dintre model și unelte:

1. Instrucțiunile agentului (skills), adică fișierele care descriu fluxul de caracterizare și ordinea pașilor. Am explicat mecanismul în articolul despre reguli explicite pentru agenți AI.
2. Descrierile uneltelor MCP. Fuse EDA AI Agent expune uneltele Solido prin servere MCP (Model Context Protocol) pe care le pot folosi Claude Code, Codex sau Cursor. Modelul alege unealta după numele și descrierea ei, deci o descriere vagă duce la apeluri greșite.
3. Uneltele care se suprapuneau au fost simplificate, iar intrările lor au primit scheme JSON explicite.

NVIDIA nu publică uneltele Siemens. Exemplul de mai jos este ipotetic și arată ce înseamnă o schemă explicită. O unealtă generică primește un șir de caractere liber, din care modelul trebuie să ghicească o linie de comandă:

{
  "name": "run",
  "description": "Rulează o comandă în directorul proiectului.",
  "inputSchema": {
    "type": "object",
    "properties": { "command": { "type": "string" } }
  }
}

O unealtă specifică spune exact ce primește și respinge intrările greșite înainte să pornească ore de simulare:

{
  "name": "characterize_cells",
  "description": "Caracterizează în SPICE celulele date, în colțurile PVT date.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "cells": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
      "corners": {
        "type": "array",
        "items": { "type": "string", "pattern": "^(tt|ss|ff)_(n40|025|125)C_[0-9]v[0-9]{2}$" }
      },
      "slew_thresholds_pct": {
        "type": "object",
        "properties": { "lower": { "const": 30 }, "upper": { "const": 70 } },
        "required": ["lower", "upper"]
      }
    },
    "required": ["cells", "corners", "slew_thresholds_pct"]
  }
}

Cu a doua variantă, un colț PVT scris greșit sau un prag de 10% în loc de 30% produc o eroare imediată, la apelul uneltei. Cu prima variantă, aceeași greșeală poate trece neobservată până la verificarea fișierului final, după o oră și jumătate de rulare.

Ce înseamnă 155 → 53 de ture

O tură este un pas al agentului: modelul primește contextul acumulat, răspunde sau cere o unealtă, apoi primește rezultatul. Din cifrele NVIDIA rezultă un detaliu pe care blogul nu îl comentează: numărul de tokeni generați per tură aproape nu s-a schimbat.

Agentul nu a devenit mai concis. A făcut de aproape trei ori mai puțini pași, iar NVIDIA leagă scăderea de alegerea mai bună a uneltelor. Economia vine din pașii eliminați, nu din răspunsuri mai scurte.

Pentru costul total contează și tokenii de intrare, pe care NVIDIA nu îi publică. La fiecare tură, modelul primește din nou tot contextul de până atunci. Dacă promptul inițial are C_0 tokeni și fiecare tură adaugă în medie c tokeni, cele n ture citesc în total aproximativ:

Primul termen scade proporțional cu numărul de ture: 155/53 ≈ 2,9 ori. Al doilea scade aproximativ cu pătratul lui: (155 · 156)/(53 · 54) ≈ 8,4 ori. Reducerea reală a tokenilor de intrare ar fi deci între 2,9 și 8,4 ori, după cât de mult crește contextul de la o tură la alta. Estimarea este a noastră și nu ține cont de memoria cache a promptului sau de compactarea contextului. În comunicatul din 26 iulie, de la conferința DAC 2026, Siemens a anunțat pentru agenții de caracterizare o reducere de 5–10 ori a costului în tokeni. Intervalul se suprapune cu estimarea noastră, dar blogul din octombrie nu publică datele din care să se poată verifica.

Ce nu spune anunțul

• Rezultatele pe toată biblioteca. Fiecare rulare a folosit 2 celule din 229, adică 72 din cele 8 244 de combinații celulă–colț ale setului complet, sub 1%. Pentru biblioteca întreagă nu există rezultate.
• Câte rulări a avut fiecare versiune și cât de mult variază notele. Știm doar că au fost aproximativ 25 de rulări în total, pentru toate rundele de optimizare. Cu atât de puține rulări, o medie de 95% poate ascunde diferențe mari între rulări.
• Toleranța și colțurile PVT. Blogul nu spune ce abatere este acceptată la acuratețe și nici care sunt cele 36 de colțuri. Biblioteca publică GF180MCU are doar 15 colțuri, deci cel puțin o parte din referințe nu provine din PDK. Figura cu fluxul de lucru din blog arată tensiuni de 0,72–0,92 V, tipice nodurilor avansate, în timp ce bibliotecile GF180MCU lucrează între 1,62 și 5,5 V. Figura este o ilustrație, nu o captură din benchmark.
• Ce a adus fiecare modificare. Instrucțiunile, descrierile MCP și schemele JSON au fost schimbate împreună, fără o comparație care să le separe efectele.
• Alte modele. S-a testat doar Claude Opus 4.8. Nu știm dacă aceleași corecturi ajută în aceeași măsură un alt model, inclusiv modelele Nemotron pe care Siemens și NVIDIA le promovează pentru Fuse EDA AI Agent.
• Cine a făcut corecturile. Legenda figurii NVIDIA spune că procesul a fost condus de un agent de programare, „cu un om în buclă”. Cât din corecturi a scris agentul și cât inginerii nu este precizat.
• Mediul și verificatorul. NeMo Gym este open source, dar mediul de caracterizare și verificatorul Siemens nu apar în depozitul public.
• Cifrele de producție. Comunicatul Siemens din iulie promitea un timp de caracterizare de peste 10 ori mai scurt. Blogul din octombrie nu prezintă date despre timp și nici rezultate de la clienți.

Ce merită reținut

1. 95% este un scor compus, nu acuratețe. Orice poartă picată duce nota rulării la zero, iar media de 55% poate însemna fie rulări eșuate, fie valori imprecise.
2. Notează rezultatul final, nu pașii. Fiecare apel de unealtă poate reuși, iar fișierul Liberty final poate fi totuși greșit. Prinde eroarea doar comparația cu o referință.
3. Un fișier valid nu este un fișier corect. Praguri de tranziție greșite dau tabele plauzibile, iar întârzierile negative, care par greșite, pot fi corecte.
4. Interfața uneltelor contează cât modelul. Cu același model, instrucțiuni mai clare, unelte mai puține și scheme JSON explicite au redus turele de la 155 la 53.
5. Economia vine din pașii eliminați. Tokenii generați per tură au rămas în jur de 530. La tokenii de intrare, pe care agentul îi recitește la fiecare tură, economia poate fi și mai mare.
6. Verificatorul trebuie să prindă scurtăturile. Când referințele sunt publice, poarta de integritate împiedică un agent să copieze valori în loc să le calculeze.

Cine vrea să înțeleagă ce modelează o celulă standard găsește bazele în cursul Electronica digitală, iar simulările tranzitorii din care se construiesc tabelele Liberty se pot exersa în cursul Simularea circuitelor electronice cu QSPICE. Despre colaborarea Siemens cu IBM la tranzistoarele stivuite, vezi articolul despre Nanostack.