• analog front end biomedicale
• analog on top
• biomedicale
• ecg
• heart rate detection
• pan tompkins

In questa attività di tesi, svolta in collaborazione con la sede di Cornaredo di STMicroelectronics, viene descritto il processo che ha portato dallo studio alla successiva implementazione su Analog Front End (AFE) proprietario di algoritmi per la rilevazione del battito cardiaco.
La soluzione pensata dall'azienda è quella di sviluppare un AFE in grado di eseguire autonomamente l'elaborazione digitale del segnale proveniente dal sensore, senza la necessità di utilizzare processori esterni: questo porta una serie di vantaggi, come la riduzione dell'ingombro e la riduzione dei consumi, rendendo il prodotto più appetibile sul mercato. Il dispositivo sarà quindi di natura embedded, con numero di risorse limitato e requisiti low-power da rispettare. La IP è sviluppata con la stessa tecnologia proprietaria di ST utilizzata per i MEMS (130nm), con un approccio di tipo Analog on Top.
L’ambiente di sviluppo e test della IP è in linguaggio python, quindi sia per la facilità di transizione dalla fase di modellazione dell’algoritmo verso l'implementazione hardware, sia per la disponibilità di pacchetti open-source, la tesi è stata sviluppata in questo linguaggio.
In generale, la rilevazione del battito cardiaco può essere effettuata a partire da segnali di natura diversa: i principali sono quelli ottenuti mediante elettrocardiografia (ECG) e pletismografia (PPG). Le due tecniche differiscono per il meccanismo fisico di funzionamento. In linea generale possiamo dire che la prima fornisce una panoramica sulla salute del cuore, mentre la seconda fornisce principalmente la frequenza cardiaca.
E' stata fatta la scelta di utilizzare segnali di natura ECG, lasciando aperta la possibilità di utilizzare anche i PPG in futuro.
Si è quindi eseguita una ricerca bibliografica, per individuare le migliori tecniche per risolvere il problema. Qui si distinguono due filoni principali, quello che utilizza algoritmi euristici e quello basato sull'impiego di reti neurali (machine learning).
Le euristiche hanno il vantaggio di essere semplici da implementare, permettendo un ridotto consumo di risorse. Sono costituite da una fase di pre-processing del segnale, seguita da un blocco decisore che individua gli istanti in cui è presente un battito seguendo una precisa logica. Viceversa, gli approcci basati su reti neurali permettono di ottenere ottimi risultati, a scapito di maggior risorse computazionali, oltre ad una fase di addestramento che deve essere svolta su un insieme di dati il più generico possibile, pena l'eccessiva specializzazione della rete sul dataset, con conseguente malfunzionamento in contesti reali.
Visti i motivi appena esposti, unito ai risultati comparabili tra le due soluzioni (da bibliografia) ed al fatto che non siamo interessati a rilevare condizioni patologiche, si è optato per l'utilizzo di algoritmi euristici.
A seguito di ricerca in letteratura sullo stato dell’arte, è stato selezionato un sottoinsieme di tecniche ritenute più vantaggiose in base al trade-off tra accuratezza e risorse richieste.
E’ stata messa a punto una procedura di valutazione in Python, per la validazione ed il calcolo delle performance degli algoritmi: le metriche utilizzate sono sensibilità e precisione, in modo da potersi confrontare con i risultati dichiarati dagli autori.
Come punto di partenza sono state utilizzate le implementazioni create da Porr e Howell dell'Università di Glasgow: i due ricercatori, in una loro pubblicazione hanno descritto il funzionamento dei migliori algoritmi di heart-beat detection, oltre a fornire un valido dataset ECG. Il dataset utilizzato nella maggior parte dei paper infatti, l'MIT-BIH Arrythmia Database, contiene una serie di imprecisioni che rischiano di falsare i risultati ottenuti. Tramite la procedura di valutazione è stato possibile selezionare gli algoritmi che restituivano i migliori risultati, che sono stati il "Pan-Tompkins", "Matched Filter" e "Stationary Wavelet Transform", dove gli ultimi due prendono il nome dalla tecnica utilizzata per la determinazione del battito. Questi tre algoritmi inoltre condividono il blocco decisore, rendendo più semplice l'implementazione hardware finale.
I modelli sono stati successivamente modificati per risolvere una serie di problematiche che ne degradavano le performance. Queste comprendono la modifica delle frequenze di taglio dei filtri, la modifica della logica del decisore (al fine di migliorare l'individuazione dei battiti e diminuire i falsi positivi), o la rimozione di componenti indesiderate dal segnale. Questi cambiamenti hanno condotto ad un notevole miglioramento delle performance, portando sensibilità e precisione oltre il 90% per tutti e tre gli algoritmi scelti pur rispettando le specifiche sui limiti computazionali.
Per adattare i modelli al funzionamento hardware, sono seguite due ulteriori cambiamenti.
Il primo consiste nella riscrittura dei blocchi che lo compongono per funzionare in real-time, in modo che in seguito all'acquisizione ed elaborazione di un campione, segua un'uscita per ogni ciclo di funzionamento.
La seconda prevede l'utilizzo dell'aritmetica floating point a 16 bit (IEEE754 half precision floating point): nella analisi degli algoritmi sopramenzionata, infatti, i dati erano elaborati in formato float a doppia precisione, cioè su 64 bit. Il motivo di questa scelta è dato dalla maggiore velocità di esecuzione delle operazioni rispetto all'utilizzo di un'aritmetica fixed point che, nonostante sia più snella dal punto di vista hardware, richiede una serie di controlli sulla dinamica che ne rallentano il funzionamento. Inoltre il processore custom a bordo dell'AFE disponde già di una floating point unit (FPU) a 16 bit.
Grazie all'utilizzo di funzioni Python precedentemente sviluppate dal team interno, è stato possibile simulare e valutare il funzionamento del modello con aritmetica Half Precision. La riduzione del numero di bit non ha comportato un degrado delle performance, che si sono mantenute in linea con quelle a doppia precisione.
Nella parte conclusiva si è proseguito con l'implementazione hardware. Questo è composto a grandi linee da una IP deputata alla gestione della catena analogica (fasi, compensazioni, trimming,..), da un processore custom e da una memoria FIFO per la comunicazione con un host processor esterno. L’implementazione avviene tramite uno script Python, sviluppato precedentemente dal team: questo modellizza le operazioni che eseguirà il processore come una serie di blocchetti tra di loro concatenati. Inoltre si occupa del caricamento in memoria RAM dei corrispettivi parametri necessari al funzionamento.
Visto che l’IP è basata su ROM di programma e data l’ottimizzazione richiesta, il codice è stato scritto utilizzando l'assembly specifico del processore.
Alcuni blocchi DSP erano già presenti sia in modello comportamentale Python che in formato assembly, mentre altri, come quello del decisore, sono stati fatti da zero. Per il test su hardware, sono state fatte simulazione RTL tramite il software SimVision di Cadence.
In particolare, lo script Python preesistente genera per ogni ciclo di funzionamento i valori delle uscite da ogni blocco e le salva in un file. Questi valori sono poi confrontati con quelli ottenuti in real-time durante la simulazione RTL in modo automatico, per verificare che l'implementazione hardware si comporti come il corrispettivo modello. La fase di verifica è stata eseguita utilizzando sia segnali ad ampia dinamica, per valutare la presenza di problematiche di overflow/underflow, che segnali ECG presi dal dataset di partenza.
Per come è fatta la IP che sfrutta ROM di programma, il processore custom esegue all'interno del ciclo una serie di operazioni fisse. Per questo motivo è stato progettato un blocco condizionale, posto a valle del decisore, che permette la scrittura in memoria FIFO solo quando avviene la rilevazione di un battito. Inoltre, questo blocco riduce sensibilmente la quantità di dati scambiati con l’esterno, passando dal sample rate del segnale di ingresso a circa [0.5-3.3Hz], con conseguentemente riduzione del contributo al consumo di potenza a livello di sistema.
Una volta verificata la coerenza tra modello software e simulazione hardware sia in pre che post-layout, sono state fatte stime di potenza, del tempo di esecuzione e dell'occupazione di area.
In conclusione sono stati effettuati dei confronti con soluzioni RTL reperiti presenti in bibliografia.
Sono poi evidenziati gli aumenti in performance dal punto di vista algoritmico rispetto alle soluzioni già esistenti in letteratura nonché possibili miglioramenti futuri.
Le modifiche alla IP necessari per l’integrazione dell’heart rate detection sono state implementate in un testchip e verranno validate quando i pezzi saranno disponibili.