EMB 91

EMBEDDED 91 • FEBBRAIO • 2024 58 SOFTWARE | FUNCTIONAL SAFETY senti tutte le condizioni (atomiche) con un salto/istruzio- ne condizionale a livello di codice oggetto. Un caso come questo può essere facilmente evitato seguendo alcune semplici linee guida di codifica riassunte da Lauterbach. Tuttavia, se non si può o non si vuole modificare il codi- ce sorgente di un collega o di un fornitore esterno, i gap sono inevitabili. Il criterio n. 2 è violato, ma i gap di osser- vabilità possono essere colmati mediante una strumenta- zione mirata. La seconda parte di questo articolo fornirà dettagli su questa modalità di strumentazione. D’altro canto, il gran numero di architetture dei core e la relativa diversità di compilatori rappresentano una sfida. Un numero impressionante di core offre la possibilità di generare una traccia del flusso del programma. Ed esiste un gran numero di compilatori, soprattutto per le archi- tetture di core utilizzate più comunemente: il risultato è una grande quantità di possibili abbinamenti architet- tura/compilatore. Non esiste un’euristica generica per mappare le decisioni del codice sorgente in salti/istru- zioni condizionali a livello di codice oggetto in modo tale da ottenere un risultato esatto per ogni possibile abbina- mento. In pratica, TRACE32 deve adattare la mappatura alla combinazione “architettura dei core/compilatore”. Molto, soprattutto per le comuni combinazioni core/com- pilatore, è già personalizzato. Per gli accoppiamenti architettura dei core/compilatore non ancora supportati per i quali l’euristica generica di TRACE32 non fornisce un risultato esatto, non occorre comunque soddisfare il criterio n. 3: Lauterbach offre una strumentazione mirata o addirittura una strumentazione completa come soluzione alternativa per questi casi. 2. Macro Una macro utilizzata in una decisione può contenere di per sé decisioni. Il compilatore espande tutte le macro prima della compilazione e gestisce l’istruzione espansa come un singolo blocco di origine. Durante questo pas- saggio le posizioni nel codice sorgente delle decisioni po- ste all’interno della macro vengono perse. In questo caso è violato il criterio n. 3: non è più possibile una mappatu- ra delle decisioni interne alle macro rispetto ai salti/istru- zioni condizionali. Il gap di osservabilità risultante può essere colmato mediante una strumentazione mirata. 3. Codice altamente ottimizzato Il codice altamente ottimizzato non è consigliato per l’a- nalisi di copertura basata sulla traccia. Per prima cosa, le singole condizioni potrebbero non essere rappresentate da salti/istruzioni condizionali a livello di codice ogget- to. Qui sarebbe violato il criterio n. 2, ma questo può es- sere facilmente risolto con una strumentazione mirata. Inoltre, un codice altamente ottimizzato risulta partico- larmente impegnativo perché potrebbe non essere possi- bile mappare esattamente le decisioni sui salti/istruzioni condizionali: la violazione del criterio n. 3 non può essere risolta in tutti i casi. In tali situazioni si consiglia un’ot- timizzazione moderata. Ciò è vantaggioso anche perché TRACE32 può visualizzare i risultati dell’analisi della co- pertura MC/DC in modo chiaro, intuitivo e leggibile. 4. Limitazioni del protocollo di tracciamento Il set di istruzioni per un’architettura di core può conte- nere istruzioni condizionali. Il compilatore le utilizza per implementare le condizioni del codice sorgente a livello di codice oggetto. Perché la copertura del codice basata sul- la traccia possa funzionare, è necessario che il protocollo di tracciamento utilizzato generi dettagli sull’esecuzione di queste istruzioni condizionali. Sfortunatamente non è sempre così. Ad oggi non esiste alcuna opzione che indi- chi al compilatore di non usare istruzioni condizionali: i gap di osservabilità nel tracciamento dei programmi sono quindi inevitabili. Il criterio n. 4 è violato, ma è possibile utilizzare una strumentazione mirata per colmare i gap. 5. Complessità del set di istruzioni Le sfide descritte nei punti da 1 a 4 sono essenzialmente quelle affrontate dai core con architettura RISC generica. Tuttavia i SoC complessi contengono anche coprocessori e core per scopi speciali per i quali viene generata una traccia di istruzioni. Alcuni esempi sono i DSP, i core con- figurabili con istruzioni definite dall’utente, i timer IP e molti altri. In questi casi TRACE32 deve sempre essere adattato in modo specifico al set di istruzioni per un’ana- lisi della copertura MC/DC. A questo proposito è sempre consigliabile verificare tempestivamente con Lauterbach. Riassumendo quanto descritto finora, per verificare la metrica MC/DC mediante copertura del codice basata su tracce di esecuzione potrebbe essere necessario intro- durre qualche forma di strumentazione del codice sor- gente. Workflow per la copertura MC/DC multimodale Poiché la strumentazione completa è necessaria solo in casi limite, ci concentreremo di seguito sulle due modali- tà di copertura MC/DC standard di TRACE32. • Copertura del codice basata sulla traccia senza stru- mentazione • Copertura del codice basata sulla traccia con stru- mentazione mirata La figura 3 fornisce una panoramica del flusso di lavoro or- ganizzato nelle due fasi: “Processo di creazione” e “Test e reportistica”.