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

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

In parole semplici, i Processor Driven Tests, o PDT, sono vettori di prova usati nella progettazione del processore via bus e possono essere originati da diversi modelli di processore.

Nel caso del modello funzionale del bus, i test consistono in una sequenza di letture e scritture di vari registri e locazioni di memoria servite dal bus del processore. In questo senso è simile al bench HDL, dove lo schema funzionale del bus coadiuva l'utente nella gestione della complessità dei dettagli del protocollo del bus.

Nel caso di uno schema funzionale completo del processore, invece, i test sono scritti in C o assembly e sono compilati dal processore. Questi test replicano molto accuratamente il funzionamento del processore, fornendo informazioni importanti sulle modalità di uscita dal reset per iniziare la fase di recupero delle informazioni, che si tradurrà nella lettura e scrittura dei registri delle periferiche, eccetera.

Un terzo modello sfrutta lo schema funzionale del bus per generare cicli casuali e forzati di bus. Questo modello è utile per caricare il bus con cicli del processore mentre viene valutata l'abilità degli altri master bus di ottimizzare il loro trasferimento di dati.
Analizziamo in dettaglio il primo di questi modelli.

Processor Driven contro HDL
Qual'è la differenza tra PDT e HDT? Nella figura seguente è riportato un immaginario processore collegato a un banco di prova HDT. Questo inizializza i registri del processore, raccoglie i dati e li confronta con quelli attesi in uscita.

 

Processor Driven vs HDL

 

Viceversa, il PDT analizza il processore in situ, circondato com'è dalle memorie delle sorgenti e di destinazione ed è interfacciato al processore stesso. Il test, scritto in C ed eseguito dalla CPU come codice embedded, carica la memoria sorgente con un'immagine (nell'esempio), inizializza il processore, e attende che l'immagine venga riprodotta in uscita.

È da notare che una volta che il test è stato settato, il progetto funziona così come funzionerebbe nel prodotto finale, leggendo la memoria sorgente, elaborando l'immagine e memorizzando le informazioni nella memoria di destinazione. In questo modo il PDT replica in modo molto accurato tutte le operazioni del processo, testando non solo il processore ma anche il suo interfacciamento con le memorie di ingresso dati e di uscita così come la capacità della CPU di comunicare con ulteriori dispositivi.

PDT

Non è difficile ipotizzare una migrazione di questo test che avviene a livello dei singoli blocchi verso un sottosistema della nostra architettura o a livello SoC. Assumendo che tra l'immagine in memoria e l'immagine nel processore non vengano inserite ulteriori interfacce hardware, il codice C di questi test può essere riutilizzato senza alcun cambiamento a livello SoC o a livello di qualsiasi altro sottosistema.

Vanno però prese alcune precauzioni nel costruire il PDT a livello del singolo blocco quando si abbia l'intenzione di riusarlo a livello SoC o in un prototipo hardware. Se alcuni dettagli della progettazione del sistema di memoria non sono disponibili in fase di progetto del blocco di test, sarà necessario adattare il test alla configurazione della memoria in uscita perché il test stesso possa essere migrato a livello SoC o a livello di un sottosistema.

Anche nel caso i cui i cambiamenti da effettuare fossero di piccola entità, sarebbe comunque arduo dover affrontare migliaia di cambiamenti dei test. Pensare in anticipo all'ambiente finale durante la fase di sviluppo del processore permette in tal caso di ridurre il flusso di riutilizzo dei test.

Post dal 3 dicembre 2008

Scarica subito una copia gratis
Tags:

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend