ITVI20100208A1 - Metodo¿e sistema di simulazione atti alla simulazione di una piattaforma hardware a componenti multipli - Google Patents

Description

“METODO E SISTEMA DI SIMULAZIONE ATTI ALLA SI-MULAZIONE DI UNA PIATTAFORMA HARDWARE A COMPONENTI MULTIPLIâ€

Descrizione

Campo dell’invenzione

L’invenzione à ̈ relativa a un metodo per simulare una piattaforma hardware multicore. L’invenzione fornisce un metodo per simulare una piattaforma hardware multicore comprendente una pluralità di dispositivi, in cui ciascun dispositivo può essere modellato come modello funzionale o come modello basato su cicli. L’invenzione definisce una simulazione comprendente modelli funzionali o modelli basati su cicli in cui i modelli funzionali sono in grado di includere un tempo di esecuzione nella risposta a una transazione.

Stato della tecnica

Piattaforme hardware multicore sono utilizzate nella maggior parte degli apparecchi elettronici, per esempio in un ambiente privato o professionale che necessita di un’elevata quantità di potenza di elaborazione. Apparecchi per piattaforme hardware multicore possono essere dispositivi dedicati che funzionano, per esempio in un dispositivo multimediale autonomo (standalone) (per esempio un lettore DVD, un lettore blu Ray o un videoregistratore a disco rigido), una tv, un sistema HIFI multicanale, un dispositivo di collegamento in rete, un telefono cellulare, un assistente digitale personale (personal digital assistant - PDA) e un lettore MP3, o dispositivi per scopi generici come computer e simili. Tali apparecchi richiedono una pluralità di funzionalità che possono essere realizzate mediante la piattaforma hardware che collega diversi dispositivi o blocchi IP con una funzionalità speciale attraverso una connessione di dati di tipo bus o punto a punto. Di conseguenza, il flusso di dati e/o di istruzioni tra i diversi dispositivi o i blocchi IP à ̈ essenziale per il funzionamento di tutto l’apparecchio.

Durante la fase di progettazione di tale apparecchio, viene utilizzata una piatta forma di simulazione per convalidare e verificare la funzionalità e per valutare le prestazioni della piattaforma hardware. Per di più, la simulazione può essere inoltre utilizzata durante la fase di test per confrontare il risultato simulato con i risultati prodotti mediante un’implementazione della piattaforma hardware. Ci sono inoltre altre combinazioni vantaggiose di una simulazione e di un’implementazione hardware, per esempio quando la funzionalità di un dispositivo viene eseguita solo mediante la simulazione e gli altri dispositivi, con i quali comunica il primo dispositivo, sono già prototipi implementati mediante hardware.

Una piattaforma hardware combina una pluralità di dispositivi (hardware) o blocchi IP. Di conseguenza, in un chip, di solito vengono combinati dispositivi multipli o blocchi IP. Ciò nondimeno, dispositivi o blocchi IP possono essere inoltre realizzati come chip separati. Per esempio, in una configurazione a chip multipli, la comunicazione tra i chip che rappresentano un dispositivo o un blocco IP può essere realizzata attraverso fili elettrici su una scheda a circuito stampato.

Al fine di distinguere i ruoli di un dispositivo o di un blocco IP, può essere utilizzato il modello di transazione. Una transazione si riferisce a un’operazione da effettuare mediante due dispositivi o IP. Un primo dispositivo avvia la transazione e, dunque, à ̈ chiamato IP master. Il secondo dispositivo semplicemente risponde alla transazione e, di conseguenza, à ̈ chiamato IP slave. La risposta dello IP slave può richiedere l’esecuzione di alcuni calcoli da parte dello IP slave. Gli IP master possono per esempio essere: CPU (central processing unit - unità di elaborazione centrale), DMA (Direct Memory Access - accesso diretto in memoria), acceleratori hardware e simili. Gli IP slave collegati a tali iniziatori di tran sazione o IP master sono per esempio: bus di comunicazione, interfacce di rete, memorie, cache e simili. Tipicamente, un IP master à ̈ collegato a diversi IP slave per formare un sottosistema. Tuttavia, un IP slave può anche essere condiviso tra diversi IP master.

Inoltre, esiste il caso aggiuntivo di un dispositivo o blocco IP avente il ruolo di IP slave per quanto riguarda una transazione e il ruolo di IP master per una transazione diversa. Questa eccezione si presenta quando il dispositivo o blocco IP dipende da un dispositivo o blocco IP differente per fornire informazioni aggiuntive. Per esempio, una cache può dipendere da una memoria, se i dati non sono disponibili nella cache stessa. Tuttavia, dato che l’accesso alla memoria à ̈ gestito dalla cache in modo trasparente per la CPU, la cache svolge il ruolo di IP slave per la CPU e il ruolo di IP master per la memoria. Di conseguenza, i due termini possono anche essere utilizzati per lo stesso dispositivo o blocco IP come nel presente esempio.

Per la simulazione della piattaforma hardware descritta sopra, ciascun dispositivo o blocco IP à ̈ rappresentato da un modello. In questo modo, la simulazione à ̈ in grado di descrivere il flusso di transazioni tra dispositivi o blocchi IP. Di conseguenza, non solo i dati in uscita della simulazione possono essere utilizzati per convalidare o per verificare il progetto della piattaforma hardware ma anche le transazioni virtuali eseguite tra i modelli rappresentano la comunicazione tra un dispositivo o blocco IP. Di conseguenza, una simulazione con una pluralità di modelli, in cui ciascun modello rappresenta un dispositivo o blocco IP à ̈ vantaggiosa per una riproduzione precisa del comportamento della piattaforma hardware.

In una simulazione, si può distinguere tra due tipi diversi di modelli, per la preci sione un modello funzionale e un modello basato su cicli. Il modello funzionale riproduce solo la funzionalità di un dispositivo o blocco IP, tralasciando l’implementazione di dettagli pertinenti (per esempio informazioni sullo stato interno, una rappresentazione dei cicli di clock, una velocità di esecuzione predefinita). Il modello funzionale à ̈ in grado di rispondere a una transazione con un output. In particolare, il modello funzionale risponde istantaneamente a un iniziatore della transazione. La concezione di modelli funzionali à ̈ semplice dato che l’implementazione consiste di solito solo in una mappatura statica degli input verso gli output. Tuttavia, se la mappatura non à ̈ statica (per esempio dipendente dall’aspetto funzionale), la concezione del modello funzionale à ̈ più complessa. Il modello basato su cicli viene impiegato per la riproduzione dello stato osservabile di un dispositivo o blocco IP in ogni ciclo. Di solito, un modello basato su cicli non ha un comportamento deterministico, il che significa che non si à ̈ conoscenza del risultato di una transazione quando la transazione viene iniziata. Un modello basato su cicli à ̈ concepito comunemente per raccogliere per prima cosa tutte le informazioni riguardanti la transazione e poi realizzare il progresso della transazione fino al completamento. Di conseguenza, una transazione viene completata in una serie di fasi che sono temporizzate in maniera corrispondente a una certa frequenza di clock. Di conseguenza, per ciascun ciclo di clock, il modello basato su cicli modifica il suo stato interno avanzando con la transazione. Di conseguenza, un modello basato su cicli può fornire una rappresentazione precisa (relativamente ai cicli di clock) del comportamento di un dispositivo hardware che implementa un dispositivo o blocco IP.

Come si può vedere da quanto precede, ciascuno dei due approcci di modellazione presenta una strategia di concezione intrinseca che può essere impiegata in modo vantaggioso in diverse simulazioni. In particolare, una simulazione costituita da modelli funzionali mostra una velocità di simulazione elevata ed à ̈ più facile da sviluppare, tuttavia à ̈ carente in termini di precisione a confronto con una simulazione basata su cicli. Al contrario, una simulazione costituita da modelli basati su cicli à ̈ più precisa, tuttavia di solito presenta una velocità di simulazione inferiore ed à ̈ più complessa da sviluppare.

Di conseguenza, considerando i vantaggi e gli svantaggi della simulazione funzionale e della simulazione basata su cicli, entrambe le simulazioni possono essere impiegate in modo vantaggioso in diverse fasi del processo di concezione di una piattaforma hardware. Di solito, i modelli funzionali vengono usati in una fase di progetto precedente dato che i modelli funzionali vengono sviluppati più velocemente. Durante la fase di test à ̈ di solito necessaria una maggiore precisione, e così ogni modello deve essere riscritto per presentare un comportamento basato su cicli.

È noto che la libreria di simulazione SystemC fornisce un motore di simulazione per una progettazione hardware e software congiunta. Comunemente, il linguaggio SystemC à ̈ utilizzato per la modellazione di processi temporizzati, per la precisione mediante un motore di simulazione che programma ciascun processo secondo requisiti temporali predefiniti. Inoltre, il linguaggio SystemC consente anche la definizione di processi che sono simili a modelli funzionali, dato che i processi non sono continuamente innescati secondo cicli di clock predefiniti. In una simulazione contenente solo blocchi che definiscono processi, l’ordine di esecuzione della simulazione à ̈ determinato dalla sequenza secondo la quale le informazioni sono trasmesse tra i processi.

La combinazione di entrambi i tipi di modelli in una simulazione dà come risulta to una simulazione a cicli non precisi. Per di più, quando si simulano transazioni concorrenti, misure di precauzione aggiuntive sono necessarie per assicurare che ciascun blocco funzioni secondo la temporizzazione di simulazione corretta. Per questo scopo, SystemC fornisce il concetto di operazioni di wait(). In questo modo, l’output di un modello funzionale può essere posticipato per un numero variabile di cicli di simulazione allo scopo di evitare incoerenze di dati per transazioni concorrenti. Di conseguenza, un blocco di processo con un’operazione di wait() si comporta da fuori come modello basato su cicli, solo con la differenza che il blocco implementa un modello funzionale.

Una descrizione dettagliata su SystemC à ̈ fornita, per esempio, in IEEE Std 1666â„¢-2005, “IEEE Standard SystemC® Language Reference Manual†, versione 2.1, marzo 2006 (disponibile all’indirizzo http://www.ieee.org qui acclusa a scopo di riferimento).

Anche se l’implementazione descritta in quanto precede nel linguaggio SystemC consente la combinazione di modelli funzionali e basati su cicli, l’implementazione di modelli funzionali con un’operazione di wait() comporta alcuni svantaggi. A motivo dell’operazione di wait(), il modello funzionale diviene dipendente dal motore di simulazione per la schedulazione degli output, e la risposta di un modello funzionale viene ritardata dall’operazione di wait() con un conseguente allungamento del tempo di simulazione complessivo.

Sommario dell’invenzione

Uno scopo dell’invenzione consiste nel proporre un nuovo approccio di simulazione per simulare una piattaforma hardware multicore che migliori la velocità di simulazione mantenendo allo stesso tempo la precisione di simulazione relativa a una simulazione della stessa piattaforma hardware i cui dispositivi sono modella ti solamente come modelli basati su cicli.

Un altro scopo dell’invenzione consiste nell’abilitare l’utilizzo di modelli funzionali in una simulazione a cicli precisi in cui i modelli funzionali mantengono ancora le proprietà funzionali (vale a dire rispondere immediatamente a una transazione).

Un ulteriore scopo dell’invenzione consiste nel consentire una combinazione flessibile di modelli funzionali e modelli basati su cicli all’interno di una simulazione.

Lo scopo viene risolto mediante l’oggetto delle rivendicazioni indipendenti. Forme di realizzazione vantaggiose dell’invenzione sono soggette alle rivendicazioni dipendenti.

Modelli funzionali sono in grado di rispondere immediatamente a un modello che inizia la transazione. Di conseguenza, sostituendo un modello basato su cicli con un modello funzionale à ̈ possibile velocizzare l’esecuzione della simulazione. Tuttavia, modelli funzionali non possono essere utilizzati all’interno di una simulazione a cicli precisi in cui i cicli nella simulazione devono corrispondere ai cicli della piattaforma hardware simulata. Di conseguenza, un primo aspetto dell’invenzione estende modelli puramente funzionali a modelli funzionali temporizzati in grado di includere un tempo di transazione nella risposta a una transazione. Il tempo di transazione restituito indica il ritardo che sarebbe stato introdotto dal dispositivo (hardware) che risponde alla transazione. Con il tempo di transazione il risultato della transazione di un modello funzionale può essere temporizzato in maniera precisa allineando e/o ritardando i risultati della simulazione rispetto al clock principale della simulazione. Rispetto a una simulazione della stessa piattaforma hardware in cui i dispositivi sono solamente descritti mediante modelli basati su cicli (e presupponendo lo stesso livello di precisione dei modelli), il primo aspetto dell’invenzione consente una maggiore velocità di simulazione a motivo dei modelli funzionali che rispondono immediatamente con una stessa precisione temporale. Inoltre, presupponendo una descrizione a cicli precisi di un dispositivo modellato come modello funzionale, il fornire un tempo di transazione consente al modello funzionale di essere utilizzato in una simulazione a cicli precisi.

Un secondo altro aspetto dell’invenzione consiste nel suggerire la modifica del modello funzionale in modo tale che fornisca le stesse informazioni temporali di un modello basato su cicli. Secondo questo secondo aspetto, il modello funzionale à ̈ in grado di rispondere immediatamente a una transazione con un risultato e un conteggio dei cicli che indicano quanto avrebbe impiegato il dispositivo (hardware) per l’elaborazione della transazione. In altre parole, il modello funzionale dell’invenzione à ̈ in grado di fornire informazioni sufficienti per un modello a cicli precisi che agisce da iniziatore della transazione in modo tale che l’iniziatore della transazione possa allineare e/o ritardare l’elaborazione delle informazioni ricevute per una simulazione a cicli precisi.

In una forma di realizzazione esemplificativa secondo il primo e il secondo aspetto dell’invenzione, il modello funzionale fornisce un tempo di esecuzione sotto forma di approssimazione del tempo di transazione che sarebbe stato necessario per il dispositivo (hardware) rappresentato per eseguire l’operazione richiesta attraverso la transazione.

Un ulteriore terzo aspetto della presente invenzione suggerisce la modifica del modello funzionale in modo tale che il modello basato su cicli e il modello funzionale vengano utilizzati in modo interscambiabile nella simulazione. In altre parole, il terzo aspetto della presente invenzione suggerisce l’adattamento del modello funzionale e del modello basato su cicli in modo tale che entrambi i tipi di modelli implementino la stessa interfaccia. In questo modo, il motore di simulazione può commutare tra un modello funzionale che indica il tempo di transazione e un modello basato su cicli a seconda di uno stato interno del sistema di simulazione. Alternativamente, il terzo aspetto della presente invenzione suggerisce un modello per implementare sia un comportamento funzionale sia un comportamento basato su cicli per un’operazione. In questo modo, il motore di simulazione à ̈ inoltre abilitato a determinare il comportamento del modello a seconda di uno stato interno del sistema di simulazione.

Una forma di realizzazione dell’invenzione fornisce un metodo implementato mediante computer per simulare una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale o da un modello basato su cicli. Il sistema di simulazione simula la piattaforma hardware avviando una transazione tramite un modello che assume il ruolo di modello master per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, eseguendo l’operazione richiesta mediante il modello slave, e rispondendo alla transazione mediante il modello slave restituendo un risultato dell’operazione eseguita al modello master. Nel caso in cui il modello slave sia un modello funzionale, il modello slave nella simulazione à ̈ adattato per eseguire l’operazione richiesta dalla transazione e rispondere immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione. Il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione.

In un’implementazione esemplificativa, un motore di simulazione del metodo implementato mediante computer programma l’esecuzione dell’operazione richiesta dalla transazione e la risposta a essa rispetto ai cicli di un clock principale, nel caso in cui il modello slave sia un modello basato su cicli.

Per di più, i modelli basati su cicli possono definire diversi cicli di esecuzione. Per esempio, ciascun modello basato su cicli presenta un ciclo predefinito TCche à ̈ un numero intero multiplo del ciclo TMdel clock principale. Il motore di simulazione programma l’esecuzione di un’operazione richiesta da una transazione e la risposta a essa per ciascuno dei modelli basati su cicli in relazione al rispettivo ciclo TC.

Il modello master può essere un modello master basato su cicli. In questo caso, a seguito della ricezione della risposta alla transazione comprendente il risultato e le informazioni sul tempo di esecuzione, il modello master viene sospeso per un numero di cicli del clock principale che corrisponde al tempo di esecuzione indicato nelle informazioni ricevute.

In un’altra forma di realizzazione esemplificativa dell’invenzione, il modello master à ̈ un modello funzionale e il modello master assume il ruolo di modello slave per un altro modello master che rappresenta un dispositivo della piattaforma hardware simulata, detto altro modello master iniziando un’altra transazione per richiedere l’esecuzione di un’operazione da parte del modello master. In questo caso, a seguito della ricezione della risposta alla transazione comprendente il risultato e le informazioni sul tempo di esecuzione, il modello master esegue l’operazione richiesta da detta altra transazione e risponde immediatamente a essa restituendo il risultato dell’esecuzione della diversa operazione e la somma del numero di cicli ricevuto e del numero di cicli stimato associati all’esecuzione dell’operazione come informazione sul tempo di esecuzione.

In un miglioramento esemplificativo, il motore di simulazione à ̈ adattato per programmare l’esecuzione di un’operazione richiesta da una transazione e una risposta a essa per ciascuno dei modelli basati su cicli a diversi punti temporali all’interno di un ciclo del clock principale.

In un’altra implementazione esemplificativa, il risultato restituito da un modello slave come risposta a una transazione che richiede l’esecuzione di un’operazione indica uno dei seguenti stati: lo stato COMPLETED (completato), in cui l’operazione viene completata con successo; lo stato PENDING (sospeso), in cui l’operazione à ̈ sospesa; e lo stato ERROR (errore), in cui l’esecuzione dell’operazione dà come risultato un errore.

In un altro miglioramento esemplificativo, il motore di simulazione à ̈ adattato per sospendere un modello master dopo che il modello master ha ricevuto come risposta a una transazione che richiede l’esecuzione di un’operazione di un modello slave un risultato indicante uno stato PENDING.

Un’altra forma di realizzazione alternativa dell’invenzione fornisce inoltre un metodo implementato mediante computer per simulare una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato sia da un modello funzionale che da un modello basato su cicli. Il modello funzionale e il modello basato su cicli hanno un’interfaccia comune. Il sistema di simulazione simula la piattaforma hardware avviando una transazione mediante un modello che assume il ruolo di modello master per richiedere l’esecuzione di un’operazione da parte di uno tra il

modello funzionale e il modello basato su cicli che rappresentano lo stesso dispositivo della piattaforma hardware, determinando secondo uno stato interno del sistema di simulazione quale dei due modelli viene utilizzato in qualità di modello slave per il dispositivo; eseguendo l’operazione richiesta mediante il modello slave determinato, e rispondendo alla transazione mediante il modello slave restituendo un risultato dell’operazione eseguita al modello master.

Un’ulteriore forma di realizzazione alternativa dell’invenzione fornisce inoltre un metodo implementato mediante computer che simula una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato da un modello che comprende un’implementazione basata su cicli di un’operazione e un’implementazione funzionale della stessa operazione. Il sistema di simulazione simula la piattaforma hardware avviando una transazione mediante un modello che assume il ruolo di modello master per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, il modello slave comprendendo un’implementazione basata su cicli dell’operazione richiesta e un’implementazione funzionale della stessa operazione, determinando secondo uno stato interno del sistema di simulazione quale delle due implementazioni à ̈ utilizzata dal modello slave per eseguire l’operazione richiesta; eseguendo l’implementazione determinata dell’operazione richiesta mediante il modello slave, e rispondendo alla transazione mediante il modello slave restituendo un risultato dell’operazione eseguita al modello master.

In un’ulteriore forma di realizzazione esemplificativa, il modello slave nella si mulazione à ̈ adattato per eseguire l’operazione richiesta dalla transazione e per rispondere immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione, nel caso in cui il modello slave sia un modello funzionale. Il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione.

Una forma di realizzazione alternativa ulteriore dell’invenzione à ̈ relativa a un programma informatico per eseguire una simulazione di una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale o da un modello basato su cicli. Il programma informatico quando viene eseguito su un processore simula la piattaforma hardware facendo sì che un modello assuma il ruolo di modello master per iniziare una transazione per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, facendo sì che il modello slave esegua l’operazione richiesta, e facendo sì che il modello slave risponda alla transazione restituendo un risultato dell’operazione eseguita al modello master. Nel caso in cui il modello slave sia un modello funzionale, il modello slave esegue l’operazione richiesta dalla transazione e risponde immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione. Il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione.

Il supporto di dati leggibile mediante computer secondo una forma di realizzazione esemplificativa dell’invenzione memorizza istruzioni che, quando sono eseguite da un processore di un sistema di simulazione, fanno sì che il sistema di simulazione simuli una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale o da un modello basato su cicli. Le istruzioni fanno sì che il sistema di simulazione simuli la piattaforma hardware mediante un modello che assume il ruolo di modello master che inizia una transazione per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, mediante il modello slave che esegue l’operazione richiesta, e mediante il modello slave che risponde alla transazione restituendo un risultato dell’operazione eseguita al modello master. Nel caso in cui il modello slave sia un modello funzionale, il modello slave esegue l’operazione richiesta dalla transazione e risponde immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione. Il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione. Un’altra forma di realizzazione esemplificativa dell’invenzione fornisce un sistema di simulazione comprendente un processore che fa sì che il sistema di simulazione simuli una piattaforma hardware multicore comprendente una pluralità di dispositivi, e una memoria per memorizzare risultati di simulazione intermedi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale o da un modello basato su cicli. Il sistema di simulazione simula la piattaforma hardware mediante un modello che assume il ruolo di modello master che inizia una transazione per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, mediante il modello slave che esegue l’operazione richiesta, e mediante il modello slave che risponde alla transazione restituendo un risultato dell’operazione eseguita al modello master. Nel caso in cui il modello slave sia un modello funzionale, il modello slave esegue l’operazione richiesta dalla transazione e risponde immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione. Il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione.

Una forma di realizzazione alternativa ulteriore dell’invenzione à ̈ relativa a un programma informatico per eseguire una simulazione di una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato sia da un modello funzionale sia da un modello basato su cicli. Il modello funzionale e il modello basato su cicli hanno un’interfaccia comune. Il programma informatico quando viene eseguito su un processore simula la piattaforma hardware facendo sì che un modello assuma il ruolo di modello master per iniziare una transazione per richiedere l’esecuzione di un’operazione da parte di uno tra il modello funzionale e il modello basato su cicli che rappresentano lo stesso dispositivo della piattaforma hardware, facendo sì che il processore determini secondo uno stato interno del sistema di simulazione quale dei due modelli viene utilizzato in qualità di modello slave per il dispositivo; facendo sì che il modello slave determinato esegua l’operazione richiesta, e facendo sì che il modello slave risponda alla transazione restituendo un risultato dell’operazione eseguita al modello master.

Il supporto di dati leggibile mediante computer secondo una forma di realizzazione esemplificativa dell’invenzione memorizza istruzioni che, quando sono eseguite da un processore di un sistema di simulazione, fanno sì che il sistema di simulazione simuli una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato sia da un modello funzionale che da un modello basato cicli. Il modello funzionale e il modello basato su cicli hanno un’interfaccia comune. Le istruzioni fanno sì che il sistema di simulazione simuli la piattaforma hardware mediante un modello che assume il ruolo di modello master che inizia una transazione per richiedere l’esecuzione di un’operazione da parte di uno tra il modello funzionale e il modello basato su cicli che rappresentano lo stesso dispositivo della piattaforma hardware, mediante il processore che determina secondo uno stato interno del sistema di simulazione quale dei due modelli viene utilizzato in qualità di modello slave per il dispositivo; mediante il modello slave determinato che esegue l’operazione richiesta, e mediante il modello slave che risponde alla transazione restituendo un risultato dell’operazione eseguita al modello master.

Un’altra forma di realizzazione esemplificativa dell’invenzione fornisce un sistema di simulazione comprendente un processore che fa sì che il sistema di simulazione simuli una piattaforma hardware multicore comprendente una pluralità di dispositivi e una memoria per memorizzare risultati di simulazione intermedi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato sia da un modello funzionale sia da un modello basato cicli. Il modello funzionale e il modello basato su cicli hanno un’interfaccia comune. Il sistema di simulazione simula la piattaforma hardware mediante un mo dello che assume il ruolo di modello master che inizia una transazione per richiedere l’esecuzione di un’operazione da parte di uno tra il modello funzionale e il modello basato su cicli che rappresentano lo stesso dispositivo della piattaforma hardware, mediante il processore che determina secondo uno stato interno del sistema di simulazione quale dei due modelli viene utilizzato in qualità di modello slave per il dispositivo; mediante il modello slave determinato che esegue l’operazione richiesta, e mediante il modello slave che risponde alla transazione restituendo un risultato dell’operazione eseguita al modello master.

Un’ulteriore forma di realizzazione alternativa dell’invenzione à ̈ relativa a un programma informatico per eseguire una simulazione di una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato da un modello che comprende un’implementazione basata su cicli di un’operazione e un’implementazione funzionale della stessa operazione. Il programma informatico, quando viene eseguito su un processore, simula la piattaforma hardware facendo sì che un modello assuma il ruolo di modello master per iniziare una transazione per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, il modello slave comprendendo un’implementazione basata su cicli dell’operazione richiesta e un’implementazione funzionale della stessa operazione, facendo sì che il processore determini secondo uno stato interno del sistema di simulazione quale delle due implementazioni à ̈ utilizzata dal modello slave per eseguire l’operazione richiesta; facendo sì che il modello slave esegua l’implementazione determinata dell’operazione richiesta, e facendo sì che il modello slave risponda alla transa zione restituendo un risultato dell’operazione eseguita al modello master.

Il supporto di dati leggibile mediante computer secondo una forma di realizzazione esemplificativa dell’invenzione memorizza istruzioni che, quando sono eseguite da un processore di un sistema di simulazione, fanno sì che il sistema di simulazione simuli una piattaforma hardware multicore comprendente una pluralità di dispositivi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato da un modello che comprende un’implementazione basata su cicli di un’operazione e un’implementazione funzionale della stessa operazione. Le istruzioni fanno sì che il sistema di simulazione simuli la piattaforma hardware mediante un modello che assume il ruolo di modello master che inizia una transazione per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, il modello slave comprendendo un’implementazione basata su cicli dell’operazione richiesta e un’implementazione funzionale della stessa operazione, mediante il processore che determina secondo uno stato interno del sistema di simulazione quale delle due implementazioni à ̈ utilizzata dal modello slave per eseguire l’operazione richiesta; mediante il modello slave che esegue l’implementazione determinata dell’operazione richiesta, e mediante il modello slave che risponde alla transazione restituendo un risultato dell’operazione eseguita al modello master.

Un’altra forma di realizzazione esemplificativa dell’invenzione fornisce un sistema di simulazione comprendente un processore che fa sì che il sistema di simulazione simuli una piattaforma hardware multicore comprendente una pluralità di dispositivi, e una memoria per memorizzare risultati di simulazione in termedi. Ciascun dispositivo à ̈ rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli. Almeno un dispositivo della piattaforma hardware à ̈ rappresentato da un modello che comprende un’implementazione basata su cicli di un’operazione e un’implementazione funzionale della stessa operazione. Il sistema di simulazione simula la piattaforma hardware mediante un modello che assume il ruolo di modello master che inizia una transazione per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, il modello slave comprendendo un’implementazione basata su cicli dell’operazione richiesta e un’implementazione funzionale della stessa operazione, mediante il processore che determina secondo uno stato interno del sistema di simulazione quale delle due implementazioni à ̈ utilizzata dal modello slave per eseguire l’operazione richiesta; mediante il modello slave che esegue l’implementazione determinata dell’operazione richiesta, e mediante il modello slave che risponde alla transazione restituendo un risultato dell’operazione eseguita al modello master.

Breve descrizione dei disegni

In quanto segue l’invenzione à ̈ descritta in maggiore dettaglio facendo riferimento alle figure e ai disegni allegati. Dettagli simili o corrispondenti nelle figure sono indicati con gli stessi numeri di riferimento.

La Figura 1 mostra schematicamente un esempio di una piattaforma multicore e un sistema di simulazione da utilizzare per la simulazione secondo una forma di realizzazione esemplificativa dell’invenzione,

La Figura 2 mostra schematicamente una piattaforma multicore semplificata con dispositivi condivisi secondo una forma di realizzazione esemplificativa dell’invenzione,

La Figura 3 illustra un esempio semplificato di una piattaforma hardware avente un solo iniziatore secondo una forma di realizzazione esemplificativa dell’invenzione,

Le figure 4a e 4b mostrano schematicamente un’interfaccia esterna per una transazione di un modello master e di un modello slave secondo una forma di realizzazione esemplificativa dell’invenzione,

La Figura 5 illustra una procedura esemplificativa per un modello slave basato su cicli per rispondere a una transazione secondo una forma di realizzazione esemplificativa dell’invenzione,

La Figura 6 mostra un diagramma temporale esemplificativo di un’operazione “cache-miss†semplificata di una cache di istruzioni che assume il ruolo di modello master e di modello slave secondo una forma di realizzazione esemplificativa dell’invenzione,

La Figura 7 mostra schematicamente la sequenza di operazioni da effettuare mediante un modello master a seguito della ricezione di una risposta a una transazione secondo una forma di realizzazione esemplificativa dell’invenzione.

Descrizione dettagliata dell’invenzione

Prima di descrivere l’invenzione in maggiore dettaglio in quanto segue, vengono definite sotto alcune definizioni e convenzioni che sono utilizzate nel presente documento.

• “Dispositivo†: il termine dispositivo à ̈ relativo a un’entità fisica o a un’entità logica della piattaforma hardware che deve essere simulata. In alcune forme di realizzazione dell’invenzione, un dispositivo à ̈ un’unità fisica separata. Tuttavia, à ̈ anche possibile che una singola entità fisica sia rappresentata da dispositivi multipli. Per esempio, una cache può essere inoltre rappresentata da dispositivi multipli, per esempio da un dispositivo che rappresenta il buffer (memoria tampone) di scrittura della cache e da un altro dispositivo che rappresenta la memoria cache. Infatti, la definizione di un dispositivo all’interno della simulazione e la sua relazione con l’hardware del mondo reale à ̈ scelta dall’ingegnere che progetta i modelli di simulazione. Esempi di dispositivi sono cache, memorie, reti, bus, MMU (unità di gestione della memoria - memory management unit), e così via o loro sub-unità logiche o fisiche.

• “IP†: il termine IP (o blocco IP) à ̈ utilizzato qui come sinonimo di dispositivo. • “sistema di simulazione†: il termine sistema di simulazione fa riferimento a un apparecchio di calcolo o sistema di calcolo che conduce la simulazione. Per esempio, in una forma di realizzazione dell’invenzione, il sistema di simulazione può essere un computer per scopi generici. In un’altra forma di realizzazione dell’invenzione, il sistema di simulazione à ̈ realizzato come qualsiasi altro tipo di apparecchio di calcolo o simile e/o struttura hardware comprendente almeno una CPU, un dispositivo di memorizzazione, una memoria, e un dispositivo di ingresso/uscita utente.

• “motore di simulazione†: il termine motore di simulazione fa riferimento a un software per condurre una simulazione. Per esempio, il motore di simulazione può essere un ambiente di esecuzione del sistema di simulazione. I compiti del motore di simulazione possono per esempio includere uno o più tra i seguenti: definire l’inizio della simulazione; programmare operazioni, per esempio transazioni da effettuare; e determinare il termine della simulazione. Per di più, l’ambiente di simulazione può fornire un clock di simulazione, a cui si fa riferimento qui anche come clock principale. Tutte le operazioni di simulazione vengono effettuate secondo i cicli di questo clock principale, per esempio il clock di sistema del sistema di simulazione.

• “simulazione a cicli precisi†: il termine simulazione a cicli precisi viene utilizzato per descrivere una simulazione che garantisce risultati di simulazione e temporizzazione corretti mediante modelli di simulazione che gestiscono in modo preciso transazioni relative ai cicli del clock principale. Una simulazione a cicli precisi riflette dunque precisamente il comportamento dei dispositivi simulati in termini di risultati e di tempo. Ciascun modello può iniziare una transazione, per esempio, per richiedere l’esecuzione di un’operazione mediante un altro modello. Il modello di inizio mette la risposta in una relazione temporale precisa rispetto ad altre transazioni, mettendo in relazione ciascuna risposta di transazione ai cicli del clock principale.

• “Modello†: un modello rappresenta un dispositivo o un IP della piattaforma hardware che deve essere simulata. Dato che ciascun modello può fornire solo un certo livello di astrazione del dispositivo corrispondente o IP, possono esserci più modelli diversi per lo stesso dispositivo o IP. L’invenzione distingue almeno i seguenti tipi di modelli:

- “modello funzionale/funzionale temporizzato†: un modello funzionale à ̈ una descrizione precisa dal punto di vista funzionale del comportamento di un dispositivo o blocco IP verso l’esterno, senza modellare i dettagli di implementazione interni del dispositivo o IP rappresentato (per esempio informazioni sullo stato interno, rappresentazione del ciclo di clock, una velocità di esecuzione predefinita). Questo facilita una risposta istantanea da parte di un modello funzionale a una richiesta proveniente da un modello master. Per di più, il termine modello “funzionale temporizzato†indica che il risultato dell’operazione richiesta fornito dal modello

funzionale include in aggiunta un tempo di transazione (il tempo di transazione à ̈ il tempo tra la ricezione di una transazione e il risultato). Il tempo di transazione indica il tempo che l’esecuzione dell’operazione richiesta e l’invio del risultato di esecuzione avrebbero richiesto sul dispositivo simulato o IP rappresentato dal modello funzionale temporizzato. Il tempo di transazione può essere espresso in cicli del clock principale e può essere approssimato dal tempo di esecuzione per l’esecuzione dell’operazione richiesta.

- “modello basato su cicli†: un modello basato su cicli à ̈ progettato per riprodurre lo stato osservabile di un dispositivo o di un blocco IP in ogni ciclo. Un modello basato su cicli non ha un comportamento deterministico dato che non vi à ̈ conoscenza dell’output/risultato di una transazione quando la transazione viene iniziata. Di conseguenza, una transazione viene completata in una serie di fasi che vengono programmate, per esempio, e che corrispondono al rapporto di cicli predefinito del dispositivo rappresentato. Di conseguenza, per ciascun ciclo predefinito, viene modificato lo stato interno del modello basato su cicli.

• “Transazione†: il termine transazione fa riferimento alle operazioni da effettuare tra due modelli. Un primo modello inizia la transazione verso un secondo modello e il secondo modello risponde a detta transazione. Per indicare il ruolo di ciascun modello, un modello che assume il ruolo di iniziatore della transazione à ̈ chiamato modello master, e un modello che riceve e risponde a detta transazione à ̈ chiamato modello slave. Allo scopo di rispondere a una transazione, il modello slave può eseguire calcoli. Dato che i modelli possono assumere il ruolo di modello master nonché il ruolo di modello slave per diverse transazioni, la proprietà di master e slave à ̈ definita rispetto a una transazione data. I termini IP master e IP slave sono usati in modo simile ai termini di modello master e modello slave. • “risposta immediata†: il termine risposta immediata significa che un modello slave risponde a una transazione entro un ciclo di clock del clock principale. Di conseguenza, la richiesta della transazione proveniente da un modello master e la risposta a essa mediante il modello slave devono essere fornite all’interno del ciclo di clock del clock principale.

Facendo riferimento ora alla figura 1, Ã ̈ illustrata una piattaforma hardware multicore 100 esemplificativa e un sistema di simulazione 105.

Il sistema di simulazione 105, mostrato in figura 1, à ̈ un dispositivo di calcolo in grado di eseguire un programma che definisce il metodo di simulazione esposto in quanto segue. In particolare, il sistema di simulazione 105 di figura 1 à ̈ illustrato sotto forma di un computer per scopi generici solo in termini di esempio illustrativo. Alternativamente, il sistema di simulazione 105 può formare qualsiasi altro tipo di dispositivo di calcolo o simile e/o struttura hardware costituita da una CPU, un supporto di memorizzazione, una memoria, un dispositivo di ingresso/uscita utente e simili.

Come indicato dalla freccia, l’invenzione à ̈ relativa al sistema di simulazione che conduce una simulazione di modelli che rappresentano una piattaforma hardware 100. Di solito, la simulazione à ̈ fornita sotto forma di programma scritto in un linguaggio di programmazione. Di conseguenza, il metodo di simulazione include modelli che implementano la funzionalità dei dispositivi o dei blocchi IP rappresentati. Ciascun modello, per esempio, può implementare un’operazione che un modello differente può richiedere che venga eseguita (per esempio un modello di memoria può implementare una funzione read() che deve essere eseguita da un modello differente). A seguito della ricezione di una richiesta per l’esecuzione di un’operazione, il modello può eseguire la sua operazione, per esempio all’interno del proprio namespace (spazio dei nomi).

In particolare, tale richiesta per l’esecuzione di un’operazione può essere realizzata come chiamata della funzione dell’operazione fornita da un modello. Tuttavia, per essere formalmente corretti, l’enunciazione di cui sopra à ̈ stata introdotta solo per semplicità. La descrizione deve essere compresa nel senso che il processore di un sistema di simulazione esegue tutte le operazioni, e che il metodo di simulazione fornisce un motore di simulazione o un kernel che effettua la schedulazione dell’esecuzione di operazioni e di altre operazioni relative al tempo (per esempio meccanismo di callback (chiamata di ritorno)). Ciò nondimeno, à ̈ scelta una descrizione con modelli che eseguono operazioni dato che à ̈ coerente con l’esecuzione di operazioni da parte dei dispositivi (hardware) che devono essere simulati.

Nella simulazione secondo l’invenzione, vengono combinati due tipi di modelli, per la precisione modelli funzionali e modelli basati su cicli. I modelli funzionali hanno il vantaggio di rispondere immediatamente a una transazione che richiede l’esecuzione di un’operazione (vale a dire risposta all’interno dello stesso ciclo di clock della simulazione). Questo vantaggio risulta da un’implementazione di un modello funzionale che non dipende dal tempo. Modelli basati su cicli sono programmati secondo un ciclo predefinito mediante il motore di simulazione.

Allo scopo di consentire la cooperazione dei modelli basati su cicli e dei modelli funzionali, i modelli funzionali sono adattati a rispondere a una transazione con un risultato che include un tempo di transazione (vale a dire il tempo di transazione che intercorre tra il tempo tra la ricezione di una transazione e la risposta). Tuttavia, per implementare una simulazione con modelli funzionali che rispon dono con un risultato comprendente il tempo di transazione, i modelli iniziatori della transazione (vale a dire i modelli master) devono essere adattati. Per esempio, i modelli iniziatori della transazione possono essere sospesi a seguito della ricezione del tempo di transazione. Nel caso in cui un modello iniziatore della transazione inizia due transazioni: una verso un modello slave funzionale (che avrebbe impiegato per esempio 4 cicli per l’esecuzione) e un’altra verso un modello slave basato cicli (che impiega per esempio 4 cicli per l’esecuzione), la sospensione temporanea del modello iniziatore della transazione può essere l’unica opzione per far sì che entrambi i risultati arrivino allo stesso tempo.

Inoltre, la sospensione di un modello iniziatore della transazione che riceve risposta a una transazione con un tempo di transazione può essere realizzata in modelli slave basati su cicli. In generale, modelli basati su cicli non hanno un comportamento deterministico. Di conseguenza, durante l’esecuzione della simulazione di un modello basato su cicli, non vi à ̈ una conoscenza deterministica di come il modello avanzerà fino al completamento. Di conseguenza, la simulazione di un modello basato su cicli viene modificata per sospendere il modello basato su cicli quando si riceve un risultato della transazione e un tempo di transazione che indica il completamento di una transazione per un punto temporale futuro. In alternativa, un modello iniziatore della transazione può propagare il tempo di transazione ricevuto indietro verso gli altri modelli che dipendono dalla transazione. Questo concetto può essere realizzato vantaggiosamente in modelli iniziatori della transazione che sono modelli funzionali. Per esempio, nel caso di tre modelli funzionali dipendenti dalla transazione, per la precisione un primo modello funzionale inizia una prima transazione verso un secondo modello funzionale dopodiché il secondo modello funzionale inizia una transazione dipendente verso un terzo modello funzionale, il primo modello funzionale può ricevere una risposta alla transazione iniziata che comprende le informazioni temporali che corrispondono alla somma del tempo per la prima transazione e della seconda transazione dipendente.

In particolare, un modello funzionale risponde immediatamente a una transazione, per la precisione all’interno dello stesso ciclo di clock. Di conseguenza, un modello funzionale riceve inoltre un risultato della transazione e un tempo della transazione e risponde a un’altra transazione all’interno dello stesso ciclo di clock. Di conseguenza, la somma del tempo di transazione ricevuto più il tempo di transazione per rispondere all’altra transazione corrisponde ai cicli del clock principale che sarebbero stati impiegati per l’esecuzione delle due transazioni nei dispositivi (hardware) rappresentati.

Per di più, la simulazione secondo l’invenzione abilita inoltre una cooperazione dei modelli che può essere cambiata dinamicamente. Normalmente, ciascun dispositivo della piattaforma hardware da simulare à ̈ rappresentato da un modello, per la precisione un modello funzionale o un modello basato su cicli. Tuttavia, esistono aspetti della simulazione per i quali à ̈ preferibile l’una o l’altra implementazione.

Di conseguenza, la simulazione à ̈ in grado di gestire un modello funzionale e un modello basato su cicli che rappresentano lo stesso dispositivo da simulare. Per questo scopo, il modello basato su cicli e il modello funzionale hanno la stessa interfaccia di transazione. Il motore di simulazione determina dinamicamente a seconda dello stato interno quale dei due modelli viene utilizzato nella simulazione per rappresentare il dispositivo. Lo stato interno può essere impostato da un utente per l’intera durata della simulazione. Alternativamente, un utente può anche specificare modelli che devono essere sostituiti a seconda di un ciclo di clock predefinito del clock di simulazione.

Alternativamente, la simulazione à ̈ in grado di gestire un modello che comprende un’implementazione funzionale e un’implementazione basata su cicli della stessa operazione per la quale si richiede l’esecuzione da parte di una transazione. In questo caso, il motore di simulazione determina dinamicamente secondo uno stato interno quale delle due implementazioni della stessa operazione viene eseguita dal modello a seguito della ricezione di una richiesta di esecuzione dell’operazione. Lo stato interno può essere impostato da un utente per l’intera durata della simulazione. In alternativa, un utente può anche specificare modelli che devono essere sostituiti a seconda di un ciclo di clock predefinito del clock di simulazione.

Inoltre, la piattaforma hardware 100 di figura 1 mostra una piattaforma con diversi iniziatori di transazioni, in particolare un DMA e diversi iniziatori, vale a dire acceleratori hardware o acceleratori hardware programmabili (elementi di elaborazione). Per di più, la piattaforma hardware 100 comprende dispositivi di risposta come per esempio un bus, una memoria principale, un NoC (“Networkon-Chip†) e un bridge (ponte). Come illustrato in figura 1, gli iniziatori della transazione sono collegati ai dispositivi di risposta e almeno alcuni dei dispositivi di risposta sono condivisi da diversi iniziatori, questo vale per esempio per il dispositivo di risposta BUS. Questa piattaforma multi-processore esemplificativa à ̈ costituita di preferenza da un GPE, e da un array regolare di processori PE o acceleratori hardware. Ciascun processore (o acceleratore hardware) presenta il proprio spazio di indirizzamento di memoria distribuito ma uniforme.

La piattaforma hardware 100 di figura 1 può essere un esempio di una piattafor ma multicore di streaming multimediale generica, che sta diventando comune non solo in dispositivi autonomi (lettori DVD o BlueRay, set-top box, e così via) ma anche in dispositivi portatili (telefoni cellulari, smart phone, e così via).

Rivolgendosi ora alla figura 2, un’architettura di base di una piattaforma hardware come delineata dalla figura 1 à ̈ illustrata in maniera semplificata.

Facendo riferimento ora alla figura 2, una piattaforma hardware à ̈ mostrata come modello astratto di componenti elettronici da 205 a 250 che sono interconnessi l’uno con l’altro per mezzo di una connessione di dati che può essere per esempio costituita da fili elettrici, da un bus o da una rete e simili. Come esempio illustrato, la combinazione di dispositivi e le caratteristiche delle connessioni di dati illustrati in figura 2 presentano un carattere esemplificativo rispetto all’invenzione. Di conseguenza, i principi dell’invenzione possono essere applicati a qualsiasi piattaforma hardware comprendente numeri differenti di dispositivi o diversi tipi di connessioni di dati.

In Figura 2 sono illustrati iniziatori della transazione 205/210 che si collegano a dispositivi 207-240. In particolare, l’iniziatore della transazione 205 à ̈ collegato a cinque dispositivi, per la precisione i dispositivi da 207 a 211, e i dispositivi 235 e 240. L’iniziatore della transazione 205 con i relativi dispositivi connessi forma un sottosistema 250. In modo simile, l’iniziatore della transazione 210 à ̈ collegato ai dispositivi da 222 a 226 e ai dispositivi 235 e 240, formando in questo modo un sottosistema 260.

Inoltre, i dispositivi 211 e 224 presentano collegamenti aggiuntivi per i quali i dispositivi 211 e 224 assumono il ruolo di iniziatori della transazione. In particolare, il dispositivo 211 assume il ruolo di iniziatore della transazione per il collegamento al dispositivo 245 e il dispositivo 224 assume il ruolo di iniziatore della transazione per il collegamento al dispositivo 250. Il collegamento tra i dispositivi 211/224 e i dispositivi 245/250 consente agli iniziatori della transazione 205/210 di comunicare indirettamente con i dispositivi 245/250. Tuttavia, dato che i dispositivi 211/224 sono collegati tra gli iniziatori della transazione 205/210 e i dispositivi 245/250, gli iniziatori della transazione 205/210 non possono direttamente iniziare una transazione ai dispositivi 245/250.

A seconda della funzionalità di un modello, un modello può implementare il ruolo di iniziatore della transazione, per la precisione modello master, o il ruolo di dispositivo di risposta, per la precisione dispositivo slave, o può in alternativa implementare entrambi i ruoli, il ruolo di iniziatore della transazione per un primo insieme di transazioni e il ruolo di dispositivo di risposta per un secondo insieme di transazioni.

Facendo riferimento ora alla figura 3, Ã ̈ mostrato un modello semplificato della piattaforma hardware 300 che deve essere simulata. La piattaforma hardware 300 esemplificativa comprende un elemento di elaborazione detto modello CORE 305, un modello di cache di istruzioni 310 e due modelli di memoria 315 e 320. In questo esempio, il modello di memoria 320 Ã ̈ facoltativo.

Per far sì che il modello CORE 305 esegua un programma che esegue istruzioni, il modello CORE preleva un’istruzione da un modello di memoria 315 o 320, e l’istruzione identifica l’operatore o gli operandi di un programma. In particolare, il modello CORE 305 include un registro di puntatore di istruzioni che determina l’esecuzione di un’istruzione successiva che deve essere eseguita e che corrisponde a una sequenza del programma. Nella piattaforma hardware descritta, in aggiunta à ̈ fornito un modello di cache di istruzioni 310 per accelerare l’operazione di prelievo delle istruzioni del modello CORE 305.

In generale, la cache di istruzioni 310 à ̈ ottimizzata per avere accesso alle informazioni memorizzate in maniera veloce. Di conseguenza, nella simulazione le istruzioni salvate nella cache possono essere lette più velocemente dal modello di cache di istruzioni 310 rispetto che dal modello di memoria 315 o 320 che memorizza il programma. Tuttavia, un modello di cache di istruzioni contiene solamente un sottoinsieme di istruzioni rispetto all’intero programma. Di conseguenza, dopo che il modello CORE 305 inizia un’operazione di prelievo dell’istruzione, il modello di cache di istruzioni 310 deve per prima cosa determinare se le istruzioni da prelevare sono presenti e/o valide nel modello di cache di istruzioni 310.

Nel caso in cui l’istruzione da prelevare sia presente, per la precisione un cachehit, il modello di cache di istruzioni 310 copia l’istruzione richiesta a un indirizzo specificato, per esempio, il registro del modello CORE 305 che fornisce l’istruzione successiva. Dopo di ciò, il modello di cache di istruzioni 310 risponde all’operazione di prelievo dell’istruzione del modello CORE 305 indicando uno stato COMPLETED.

Nel caso in cui l’istruzione da prelevare non sia presente, per la precisione un cache-miss, il modello di cache di istruzioni 310 reindirizza l’operazione di prelievo dell’istruzione al modello di memoria comprendente il programma. A questo scopo, il modello di cache di istruzioni 310 inizia una transazione che richiede l’esecuzione di un’operazione di lettura dell’istruzione da parte del modello di memoria 315 o 320. A motivo del ritardo introdotto come latenza dal modello di memoria 315 o 320, il modello di cache di istruzioni risponde al modello CORE iniziatore della transazione dopo un periodo di tempo che corrisponde alla somma del tempo necessario per l’operazione cache-miss e della latenza della memo ria (hardware).

In maggiore dettaglio, dopo che à ̈ trascorsa la latenza della memoria, il modello di memoria 315 o 320 copia l’istruzione di lettura in un certo indirizzo. A seguito della ricezione del risultato dell’operazione di lettura dell’istruzione, il modello di cache di istruzioni 310 à ̈ in grado di aggiornare le istruzioni messe nella cache. Allo stesso tempo il modello di cache 310 copia l’istruzione richiesta in un indirizzo specificato, per esempio, il registro del modello CORE 305 che fornisce l’istruzione successiva e risponde indicando uno stato COMPLETED.

Facendo riferimento ora alle figure 4a e 4b, sono mostrate le interfacce di un modello master 405 e di un modello slave 410, che abilitano il modello master e il modello slave a iniziare/rispondere a una transazione.

Come mostrato in figura 4a, l’interfaccia del modello master 405 à ̈ in grado di iniziare una transazione. La transazione può essere usata per richiedere l’esecuzione di un’operazione. Come esempio, una CPU, che assume il ruolo del modello master 405, può richiedere che una cache fornisca l’istruzione successiva. Inoltre, l’interfaccia del modello master 405 definisce anche una risposta a una transazione. Per esempio, la risposta può indicare uno degli stati seguenti COMPLETED, ERROR e PENDING, in cui lo stato COMPLETED definisce che l’operazione à ̈ stata completata con successo; lo stato PENDING definisce che l’operazione à ̈ sospesa, e lo stato ERROR definisce che l’esecuzione dell’operazione ha dato come risultato un errore.

Come mostrato in figura 4b, l’interfaccia del modello slave 410 à ̈ in grado di ricevere una transazione. Una transazione verso un modello slave 410 può richiedere l’esecuzione di un’operazione da parte del modello slave. Di conseguenza, dopo che il modello slave 410 riceve una transazione che richiede l’esecuzione di un’operazione del modello slave 410, il modello slave 410 elabora l’operazione richiesta. Modelli slave possono fornire diverse operazioni, per esempio un modello di cache può fornire un’operazione di lettura di cache, una memoria può fornire un’operazione di lettura della memoria e un’operazione di scrittura della memoria. Un’operazione che si richiede che debba essere eseguita da un modello master può provocare inoltre l’esecuzione di un’operazione dipendente/operazioni dipendenti multiple. Per esempio, un’operazione di scrittura della memoria può inoltre provocare il fatto che vengano invalidati i rispettivi dati in una cache.

Dopo il completamento dell’esecuzione dell’operazione richiesta dal modello slave 410 e il completamento di altre operazioni dipendenti da altri modelli, l’interfaccia del modello slave definisce la risposta per indicare lo stato COM-PLETED. Inoltre, se l’operazione o qualsiasi operazione dipendente non può essere elaborata immediatamente (per esempio il modello slave à ̈ una modalità basata sui cicli), l’interfaccia del modello slave definisce la risposta per indicare uno stato PENDING. Se una qualsiasi transazione dà come risultato un errore, l’interfaccia del modello slave definisce la risposta per indicare uno stato ER-ROR.

In questa forma di realizzazione esemplificativa, non vi à ̈ distinzione tra un modello master funzionale o un modello master basato su cicli, o tra un modello slave funzionale o un modello slave basato su cicli dato che tutti i modelli master e tutti i modelli slave implementano la stessa interfaccia di transazione. In particolare, il modello master funzionale e il modello master basato su cicli implementano la stessa interfaccia, per la precisione l’interfaccia illustrata da figura 4a. Inoltre, il modello slave funzionale e il modello slave basato su cicli implemen tano la stessa interfaccia, per la precisione l’interfaccia illustrata da figura 4b. Facendo riferimento ora a figura 5, à ̈ mostrata la procedura di esecuzione di un’operazione richiesta in un modello slave basato su cicli 505.

Il modello slave mostrato in figura 5 à ̈ un modello basato su cicli. Al contrario di un modello slave funzionale per il quale una transazione ricevuta innesca l’esecuzione di un’operazione richiesta e la risposta alla transazione, nel modello basato su cicli l’esecuzione à ̈ temporizzata secondo un clock principale che può essere per esempio il clock di sistema o un clock di sistema pre-scalato, oppure un meccanismo di temporizzazione differente.

Quando una transazione viene ricevuta dal modello slave basato su cicli 505 in corrispondenza del punto temporale T0, il modello slave basato su cicli registra la transazione come transazione sospesa per programmare l’esecuzione delle operazioni interne richieste. La schedulazione viene effettuata mediante un motore di simulazione. Dopo una registrazione riuscita della transazione ricevuta come transazione sospesa, il modello slave basato su cicli risponde all’iniziatore della transazione indicando uno stato PENDING. Nel caso in cui ci sia un errore nella transazione, la risposta all’iniziatore della transazione indica uno stato ERROR. Un errore può risultare, per esempio, da un riferimento a un indirizzo in cui non ci sono dispositivi mappati su di esso, o se la dimensione (numero di byte implicati nel trasferimento) non à ̈ supportata dal dispositivo slave.

La risposta alla transazione che indica lo stato PENDING viene trasmessa immediatamente dal modello slave basato su cicli 505 al modello master che richiede l’esecuzione dell’operazione, per la precisione all’interno dello stesso ciclo di temporizzazione TC. Con la risposta, il controllo viene ceduto al modello master mediante un’operazione di ritorno che indica lo stato PENDING.

Dato che il modello slave basato su cicli 505 registra la transazione come transazione sospesa, il motore di simulazione del sistema di simulazione inizia a programmare l’esecuzione dell’operazione richiesta al punto temporale T0+ TC. La schedulazione viene effettuata in due fasi. Per prima cosa, il motore di simulazione richiama la funzione eval() del modello slave basato su cicli 505, per esempio per raccogliere gli input per l’operazione richiesta. All’interno dell’operazione eval() anche altri calcoli possono essere effettuati dal modello slave basato su cicli 505. Tuttavia, all’interno della funzione eval() lo stato osservabile del modello slave basato su cicli 505 non deve essere cambiato.

Dopo di ciò, il motore di simulazione richiama la funzione commit() per cambiare lo stato osservabile di un modello slave basato su cicli 505. Di conseguenza, l’elaborazione della funzione eval() viene completata quando à ̈ schedulata l’esecuzione della funzione commit() del modello slave basato su cicli 505. Come esempio, la funzione commit() di un modello slave basato su cicli può copiare byte provenienti da una memoria su un certo indirizzo predefinito o innescare un meccanismo di callback.

Nella simulazione dell’invenzione, i modelli basati su cicli impiegano le funzioni eval() e commit() allo scopo di simulare il fronte in salita del clock che aziona i dispositivi che funzionano in parallelo. I modelli basati su cicli vengono programmati. La schedulazione elabora consecutivamente una transazione sospesa registrata. Per evitare la distruzione di dati di ingresso da parte di un modello basato su cicli che modifica uno stato accessibile, l’elaborazione di ciascuna transazione à ̈ separata nella funzione eval() e nella funzione commit() che sono schedulate dal motore di simulazione in modo sequenziale. Di conseguenza, il motore di simulazione esegue per prima cosa la funzione eval() di tutte le transa zioni registrate per i modelli basati su cicli prima di eseguire la funzione commit() di tutte le transazioni registrate.

Nell’esempio di un modello slave basato su cicli 505 mostrato in figura 5, il motore di simulazione programma la funzione eval() e la funzione commit() per tre cicli TC, per la precisione ai punti temporali: T0+ TC, T0+ 2TC, T0+ 3TC. Durante la terza esecuzione della funzione commit(), per la precisione al punto temporale T0+ 3TC, il risultato della transazione viene determinato. Dopo di ciò, il modello slave basato su cicli impiega un meccanismo di callback per utilizzare una funzione di callback per restituire al modello iniziatore della transazione un risultato indicante uno stato COMPLETED. Dopo il completamento riuscito, la transazione viene deregistrata dall’esecuzione per il modello slave basato su cicli. In particolare, la simulazione impiega il meccanismo di callback per un modello slave basato su cicli per rispondere al modello master che inizia la rispettiva transazione. Quando il modello slave basato su cicli ha già restituito una risposta indicante lo stato PENDING, il meccanismo di callback fornisce un metodo differente asincrono per trasferire il controllo di nuovo al modello master. In particolare, un modello master passa dopo l’iniziazione di una transazione un puntatore di funzione a una funzione di callback che deve essere eseguita, dopo il completamento della transazione mediante il modello slave. Il puntatore di funzione può essere utilizzato dal modello slave per comunicare al modello iniziatore che la transazione à ̈ terminata.

Come risulta evidente dalla descrizione precedente relativa alla figura 5, ciascun modello basato su cicli à ̈ in grado di effettuare la registrazione e la deregistrazione su un motore di simulazione per programmare l’esecuzione di una transazione che richiede l’esecuzione di un’operazione specifica. Il ciclo TCsecondo il quale l’esecuzione della transazione à ̈ programmata determina la frequenza di esecuzione. Il modello basato su cicli può avere diverse frequenze di esecuzione. Di conseguenza, ciascun modello basato su cicli presenta un ciclo predefinito TCche à ̈ un numero intero multiplo del ciclo TMdi un clock principale. In particolare, il clock principale di cicli TMà ̈ definito in modo tale che TM= N·TCsia vero per il ciclo TCdi tutti i modelli basati su cicli e N sia un numero intero ≥ 1.

Anche se non illustrata nella figura 5, la schedulazione di transazioni multiple può essere registrata dal motore di simulazione per un modello basato su cicli. Facendo riferimento ora alla figura 6, à ̈ mostrato un diagramma temporale esemplificativo di un’operazione di cache-miss semplificata effettuata da una cache di istruzioni che assume il ruolo di modello master e di modello slave. Questo esempio illustra inoltre la temporizzazione riguardante l’operazione di cache-miss introdotta rispetto alla figura 3.

Come si può vedere dalla figura 6, al punto temporale T0, il modello CORE 605 inizia la transazione T61 richiedendo un’operazione di prelievo dell’istruzione al modello di cache di istruzioni 610. Il modello di cache di istruzioni 610 à ̈ realizzato in questo esempio come modello funzionale. Di conseguenza, la cache di istruzioni determina immediatamente se l’istruzione richiesta à ̈ presente nella cache. Nell’esempio, l’istruzione richiesta non à ̈ presente (o non à ̈ valida) nel modello di cache di istruzioni 610. Di conseguenza, il modello di cache di istruzioni 610 inizia la transazione T62 richiedendo un’operazione di lettura dell’istruzione al modello di memoria 615.

Il modello di memoria 615 di questo esempio à ̈ realizzato come modello basato su cicli. Di conseguenza, il modello di memoria 615 riceve la transazione che richiede la lettura dell’istruzione e registra questa transazione sospesa in mo do tale che sia schedulata dal motore di simulazione. All’interno dello stesso ciclo di clock TC, il modello di memoria 615 risponde al modello di cache 610 che indica uno stato PENDING. Dato che il modello di cache 610 riceve la risposta che indica un’operazione PENDING, il modello di cache 610 viene sospeso fino a che viene innescata una callback al modello di cache 615. Per sospendere un modello funzionale, i parametri del modello funzionale vengono salvati. In aggiunta, il modello funzionale risponde al proprio iniziatore della transazione, in questo esempio il modello CORE 605, indicando ancora lo stato PENDING. Dato che il modello di memoria 615 registra la transazione che richiede l’esecuzione di un’operazione di lettura dell’istruzione, il motore di simulazione – nell’esempio la latenza del modello di memoria corrisponde a tre cicli – programma per i tre cicli successivi T0+ TC, T0+ 2TC, e T0+ 3TCl’esecuzione di Ex63, Ex64 e Ex65, in primo luogo di una funzione eval() e poi di una funzione commit().

Al punto temporale T0+ 3TC, l’esecuzione della funzione commit() del modello di memoria 615 dà come risultato il completamento dell’operazione di lettura dell’istruzione. Di conseguenza, il modello di memoria 615 copia l’istruzione richiesta in un certo indirizzo della cache di istruzioni 610. In aggiunta, il modello di memoria 615 impiega il meccanismo di callback per rispondere alla cache di istruzioni indicando uno stato COMPLETED. A seguito della ricezione del risultato che indica il completamento dell’operazione di lettura dell’istruzione, il modello di cache di istruzioni 610 può aggiornare le istruzioni messe nella cache. Allo stesso tempo, il modello di cache di istruzioni 610 copia l’istruzione richiesta su un indirizzo specificato, per esempio il registro del modello CORE 605 che fornisce l’istruzione successiva, e risponde al modello CORE attraverso il mec canismo di callback indicando uno stato COMPLETED. Dato che il modello di cache di istruzioni 610 à ̈ un modello funzionale, la risposta include informazioni temporali sul tempo che l’esecuzione dell’operazione di lettura di cache richiesta avrebbe impiegato sul dispositivo (hardware). Nell’esempio, la risposta include informazioni temporali che indicano N cicli aggiuntivi.

Facendo riferimento ora alla figura 7, Ã ̈ mostrata una sequenza di operazioni da effettuare mediante un modello master a seguito della ricezione di un risultato come risposta a una transazione.

Come mostrato in figura 7, il modello master sul lato di sinistra inizia una transazione T705 che richiede l’esecuzione di un’operazione verso un modello slave sul lato di destra. Dopo di ciò, il modello slave esegue l’operazione richiesta e risponde alla transazione T710 includendo un risultato dell’operazione richiesta. A seguito della ricezione della transazione T710 che include il risultato dell’operazione richiesta, il modello master determina se il risultato indica uno stato PENDING. Se si determina che il risultato indica uno stato PENDING (SÌ), il modello master viene sospeso fino a che il meccanismo di callback viene innescato per il modello master (fase S715). Se il modello master determina che il risultato non indica uno stato PENDING (NO), il modello master determina se il risultato indica uno stato ERROR. Se si determina che il risultato indica lo stato ERROR (SÌ), la transazione ha generato un errore e il modello master può effettuare la gestione dell’errore per rimediare allo stato di errore nel modello slave (fase S720).

Se il modello master determina che il risultato non indica uno stato ERROR (NO), il modello master determina se il risultato indica uno stato COMPLETED. Un risultato dell’operazione di determinazione del fatto che il risultato della tran sazione non indicava lo stato COMPLETED à ̈ una situazione impossibile (S725). Se si determina che il risultato indica lo stato COMPLETED (SÃŒ), e se si determina che il risultato non include un numero di cicli (NO), viene indicato che l’esecuzione dell’operazione richiesta à ̈ stata completata con successo (fase S730). Dopo di ciò, il modello master continua a elaborare operazioni.

Se si determina che il risultato indica lo stato COMPLETED (SÌ), e se si determina che il risultato include un numero di cicli (SÌ), il modello master rileva il numero di cicli che il modello slave deve includere nella risposta alla transazione che ha richiesto l’esecuzione dell’operazione.

Se il modello master à ̈ un modello funzionale, il modello master aggiunge il numero di cicli ricevuto dal modello slave a un numero di cicli consumati da parte del modello master stesso per operazioni precedenti (fase S735). La somma del numero di cicli ricevuto e del numero di cicli interno può essere inclusa in una risposta a una transazione in cui il modello master assume il ruolo di modello slave.

Se il modello master à ̈ un modello basato su cicli, il modello master viene sospeso per il numero di cicli di clock restituiti dal modello slave più il numero di cicli consumati da parte del modello master stesso (fase S740).

Allo scopo di illustrare ulteriormente i vantaggi della simulazione secondo i diversi aspetti dell’invenzione, un esempio di un modello CORE, di un modello di cache di istruzioni e di un modello di memoria vengono forniti in un linguaggio in pseudo codice. Questi modelli implementano solo un minimo di funzionalità e sono mostrati per illustrare il flusso di dati e di istruzioni tra i modelli. In quanto segue, viene descritto per prima cosa un modello CORE, successivamente viene introdotto un modello di cache di istruzioni e alla fine un modello di memoria.

Il seguente blocco di codice sorgente 1 illustra un’implementazione esemplificativa di un modello basato su cicli secondo gli aspetti 1 e 2 dell’invenzione. In particolare, il blocco di codice sorgente 1 descrive un modello CORE in linea con il modello CORE 305 della forma di realizzazione esemplificativa di figura 3 e il modello CORE 605 della forma di realizzazione esemplificativa di figura 6.

void reset()

{

current_stage = 0;

}

void clock_eval()

{

/* non necessario in questo semplice esempio */

}

/* uno stadio per ciclo di clock, tranne che in caso di stalli */ void clock_commit()

{

byte buffer[4]; /* istruzioni a 32-bit */

ret = COMPLETED;

switch (current_stage)

{

case 0:

ret = fetch(PC, buffer, fetch_callback);

break;

case 1:

inst = decode(buffer);

break;

case 2:

ret = exec(inst, exec_callback);

break;

default:

assert(0);

}

if ((ret is COMPLETED) || (ret is ERROR))

{

if (ret is ERROR)

{

current_stage = 0; /* termina l’istruzione */

treat_error(); /* ad esempio solleva l’eccezione */ }

else

{

/* va al prossimo stadio di pipeline */ current_stage++;

if (current_stage == 3)

{

commit_instruction(inst);

current_stage = 0;

}

}

}

else

{

/* e’ inutile essere cloccati se dobbiamo

aspettare che la transazione finisca, e questo succedera’ quando viene chiamata una delle due callback, e la callback riattivera’ il clock */

suspend_clock();

}

}

mem_ret_t fetch(address, buffer, callback)

{

mem_ret_t ret = next_device->read(address, buffer, callback);

if (ret is PENDING)

{

save_params(address, buffer, callback);

}

return ret;

}

inst decode(buffer)

{

return_instruction_encoded_in_buffer();

}

mem_ret_t exec(inst, callback)

{

if ((inst is LOAD) || (inst is STORE))

{

mem_ret_t ret;

if (inst is LOAD)

{

ret = next_device->read(inst->address, inst->buffer, inst->callback);

}

else if (inst is STORE)

{

ret = next_device->write(inst->address, inst->buffer, inst->callback);

}

if (ret is PENDING)

{

save_params(inst->address, inst->buffer,

inst->callback);

}

return ret;

}

else

{

/* in questo caso supponiamo che l’istruzione

non coinvolga nessuna operazione di memoria */ execute_inst(inst);

return COMPLETED(0);

}

}

void fetch_callback(mem_ret_t ret)

{

/* esegui tutte le altre operazioni necessarie quando termina uno stadio di fetch */

/* va la prossimo stadio di pipeline */

current_stage = (current_stage 1) % 3;

reactivate_clock();

}

)PA71080IT

void exec_callback(mem_ret_t ret)

{

/* esegui tutte le altre operazioni necessarie quando

termina lo stadio di esecuzione */

/* va al prossimo stadio di pipeline */

current_stage++;

if (current_stage == 3)

{

commit_instruction(inst);

current_stage = 0;

}

reactivate_clock();

}

Blocco di codice sorgente 1

Un CORE nella piattaforma hardware che deve essere simulata può essere inteso come un’unità di elaborazione. Il CORE preleva un’operazione, decodifica l’operazione prelevata e in seguito esegue l’operazione decodificata. Le istruzioni vengono normalmente fornite da una cache di istruzioni o da una memoria che contiene il programma.

Il modello CORE del blocco di codice sorgente 1 realizza inoltre la stessa sequenza di operazioni di un modello basato su cicli. In particolare, il modello in pseudo codice del blocco di codice sorgente 1 con un’implementazione di un modello CORE effettua una distinzione tra tre fasi per l’operazione di fetch (prelievo), decodifica ed esecuzione di un’istruzione. A questo scopo, il modello CORE basato su cicli include una variabile di stato chiamata current_stage. Durante l’inizializzazione o per un reset del sistema la variabile di stato current_stage viene azzerata (cfr. blocco di codice sorgente 1, linee 1 – 4).

Durante la simulazione, il motore di simulazione esegue per ogni modello basato su cicli registrato la funzione eval() e la funzione commit() in una schedulazione che corrisponde a un ciclo predefinito TC. Nel caso particolare, le funzioni si chiamano clock_eval() e clock_commit(). La funzione clock_eval() del modello CORE à ̈ vuota (cfr. blocco di codice sorgente 1, linee 7 – 10). La funzione clock_commit() determina per prima cosa la fase successiva che deve essere elaborata ed esegue la funzione corrispondente, per la precisione la funzione fetch(), decode() o exec() (cfr. blocco di codice sorgente 1, linee 19 – 35).

Quando per esempio la funzione fetch() del modello CORE inizia una transazione che richiede l’esecuzione di un’operazione di prelievo dell’istruzione mediante una cache di istruzioni, la funzione clock_commit() include inoltre una sezione (cfr. blocco di codice sorgente 1, linee 37 – 65) per distinguere e/o elaborare il risultato ricevuto come una risposta all’istruzione iniziata. In particolare, il modello CORE distingue, se il risultato ricevuto indica lo stato COMPLETED, tra le differenti fasi in cui può trovarsi il modello CORE. Se il modello CORE si trova nella fase di prelievo o di decodifica, un risultato indicante uno stato

COMPLETED dà come risultato il fatto che il modello CORE procede alla fase successiva. Se il modello CORE si trova nella fase di esecuzione, un risultato indicante uno stato COMPLETED dà come risultato il fatto che il modello CORE esegue per prima cosa la funzione commit_instruction() prima di procedere con la prima fase, per la precisione la fase di prelievo dell’istruzione successiva (cfr. le linee 37 – 57). Nel caso in cui il risultato ricevuto indichi uno stato ERROR, il modello CORE effettua una gestione dell’errore e interrompe l’elaborazione dell’ultima istruzione.

Solo se il risultato ricevuto indica uno stato PENDING, la schedulazione da parte del motore di simulazione viene interrotta e il modello CORE viene sospeso (cfr. blocco di codice sorgente 1, linee 58 – 65). Mediante uno stato PENDING, un modello slave verso il quale à ̈ stata iniziata una transazione che richiede l’esecuzione di un’operazione indica che l’esecuzione non à ̈ stata completata. In hardware, un CORE entrerebbe in una fase di stall emettendo operazioni NOP. Ancora, nella simulazione, il modello CORE può essere sospeso, riducendo il carico di simulazione. Per riprendere dopo uno stato sospeso con la fase che il modello CORE stava eseguendo precedentemente, due delle tre funzioni del modello CORE, per la precisione la funzione fetch() e la funzione exec(), hanno una funzione di callback associata, per la precisione fetch_callback() e exec_callback().

Specificamente, la fase di prelievo, implementata dalla funzione fetch() nel modello CORE del blocco di codice sorgente 1, emette un’operazione di lettura verso il dispositivo successivo (cfr. blocco di codice sorgente 1, linea 71). Questo dispositivo successivo può essere, per esempio, un modello di una cache di istruzioni. In questo caso, il dispositivo successivo risponde con un risultato che indica lo stato PENDING, i parametri vengono salvati (cfr. blocco di codice sorgente 1, linee 73 – 77), e il modello CORE viene sospeso (cfr. blocco di codice sorgente 1, linea 64).

Nel caso in cui il dispositivo successivo risponda con un risultato che indica lo stato COMPLETED, il modello CORE avanza alla fase successiva.

Inoltre, la fase di decodifica, implementata dalla funzione decode() nel modello CORE, restituisce l’istruzione codificata in un buffer (cfr. blocco di codice sorgente 1, linee 82 – 85).

La fase di esecuzione, implementata dalla funzione exec() nel modello CORE del blocco di codice sorgente 1, distingue tra operazioni di load/store e altre operazioni. In particolare, se l’istruzione decodificata viene determinata essere un’istruzione LOAD o STORE, viene iniziata la transazione corrispondente verso un dispositivo successivo, per la precisione per richiedere l’esecuzione di un’operazione di load o di store. Per esempio, il dispositivo successivo à ̈ un dispositivo di tipo memoria. Nel caso in cui il dispositivo successivo risponda con un risultato che indica lo stato PENDING, i parametri vengono salvati (cfr. blocco di codice sorgente 1, linee 103 – 106), e il modello CORE viene sospeso (cfr. blocco di codice sorgente 1, linea 64). Nel caso in cui il dispositivo successivo risponda con un risultato che indica lo stato COMPLETED, il modello CORE avanza alla fase successiva. Alternativamente, altre istruzioni vengono eseguite dalla funzione execute_inst() (cfr. blocco di codice sorgente 1, linea 114).

Per il meccanismo di callback di un modello basato su cicli, il modello CORE fornisce due funzioni di callback associate, per la precisione fetch_callback() e exec_callback(). La funzione fech_callback() avanza alla fase successiva del modello CORE ed esegue la funzione reactivate_clock() che riattiva la schedulazione da parte del motore di simulazione secondo il ciclo predefinito TC(cfr. blocco di codice sorgente 1, linee 121 – 129). In modo simile, la funzione exec_callback() incrementa il contatore di fasi della pipeline per avanzare alla fase successiva e il modello CORE deve proseguire con la fase di prelievo dell’istruzione successiva, la funzione exec_callback() esegue inoltre la funzione commit_instruction(). Inoltre, il modello CORE esegue la funzione reactivate_clock() che riattiva la schedulazione da parte del motore di simulazione se condo il ciclo predefinito TC(cfr. blocco di codice sorgente 1, linee 133 – 149). Il modello CORE esemplificativo del blocco di codice sorgente 1 può essere utilizzato per una simulazione della piattaforma hardware descritta in relazione alle figure 3 e 6. L’interazione del modello CORE del blocco di codice sorgente 1 con altri modelli à ̈ spiegata nella descrizione che segue.

Come descritto sopra, il modello CORE 605 di figura 6 inizia al punto temporale T0la transazione T61 che richiede un’operazione di prelievo dell’istruzione al modello di cache di istruzioni 610. La transazione T61 corrisponde all’implementazione del modello CORE del blocco di codice sorgente 1 che esegue la funzione next_device->read() (cfr. blocco di codice sorgente 1, linea 71). Quando il modello CORE 605 di figura 6 riceve una risposta che indica uno stato PENDING, l’implementazione del modello CORE del blocco di codice sorgente 1 salva i parametri (cfr. blocco di codice sorgente 1, linea 75) e sospende il modello CORE mediante sospensione del clock (cfr. blocco di codice sorgente 1, linea 64).

Quando il modello CORE 605 di figura 6 riceve la callback al punto temporale T0+ 3TC, l’implementazione del modello CORE del blocco di codice sorgente 1 avanza alla fase successiva ed esegue la funzione reactivate_clock() per riattivare la schedulazione da parte del motore di simulazione (cfr. blocco di codice sorgente 1, linea 129).

Il blocco di codice sorgente 2 seguente illustra un’implementazione esemplificativa di un modello funzionale secondo gli aspetti 1 e 2 dell’invenzione. In particolare, il blocco di codice sorgente 2 descrive un modello di cache di istruzioni in linea con il modello di cache di istruzioni 310 della forma di realizzazione esemplificativa di figura 3 e il modello di cache di istruzioni 610 della forma di realiz zazione esemplificativa di figura 6.

mem_ret_t icache_read(address, size, buffer, callback)

{

line = identify_target_line(address);

if (line->valid && (line->tag == get_tag(address))

{

copy_bytes(address, size, buffer, line);

return COMPLETED(L * clock_ratio); /* dobbiamo immaginare che lo stesso dispositivo puo’ essere usato con diversi rapporti di clock (clock ratio = main clock / device clock), cioe’ la latenza e’ sempre L cicli del dispositivo, ma il valore ritornato e’ relative al clock principale */

}

else

{

line->tag = get_tag(address);

mem_ret_t ret = next_device->read(align_address(address),

LINE_SIZE, line, icache_callback);

if (ret is ERROR)

return ERROR(get_error_code(ret));

else if (ret is COMPLETED)

{

copy_bytes(address, size, buffer, line);

return COMPLETED(get_cycles(ret) L * clock_ratio); }

else if (ret is PENDING)

{

save_params(address, size, buffer, callback);

return PENDING;

}

}

}

void icache_callback(mem_ret_t ret)

{

if (ret is ERROR)

caller_callback(ERROR(get_error_code(ret));

else if (ret is COMPLETED)

{

copy_bytes(address, size, buffer, line);

caller_callback(COMPLETED(get_cycles(ret) L *

clock_ratio));

}

else if (ret is PENDING)

assert(0)

}

Blocco di codice sorgente 2

Il modello di cache di istruzioni del blocco di codice sorgente 2 mostra il comportamento della cache di istruzioni dopo che un modello master (per esempio una CPU) inizia un’operazione di lettura di cache di istruzioni (detta icache_read()). Nel caso di un’operazione di lettura di cache di istruzioni a un indirizzo specifico, il modello fornisce due comportamenti alternativi.

Per prima cosa, se l’indirizzo à ̈ contenuto in una linea della cache e la linea à ̈ marcata come valida (cfr. blocco di codice sorgente 2, linea 5), le istruzioni vengono

copiate dalla linea di cache in un buffer passato dall’iniziatore (cfr. blocco di codice sorgente 2, linea 7) e il modello torna uno stato COMPLETED che indica un completamento riuscito dell’operazione di lettura di cache di istruzioni (cfr. blocco di codice sorgente 2, linea 9). Dato che la cache di istruzioni viene modellata come modello funzionale, il modello risponde alla transazione con un risultato che include le informazioni temporali che indicano che l’operazione di lettura avrebbe impiegato su un dispositivo reale L cicli moltiplicati per un certo rapporto di clock in modo tale che il numero di cicli restituito sia relativo al clock principale (cfr. blocco di codice sorgente 2, linea 9).

In secondo luogo, se l’indirizzo non à ̈ registrato nel buffer o se la linea non à ̈ valida, il modello della cache di istruzioni reindirizza l’operazione di lettura verso un dispositivo successivo (cfr. blocco di codice sorgente 2, linea 19). Ci sono due diverse risposte possibili, che il modello di cache di istruzioni illustrato sopra può gestire.

Nel caso in cui il dispositivo successivo verso il quale l’operazione di lettura di istruzione viene reindirizzata e tutti gli altri dispositivi che sono richiesti in aggiunta per eseguire l’operazione di lettura siano realizzati sotto forma di modelli funzionali, l’operazione di lettura viene eseguita (elaborata) immediatamente dal modello del dispositivo successivo e dagli altri dispositivi e i risultati sono immediatamente disponibili con la risposta alla transazione.

In questo caso, il modello di cache di istruzioni del blocco di codice sorgente 2 esamina la risposta istantanea alla transazione che ha iniziato l’operazione di lettura memorizzata nella variabile di ritorno ret (cfr. blocco di codice sorgente 2, linea 23). A seconda dello stato indicato dalla variabile di ritorno ret, il modello di cache di istruzioni viene programmato per effettuare la gestione di errore (cfr. blocco di codice sorgente 2, linee 23 – 24), per copiare i byte richiesti a seguito della ricezione di uno stato COMPLETED (cfr. blocco di codice sorgente 2, linee 27 -29) o per innescare un’operazione di sleep (sospensione) a seguito della ricezione uno stato PENDING (cfr. blocco di codice sorgente 2, linee 31 – 36).

Lo stato COMPLETED può essere inviato solamente da un modello funzionale che risponde istantaneamente alla transazione che inizia una richiesta di lettura. In questo caso, la risposta al modello che inizia la transazione che richiede la lettura della cache di istruzioni include la somma delle informazioni temporali ricevute dal dispositivo successivo ed il numero L di cicli moltiplicato per un certo rapporto di clock (per esempio gli L cicli determinati dalla durata del cache miss).

Nel caso in cui il dispositivo successivo, verso il quale l’operazione di lettura di istruzione viene reindirizzata dal modello di cache di istruzioni, sia realizzato come modello basato su cicli, il modello basato su cicli risponderà alla transazione che richiede l’esecuzione dell’operazione di lettura di istruzione con una risposta istantanea che indica uno stato PENDING. Dopo che il modello basato su cicli del dispositivo successivo completa l’esecuzione dell’operazione, viene utilizzato il meccanismo di callback.

Per il meccanismo di callback, il modello di cache di istruzioni fornisce la funzione icache_callback() (cfr. blocco di codice sorgente 2, linee 41 – 54). Dopo che il modello basato su cicli ha completato la transazione iniziata e risponde indicando uno stato COMPLETED, la funzione di callback effettua un’ispezione simile della variabile di ritorno ret. Di conseguenza, a seguito della ricezione dello stato COMPLETED, il modello di cache di istruzioni prova a rilevare le informazioni temporali ricevute dal dispositivo successivo e a seconda del fatto che l’operazione ha avuto successo o meno risponde all’iniziatore della transazione dell’operazione di lettura nella cache di istruzioni con una somma delle informazioni temporali ricevute dal dispositivo successivo e delle informazioni temporali che indicano gli L cicli moltiplicati per un certo rapporto di clock (gli L cicli dati dalla durata della cache miss).

Il modello di cache di istruzioni esemplificativo del blocco di codice sorgente 2 può essere utilizzato per una simulazione della piattaforma hardware descritta in relazione alle figure 3 e 6. L’interazione del modello di cache di istruzioni del blocco di codice sorgente 2 con altri modelli à ̈ spiegato nella descrizione che segue. Il modello CORE 605 di figura 6 inizia la transazione T61 che richiede l’operazione di prelievo dell’istruzione al modello di cache di istruzioni 610. A seguito della ricezione della transazione T61 dalla cache di istruzioni del blocco di codice sorgente 2, la cache di istruzioni del blocco di codice sorgente 2 per prima cosa determina se l’indirizzo fornito con l’operazione di prelievo dell’istruzione à ̈ contenuto in una linea e se tale linea à ̈ marcata come valida (cfr. blocco di codice sorgente 2, linea 5).

Se questa verifica dà come risultato un cache-miss, il modello di cache di istruzioni del blocco di codice sorgente 2 inizia una transazione che richiede l’esecuzione di un’operazione di lettura in un dispositivo successivo (cfr. blocco di codice sorgente 2, linea 19). Questa transazione corrisponde alla transazione T62 di figura 6.

Quando il modello di cache di istruzioni 610 di figura 6 riceve una risposta che indica uno stato PENDING all’interno dello stesso ciclo di clock, il modello di cache di istruzioni del blocco di codice sorgente 2 salva i parametri (cfr. blocco di codice sorgente 2, linea 33) e restituisce un risultato indicante uno stato PEN-DING al modello CORE (cfr. blocco di codice sorgente 2, linea 35).

Il modello di memoria 615 chiama la callback al punto temporale T0+ 3TCin Figura 6. Di conseguenza, il modello di cache di istruzioni del blocco di codice sorgente 2 procede all’esame del risultato della transazione e copia i byte richiesti (cfr. blocco di codice sorgente 2, linea 47) e utilizza il meccanismo di callback per restituire al modello CORE una risposta che indica lo stato COMPLETED e restituisce L cicli moltiplicati per un certo rapporto di clock.

Il blocco di codice sorgente 3 seguente illustra un’implementazione esemplificativa di un modello con un’implementazione basata su cicli e funzionale della stessa operazione secondo l’aspetto 3 dell’invenzione. In particolare, il blocco di codice sorgente 3 descrive un modello di memoria in linea con il modello di memoria 315 della forma di realizzazione esemplificativa di figura 3 e il modello di cache di istruzioni 615 della forma di realizzazione esemplificativa di figura 6. Secondo la descrizione dell’invenzione di cui sopra, l’implementazione fornisce una cooperazione dinamica tra i modelli. I modelli interagiscono iniziando e rispondendo a transazioni. Siccome i tipi diversi di modelli, per la precisione modelli funzionali e modelli basati su cicli, implementano la stessa interfaccia, i due tipi di modelli possono essere utilizzati in modo interscambiabile nella simulazione. In particolare, il tipo di modello può essere cambiato sia sostituendo dinamicamente un tipo di modello con un altro tipo di modello differente oppure riconfigurando dinamicamente un modello comprendente un’implementazione basata su cicli di un’operazione e un’implementazione funzionale della stessa operazione.

A questo scopo, il sistema di simulazione può definire uno stato interno che determina quali dei modelli o quali delle implementazioni vengono utilizzate per una particolare transazione. Al posto di uno stato interno, il sistema di simulazione può inoltre leggere un file di configurazione all’avvio oppure attendere istruzioni dall’utente attraverso un dispositivo di input (per esempio tastiera, mouse, touch screen). In questo modo, un utilizzatore à ̈ in grado di determinare il comportamento della simulazione. In alternativa, lo stato interno può essere mo dificato a seconda di una condizione di simulazione, per esempio una durata di simulazione predefinita e/o un risultato di simulazione predefinito. In questo modo, la velocità della simulazione o la precisione della simulazione possono essere migliorate.

mem_ret_t mem_read(address, size, buffer, callback)

{

if (current_mode_is_functional)

{

if (new_mode_must_be_cycle_based) /* questo puo’

essere specificato dall’utente per esempio e puo’

essere relativo a un particolare ciclo di clock,

ad es. Inizia a comportarti in modo preciso dal ciclo C */

{

change_current_mode_to_cycle_based();

/* abbiamo bisogno del clock per implementare

il modello basato su cicli */

enable_clock();

/* inizia le nuove transazioni in modo preciso */

return mem_read_cycle_based(address, size,

buffer, callback);

}

else

/* inizia le nuove transazione in modo funzionale */ return mem_read_functional(address, size,

buffer, callback);

}

else

{

if (new_mode_must_be_functional)

{

if (no_more_pending_cycle_based_transactions)

{

change_current_mode_to_functional();

/* non abbiamo bisogno del clock per implementare il modello funzionale */

disable_clock();

}

/* in ogni caso inizia le nuove transazioni in modo funzionale */

return mem_read_functional(address, size,

buffer, callback);

}

else

/* inizia le nuove transazioni in modo cycle-based */ return mem_read_cycle_based(address, size,

buffer, callback);

}

}

mem_ret_t mem_read_cycle_based(address, size,

buffer, callback)

{

latency = compute_latency(address, size);

add_pending_trans(address, size, buffer,

callback, latency);

return PENDING;

}

mem_ret_t mem_read_functional(address, size,

buffer, callback) {

latency = compute_latency(address, size);

copy_bytes(address, size, buffer);

return COMPLETED(latency * clock_ratio);

}

void mem_clock_eval()

{

for (p = pending_trans; p != NULL; p = p->next) p->count--;

}

void mem_clock_commit()

{

for (p = pending_trans; p != NULL; p = n)

{

n = p->next;

if (p->count == 0)

{

copy_bytes(address, size, buffer);

remove_pending_trans(p);

caller_callback(COMPLETED(0));

}

}

Blocco di codice sorgente 3

Nel modello di memoria del blocco di codice sorgente 3, il comportamento del modello può essere cambiato attraverso uno stato interno del sistema di simulazione, per la precisione le variabili di stato new_mode_must_be_cycle_based e new_mode_must_be_functional. Nel caso in cui la variabile di stato new_mode_must_be_cycle_based sia true (cfr. blocco di codice sorgente 3, linea 5), il comportamento del modello di memoria viene commutato in modo tale che diventi un modello basato su cicli abilitando il clock (cfr. blocco di codice sorgente 3, linea 14) e innescando l’implementazione basata su cicli dell’operazione di lettura attraverso la funzione mem_read_cycle_based() (cfr. blocco di codice sorgente 3, linea 17). Nel caso in cui la variabile di stato new_mode_must_be_functional sia true (cfr. blocco di codice sorgente 3, linea 26), il comportamento del modello di memoria viene commutato in modo tale da diventare un modello funzionale disabilitando il clock (cfr. blocco di codice sorgente 3, linea 14) e iniziando l’implementazione funzionale dell’operazione di lettura attraverso la funzione mem_read_functional() (cfr. blocco di codice sorgente 3, linea 38).

Nel modello di memoria del blocco di codice sorgente 3, una variabile di stato determina se il modello si comporta come un modello basato su cicli o come un modello funzionale. Il comportamento può essere impostato da un utilizzatore per l’intera durata della simulazione. Alternativamente, un utilizzatore può inoltre specificare il cambiamento del comportamento del modello di memoria a seconda di un ciclo di clock predefinito del clock di simulazione. Definendo un ciclo del clock della simulazione per commutare un modello da un comportamento basato cicli a un comportamento funzionale si può permettere un completamento più veloce della simulazione dopo il ciclo di clock predeterminato (per esempio dopo il ciclo di clock C). Definendo un ciclo del clock della simulazione per commutare un modello da un comportamento funzionale a un comportamento basato cicli si può permettere una simulazione maggiormente precisa dopo il ciclo di clock specificato (per esempio dopo il ciclo di clock C dove C determina un punto temporale in cui la piattaforma hardware simulata inizia a effettuare una serie di istruzioni che sono di interesse per l’ utente).

Per quanto riguarda l’implementazione basata su cicli del modello di memoria del blocco di codice sorgente 3, le funzioni mem_read_cycle_based(), mem_clock_eval() e mem_clock_commit() sono essenziali.

In particolare, dopo la determinazione del comportamento del modello (cfr. blocco di codice sorgente 3, linee 3 – 45), l’implementazione basata su cicli del modello di memoria determina per prima cosa la latenza dell’operazione di lettura per simulare questa latenza mediante il numero di cicli di sospensione (cfr. blocco di codice sorgente 3, linea 56). In secondo luogo, l’operazione di lettura viene registrata per la schedulazione da parte del motore di simulazione (cfr. blocco di codice sorgente 3, linea 53). Dopo di ciò, il modello di memoria risponde con un risultato indicante uno stato PENDING al modello che ha iniziato l’operazione di lettura (cfr. blocco di codice sorgente 3, linea 55).

Inoltre, il modello di memoria del blocco di codice sorgente 3 presenta una funzione mem_clock_eval() e una funzione a mem_clock_commit() che devono essere eseguite dal motore di simulazione dopo che l’operazione di lettura à ̈ stata registrata come operazione sospesa. Di conseguenza, per l’elaborazione dell’operazione di lettura il motore di simulazione esegue la funzione mem_clock_eval() che decrementa solamente il contatore interno che simula la latenza della memoria. Dato che ci può essere più di una transazione che richiede un’operazione di lettura al modello di memoria simulato, una lista di transazioni sospese viene utilizzata per immagazzinare ciascuna transazione che richiede un’operazione di lettura. Questa lista viene utilizzata per iterare sulle transazioni sospese decrementando il contatore interno per ciascuna delle transazioni sospese (cfr. blocco di codice sorgente 3, linee 69 – 70).

La funzione mem_clock_commit() del modello di memoria del blocco di codice sorgente 3 implementa una risposta alla transazione che ha richiesto l’operazione di lettura. Per ognuna delle transazioni sospese, il modello di memoria determina se il contatore interno à ̈ diventato zero, il che indica che la latenza della memoria à ̈ trascorsa (cfr. blocco di codico sorgente 3, linee 74 – 80). Se il contatore à ̈ pari a zero, i byte da leggere vengono copiati all’indirizzo specificato (cfr. blocco di codice sorgente 3, linea 82), la transazione viene deregistrata (vale a dire rimossa) dalla lista di transazioni sospese (cfr. blocco di codice sorgente 3, linea 84) e il meccanismo di callback viene eseguito per restituire al modello che ha iniziato la transazione che ha richiedesto l’operazione di lettura un risultato indicante uno stato COMPLETED. Il risultato restituito al modello che ha iniziato la transazione include inoltre uno zero per indicare che l’operazione à ̈ già stata completata. Per quanto riguarda l’implementazione funzionale del modello di memoria del blocco di codice sorgente 3, la funzione mem_read_functional() à ̈ essenziale. Dopo la determinazione del comportamento del modello (cfr. blocco di codice sorgente 3, linee 3 – 45), l’implementazione funzionale del modello di memoria del blocco di codice sorgente 3 per prima cosa determina la latenza dell’operazione di lettura che deve essere simulata (cfr. blocco di codice sorgente 3, linea 59), in secondo luogo copia i byte da leggere all’indirizzo specificato (cfr. blocco di codice sorgente 3, linea 61) e dopo di ciò restituisce al modello iniziatore un risultato che include uno stato COMPLETED e informazioni temporali che indicano che l’operazione di lettura avrebbe impiegato un numero di cicli di dispositivo pari a LATENCY (vale a dire un certo numero di cicli che corrispondono alla latenza determinata (cfr. blocco di codice sorgente 3, linea 65)).

Il modello di memoria esemplificativo del blocco di codice sorgente 3 può essere utilizzato per una simulazione della piattaforma hardware descritta in relazione alle figure 3 e 6. L’interazione del modello di memoria del blocco di codice sorgente 3 con altri modelli à ̈ spiegata nella descrizione che segue. Per l’esempio seguente, il modello di memoria del blocco di codice sorgente 3 à ̈ un modello basato su cicli. Di conseguenza, solo le funzioni mem_read_cycle_based(), mem_clock_eval() e mem_clock_commit() sono utilizzate.

Quando il modello di cache di istruzioni 610 di figura 6 emette al punto temporale T0+ TCla transazione T62 che richiede l’operazione di lettura di un’istruzione, il modello di memoria del blocco di codice sorgente 3 registra una transazione sospesa da schedulare mediante il motore di simulazione per mezzo della funzione add_pending_trans() (cfr. blocco di codice sorgente 3, linea 51).

Dopo di ciò, il modello di memoria del blocco di codice sorgente 3 risponde immediatamente al modello di cache di istruzioni indicando uno stato PENDING (cfr. blocco di codice sorgente 3, linea 53).

A motivo del fatto che il modello di memoria del blocco di codice sorgente 3 registra la transazione che richiede l’esecuzione di un’operazione di lettura di un’istruzione nella lista delle transazioni sospese, il motore di simulazione – con una latenza di tre cicli – programma l’esecuzione dell’elaborazione della transazione per i tre cicli consecutivi, e per ciascun ciclo viene chiamata prima la funzione mem_clock_eval() e poi la funzione mem_clock_commit() (cfr. blocco di codice sorgente 3, linee 68 – 83).

La terza esecuzione della funzione mem_clock_commit() del modello di memoria del blocco di codice sorgente 3 comporta il completamento dell’operazione di lettura dell’istruzione. Il modello di memoria del blocco di codice sorgente 3 copia l’istruzione richiesta in un certo indirizzo della cache di istruzioni (cfr. del blocco di codice sorgente 3, linea 82). In aggiunta, il modello di memoria del blocco di codice sorgente 3 deregistra la transazione dalla lista delle transazioni sospese (cfr. blocco di codice sorgente 3, linea 84) e impiega il meccanismo di callback per rispondere alla cache di istruzioni indicando uno stato COMPLE-TED con zero cicli (cfr. blocco di codice sorgente 3, linea 86).

Claims (15)

1. RIVENDICAZIONI 1. Metodo implementato mediante computer per simulare una piattaforma hardware multicore comprendente una pluralità di dispositivi, ciascun dispositivo essendo rappresentato nella simulazione da un modello funzionale o da un modello basato su cicli, il metodo essendo eseguito su un sistema di simulazione comprendente le fasi di: - iniziare una transazione mediante un modello che assume il ruolo di modello master per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, - eseguire l’operazione richiesta mediante il modello slave, e - rispondere alla transazione mediante il modello slave restituendo un risultato dell’operazione eseguita al modello master; in cui, nel caso in cui il modello slave sia un modello funzionale, il modello slave nella simulazione à ̈ adatto a eseguire l’operazione richiesta dalla transazione e rispondere immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione, e in cui il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione.
2. 2. Il metodo implementato mediante computer secondo la rivendicazione 1, in cui, nel caso in cui il modello slave sia un modello basato su cicli, un motore di simulazione del metodo implementato mediante computer schedula l’esecuzione dell’operazione richiesta dalla transazione e la risposta a essa rispetto ai cicli di un clock principale.
3. 3. Il metodo implementato mediante computer secondo la rivendicazione 2, in cui ciascun modello basato su cicli presenta un ciclo predefinito TCche à ̈ un numero intero multiplo del ciclo TMdel clock principale, e il motore di simulazione à ̈ adatto a programmare l’esecuzione di un’operazione richiesta da una transazione e una risposta a essa da parte di ciascuno dei modelli basati su cicli in relazione al rispettivo ciclo TC.
4. 4. Il metodo implementato mediante computer secondo una qualsiasi delle rivendicazioni da 1 a 3, in cui il modello master à ̈ un modello master basato su cicli, e in cui a seguito della ricezione della risposta alla transazione comprendente il risultato e le informazioni sul tempo di esecuzione, il modello master viene sospeso per un numero di cicli del clock principale che corrisponde al tempo di esecuzione indicato nelle informazioni ricevute.
5. 5. Il metodo implementato mediante computer secondo una qualsiasi delle rivendicazioni da 1 a 3, in cui il modello master à ̈ un modello funzionale e il modello master assume il ruolo di modello slave per un altro modello master che rappresenta un dispositivo della piattaforma hardware simulata, detto altro modello master iniziando un’altra transazione per richiedere l’esecuzione di un’operazione da parte del modello master, e in cui a seguito della ricezione della risposta alla transazione comprendente il risultato e le informazioni sul tempo di esecuzione, il modello master esegue l’operazione richiesta da detta altra transazione e risponde immediatamente a essa restituendo il risultato dell’esecuzione della diversa operazione e la somma del numero di cicli ricevuto e del numero stimato di cicli associati all’esecuzione dell’operazione come informazioni sul tempo di esecuzione.
6. 6. Il metodo implementato mediante computer secondo una delle rivendicazioni da 2 a 5, in cui il motore di simulazione à ̈ adatto a schedulare l’esecuzione di un’operazione richiesta da una transazione e una risposta a essa da parte di ciascuno dei modelli basati su cicli a diversi punti temporali all’interno di un ciclo del clock principale.
7. 7. Il metodo implementato mediante computer secondo una qualsiasi delle rivendicazioni da 1 a 6, in cui il risultato restituito da un modello slave come risposta a una transazione che richiede l’esecuzione di un’operazione indica uno dei seguenti stati: - stato COMPLETED, in cui l’operazione à ̈ stata completata con successo oppure; - stato PENDING, in cui l’operazione à ̈ sospesa; e - stato ERROR, in cui l’esecuzione dell’operazione dà come risultato un errore.
8. 8. Il metodo implementato mediante computer secondo una qualsiasi delle rivendicazioni da 1 a 7, in cui, il motore di simulazione à ̈ adatto a sospendere un modello master dopo che il modello master ha ricevuto come risposta a una transazione che richiede l’esecuzione di un’operazione da parte di un modello slave un risultato indicante uno stato PENDING.
9. 9. Un metodo implementato mediante computer per simulare una piattaforma hardware multicore comprendente una pluralità di dispositivi, ciascun dispositivo essendo rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli, in cui almeno un dispositivo della piattaforma hardware à ̈ rappresentato sia da un modello funzionale sia da un modello basato cicli, il modello funzionale e il modello basato su cicli avendo un’interfaccia comune, il metodo essendo condotto mediante un sistema di simulazione comprendente le fasi di: - iniziare una transazione mediante un modello che assume il ruolo di modello master per richiedere l’esecuzione di un’operazione da parte di uno tra il modello funzionale e il modello basato su cicli che rappresentano lo stesso dispositivo della piattaforma hardware, - determinare secondo uno stato interno del sistema di simulazione quale dei due modelli viene utilizzato in qualità di modello slave per il dispositivo, - eseguire l’operazione richiesta mediante il modello slave determinato, e - rispondere alla transazione mediante il modello slave restituendo un risultato dell’operazione eseguita al modello master.
10. 10. Un metodo implementato mediante computer per simulare una piattaforma hardware multicore comprendente una pluralità di dispositivi, ciascun dispositivo essendo rappresentato nella simulazione da un modello funzionale e/o da un modello basato su cicli, in cui almeno un dispositivo della piattaforma hardware à ̈ rappresentato da un modello che comprende un’implementazione basata su cicli di un’operazione e un’implementazione funzionale della stessa operazione, il metodo essendo condotto mediante un sistema di simulazione comprendente le fasi di: - iniziare una transazione mediante un modello che assume il ruolo di modello master per richiedere l’esecuzione di un’operazione da parte di un modello che assume il ruolo di modello slave, il modello slave comprendendo un’implementazione basata su cicli dell’operazione richiesta e un’implementazione funzionale della stessa operazione, - determinare secondo uno stato interno del sistema di simulazione quale delle due implementazioni deve esser utilizzata dal modello slave per eseguire l’operazione richiesta, - eseguire l’implementazione determinata dell’operazione richiesta mediante il modello slave, e - rispondere alla transazione mediante il modello slave restituendo un risultato dell’operazione eseguita al modello master.
11. 11. Il metodo implementato mediante computer secondo la rivendicazione 9 o 10 in cui, nel caso in cui il modello slave sia un modello funzionale, il modello slave nella simulazione à ̈ adatto a eseguire l’operazione richiesta dalla transazione e rispondere immediatamente a essa restituendo il risultato dell’operazione eseguita e le informazioni sul tempo di esecuzione, e in cui il tempo di esecuzione indica un numero stimato di cicli di un clock principale che il dispositivo rappresentato dal modello slave funzionale avrebbe richiesto per l’esecuzione dell’operazione.
12. 12. Il metodo implementato mediante computer secondo una qualsiasi delle rivendicazioni da 9 a 11 comprendente inoltre le fasi del metodo secondo una delle rivendicazioni da 2 a 8.
13. 13. Programma informatico per l’esecuzione di un metodo secondo una qualsiasi delle rivendicazioni da 1 a 12.
14. 14. Supporto di dati contenente un programma informatico secondo la rivendicazione 13.
15. 15. Sistema informatico sul quale à ̈ caricato un programma informatico secondo la rivendicazione 13.