Completato nuovo AVR Soft-Core Radiation Hardened

[deluca]

Salve a tutti,

proprio qualche giorno fa, presso i Laboratori di Progettazione Elettronica dell' INFN di Catania, abbiamo completato con successo la sintesi di un SuperAVRcore, da impiegare nello slow-control di apparati elettronici durante esperimenti di fisica nucleare, con il quale è possibile emulare in buona parte i micro 8/16bit Risc AVR di Atmel. L'hardware è stato descritto interamente in (generic) VHDL ed è stato sintetizzato su una Fpga Stratix Altera 1S25F672C utilizzando 3251 Logic Element su 25660 disponibili, il (13%) delle risorose Hw. (Le altre risorse ci serviranno per implementare altre periferiche come ad esempio un CORDIC per calcoli trigonometrici veloci e un coprocessore per calcoli a virgola mobile).
Abbiamo sviluppato il SoftCore con architettura Radiation Hardened implementando la codifica e decodifica Hamming per evitare fault per la presenza di bit-flips causati dalle radiazioni ionizzanti. La frequenza di clock a cui può lavorare il SoftCore AVR, è di circa 10 volte superiore degli AVR convenzionali. Possiamo tranquillamente superare i 100-150 Mips (dipende dalla FPGA impiegata). La possibilità di implementare molti micro uguali sullo stesso core utilizzando il "Triple Modular Redundancy" ed un Voter in uscita permette di avere una certezza sui risultati dei dati elaborati. Il passo successivo, visto che è possibile il porting del VHDL nativo, sarà quello di sintetizzare il core e gli altri IP in FPGA resistenti alle radiazioni ionizzanti della ACTEL.




Il top-level entity

Di seguito sono riportate alcune specifiche basilari del superAVRcore:

Core Freq > 150Mhz - 150MIPS with PLLx3 - Versione stabile 100Mhz
128K ROM sintetizzabile
32K RAM Hamming protected (espandibile fino a 64Kb)
5 porte I/O 8bit PA,PB,PC,PD,PE - <30 nSec toggle Time !!
UART 100% AVR compatible
Timer 16bit
Timer 8bit
Input ICP
Input T0 e T1
Fast PWMout 10bit - 40Khz
I2C TWI - 100 / 400 Khz
SPI - up-to 8 Mbit/sec
External Interrupts Int0 e Int1

Compatibilità 100% con il firmware per AVR Atmel, tools used: AVRstudio, Wiring, WinAVR, AVR-GCC, Bascom-AVR, Codevision, ICC ed altri.

Ultimo aggiornamento - 3/05/2012

[flz47655]

Molto interessante, siete partiti da qualche progetto open?
Quanto tempo ci può volere per un progetto così?
Il fatto che ci sia una sorta di verifica dell'integrità della RAM lascia supporre che ci saranno radiazioni, ma la memoria che contiene la configurazione dell'FPGA non rischia di corrompersi se non ha una correzione degli errori?
Ottimo lavoro ad ogni modo, ciao

[deluca]

Il firmware HEX generato con la compilazione del sorgente, viene convertito in VHDL e sintetizzato insieme a tutti i moduli.
Al power-up appena dopo lo scaricamento del bitstream, il codice fw, a configurazione ultimata, esegue una sorta di test di tutti i moduli del micro e delle periferiche per ricercare eventuali anomalie (il tutto avviene in pochissimi cicli macchina).
E' possibile effettuare questi test durante dead-cycles così da essere certi che tutti i moduli funzionino per tutto il tempo di analisi.
Eventuali anomalie vengono loggate e trasmesse all'unità esterna di elaborazione.

NB. Questo Soft-Core verrà utilizzato in applicazioni ove è previsto l'impiego di un micro risc minimale al posto di micro non Radiation-Hardened.

Comunque stiamo trasferendo il tutto su Stratix III che permette una analisi CRC del bitstream durante lo scaricamento "Configuration Error Detection"
http://www.altera.com/literature/an/an539.pdf


Ciao

[flz47655]

Sembra che avete pensato a tutto

[peter90]

Scusate la mia ignoranza,
è possibile implementare questo softcore in una cpld magari grossa, così da evitare la memoria esterna?

E' possibile espandere le periferiche o ad esempio aggiungere altre porte digitali di IO?

Ciao e buon 1° Maggio.

[flz47655]

Dal dato di luca: 2696 Logic Element direi proprio che devi togliere qualcosina per farci stare tutto in una CPLD di grosse dimensioni come la Max V 5M2210Z che dispone di 2,210 LE, economicamente probabilmente conviene acquistare una piccola FPGA e la memoria esterna che tra l'altro offrono risorse per della logica aggiuntiva.

Per il resto si può fare tutto, con la CPLD citata ad esempio hai 271 pin di I/O che puoi utilizzare, per periferiche aggiuntive devi fare i conti con le risorse disponibili sul tuo chip ed implementarle, non puoi implementare però in generale dell'elettronica analogica (niente ADC)

Se sei agli inizi ti consiglio di partire con progetti più semplici però
Ciao

[peter90]

Scusa flz, io sto proprio iniziando con cose moltosemplici, ma sono abbastanza curioso e rimango abbastanza impressionato dalle cose
che si possono fare con le fpga.

Scusate ancora la mia ignoranza, ma ad esempio posso mettere più di un micro dentro una fpga e far svolgere ad ognuno un proprio compito
con dei firmware diversi?

grazie per la pazienza

[flz47655]

Ciao peter, certamente puoi mettere anche più micro nella fpga con compiti diversi.
La cosa migliore però è risolvere direttamente in hardware alcuni problemi con alto parallelismo.

Hai già una dev-board? Ti conviene studiare un pochino e poi iniziare a mettere in pratica i concetti più semplici per "entrarci dentro" del tutto

Ciao

[legacy]

ciao
e' pubblico il progetto ? si possono consultare i sorgenti ?
per la parte cordic avete sviluppato' una fpu in virgola fissa ?

nel cordic la precisione dipende dal numero di iterazioni (fondamentalmente di cose semplici, somme e moltiplicazioni), come l'avete implementata ?

[deluca]

Purtroppo, per regolamento interno fino a quando non verrà pubblicato il report internazionale i sorgenti del SuperAVRcore non potranno essere rilasciati.

Cmq stiamo affrontando due versioni di Cordic .. uno di tipo Std_logic e uno in versione Real.
Essenzialmente il core del processore Cordic è costituito da tre blocchi fondamentali. Il pre-processore, il post-processor e il nucleo principale CORDIC. Il nucleo CORDIC è costruito utilizzando una pipeline di blocchi che rappresenta un modulo nei processi di iterazione.
Tutte le iterazioni sono eseguite in parallelo, utilizzando una struttura pipeline. A causa della pipeline, la struttura di base può eseguire una trasformazione CORDIC ogni ciclo di clock.

La differenza tra i due metodi sta nell’interpretazione del dato all’ingresso (ovvero l’angolo espresso in radianti).
Chiaramente la precisione raggiungibile con la rappresentazione in virgola mobile è di gran lunga superiore a quella in virgola fissa,
Ma stiamo valutando ed analizzando le due versioni per trovare un compromesso con l'hw a disposizione in termini di Logic Element.

Ciao

[legacy]

Se mai pubblicate il sorgente andro' a vedere proprio la parte relativa alla matematica!

In ambito automotive ho implementato una libreria cordic in fixedpoint con rescaling per un 4 core e500 (una belva, e' fondamentalmente un core ppc pero' molto ma molto potente e con la possibilita' di essere AMP o SMP) ottenendo ottimi risultati in termini di velocita' e precisione. I core non avevano fpu, usare softfloat era pesante e vietato da alcune specifiche cliente al lato sistema operativo (VxWorks), quindi non restava che il fixed point a 64bit con rescaling: in pratica abbiamo scelto una configurazione AMP in cui un core fa solo conti, spilandoli dallo stack delle cose da fare e mettendo i risultati nelle buche delle lettere di chi si aspettava il risultato processato (shared ram), il master comanda e supervisiona lo stato del mezzo (una moto da corsa) e gli alri due fanno altro (tra cui telemetria).

Per me quindi si tratta di banale (si fa per dire) approccio iterativo, un loop fino a che l'errore e' inferiore a quanto desiderato, cosa che per natura degli algoritmi cordic corrisponde ad un passo di convergenza.

Nel vostro caso mi sto anche chiedendo: come la fate voi la parte di floating point ? C'e' un softcore dedicato che realizza una sorta di macro architettura su cui far girare del microcodice e quindi ricadiamo all'incirca all'approccio informatico che ho seguito io ? Oppure avete sbrogliato il softfloat in Vhdl ? E nel caso come gestite le iterazioni per ottenere convergenza degli algoritmi Cordic verso la soluzione con un errore di approssimazione accettabile ?

[deluca]

Qualche segretuccio lo possiamo svelare....

In parole povere quello che ci siamo imposti è di realizzare un Core Cordic basato su doppia precisione esponenziale.
un 64bit reale (in realtà ne utilizziamo solo 61), chiaramente scritto in VHDL.

Quello che stiamo sviluppando è un Cordic floating-point nel quale un vettore floating-point è ruotato intorno di un angolo floating-point.
Inoltre stiamo cercando di mantenere la gamma di convergenza esponenziale tra 0 e 1.1182.
Il look-up table che abbiamo implementato richiede 456 bytes costituiti da 60x61 bits.
La doppia precisione adder/subtractor è costituita da un core three-stage pipelined.
Il multiplex usato per selezionare il valore della tangente hyperbolica dal look-up table è un 61:1.

La discussione potrebbe dilungarsi non so per quanto ancora....!! ma purtroppo il tempo che posso dedicare al forum è sempre limitato,

Cmq grazie per l'attenzione che hai posto al topic.

[legacy]

Molto molto bello, complimenti!


p.s.
perdona la curiosita', cosa usate esattamente ?



Centra si e no, nel mio caso misuro la distanza di Hamming, perche' ho due apparati ridondati e confronto quanto siano uguali alcune zone della loro memoria (che per definizione di ridondato deve essere identica, altrimenti uno dei due e' in avaria o ha avuto problemi e la cosa va approfondita e gestita), dato che fare reboot dell'apparato in volo, al primo errore che incontra, costa ed e' rischioso (anche in termini di probabilita' di fallimento missione) prima di dicidere di dare il reboot (ultima spiaggia) interessa fare una misura precisa per la differenza fra due buffer, che sono strutturati in modo furbo, cioe' in modo che si possa capire quale dei due apparati sta sbagliando e cercare di correggere l'errore senza dover fare reboot, dato che interessa la misura per la differenza fra due chunk di dati sfrutto una matrice levenshteiniana nbyte x nbyte con dei trucchetti iterativi per ridurre le dimensioni di quella matrice senza scadere in consumi eccessivi di tempo (come si sa, la coperta e' sempre corta, o sprechi spazio e risparmi tempo, o sprechi tempo e risparmi spazio, nel mezzo i compromessi)

Mi sono occupato per un po' di avionica, nel mio caso per le centraline di aerei ed elicotteri (civili, ma anche militari) l'hw era schermato, e al lato firmware ci sincervamo dello stato dell'hw facndo dei PBIT e dei CBIT, i primi stanno per PowerOn Built In Tests, i secondi per Continuously Built In Tests, in pratica test pesantissimi quando, per dirla come se fosse banale come una automobile, quando si gira la chiave per mettere in moto l'aereomobile, prima di dare l'OK il mezzo fa fare tutta una serie di test a tappeto su tutte le sue componenti hw, l'altra batteria di test invece era implementata in un paio di task eseguiti con priorita' bassa dal Kernel avionico che schedula la cosa a tutti i moduli ciclicamente.

Quando i progetti sono militari vengono spezzati in una serie di sotto sotto progetti in modo che nessuno (eccetto pochi pochissimi eletti, e ovviamente il committente) abbia la visione dell'insieme. Io non ho la piu' pallida idea dei moduli sviluppati dagli altri, conosco solo le loro interfacce pubbliche e le conosco solo se qualche loro requisito riguarda anche la mia parte. In pratica Io mi sono occupato solo di un piccolo modulo telemetrico + tactical mission (classico da elicottero militare), e dal mio piccolo punto di vista il processore era un PPC440/460 con attaccato un modulo 1353 per parlare con armamenti e sensoristica varia (sopratutto per i controlli rotori), e dovevo in pratica, per la parte che toccava a me, fare test su tutto l'hw della mia board: cioe' principalmente sulla cpu, perche' il resto era in fpga (codice a me ignoto) e provedeva da se a fare test, bastava invocarli e leggerne il risultato. Per la CPU ho dovuto inventarmi modi "fantasiosi" per testare la ALU, i salti, le TLB, ecc ecc tutto quanto, sopratutto in negativo causando volontariamente delle exception per vedere se la CPU era ancora in grado di gestirle e sopratutto in quanto tempo.

Voi (e beati voi che potete vedere il progetto nella sua totalita') come vi regolate ?

[deluca]

Molto semplicemente, per codificare in hamming, dopo aver definito le maschere xor per ogni parità e creato la funzione xor speciale codifichiamo in streaming i dati del bus dati nel formato 8D+4P dove i 4P bit aggiunti sono ricavati applicando l'xor speciale ai dati in AND con la maschera di parità.

Per la decodifica invece dati applichiamo il processo inverso andando a calcolare ogni singolo bit syndrome, poi con un semplice
correttore a bit singolo viene rispristinato il "dato" d'ingresso.

A livello di risorse Hw sprechiamo per fare il tutto una decina di Logic Element.

Scusa la mia curiosità .... hai per caso un link o un sito web ove visionare qualcuno di questi progetti ?
Mi sembrano abbastanza interessanti, di sicuro le problematiche legate all'avionica sono un pò diverse di quelle affrontate da noi.... ma
può essere di certo molto interessante.

Ciao

[legacy]

Bello e molto piu' semplice di come lo immaginavo io avendo in mente un diff sui chunk di ram, mi piace

Eh, per quello che facevo io ... posso solo dirti: se hai modo di assistere ad una parata delle frecce 3colore, osserva M346, ci ha lavorato gente che conoscevo mentre io mi occupava di elicotteri. Che altro dirti ? Sfoglia le rivista di finmeccanica, perche' penso che sia la sola fonte pubblicha possibile, tutto il resto (per quanto ne so io) e' coperto da segreto, tanto che nemmeno io quando ci lavoravo potevo visionare qualcosa. Come ho scritto prima per ragioni di segretezza ogni squadra puo' vedere solo un pezzetto del tutto. Purtroppo (o per fortuna) non lavoravo direttamente sotto finmeccanica ma per un gruppo che dipendeva da Finmeccanica, del resto loro hanno sotto o in parallelo (sono tecnicamente Clienti, pero' non mi e' mai stato del tutto chiaro l'organigramma) varie come Augusta (elicotteri) ed Alenia/Aermacchi (aerei).

Poi ho cambiato genere, da avionica ad automotive, perche' quello e' un bruttissimo mondo, eccessivamente claustrofobico e snervante.

[Tedesco]

Ciao a tutti....

Complimeti per il lavoro deluca!!........
Ma quanto tempo vi è servito per sviluppare tutto?
Una volta mi è capitato di fare una valutazione per un progetto molto simile e mi ricordo che ci sarebbe voluto un bel pò di tempo!!....

domanda: avete scelto quell'architettura per facilitare il vostro porting del FW, o perchè semplicemente il NiosII non faceva al caso vostro?....

Un saluto.
Ciao...

[deluca]

Ciao Tedesco,
diciamo che questo lavoro, come tanti altri, è il frutto di tanti anni di esperienza che si è concretizzato tra la fine del 2011 e l'inizio del 2012.
Abbiamo mirato a questa architettura proprio per il porting del FW ma soprattutto per mettere tutto quanto su Fpga rendendola Radiation Hardened attraverso l'Hamming protection code.

La maggior parte dei sistemi HW slow-control che realizziamo sono basati su controllori AVR....
Motion control, PID regulator, Robotic systems, hanno il cuore AVR 8/16/32 bit,
ma tante volte non possiamo mettere l'hardware nelle vicinanze degli apparati sperimentali che sparano particelle ionizzanti che possono influire sul buon funzionamento della cpu.
Così siamo passati a soft-core su cui è possibile intervenire a livello hardware per integrare EDAC (error detection and correction) che ci permette di installare l'hw nelle vicinanze degli apparati sperimentali.

Naturalmente l'implementazione del NIOS II, che utilizziamo pure, ce la riserviamo per altre applicazioni .....
La nostra filosofia è quella di implementare IP core con codice nativo proprietario in modo da poterli trasportare su famiglie diverse.

Saluti

[legacy]

La parte spazio del posto dove lavoravo io prima quando non usava chip Asic (stra costosi) usava versioni speciali di fpga, in ogni caso usava cpu ppc con schermatura.

Non ho mai approfondito piu' del dovuto (anche perche' di certe cose non parlano, specialmente gli hwristi), pero' la discussione era nata da una mia semplice osservazione: perche' nell'era del post G5 voi state usando un G1 ? In particolare un ppc601 ???

So che le norme militari impongono che ci siano pezzi di ricambio per oltre 20 anni da che parte una commessa, e almeno 15 anni di maturato consolidamento, pero' mi sembrava comunque eccessivo spingersi ad una cpu degli anni '90 ... e io nella mia parte, seguendo gli elicotteri ho sempre visuto usare i 440/460 (cpu moderne, 2004), mai un 601 !!!


Anche se e' anche vero che non ho mai lavorato all'hw di cose da mandare nello spazio, e nemmeno terresti a velocita' superiori a quelle del suono perche' per me i MACH erano out of limits. Ok, centra zero con le radiazioni, pero' l'hw di un aereo subsonico cambia parecchio, e il software cambia altrettanto parecchio: servono anche molte piu' competenze, che io chiaramente non ho.


Ok, quindi ma il 601 ??? Perche' quel nonnino ??? E la risposta e' stata: non crederai davvero che quel ppc601 sia lo stesso che monta il tuo machintosh 4400 (e' uno scassone degli anni '90), vero ?

Risposi "eccerto, io sulla mia 4400 monto un 603, mica quel manufatto dell'anteguerra"

Come se il 603 fosse tanto diverso dal 601 =D

Battuta ironica per appassionati di PowerPC, il 601 e il 603 hanno un paio di anni di differenza, anche se il 601 e' retrocompattibile con la precedente linea di processori POWER (non PowerPC, ma semplicemente Power e basta), mentre il 603 non lo era perche' tagliava corto per entrare di petto nella nuova ISA IBM-Motorola-Apple senza la palla al piede delle cose fatte solo da IBM-Motorola.

Poi mi ha spiegato brevemente che il 601 che mandano in orbiata (satelliti) non e' una cpu "normale" ma e' cosi' vecchio il core perche' e' stra testata la soluzione hw che vendono con su una buona schermatura che, da quello che ho capito, protegge la cpu intrinsecamente.

Non ho ben capito se intendesse una soluzione Radiation Hardened come quella che hai usato, e ovviamente ci credo poco, anche perche' ho scritto io un pezzo del codice che ci gira sopra (ho scritto solo i diagnostici), e so dai colleghi che lo scheduling per il mio codice spende e' del 15%, il task a bassa priorita' e' continuamente schedulato per testare la cpu: ho scritto proprio i test per la ALU (gli faccio fare operazioni di cui so gia' a priori il risultato, 1+1=2 .. etc), per il branch unit (i salti), per le TLB, per vedere se scattano o meno in caso di accesso in zone protette di memoria, e per la FPU. La vera protezione e' hw, ma nel senso che il sistema e' ridondato: ci sono 4 cpu che fanno tutte la stessa cosa e si controllano a vicenda attraverso un altro pezzo di hw chiamato "voter": stessa filosofia, tra parentesi che si usa sui treni ad alta velocita', solo che il ridondato e' un 2 su 2, ma sempre con un voter hw che controlla lo stato delle due cpu: nel ferroviario non c'e' possibilita' di ripristino, se una delle due cpu fallisce il treno si ferma all'istante ... il tmission computer del satellite sopporta fino a 3 mobo guaste prima di autopensionasi =P

Siccome non lavoro piu' per loro, e mi e' rimasto un po' il dubbio e la curiosita' di vedere che combinano gli altri: mi/ci dai qualche dritta ?
Che altri trucchi (hw o sw) ci sono per proteggersi dalle particelle ?

[deluca]

Caro legacy,
I metodi che noi impieghiamo quando implementiamo hw su fpga con sram, visto che usiamo fpga standard commerciali, per proteggerle dalle radiazioni ionizzanti sono lo Scrubbing, il DWC (Duplication with Comparison),e sopratutto il TMR (triple Modular Redundancy) come rappresentato in figura



Proprio questo metodo è quello che nel nostro ambiente risulta essere il più efficace.

In alcune applicazioni siamo costretti a triplicare l'hardware e poi attraverso 3 voter realizziamo una rete ridontante.

P.S. Si potrebbe ridurre il PTR ? (tempo di lettura dei post, visto che ne ho veramente poco) .........grazie

Saluti

[legacy]

Ottimo, grazie. Solo una cosa: prima ho parlato di voter in ambito ferroviario, ai piu' attenti sicuramente si sara' accesa la classica lampadina che si accende quando qualcosa non torna: per farla breve e' grazie alle tecniche che hai elencato che e' stato possibile recentissimamente (Bologna marzo 2012) poter introdurre un paio di DSP nei sistemi ferroviari ad alta velocita'.