Una FIFO si riempie, alcuni campioni vanno persi e sullo schermo resta un eco perfettamente plausibile. Il firmware può ancora superare la soglia e segnalare un’indicazione: il picco esiste, ma l’acquisizione è incompleta. È uno di quei casi in cui elettronica digitale, software embedded e analisi del segnale devono parlare la stessa lingua.
Ho realizzato SLX EchoBench per rendere esplorabile questo problema attraverso un banco a ultrasuoni virtuale. Dietro la scena 3D lavorano un motore C++20, firmware ARM con Eclipse ThreadX, la piattaforma di emulazione Renode e una FIFO descritta in SystemVerilog, eseguita tramite Verilator. Il progetto collega così interfaccia operatore, dati sintetici e verifica congiunta di firmware e logica digitale. La preview Windows su GitHub permette di provarlo offline.
FPGA: costruire il percorso dei dati in logica programmabile
FPGA significa Field-Programmable Gate Array: un circuito integrato le cui risorse logiche e connessioni possono essere configurate dopo la produzione. Registri, memorie e funzioni combinatorie permettono di realizzare percorsi digitali dedicati, con più operazioni attive in parallelo. L’introduzione AMD alla logica programmabile descrive questo principio e il suo impiego nell’elaborazione dei dati.
In una catena di misura, una FPGA può occuparsi di ricevere campioni da un convertitore analogico-digitale, sincronizzare canali, gestire buffer e applicare elaborazioni in pipeline. Il firmware del processore può curare configurazione, gestione degli stati e decisioni di livello superiore. Il confine tra queste responsabilità diventa parte del progetto: quali dati sono pronti, quando possono essere letti e come viene comunicato un errore.
Nel modello EchoBench il campionamento nominale è di 25 milioni di campioni al secondo, un campione ogni 40 ns. Questa scala temporale aiuta a capire perché capacità dei buffer e controllo del flusso siano importanti. Il valore descrive il segnale sintetico; la velocità con cui il PC esegue la demo è una misura diversa.
RTL e SystemVerilog: dare forma al comportamento del circuito
La sigla RTL, Register Transfer Level, indica una descrizione della logica attraverso registri, operazioni e trasferimenti scanditi dal clock. Linguaggi hardware come VHDL, Verilog e SystemVerilog permettono di esprimere questi circuiti. Per portarli su una FPGA servono poi sintesi, implementazione e verifica temporale sul dispositivo scelto.
In EchoBench il blocco RTL è una FIFO sincrona da 256 parole di 16 bit, scritta in SystemVerilog. FIFO significa First In, First Out: il primo dato inserito è il primo disponibile in uscita. Puntatori, occupazione, segnali di disponibilità e contatore dei dati persi costituiscono un esempio piccolo, ma significativo, di un componente usato nei percorsi di acquisizione.
Verilator compila la descrizione Verilog/SystemVerilog in un modello C++ o SystemC eseguibile. EchoBench usa il modello compilato della FIFO in una libreria nativa: reset, scritture, letture e overflow passano attraverso quella logica. Questa verifica riguarda il comportamento RTL; la preview distribuisce il modello eseguibile e non un bitstream per una scheda FPGA fisica.
Dal banco virtuale al segnale a ultrasuoni
La scena riproduce un banco di ispezione con movimentazione della sonda e un provino di riferimento. Il modello implementa una misura pulse-echo a fascio normale: genera l’impulso, gli echi dei riflettori e quello di fondo, collegandoli alla posizione della sonda e ai parametri impostati. Il provino dimostrativo ha uno spessore di 40 mm e tre riflettori noti.
Ogni acquisizione contiene 512 campioni a 25 MS/s, con un impulso nominale di 5 MHz. Guadagno, filtro, rumore, attenuazione e accoppiamento permettono di osservare come cambiano il segnale e la sua utilizzabilità. È un modello acustico sintetico e semplificato, descritto nella documentazione dell’architettura: i risultati valgono entro queste ipotesi e servono a sviluppare e discutere il flusso di elaborazione.
A-scan, B-scan e C-scan: leggere la stessa acquisizione
L’A-scan mostra il segnale nel tempo, in forma RF o come inviluppo. Due finestre temporali, i gate, delimitano le zone di interesse: nella configurazione inclusa, il gate A cerca gli echi interni e il gate B osserva l’eco di fondo. Ampiezza, tempo di volo e spessore stimato restano associati alla posizione e alla configurazione usate per acquisire il punto.
Il B-scan affianca gli inviluppi lungo la passata selezionata; il C-scan colloca sulla superficie campionata ampiezza, spessore o qualità dell’acquisizione. La scansione può essere manuale oppure seguire un raster. L’interfaccia consente di passare dal quadro generale al dettaglio del segnale, fermare la prova e tornare a un punto registrato.
La qualità del dato e l’estensione del percorso campionato sono informazioni distinte. Accoppiamento insufficiente, saturazione e perdita di campioni possono rendere un punto non valutabile. Le mappe descrivono le acquisizioni di superficie del modello; una zona attraversata dalla sonda non costituisce, da sola, una dimostrazione di copertura ultrasonora del volume.
Riferimenti noti e taratura del modello
La vista di riferimento rende visibili i riflettori sintetici presenti nel provino. È utile per collegare ciò che si vede nella geometria all’eco osservato, provare posizioni diverse e discutere le cause di un’indicazione. Il riferimento geometrico conserva così un ruolo esplicito durante la prova.
La sezione Setup & calibration comprende due riferimenti sintetici da 20 e 40 mm, con cui ricavare velocità e offset temporale del modello. Configurazione e taratura vengono conservate insieme ai risultati. Questa funzione permette di verificare il comportamento del software nelle condizioni dichiarate; la taratura di uno strumento fisico richiede riferimenti, procedure e verifiche specifici.
ThreadX e Renode: il firmware dentro la piattaforma virtuale
Eclipse ThreadX è un RTOS, un sistema operativo in tempo reale per applicazioni embedded. Offre thread, schedulazione, sincronizzazione e servizi temporali. In EchoBench un thread di acquisizione legge i campioni e lo stato della periferica, cerca il massimo nel gate e scrive il risultato in un’area di memoria condivisa con l’ambiente di prova.
I due firmware ARM compilati vengono eseguiti da Renode su una piattaforma virtuale Cortex-M3. La piattaforma comprende memoria, timer SysTick e una periferica di acquisizione sviluppata in C#. Il processore accede a registri mappati in memoria, o MMIO: COUNT indica i campioni disponibili, DATA restituisce il campione successivo e FLAGS segnala la perdita di dati.
Nel profilo con RTL, la periferica C# richiama la libreria della FIFO compilata con Verilator. È un collegamento concreto tra istruzioni ARM eseguite, accessi ai registri e comportamento della logica digitale. La guida Renode ai modelli di periferica spiega il meccanismo generale degli accessi sul bus; la documentazione EchoBench descrive il collegamento specifico usato nella demo.
L’esperimento: stesso picco, decisioni diverse
Entrambe le versioni ricevono gli stessi campioni salvati. Nel profilo incluso il gate lavora sui campioni Q15, a 0 dB e senza filtro. La differenza è intenzionale: A ignora la condizione di overflow e può accettare il picco residuo; B verifica la completezza del dato e rifiuta l’acquisizione incompleta. Questo caso rende osservabile un errore di ammissione del dato che potrebbe restare nascosto guardando soltanto l’ampiezza.
Per riprodurre il problema, il profilo ThreadX + Verilator FIFO può tentare di inserire un burst di 512 parole in una FIFO da 256, prima di leggerne il contenuto. Restano 256 parole e 256 tentativi di scrittura vengono conteggiati come perdita. Un picco presente nella parte conservata può quindi sopravvivere al guasto: la versione A lo accetta, mentre B considera anche il flag di perdita e il numero di campioni. Il guasto del modello host ha un contratto separato e scarta 64 campioni.
Il dettaglio dei segnali ready/valid rende il caso utile anche per chi sviluppa FPGA. In ingresso un trasferimento è accettato quando il produttore presenta un dato valido e la FIFO è pronta a riceverlo. La disponibilità permette di regolare il flusso, attraverso la backpressure. Il test di overflow forza invece i tentativi a coda piena e verifica che l’informazione sulla perdita arrivi fino alla decisione del firmware.
L’esecuzione firmware riguarda il singolo ingresso salvato selezionato; la scansione raster e le mappe sono elaborate dal modello host. Il risultato conserva gli hash dell’ingresso, dei firmware e dell’RTL, oltre ai tick ThreadX effettivamente osservati. Tempi e periferiche appartengono alla piattaforma emulata e richiedono una validazione dedicata prima di trarre conclusioni su una scheda fisica.
Godot e C++20: collegare il banco 3D alle elaborazioni
La parte visibile del laboratorio usa Godot 4.5 e GDScript per la scena 3D, i controlli dell’operatore e la consultazione dei risultati. Il banco rende immediato il collegamento tra posizione della sonda, configurazione e segnale: spostare la sonda cambia i dati prodotti dal modello e il contesto con cui leggerli.
Il motore C++20 gestisce modello acustico, elaborazione, sessioni e lavori di emulazione. Interfaccia e motore comunicano mediante un’API locale con messaggi JSON; Renode viene avviato come processo separato, con possibilità di annullare il lavoro. Questa organizzazione permette di mantenere reattivi i comandi mentre si esegue il confronto firmware e di conservare insieme ingresso, configurazione ed esito.
Ripetere la prova e conservare le evidenze
Una sessione salva campioni, pose della sonda, parametri applicati, taratura, eventi e annotazioni. Il replay permette di selezionare un’indicazione o un evento e ritrovare il relativo contesto, senza dover ricreare manualmente la scansione. È un supporto pratico per confrontare una modifica, discutere un caso e documentare il motivo di una decisione.
I report sono esportabili in HTML, JSON e CSV con unità dichiarate. I controlli di integrità e la provenienza delle elaborazioni aiutano a mantenere il legame tra dati e risultati. La documentazione delle verifiche riporta i controlli eseguiti e i limiti delle conclusioni.
Scambio dati: il sottoinsieme NDE 4.4 incluso
EchoBench implementa un mapping documentato del formato NDE 4.4: il dataset pubblico contiene un singolo A-scan grezzo selezionato, con dimensioni 1 × 1 × 512. La sessione nativa completa è conservata nell’estensione del produttore, insieme alle informazioni necessarie per il ripristino.
La validazione comprende gli schemi ufficiali e la verifica del recupero esatto dei campioni e della sessione. Importazione ed esportazione riguardano questo specifico mapping SLX. L’integrazione con file di strumenti diversi, dataset volumetrici o DICONDE richiede adattatori e prove di interoperabilità dedicati.
Come provare la preview Windows
Per una prima prova, scarica il pacchetto portatile Windows x64 dalla release v0.1.0-preview, estrai l’intero archivio e avvia EchoBench.exe, mantenendo accanto le cartelle e le risorse incluse. La visita guidata presenta il banco; Technical analysis apre segnali e mappe; Evidence & replay raccoglie sessioni e confronto firmware.
La repository GitHub slx-echobench comprende interfaccia Godot/GDScript, contratti API, documentazione ed esempi. Il motore C++20 proprietario è distribuito come SDK binario. Il progetto è fornito con Silicon LogiX Evaluation License 1.0; finalità di valutazione e condizioni d’uso sono indicate nella licenza.
Dalla demo a un progetto su misura
EchoBench offre una base concreta per discutere requisiti di acquisizione, gestione degli errori, interfaccia operatore e riproducibilità dei test. Il passaggio a un sistema industriale parte dai dati reali, dalla catena di misura e dalle condizioni di accettazione del cliente.
Le attività su commessa possono comprendere firmware e driver, logiche FPGA e percorsi di acquisizione, software desktop, collegamento a strumenti, banchi hardware-in-the-loop e integrazioni con sistemi di produzione. Tecniche come PAUT, TFM e TOFD, modelli acustici qualificati, robotica e analisi AI richiedono sviluppi e validazioni specifici e sono estensioni da definire nel progetto.
Stai sviluppando un sistema di acquisizione o un banco di ispezione? Descrivimi il progetto: tipo di sonda o sensore, elettronica disponibile, frequenza di campionamento, formato dei dati e caso critico da riprodurre. Sono gli elementi da cui partire per impostare una prova utile e misurabile.
Domande frequenti
Serve una sonda o una scheda FPGA per provare EchoBench?
La preview inclusa funziona offline su Windows x64 con un banco e segnali sintetici. Firmware e FIFO RTL vengono eseguiti nell’ambiente virtuale distribuito con il pacchetto.
Il programma può qualificare un’ispezione su un pezzo reale?
La demo serve a esplorare e verificare il flusso software entro il modello dichiarato. La qualificazione di una procedura NDT, la risposta dei difetti reali e la taratura dello strumento richiedono prove fisiche e criteri dedicati.
Il confronto A/B esegue davvero il firmware?
Sì. Il comando di esecuzione firmware avvia i binari ARM ThreadX in Renode sul punto salvato selezionato. È disponibile anche un confronto separato tra i processori del modello host; l’interfaccia distingue i due percorsi.
Posso importare qualsiasi file .nde?
La versione iniziale importa i file che rispettano il mapping SLX del singolo A-scan NDE 4.4. Altri produttori e altre organizzazioni dei dati richiedono una verifica di compatibilità e un adattatore.
Riferimenti tecnici e approfondimenti
Per approfondire le tecnologie e ripercorrere le scelte del progetto, questi sono i riferimenti ufficiali e i documenti della preview:
- AMD — The Programmable Logic Advantage: introduzione a FPGA, logica programmabile e architetture riconfigurabili, pagina 5 del documento.
- Verilator — Overview: dalla descrizione Verilog/SystemVerilog al modello compilato eseguibile.
- Eclipse ThreadX RTOS: progetto ufficiale, servizi del kernel e port per le architetture embedded.
- Renode — Peripheral modeling guide: periferiche virtuali, registri e accessi del processore al bus.
- Renode — Co-simulating with an HDL simulator: approfondimento sulle integrazioni tra piattaforme emulate e modelli HDL.
- Godot 4.5 — Introduction to Godot: motore 2D/3D, applicazioni e linguaggi supportati.
- NDE 4.4 e mapping NDE di EchoBench: formato di scambio e sottoinsieme effettivamente implementato.
- Architettura EchoBench, API locale e verifiche e limiti: contratti, responsabilità dei componenti e condizioni delle prove.
