DIGITAL
SoC CO-DESIGN
47
- ELETTRONICA OGGI 456 - SETTEMBRE 2016
Dopo aver usato il modello ad anello di controllo per regolare il
controllore, la fase successiva consiste prevede la verifica del
controllore in simulazione usando modelli fedeli che includono le
periferiche. Per questo motivo è necessario integrare modelli di
specifica accurati nelle temporizzazioni per i componenti in C e in
HDL del controllore. Questi modelli di specifica sono dotati della
semantica necessaria per la generazione di codice in C e in HDL.
Con la simulazione si verifica quindi che il sistema con i modelli di
specifica ricalchi fedelmente il modello ad anello di controllo. Una
volta che le prestazioni sono state validate con i modelli ad alta
fedeltà, si passa alla prototipazione del controllore su hardware.
Seguendo il flusso di lavoromostrato in figura 1, si inizia generan-
do il core IP. Il flusso di lavoro per la generazione di quest’ultimo
permette di scegliere la scheda di sviluppo di riferimento e di ef-
fettuare la mappatura delle porte di ingresso e di uscita dell’unità
verso le interfacce di destinazione, inclusa l’interfaccia AXI4 e le
porte esterne. Attraverso l’integrazione con la Suite di Progettazio-
ne Vivado, il flusso di lavoro genera il bitstream e programma la
matrice del SoC Zynq-7020. Con il core IP ora caricato all’interno
del dispositivodi destinazione,il passo successivo consiste nel ge-
nerare codice C dedicato a partire dal modello Simulink relativo al
core ARM. Il processo di generazione del codice C, di compilazio-
ne e di produzione del file eseguibile con Linux embedded è com-
pletamente automatizzato, e il prototipo è quindi pronto a operare.
Per eseguire l’hardware del prototipo e verificare che fornisca
risultati coerenti con i modelli di simulazione, si realizza un mo-
dello Simulink modificato (Fig. 4a) da utilizzare come pannello
di controllo ad alto livello. In questo modello è stato rimosso il
modello di simulazione per l’apparecchio – ossia, l’elettronica
di pilotaggio, il motore, il carico e il sensore – sostituito con gli
I/O per la ZenBoard. Usando questo modello in una sessione
Simulink, è possibile avviare il motore, scegliere diversi profili
di stimoli, monitorare i segnali relativi e acquisire i dati per una
post-elaborazione successiva in MATLAB, ma per il momento si
ripete il test dell’impulso (Fig. 3). La figura 4b mostra i risultati
ottenuti per la velocità di rotazione dell’albero e per la corrente di
fase del prototipo hardware, confrontati con i risultati della simu-
lazione. La sequenza di avvio del prototipo hardware differisce
sensibilmente da quelle dei due modelli di simulazione. Ciò è tut-
tavia prevedibile perché l’angolo iniziale fra il rotore del motore
e lo statore nel test dell’hardware differisce dall’angolo iniziale
usato in simulazione, producendo una risposta diversa, dato che
l’algoritmo di controllo in corrente aziona il motore tramite la mo-
dalità di calibrazione del suo encoder.
Quando l’impulso è applicato a 2 secondi, i risultati della simula-
zione e dell’hardware di prototipazione corrispondono pressoché
esattamente. In base a questi risultati è possibile procedere con
ulteriori test sotto diverse condizioni di carico e operative, o effet-
tuare direttamente ulteriori ottimizzazioni in C e in HDL.
La collaudata tecnologia di generazione di codice in C e in HDL,
unitamente al supporto hardware per i SoC interamente program-
mabili, permette di implementare un processo rapido e ripetibile
per ottenere algoritmi funzionanti su hardware reale.
La verifica continua fra l’ambiente di simulazione e l’ambiente har-
dware consente ai progettisti di identificare e risolvere criticità fin
dalle prime fasi del processo di sviluppo.
MathWorksmette a disposizione il supporto al flusso di lavoro per
le schede di sviluppo basate su prodotti Zynq, i kit per la realizza-
zione di radio SDR e i kit per il controllo del motore.
Fig. 4(a) – Modello Simulink per collaudare l’hardware del prototipo
Fig. 4(b) – Confronto fra i risultati della prototipazione hardware e
della simulazione