Metodologia ESL: un esempio pratico di applicazione

• 
• Tweet
• Pin It
• Condividi per email

L’impiego di una metodologia basata su ESL ha permesso a un team di progettazione di Siemens di effettuare un confronto tra diverse architetture di uno switch Ethernet 100 Mbps in modo rapido e accurato. Saranno quindi descritte le fasi che hanno portano alla creazione dei modelli architetturali e fornita di conseguenza l’analisi dei risultati

Allo scopo di valutare appieno i benefici legati al passaggio a una metodologia basata su ESL un gruppo di progettisti della divisione IA&DT (Industrial Technology and Drive Technologies) di Siemens, partendo dal progetto di uno switch Ethernet già esistente, ha generato una specifica a livello architetturale eseguibile. Al fine di poter passare dalla definizione del sistema alla fase di esplorazione architetturale è stato utilizzato un toolset ESL di CoFluent Design. Variando la mappatura del modello funzionale nel modello della piattaforma è stato possibile creare un certo numero di architetture adatte all’implementazione del progetto.

Nel caso di un progetto complesso come quello di uno switch Ethernet, esistono molte variabili a livello architetturale che possono influenzare costi e prestazioni del sistema. In passato, per effettuare il confronto tra diverse architetture si ricorreva a calcoli e analisi di tabelle Excel, basati in larga misura sul know how acquisito dagli architetti di sistema. Fare affidamento sull’analisi degli spreadsheet e sull’esperienza acquisita può rappresentare un limite al numero delle configurazioni che è possibile analizzare. L’adozione di un processo automatizzato per le operazioni di generazione e confronto permette di valutare in maniera accurata un numero sicuramente maggiori di casi di test (test cases). L’obiettivo finale è pervenire a una combinazione ottimale di variabili di progetto che permetta di ottenere le migliori prestazioni senza nessun tipo di ridondanza (fattore che si riflette favorevolmente sui costi di progetto).

Flusso di progettazione
Il flusso di progettazione utilizzato viene riportato in figura 1. Nella prima fase i progettisti di sistema devono prendere in esame i requisiti dei clienti e considerare tutti i possibili casi di utilizzo (use case). La modellazione comportamentale temporizzata si basa sulle specifiche provenienti dalla prima fase prevista dal flusso ESL. In questa fase viene dichiarata la struttura interna e il flusso di trasferimento dei segnali mediante la definizione degli accoppiamenti e delle funzioni necessarie allo scopo.

Fig. 1 – Flusso di progettazione ESL

La messa a punto della piattaforma reale avviene nella fase di modellazione della piattaforma stessa. Per questa modellazione è anche possibile utilizzare il modello strutturale: esso è di tipo grafico e gerarchico. Una piattaforma semplificata per il modello funzionale viene progettata seguendo lo stesso metodo di trasformazione successive: la soluzione cui si perviene è la classica “scatola nera” che contiene l’insieme completo di funzionalità del sistema. Sono tre gli elementi con i quali è possibile descrivere qualsiasi piattaforma fisica: processori, memorie e nodi di comunicazione.

Per poter utilizzare il modello nella fase successiva, ovvero quella della modellazione architetturale, il significato di modello di piattaforma in questo contesto viene ampliato prendendo in considerazione il significato a livello sia funzionale sia di piattaforma di una struttura. Il metodo più comunemente adottato prevede la mappatura dal modello funzionale in quello della piattaforma.

A livello di progettazione architetturale vengono aggiunte ulteriori informazioni al modello comportamentale. Poiché il diagramma delle attività funzionali utilizza la piattaforma, è necessario prevedere l’allocazione e il rilascio di uno spazio di memoria per una memoria specificata. I valori assegnati per l’interfacciamento tra le funzioni e le piattaforme rappresenta la durata temporale. Tutti questi elementi, ovviamente, influenzano le prestazioni. Le prestazioni dell’intero sistema - utilizzo del bus, requisiti di memoria, dissipazione di potenza, costi - sono ricavati attraverso la simulazione.

Modellazione funzionale
La modellazione funzionale prevede le seguenti operazioni:
– analisi e modellazione dell’ambiente dell’intero sistema;
– definizione dei limiti del sistema con i suoi ingressi e le sue uscite;
– definizione del comportamento del sistema;
– sintesi del comportamento mediante un diagramma di attività e successiva verifica.
Le funzioni previste per lo switch comprendono la trasmissione dei frame, la ricerca della porta di destinazione in base alla tabella degli indirizzi, la memorizzazione dell’indirizzo della sorgente e del numero di porta associato e la valutazione della rete VLAN (Virtual Local Area Network).

La fase successiva definisce i confini del sistema e determina gli ingressi e le uscite. A questo stadio di progettazione funzionale le specifiche relative alla tecnologia di implementazione non vengono prese in considerazione poiché in questa fase è necessario ottenere come risultato una soluzione indipendente da una particolare tecnologia.

La modellazione ambientale prende in considerazione le interfacce a livello di sistema, in particolar modo le porte di ricezione (Rx), quelle di trasmissione (Tx) e l’interfaccia dello switch. Il progetto che si sta prendendo in considerazione è in grado di ospitare quattro porte Rx e altrettante Tx. L’interfaccia dello switch, dal canto suo, si preoccupa della configurazione dello stesso, compresa l’inizializzazione della tabella di indirizzi e della tabella della rete VLAN.

Al fine di realizzare un sistema scalabile, viene specificato un parametro generico denominato PortNo. Mediante i parametri generici è possibile la messa a punto dei parametri del sistema in modo da far girare le simulazioni senza dover procedere alla ricompilazione del modello. Una caratteristica di questo tipo permette di semplificare la misura delle prestazioni e il relativo confronto.

La configurazione stabilisce gli attributi per configurare il sistema. Questi attributo sono caratterizzati da un proprio tipo definito in conformità alle funzionalità dello switch. Una volta completata la configurazione, lo switch dà avvio all’istradamento dei frame. Producer ha il compito di generare i frame e di collocarli nelle corrispondenti code di messaggio FrameIn. Quando lo switch termina l’elaborazione dei frame, li colloca nelle corrispondenti code di messaggio Frame Out.

Comportamento del sistema di commutazione
Una volta definito l’ambiente del sistema è possibile studiare il comportamento dello stesso sotto svariati punti di vista. In primo luogo l’intero sistema viene descritto senza apportare alcuna miglioria. Da un punto di vista esterno, lo switch riceve i frame da un generatore (Producer) e li invia al ricevitore appropriato. Si tratta come si può vedere di una descrizione algoritmica molto astratta. La valutazione delle prestazioni (benchmarking) è basata su questo sistema astratto e può essere riutilizzata per il perfezionamento del sistema. Essa assicura la correttezza del primo prototipo dell’intero sistema di commutazione così come quello delle migliorie apportate nelle fasi successive.

Una volta verificato il modello astratto, questo viene perfezionato passo dopo passo: nella figura 2 viene rappresentato graficamente il sistema di commutazione finale.

Fig. 2 – Rappresentazione grafica del sistema di commutazione

Ciascuna istanza di Input Processing e Output Processing dispone del relativo Input Buffer e Output Buffer. La fu
nzione Routing si preoccupa di istradare il frame dall’InputBuffer della porta sorgente all’OutputBuffer della porta di destinazione. SharedBuffer dal canto suo viene impiegato per la configurazione che richiede una memoria centrale per memorizzare tutti i frame e non prevede il ricorso a Input Buffer o a Output Buffer.

In base alle caratteristiche di traffico di una tipica comunicazione Industrial Ethernet sono stati generati numerosi casi di test (test cases), realizzati usando un file Excel al fine di collaudare tutte le varie tipologie di situazioni di traffico. Il file XML viene generato dal file Excel e quindi letto dal testbench del modello ESL. Nel corso del presente articolo vengono presentati alcuni dei casi di test di utilizzo più frequente.

Il traffico Ethernet si distingue fra traffico burst e traffico base. Il traffico del primo tipo contiene i frame più corti, 64 byte, ed è contraddistinto da un fattore di carico pari al 100%. Il gap all’interno dei frame più corto è di 12 byte. Il traffico base, invece, contiene frame caratterizzati da lunghezza e fattore di carico variabili. I casi di test mettono in evidenza gli scenari nel caso peggiore (worst-case), come accade quando il traffico burst arriva contemporaneamente a uno switch da parte di tutti gli altri switch della rete, situazione questa particolarmente onerosa per la memoria.

Una volta definiti il diagramma funzionale e gli algoritmi per ciascun blocco funzionale, è possibile ricavare parecchie configurazioni. Il toolset ESL consente di configurare le diverse soluzioni in conformità ai requisiti dell’applicazione. Oltre è ciò è possibile inserire differenti algoritmi per le configurazioni. Al fine di ottenere diverse configurazioni allo stesso modello grafico vengono applicati vari schemi di pianificazione dello switch.

Esplorazione architetturale e analisi delle prestazioni
La piattaforma rappresenta la soluzione fisica presa in considerazione per il progetto al fine di supportare la soluzione funzionale. La ricerca della struttura appropriata richiede la progettazione di un architettura fisica. La piattaforma risulta composta dai processori e dalle relative interconnessioni, che possono prendere la forma di nodi di comunicazione e memoria condivisa. Un processore è in grado di far girare le funzioni, siano essere hardware oppure software. Dapprima si descrive la struttura della prima piattaforma che rappresenta i componenti fisici, senza prendere in considerazione nessuna miglioria a livello della piattaforma hardware (Fig. 3).

Fig. 3 – Modello della piattaforma: SimplestPlatform

Questa piattaforma astratta consente di effettuare la prima (e più semplice) mappatura dal modello funzionale su quello della piattaforma. Essa garantisce il corretto comportamento sia di Producer e Receiver sia di FrameIn e FrameOut dopo la mappatura. L’attenzione è concentrata sull’architettura dello switch centrale. Al fine di creare strutture di piattaforme più complesse è necessario procedere a una migliore definizione di SwitchProc. Le prime migliorie apportate alla piattaforma vengono illustrate in figura 4: qui CentralProc viene considerata un’unità di elaborazione hardware e sono state create due memorie condivise.

Fig. 4 – Modello della piattaforma: RefinedPlatform 1

Il toolset ESL può impostare differenti tipologie per un nodo di comunicazione: un bus, una rete di instradamento, un collegamento punto-punto oppure un modello esterno definito dall’utente. Se la tipologia di un nodo di comunicazione è un bus, l’interfaccia è allocata al nodo. È possibile far ricorso a una modalità di simulazione specifica relativa a un bus con caratteristiche di concorrenza e non viene generata alcuna interfaccia. Il risultato che si ottiene non è così accurato come quello che prevede un bus con un’interfaccia, ma assicura una velocità di simulazione più spinta. CentralBus, che collega SharedMem e CentralProc, è un bus allocato con interfacce. Il buffer condiviso, la tabella degli indirizzi e la tabella della VLAN sono mappate nelle memorie per analizzare l’influenza dell’ampiezza del bus. SimplestPlatform è stata perfezionata in un altro modo per creare RefinedPlatform2 rappresentata in figura 5. In questa piattaforma vi sono tre memorie, identificate come InputMem, OutputMem e TableMem.

Fig. 5 – Modello della piattaforma: RefinedPlatform 2

Modellazione architetturale
I modelli architetturali vengono creati mediante la mappatura del modello funzionale nel modello della piattaforma. Il tool di mappatura analizza le possibili soluzioni per ciascuna comunicazione funzionale in maniera automatica. L’utente sceglie le modalità della loro mappatura sui nodi di comunicazione sulla piattaforma e definisce i loro corrispondenti attributi.

SMMap_1Mem
Il primo modello architetturale è il risultato della mappatura del modello della memoria condivisa in RefinedPlatform1. L’obbiettivo è individuare la corretta ampiezza del bus e i requisiti di memoria del sistema. In questo modello architetturale, l’accesso alle tabella degli indirizzi (AddrT) e della VLAN (VLANT) e al frame buffer (SharedBuffer) viene eseguito attraverso il singolo bus condiviso (CentralBus). Esiste solo una memoria condivisa (SharedMem), ragion per cui il traffico su CentralBus dovrebbe essere abbastanza intenso.

SMMap_2Mem
Per la configurazione della memoria condivisa può essere generata un’altra memoria al fine di immagazzinare i dati in ingresso (entry) delle tabelle degli indirizzi e della VLAN. In questo modello architetturale AddrT e VLANT sono mappati in TableMem invece che in SharedMem.

OQMap_2Mem
Il modello architetturale è basato sullo schema di pianificazione Output Queue configurato nel modello funzionale e nel modello della piattaforma RefinedPlatform2. L’utilizzo dello schema OutputQueue prevede che i frame vengano istradati immediatamente al corrispondente OutputBuffer.

OQMap_3Mem
Se si analizza la precedente architettura si può notare che il traffico su InputBus è ancora intenso in quanto InputProcessing e Routing devono utilizzarlo per effettuare tutti gli accessi alla memoria, compresi quelli relativi a AddrT, VLANT e Input Buffer. Un’opzione possibile sarebbe quella di rimuovere AddrT e VLANT da InputMem e impostare un’altra memoria indipendente per memorizzare i dati in ingresso delle tabelle degli indirizzi e della VLAN in modo del tutto simile a quanto fatto con SMMap_2Mem. In questo caso l’accesso alle tabelle degli indirizzi e delle VLAN avviene attraverso TableBus e non tramite InputBus.

Altri tipi di architetture
Utilizzando la stessa metodologia, i medesimi modelli della funzione possono essere mappati nel modello della piattaforma RefinedPlatform2. Un’altra possibilità è quella di mappare AddrT e VLANT in InputMem o in TableMem. InputBuffer è mappato in InputMem e Output Buffer in OutputMem.

Alla fine è stato possibile ottenere sei soluzioni architetturali: IQMap_2Mem, IQMap_3Mem, VOQMap_2Mem, VOQMap_3Mem, PMVOQMap_2Mem e PMVOQMap_3Mem. Questi modelli architetturali sono stati verificati utilizzando il medesimo testbench come nel caso del modello funzionale. I dati definitivi relativi alle prestazioni sono ricavati da questi modelli architetturali al fine di procedere alla soluzione ottimale.

Analisi delle prestazioni
Per quanto concerne l’analisi delle prestazioni sono stati presi in considerazione gli aspetti che seguono.
Ampiezza del bus: essa naturalmente varia in base alle differenti architetture. Alcune utilizzano un solo bus, mentre altre prevedono più bus. Per il pro
getto che si sta analizzando sono state proposte due piattaforme, una con due e l’altra con tre bus. Le architetture IQMap_2Mem, VOQMap_2Mem e PMVOQMap_2Mem (ovvero tre delle sei soluzioni architetturali ottenute – si faccia riferimento alla prima parte) richiedono un InputBus bus a 64 bit a 125 MHz. Poiché è necessario assegnare un Output Bus a ogni porta, l’ampiezza di ognuno di essi è pari a 16 bit. Risulta di conseguenza ampliare in maniera semplice il numero di porte dello switch. In ogni caso è sempre necessario un bus singolo a 64 bit per SMMap.
Dimensione di memoria: per ottenere i requisiti in termini di memoria è stato utilizzato un particolare test che prevede un traffico di tipo burst. Nella figura 6 vengono riportati i risultati per l’architettura SMMap_1Mem.

Fig. 6 - Variazioni della memoria dello switch

Si può osservare che i requisiti di memoria aumentano in presenza di traffico burst, mentre diminuiscono quando questo traffico termina. Le condizioni del test prevedono durata del burst di 1 ms, periodo del traffico 100 ms e fattore di carico del traffico base pari al 12%. Se si imposta un fattore di carico superiore al 12%, i requisiti di memoria crescono continuamente. Il risultato appare ragionevole, perché la velocità aggregata di trasferimento di ingresso è 100 Mbps x 3 x 12% = 36 Mbps e la velocità di trasferimento di uscita è pari a 40 Mbps. La dimensione di memoria richiesta è di circa 60 kbyte. Utilizzando questo “test case” è possibile ottenere i requisiti in termini di memoria delle differenti architetture. Nel caso delle architetture IQMap, VOQMap e PMVOQMap, se si riduce l’ampiezza di InputBus lo switch funziona ancora, ma la dimensione della memoria aumenta continuamente. È necessaria una maggiore quantità di memoria per immagazzinare i frame che non possono essere inoltrati immediatamente verso l’uscita.

Colludo di priorità: lo switch deve essere in grado di trasferire i frame in base alla priorità, trasferendo dapprima i frame a più elevata priorità. Nella figura 7.1 è possibile osservare che all’incremento del fattore di carico i frame con priorità più elevata (cioè Prio4) sono caratterizzati dalla latenza inferiore. Questo fatto diventa più evidente tanto maggiore è il fattore di carico.

Modalità intercalata (Interleave) e non intercalata (Non-Interleave): nella figura 7.2 viene proposto il confronto tra le due modalità. La modalità intercalata consente la combinazione di celle che appartengono a differenti frame nella coda di ingresso dello switch, mentre nella modalità non intercalata tutte le celle che appartengono al medesimo frame devono essere elaborate prima delle altre celle presenti nei differenti frame. Il test effettuato ha permesso di dimostrare la superiorità della modalità Non-Interleave, che permette di ridurre la latenza media.

Confronto tra le regole per la scelta della coda: differenti regole per la selezione della coda danno luogo a prestazioni diverse (Fig. 7.3). La tecnica LQF (Longest Queue First) è un metodo di pianificazione della coda che assegna la priorità alla coda caratterizzata da più elevato numero di frame in attesa, mentre la tecnica RR (Round Robin) gestisce le code seguendo un ordine specifico, indipendentemente dal numero di frame contenuti in ciascuna coda. Le prestazioni offerte da questi due metodi sono abbastanza simili, anche se la modalità Random è instabile è può introdurre in molti casi una maggiore latenza.

Confronto tra le latenze dei frame: osservando la figura 7.4 si può vedere che la latenza di IQMap_3Mem è molto grande, mentre i migliori risultati si ottengono con SMMap_2Mem in quanto la funzione Routing non deve leggere da InputBuffer e scrivere su OutputBuffer. Durante l’elaborazione di un frame, lo switch deve eseguire operazioni di scrittura e lettura su SharedMem una sola volta. Poiché CentralBus non può essere suddiviso in singole porte, le possibilità di espansione risultano alquanto limitate. Con PMVOQMap_3Mem è possibile ridurre la latenza del frame. Poiché OutputBus, la cui ampiezza pari a 64 bit, può essere suddiviso in quattro bus, per ciascuna porta è necessario un bus di ampiezza di 32 bit.

Fig. 7 – Risultati desunti dall’analisi delle prestazioni dello switch

Un’architettura come questa è in grado di garantire prestazioni elevate: nel caso il fattore di carico sia inferiore al 90%, la latenza media è anche inferiore rispetto a quella di OQMap_3Mem. Gli switch con coda di uscita sono in grado di garantire le prestazioni ottimali. In ogni caso lo switch opera in modalità “store-and-forward”: l’architettura OQMap_3Mem deve accedere alla memoria quattro volte (una lettura e una scrittura su InputMem e una lettura e scrittura su OutputMem). La latenza del frame può aumentare considerevolmente. Nonostante questo svantaggio, è possibile ottenere prestazioni migliori rispetto a quelle conseguibili con IQMap_3Mem e VOQMap_3Mem. Nei casi in cui il fattore di carico risulti molto elevato, questa architettura risulta più stabile rispetto alle altre.

Analisi dei risultati conseguiti
Come si è visto nel corso dell’articolo, il team di progetto ha sviluppato differenti architetture e confrontato i risultati della simulazione per analizzare vantaggi e svantaggi. In passato il confronto tra le architetture prevedevano l’uso di calcoli e analisi mediante tabelle Excel, basate in larga misura sul know how acquisito dagli architetti di sistema. In questo caso l’esame dei risultati ha permesso al team di prendere confidenza con la metodologia ESL.

I risultati ottenuti in questo progetto si possono riassumere nei seguenti punti:
– definizione dell’ampiezza del bus e dei requisiti per le varie architetture;
– dimensionamento accurato della memoria grazie all’analisi di vari scenari di traffico, come ad esempio il traffico burst;
– miglioramento delle prestazioni del sistema reso possibile dalla separazione tra la memoria della tabella della VLAN e della tabella degli indirizzi dalla memoria del frame;
– confronto accurato tra le latenze del frame per determinare l’algoritmo di scheduling capace di assicurare le migliori prestazioni.

Per realizzare il sistema in tempi rapidi è stato utilizzato CoFluent Studio. Le funzionalità di questo toolset hanno consentito di valutare in maniera efficace le problematiche legate alle prestazioni, come ad esempio la dimensione della memoria e l’ampiezza del bus. Per la creazione di cinque modelli funzionali perfezionati e la verifica del loro comportamento ci sono voluti all’incirca un paio di mesi.

I modelli funzionali sono stati mappati nei modelli della piattaforma e tutti i dati relativi alle prestazioni sono stati ricavati in due settimane. L’analisi delle prestazioni ha permesso di dedurre che la separazione della memoria della tabella della VLAN e della tabella degli indirizzi dalla memoria del frame ha permesso di incrementare le prestazioni del sistema, mentre l’ampiezza del bus tra la memoria del frame e le unità di elaborazione può essere ridotta. I requisiti in termini di dimensioni della memoria sono simili per tutte le architetture. I dati relativi alle prestazioni sono stati ottenuti dalla simulazione e quindi risultano più accurati rispetto a quelli che si possono ricavare con metodi di analisi statica. L’esame dei risultati della simulazione ha permesso di concludere che la criticità del sistema è rappresentata dal buffer che può memorizzare i frame in ingresso. L’elemento della piattaforma che può rappresentare il buffer è la memoria, il cui sviluppo è divenuto l’obiettivo principale del progetto dello switch.

La tabella degli indirizzi e la tabella della VLAN sono stati individuati come “colli di bottiglia” critici; la generazi
one di soluzioni architetturali differenti ha consentito di determinare l’architettura migliore per la realizzazione hardware. Mediante la rimozione della memoria della tabella dalla memoria del frame e la creazione di un bus separato, è stato possibile ridurre l’ampiezza del bus tra l’unità di elaborazione e la memoria del buffer del frame.
I test case sono stati creati in un file Excel: il file XML ha permesso l’interoperabilità di CoFluent Studio ed Excel con i “test cases”. Il modello dello switch generato in CoFluent Studio può essere utilizzato come una specifica eseguibile della successiva implementazione TML o RTL. I testbench CoFluent utilizzati per il collaudo del modello possono essere pure riutilizzati per il collaudo di modelli TML o RTL.

TRIAS Mikroelektronik 

Kai Liu

• 
• Tweet
• Pin It
• Condividi per email