Approvazione della verifica oltre la copertura

Una visione progettuale comune dell'approvazione della verifica consiste nell'iniziare con un piano di verifica completo, che copra tutti i requisiti definiti tra specifiche e casi d'uso, la definizione dell'architettura e qualsiasi altro documento pertinente. I test vengono quindi sviluppati per coprire ogni caratteristica del piano di verifica. Questi test vengono eseguiti e sottoposti a debug e i problemi identificati vengono risolti all'interno della progettazione. Questo processo viene ripetuto finché non viene raggiunto il livello di copertura concordato. La copertura funzionale è la metrica con cui viene misurato questo processo e funziona bene all'interno del suo ambito. I principali fornitori di EDA (Electronic Design Automation) dispongono di strumenti per eseguire simulazioni, accumulare statistiche sulla copertura e contribuire a far avanzare ulteriormente tali metriche. Ma questa non è l'intera storia in segno di approvazione. La copertura misura la conformità al piano di verifica, che è diversi passaggi rimossi dai requisiti del cliente. Come fanno i progettisti a sapere che le informazioni critiche non sono state eliminate o aggiunte lungo il percorso?

Cos'altro conta in fase di approvazione?

Tutto prima delle specifiche/requisiti funzionali sviluppati internamente è importante. Non è possibile chiudere completamente il cerchio tra i requisiti del cliente e l'implementazione/verifica a meno che questi non siano inclusi nell'analisi. Ora le catene del valore sono compresse e i system-on-chip (SoC) stanno diventando più specifici dell'applicazione. I clienti si aspettano progetti adattati alle loro esigenze esatte, quindi ciò che hanno definito come requisiti deve essere abbinato nell'implementazione/verifica. Non sarà ben accolto se il cliente scopre che ci si aspetta che corregga le mancate corrispondenze.

La sfida qui è che la definizione potrebbe essere un insieme piuttosto misto di input: Word, PDF, documenti basati su DITA, fogli di calcolo, Simulink, SysML o prototipi di modelli virtuali e carichi software che dovrebbero essere eseguiti sull'hardware finale (forse con indennità per alcuni i cambiamenti). Potrebbero esserci anche requisiti documentati in DOORS, Jama Connect o un formato simile. In che modo il team di verifica, il team di progettazione o l'architetto approvano che l'implementazione e la verifica soddisfano i requisiti? Faranno del loro meglio, ovviamente, ma dov'è il processo dettagliato e verificabile per garantire che ogni requisito sia associato a una realizzazione dell'implementazione e che la verifica dell'implementazione sia adeguatamente coperta?

Per renderlo più concreto, supponiamo che ci sia una caratteristica che un cliente importante desidera, ma che nessun altro richiede. Forse per svista o incomprensione, questa caratteristica non rientra nelle specifiche/requisiti funzionali. Succede troppo spesso. Anche l'ideale di una copertura del 100% non coglierà questo problema poiché la copertura è buona quanto il piano di verifica. C'è un grosso problema se il piano di verifica non riflette accuratamente i requisiti.

Oppure supponiamo che durante la progettazione, un team decida di non poter implementare esattamente ciò che le specifiche richiedono, ma venga implementata un'alternativa con la convinzione che sarà altrettanto buona o addirittura migliore. Il team non è a conoscenza del fatto che questa modifica influirà sulle prestazioni in alcuni casi d'uso rari ma importanti. Forse questo sarà catturato nella simulazione? Forse, ma è molto difficile essere completi nei test a livello di sistema. C'è il rischio reale che questo cambiamento problematico sopravviva fino al silicio.

La traccia dei requisiti integra la copertura per l'approvazione della verifica

È probabile che nella nostra vita non sia possibile eseguire il controllo dell'equivalenza tra documenti Word, modelli virtuali e livello di trasferimento dei registri (RTL), ma non è necessario. I costruttori di sistemi e i team di software stanno già utilizzando attivamente la tracciabilità dei requisiti come metodo molto solido per tenere traccia della corrispondenza tra i requisiti di livello superiore e di implementazione, fino alla realizzazione, alla verifica e al test. Questa tracciabilità è supportata con la traccia dei requisiti utilizzando Requirements Interchange Format (ReqIF) con piattaforme come DOORS e strumenti Jama Connect.

Sebbene questi strumenti siano progettati per una facile adozione nel mondo del software, non comprendono la semantica dell'hardware. Supportano i collegamenti di "oggetti estranei" per connettersi ai dati di progettazione e verifica, ma l'onere di eseguire correttamente tali collegamenti ricade sugli ingegneri di progettazione e verifica. Questo potrebbe non essere così male se ci fossero solo poche centinaia di oggetti da tracciare. Ma pensa alla mappa di memoria, alla mappa di interrupt, alla mappa di muxing IO; questi possono essere eseguiti su decine di migliaia di oggetti o più. L'aggiornamento manuale di tutti questi oggetti attraverso modifiche progettuali e ripartizioni diventa estremamente difficile, se non impossibile.

Un approccio migliore è attraverso la gestione della tracciabilità, che può connettersi a strumenti come ReqIF lato cliente e direttamente agli artefatti tracciati dai team di progettazione e verifica. La comprensione della semantica del design consente di dedurre le connessioni tra i requisiti e l'implementazione e di mantenerli tracciati correttamente durante l'evoluzione del progetto. Questo metodo garantisce collegamenti verificabili dalle specifiche del cliente, fino ai requisiti di progettazione e, infine, alla realizzazione del SoC.

Questa è la tracciabilità che può completare l'obiettivo di approvazione della verifica con un basso impatto sui team di progettazione SoC. Il tipo di supporto per la tracciabilità in cui troverai Arteris Harmony Traccia.