Home
Accesso / Registrazione
 di 

Come utilizzare un banco di prova processor-driven per sistemi SoC 2/2

Come utilizzare un banco di prova processor-driven per sistemi SoC 2/2

Portabilità dei PDT

Primo punto di vista: molti test a livello di blocchi che sono pilotati dal processore possono essere applicati a livello SoC o di un qualsiasi sottosistema con piccole o addirittura nessuna modifica. Questo beneficio è dovuto al fatto che l'interfaccia tra il blocco sottoposto a test e il processore è come se rimanesse inalterato così come succede per il resto dei blocchi attorno ad esso.

Se i registri indirizzabili nel blocco continuano a mantenere le loro vecchie posizioni all'interno della mappa degli indirizzi, lo stesso PDT può essere utilizzato per accedere a livello del blocco e a livello SoC. Questo test è immune, cioè, dai cambiamenti che al contrario possono rendere l'HDT non operativo.

Cambiare un pin o i nomi di alcuni dispositivi, così come le sequenze di accesso e di timing, raramente hanno effetti sulla piattaforma di test PDT. Questo è spiegato dal fatto che la funzione di inizializzazione dell'hardware può essere impattata da cambiamenti al bus control o alla logica di arbitraggio, ma conserva comunque una copia delle funzioni di centinaia di chiamate di test, isolando ogni prova da cambiamenti di inizializzazione hardware.

Un secondo piano di riutilizzo si estende l'ambiente di verifica dalla simulazione al target reale. Dal momento in cui i PDT vengono scritti e compilati come porzioni di codice embedded, questi possono essere utilizzati in ogni rappresentazione completa del processore, sia che essa sia una simulazione sia che corrisponda a un dispositivo fisico. Tutti quei test che trascendono il riferimento al livello fisico o di simulazione sono molto utili in laboratorio perché consentono di scovare bug che a livello di simulazione non possono essere riprodotti e risolti.

Sorgenti di codice per i PDT

Una suite tipica di DPT prevede centinaia di migliaia di piccoli test progettati per validare tutti i blocchi funzionali accesibili attraverso il bus della CPU. Ognuno può partire grazie a una calling di una routine di inizializzazione del processore che va a settare funzioni base della CPU come la MMU, la cache, gli interrupt e gli stack. Una volta che l'inizializzazione è completa, il processore avvia l'esecuzione dei test.

Sebbene questi test siano compilati una volta raggiunto l'obiettivo ed eseguiti in un modello funzionale del processore, molto sviluppatori non li considerano firmware a tutti gli effetti. Essi sono dei semplici blocchi scritti in C e applicati all'hardware da parte della CPU.

Quasi ogni progetto di un sistema embedded ha un team di ingegneri che si occupano di sviluppare e analizzare tutta quella che è la diagnostica hardware. Questi vengono utilizzati prima di passare al silicio in laboratorio, nei test di produzione e un breve loro elenco è spesso fornito con il prodotto come uno strumento di self-test per l'utente finale. La diagnostica dell'hardware rende eccellente un PDT per la simulazione. Poiché questi sono sviluppati a partire dalle specifiche hardware rappresentano un ottimo punto di osservazione per il progetto e spesso rilevano discrepanze o ambiguità nelle specifiche prima della loro implementazione.

PDT

Un'altra eccellente sorgente di test è il codice Boot-ROM. È possibile immaginare a questo come a una elaborata routine di inizializzazione che configura non solo il processore ma anche della logica circostante. Il codice boot deve essere completato con successo prima che vengano posti in esecuzione i driver dei dispositivi, il sistema operativo o altre applicazioni. La sua esecuzione è spesso associata alla visualizzazione nello schermo della scritta “getting a prompt” e la sua esecuzione corretta è considerata uno degli step più importanti nella realizzazione di nuovo hardware.

Gli stessi argomenti legati alla simulazione della diagnostica hardware possono essere associato al codice boot. L'intero progetto beneficia enormemente dal check iniziale di questi tratti di codice e il team dedicato all'hardware è in grado di aggiungere rilevanti routine di verifica con il minimo sforzo. Uno dei maggiori benefici di verifica deriva dal firmware che è altamente interattivo con l'hardware. Quando si innalza il livello di complessità del software, il valore della verifica hardware diminuisce e il runtime di simulazione cresce drammaticamente.

 

 

Scrivi un commento all'articolo esprimendo la tua opinione sul tema, chiedendo eventuali spiegazioni e/o approfondimenti e contribuendo allo sviluppo dell'argomento proposto. Verranno accettati solo commenti a tema con l'argomento dell'articolo stesso. Commenti NON a tema dovranno essere necessariamente inseriti nel Forum creando un "nuovo argomento di discussione". Per commentare devi accedere al Blog

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 1 utente e 27 visitatori collegati.

Utenti online

Ultimi Commenti