ARM CoreSight è la tecnologia sviluppata da ARM per eseguire il debug ed il trace non invasivi sui sistemi di tipo SoC (System-On-Chip). Una delle funzionalità aggiunte a questa tecnologia è rappresentata dal System Trace Macrocell, che scopriremo in questo articolo.
La tecnologia ARM CoreSight fornisce una soluzione completa per il debug ed il trace rivolta alle applicazioni basate sui System-On-Chip (SoC), dai più semplici di tipo single-core fino a quelli più complessi di tipo multi-core. La tecnologia CoreSight è basata su un sistema di macrocelle, modulare e flessibile, costruito attorno all’Embedded Trace Macrocell (ETM), largamente diffusa e supportata dallo strumento di sviluppo per ARM RealView.
I fattori chiave Coresight
I vantaggi principali che derivano dall’utilizzo di questo strumento diagnostico si possono riassumere nel modo seguente:
- elevata visibilità sul funzionamento completo del sistema, attraverso un’interfaccia di debug con numero ristretto di pin;
- soluzione di tipo standard adottabile da diversi vendor tramite licenza e supportata da numerosi strumenti di sviluppo;
riutilizzabile per sistemi ARM singlecore, multi-core, o DSP; - permette di ridurre i tempi di sviluppo dell’applicazione software contribuendo a rilasciare dei prodotti affidabili con elevate prestazioni.
Il debug con Coresight
In figura 1 è mostrato uno schema a blocchi relativo all’architettura CoreSight applicata ad un tipico esempio di SoC. I sistemi CoreSight utilizzano una particolare porta per il debug, detta Debug Access Port, attraverso la quale il debugger software può accedere in modalità realtime alle catene di scansione JTAG presenti all’interno del dispositivo, al bus system AMBA, ed a tutti i registri di configurazione relativi al trace e al debug. Nel caso di sistemi multi-core, la DAP viene mantenuta attiva anche se uno dei core è disabilitato oppure è in modalità sleep. La DAP è un esempio di bridge realizzato tra il clock di debug esterno e domini multipli di core sul SoC. Ciò permette anche di mantenere la comunicazione di debug con ogni core, anche quello con la frequenza più alta in assoluto, a differenza di una daisy-chain JTAG dove si deve utilizzare la fequenza più bassa tra quelle disponibili su tutti i core.
Figura 1: architettura CoreSight.
Embedded Cross Trigger (ECT)
L’ECT si compone di una matrice Cross Trigger e di un blocco di interfaccia Cross Trigger. La prima fornisce dei canali attraverso i quali gli eventi di debug possono passare, sia attraverso i core che l’ETM. Nei sistemi multi-core, dove vengono adottate tecniche di comunicazione IPC (Inter Process Communication) e memoria condivisa, è estremamente importante poter fermare e far ripartire tutti i core in modo sincrono. Per assicurare che questa sincronizzazione avvenga entro un numero ristretto di cicli di clock, viene utilizzata una matrice Cross Trigger. L’interfaccia Cross Trigger fornisce invece la logica di controllo per collegare gli eventi di debug con ciascun canale della matrice.
Embedded Trace Macrocell (ETM)
La macrocella ETM esegue il monitoraggio dei bus interni del core, consentendo di catturare informazioni specifiche sull’attività del processore (sia dati che istruzioni), sia prima che dopo il verificarsi di uno specifico evento, senza impattare sulle prestazioni del processore e lasciando che esso possa funzionare a piena velocità. Le informazioni acquisite con il trace vengono compresse (si può arrivare ad una media di 1 singolo bit per ogni ciclo di CPU), e la disponibilità di potenti filtri configurabili via software e di trigger logici permette agli sviluppatori di selezionare quali istruzioni e dati occorre catturare, prima ancora di eseguire la compressione fisica. Il trace in formato compresso può essere trasferito all’esterno del chip tramite la porta dedicata Trace Port Interface Unit, oppure può essere memorizzato nell’Embedded Trace Buffer (ETB), quindi on-chip. La Trace Port Interface Unit esegue la formattazione e la trasmissione dei dati all’esterno del chip, con frequenze asincrone rispetto a quella del core. I trace vengono trasmessi come sequenze di byte, ciascuna identificata da uno specifico ID sorgente: in questo modo è così possibile trasmettere trace multipli attraverso una singola porta di trace. La trace port si può configurare sia durante la fase di sintesi del SoC, che via software, con un’ampiezza compresa tra 2 e 34 pin ed una frequenza da un minimo di 1 kHz al massimo supportato dal sistema target. Con riferimento alla figura 2, osserviamo la presenza del Trace Funnel, la cui funzione è quella di combinare sorgenti multiple di trace in un unico bus, chiamato AMBA Trace Bus (ATB), il quale seleziona le singole sorgenti basandosi su tecniche di arbritaggio e priorità. Analogamente, in figura 3 viene mostrata la funzionalità della macrocella ITM. L’ETM implementa in pratica, direttamente a livello hardware, un meccanismo di trace hardware, e si suddivide in tre categorie principali:
- trace delle istruzioni (program trace). È particolarmente utile per eseguire il debug sia a livello software che hardware. Le dimensioni delle macrocelle di tracesono in genere abbastanza ridotte (ad esempio l’ARM Cortex-M3 ha un ETM di circa 7.000 porte logiche), e si ottiene anche un buon valore di compressione dei dati (si può arrivare fino a circa 1 bit per ogni istruzione di CPU). Ne consegue che anche i requisiti di banda relativi alla porta di trace non sono molto stringenti; una RAM da 4KB è ad esempio sufficiente per memorizzare 30.000 linee di codice assembler , e si possono così eseguire sessioni di trace che durano anche diverse ore oppure giorni interi;
- trace dei Esistono alcune categorie di problemi per le quali è necessario disporre anche di un trace relativo ai dati (indirizzi dei dati e/oppure valore dei dati), si pensi soprattutto ai casi di errore di coerenza dei dati, di corruzione della memoria, o anche di problemi hardware legati alla memoria dati. Il trace dei dati è quello che comporta il costo maggiore, in quanto le dimensioni delle macrocelle sono maggiori, è difficile comprimere efficacemente i dati (si arriva a circa 1-2 byte per istruzione), e le porte di trace devono essere più veloci;
- trace del bus.
Figura 2: debug su SoC multicore.
Figura 3: CoreSight Instrumentation Trace Macrocell
Coresight Serialwire
L’interfaccia SerialWire permette di eseguire il debug attraverso un’interfaccia seriale composta di due soli fili, equivalente, ma con prestazioni superiori, rispetto alla tradizionale interfaccia JTAG a 5/6 pin.
Il System Trace Macrocell
L’architettura CoreSight si è ampliata con l’introduzione di due macrocelle: il System Trace Macrocell (STM), ed il Trace Memory Controller (TMC). L’STM è stato progettato per eseguire il trace del sistema sia dal punto di vista software (impiegando delle apposite porte di stimolazione del software mappate in memoria) che hardware. I dati acquisiti dall’STM vengono compressi e memorizzati in un buffer di trace, che può risiedere sul chip oppure al suo esterno. Come visibile sempre in figura 1, l’STM si collega direttamente al bus principale di sistema AXI, e questo permette di avere un punto di accesso flessibile con ampia larghezza di banda e bassa latenza, che può essere utilizzato da qualunque dispositivo master del sistema (ad esempio la CPU, il controllore DMA, la GPU, ecc.) per generare informazioni utili per il trace. STM supporta anche la funzionalità di generazione del timestamp, abilitando la correlazione temporale dei flussi di messaggi generati da un qualunque master. I flussi di trace possono viaggiare su canali hardware dedicati e pertanto comportano un overhead a livello di prestazioni estremamente ridotto, soprattutto se paragonato alle tradizionali tecniche di trace puramente software. Ciò consente, ad esempio, di abilitare il trace direttamente sui dispositivi di produzione, memorizzare i dati acquisiti in memoria volatile, ed eseguire poi il download attraverso canali di comunicazione wireless oppure tramite la porta di debug SerialWire (due soli pin anzichè i 5 richiesti come minimo dalla JTAG). Oltre ai flussi di trace prodotti dal bus di sistema (tramite la Bus Trace Macrocell) e da altre unità di elaborazione, è possibile anche raccogliere informazioni sugli eventi che si verificano nel sistema, e questa informazione viene corredata con un timestamp in modo tale che possa essere successivamente correlata con tutti gli altri trace del sistema. Il System Trace Macrocell, come il suo predecessore Instrumentation Trace Macrocell, viene configurato e controllato tramite un software di basso livello. La configurazione e gestione dell’STM è infatti eseguita scrivendo in appositi registri mappati in memoria, ed il trace stesso viene memorizzato in una periferica mappata in memoria.
Vantaggi di STM
STM si propone come il successore naturale del CoreSight Instrumentation Trace Macrocell (ITM) per applicazioni di medie/elevate prestazioni. STM presenta i seguenti vantaggi rispetto alla precedente tecnica ITM:
- un’interfaccia slave dedicata di tipo AXI in grado di ricevere le informazioni di instrumentazione del software. Questa soluzione comporta una latenza significativamente inferiore rispetto all’interfaccia APB dell’ITM, ed è separata dall’APB per quanto riguarda la programmazione dei registri STM;
- più processori e differenti processi possono condividere ed accedere direttamente all’STM senza essere a conoscenza di ciò che fanno gli altri processori o processi; a ciascuno di essi viene infatti assegnato un canale differente (indicato anche con il termine “stimolo STM”). Sono disponibili 128 master, ciascuno dei quali supporta 536 porte di stimolazione; ad ogni gruppo di 16 porte di stimolazione sono associati 4KB di memoria. L’ITM supportava invece solo 32 canali;
- l’STM può, opzionalmente, chiedere all’AXI di mettersi in attesa quando la sua coda FIFO si riempie completamente, assicurando così che non vi sia alcuna perdita di dati a causa di overflow, e senza dover eseguire il polling via software dello stato della coda FIFO. Questo comportamento dipende dall’indirizzo a cui si scrive, e può pertanto essere controllato indipendentemente da ogni porta di stimolazione;
- una coda FIFO migliorata e configurabile, in grado di supportare fino a 32 word di dati, riduce il rischio che la coda FIFO si riempia velocemente. L’ITM disponeva invece di una FIFO a word singola;
- il timestamp può essere richiesto individualmente per ogni scrittura, basandosi sull’indirizzo a cui si esegue la scrittura. L’ampiezza di banda può poi essere ottimizzata richiedendo un timestamp unico per una sola scrittura in un messaggio composto da una successione di scritture multiple;
- i timestamp relativi all’STM sono correlati automaticamente con i timestamp prodotti dalle altre sorgenti di trace presenti nel sistema CoreSight, abilitando perciò una correlazione automatica, ad esempio, con il program trace prodotto dal Le specifiche dell’architettura STM sono compatibili all’indietro con l’ARMv7M e con il modello di programmazione del CoreSight ITM. Ciò consente di eseguire una transizione agevole dal software scritto per un ARMv7-M o per il CoreSight ITM verso un’applicazione basata sulla macrocella STM. Oltre all’interfaccia slave AXI (acronimo di Advanced eXtensible Interface), STM fornisce anche un’interfaccia per gli eventi a livello hardware, che traccia i segnali connessi a questa interfaccia sul loro fronte di salita. In figura 4 e figura 5 è mostrata la macrocella STM integrata in un tipico sistema. L’interfaccia AXI slave è connessa ad un sistema che abilita tutti i sistemi master, come processori e controllori DMA, alla generazione di trace scrivendo sulle porte di stimolazione STM.
Per finalità di configurazione, l’STM è connesso al debug APB, in modo tale da consentire l’accesso da parte di agent di debug sia on-chip che offchip. Il trace prodotto da STM viene emesso tramite l’interfaccia ATB ed integrato con il resto dell’infrastruttura di trace CoreSight.
STM: caratteristiche
Le caratteristiche di STM si possono riassumere nel modo seguente:
- sistema sincrono con un clock e due reset;
- interfaccia AXI slave a 32-bit utilizzata come porta di stimolazione di ingresso;
- interfaccia hardware per il monitoraggio degli eventi (fino a 32 eventi distinti);
- interfaccia slave a 32-bit APB (Advanced Peripheral Bus) per la configurazione e la lettura dello stato;
- interfaccia master a 32-bit ATB (Advanced Trace Bus) per l’uscita del trace;
- interfaccia DMA compatibile con il controllore AMBA DMA-330;
- due buffer FIFO con profondità configurabile;
- software di stimolazione memorymapped con supporto per 536 porte di stimolazione e 128 master;
- compressione dei dati;
- timestamp degli eventi di trigger; STM – schema a blocchi
In figura 5 sono mostrati i principali blocchi funzionali che compongono l’STM. La selezione di quale porta di stimolazione e quale evento hardware debba essere tracciato è basata sullo stato e sulla programmazione dell’interfaccia di autenticazione. Le informazioni provenienti dalle due interfacce, AXI e hardware, sono arbitrate attribuendo una priorità maggiore ai dati che arrivano dall’AXI; l’informazione di trace viene poi presentata alla logica di generazione dei pacchetti, dove viene aggiunto il timestamp ed organizzata scondo il protocollo STPv2. I pacchetti STPv2 vengono quindi fatti confluire nel flusso che viene emesso tramite l’interfaccia ATB. In caso di overflow, cioè quando la FIFO STM è piena, l’STM può sia portare in stallo (attesa) l’interfaccia AXI, oppure scartare i dati che arrivano segnalando la condizione di overflow nel flusso di trace. Lo stesso discorso si applica anche agli eventi hardware. Periodicamente, l’STM trasmette inoltre una sequenza di sincronizzazione affinchè i ricevitori del trace possano allinearsi al flusso di trace emesso. Per quanto riguarda i segnali di clock, l’STM dispone di un singolo segnale di clock in ingresso (CLK), sincronizzato con il clock del bus di sistema. Nel caso in cui l’interfaccia STM si connetta ad un bus con un clock differente, occorre impiegare un bridge asincrono. Sono invece disponibili due segnali di reset: ARESETn e STMRESETn. Il primo serve a resettare soltanto il blocco AXI slave ed il DMA, mentre il secondo resetta i restanti blocchi dell’STM.
Figura 4: il sistema STM integratoSTM integrato
Figura 5: schema a blocchi dell’STM.
Conclusioni
Con l’avvento dei System-On-Chip (SoC), il software è diventato la voce di costo predominante nel ciclo di vita di un prodotto. Il successo di un prodotto dipende fortemente dalla disponibilità del software al momento giusto, con prestazioni e standard qualitativi adeguati. Diventano pertanto fondamentali gli strumenti di debug e trace. Molti sistemi di debug attuali sono però invasivi e forniscono una visibilità limitata a livello di sistemi complessi multi-core e multi-processore. ARM CoreSight, per contro, è diventato lo standard per il debug ed il trace dei sistemi basati su architettura ARM, in grado di agire in modalità real-time, non invasiva, senza alterare le prestazioni del sistema sotto indagine. La macrocella STM, aggiunta alla versatile, modulare, e flessibile architettura CoreSight, estende le funzionalità di trace e la visibilità sull’intero sistema.
