La guerra dei core

La disponibilità di geometrie di processo Cmos sempre più piccole ha significato, negli anni recenti, che i produttori sono stati impegnati a promuovere microcontrollori a 32 bit nei segmenti che erano stati in precedenza dominio dell'architettura a 8 bit. Incoraggiati dalle forti campagne promosse da Arm, alcuni produttori di microcontrollori sembrano avere chiaro nei loro obiettivi il mercato degli 8 bit, ma hanno dedicato l'intero loro portfolio all'offerta a 32 bit. Questo articolo guarda al razionale dietro queste scelte, e al vero impatto che questo ha sulla scelta disponibile per i progettisti di embedded-control, attraverso la seguente domanda "quanto è veramente importante il core?"

"Gate counts and discounts"
L'embedded control è sempre stato pochi passo dietro i settori principali dell'industria informatica per diverse ragioni: la prima è la necessità del controllo dei costi o, forse, che gli ingegneri progettisti di embedded sono per necessità più cauti e hanno bisogno di assicurarsi che i microcontrollori lavorino in applicazioni quotidiane, tangibili. Qui, affidabilità e solidità sono valutati più che in altri ambiti, e possono essere raggiunti solo con buone regole di progettazione e una profonda conoscenza del sistema. Quindi, mentre il resto del mondo dei semiconduttori si sta muovendo verso le nuove geometrie a 22nm e oltre, la maggior parte dei microcontrollori, come quelli presenti in frigoriferi, lavatrici o telecomandi per Tv, stanno solo ora abbattendo la barriera dei 200 nm. Questo livello di evoluzione colloca l'embedded control al punto in cui era l'industria del desktop oltre un decennio fa: quando i gate logici iniziarono ad essere relativamente economici rispetto ai costi dei package e funzioni analogiche su un dato die. Non sembra più ridicolo per esempio considerare l'utilizzo di un core a 32 bit per risolvere un problema di Led lampeggiante.

La facilità nel progettare
Naturalmente, è tutta una questione di facilità di progettazione. Poiché un crescente numero di applicazioni ha iniziato ad usare i microcontrollori in sostituzione dei sistemi elettromeccanici con meccatronica, a sempre più ingegneri è chiesto di padroneggiare l'arte della progettazione del firmware per l'embedded control. Il firmware dei microcontrollori è il cuore dell'intelligenza che ci si aspetta da un prodotto embedded. Poiché sempre più prodotti necessitano di firmware, questi hanno anche necessità di essere sviluppati più velocemente, dato che il time-to-market è un parametro chiave sul quale virtualmente oggigiorno ogni progetto sembra essere misurato.

Linguaggi di programmazione
Il primo e più ovvio beneficio derivante dall'utilizzo di un più piccolo processo Cmos è che molta più Flash di memoria programma può essere resa disponibile per un dato target di prezzo. Questo può essere tradotto in un più rapido sviluppo dato che le limitazioni di spazio sono diminuite e i progettisti possono concentrarsi più facilmente sugli obiettivi fondamentali dei progetti. Ricche librerie possono essere usate per standardizzare lo sviluppo di applicazioni e strumenti di rapida prototipizzazione possono aiutare a generare il codice, automaticamente, sulla base di modelli. Per questo è stato fondamentale la graduale transizione dal linguaggio Assembly a quello C nell'arco degli ultimi dieci anni.

"Core independence"
Il linguaggio C è un importante passo verso la core independence: se usato opportunamente, il linguaggio C può rendere il codice dell'applicazione più leggibile, più facile da manutenere e più semplice da migrare. Ha la capacità di portare i progetti lontano dagli idiosincratici mnemonici e piccoli dettagli delle architetture proprietarie di microcontrollori, e ridurre tutte le architetture di embedded-control allo stesso modello astratto, stack-based. Fondamentalmente, la transizione verso C ha spostato i riflettori dalla progettazione dei core. Ovviamente, i core restano una questione importante, dato che devono essere veloci e intelligenti, ma non sono più un ostacolo alla migrazione. Il linguaggio C ha permesso ai progetti di muovere verso un'era di maggiore indipendenza dai core. Il fatto che un progetto sia basato su un'architettura a 8, 16 o 32 bit può diventare un irrilevante dettaglio se un compilatore C è attivato al solo premere un pulsante.

Separazione tra schema hardware e software
Un'altra conseguenza positiva dell'ampia adozione del linguaggio C è stata che la progettazione del firmware embedded si è avvicinato alle tecniche dell'informatica tradizionale. Un numero sempre maggiore di aziende sta trovando più conveniente separare la progettazione hardware dallo sviluppo software. Questo è in parte dovuto al numero relativamente elevato di laureati in informatica, e anche perché permette allo sviluppo hardware e software di progredire in parallelo per raggiungere un più rapido time-to-market.
I progettisti hardware hanno ancora bisogno di essere altamente qualificati e gli ingegneri del software hanno bisogno di acquisire certe esperienze nella progettazione embedded o il risultante sistema rischia di essere elegante, ma inefficiente. I sistemi efficienti useranno diversi livelli di librerie software per fornire complesse funzioni, come connettività (Usb, Tcp/IP) e supporto di file system indipendentemente dal core.
Sistemi operativi in tempo reale possono essere usati per evitare che i progetti diventino un impossibile groviglio di spaghetti, all'inseguimento degli eventi e delle interruzioni. I più diffusi Rtos sono disponibili per un'ampia gamma di architetture, ancora una volta eliminando i dettagli del core dalla visuale dei progettisti e fornendo un percorso pulito di migrazione. Infine, tutti questi livelli software intersecano quelli hardware, dove è la larghezza e profondità della piattaforma del fornitore che importa. La piattaforma deve offrire il set di opzioni più ampio possibile per fornire al team di progettazione una complessa matrice di periferiche, memoria e package compatibili.

Tenere il carico fuori dal core
Sembra che la maggior parte degli sforzi marketing dei produttori di microcontrollori siano concentrati sulla prestazione grezza espressa in Mips (milioni di istruzioni per secondo), a dispetto del fatto che il livello di Mips di un microcontrollore può significare relativamente poco in termini di reale prestazione dell'applicazione. Per esempio, le tecniche di emulazione software spesso denominate “bit banging” sono frequentemente usate nell'embedded control, ma ad un costo prestazione estremamente elevato. Al contrario, il giusto set di periferiche può produrre una rilevante riduzione delle prestazioni necessarie a un progetto. Idealmente, quando la logica corretta è al suo posto e i giusti moduli periferiche e le loro connessioni possono essere configurate per soddisfare completamente l'applicazione, il processore può essere messo in stand-by o altra modalità a basso consumo, in effetti lasciando il misuratore di Mips dell'applicazione ancorato allo zero. La continua innovazione, in aggiunta ai perfezionamenti e ritocchi al set di periferiche, può fare una differenza maggiore della scelta del core. Le moderne architetture a 8 bit, per esempio, offrono blocchi logici configurabili e una fine granularità nell'architettura delle periferiche, abbinata ad elevata connettività interna. Questo consente alle moderne architetture a 8 bit di competere facilmente persino con i più veloci processori a 32 bit con un set di periferiche meno flessibile.

Oltre la logica
Mentre la corsa a geometrie più piccole ha aiutato ad offrire più elevata densità di logic-gate, conducendo a memorie di dimensioni maggiori, core più grandi, e dies più piccoli, l'analogica sta fornendo la fonte di nuove sfide e difficili compromessi. Queste le aree di maggiore preoccupazione:

• Integrazione Analogica - Mentre i gate rimpiccioliscono con la geometria di un processo Cmos, condensatori e resistenze non lo fanno in egual misura. Dai moderni microcontrollori a 8 bit ci si aspetta che integrino amplificatori operazionali, amplificatori di strumentazione, convertitori A/D e D/A, comparatori, precisi oscillatori e tensioni di riferimento. Tuttavia, queste periferiche analogiche sono più difficili da integrare in piccole geometrie con lo stesso livello di precisione e prestazione. Con l'eccezione di un paio di A/D e D/A basici, davvero pochi produttori si sono avventurati lungo questo sentiero.

• Durata delle data Eeprom e memorie - Con una più piccola geometria risulta più insidioso. Questo significa un basso numero di cicli erase/write e una più breve conservazione della memoria, a volte misurata in mesi invece di decenni, tipicamente offerti da geometrie a 8 bit e maggiori. L'emulazione Eeprom nelle Flash è offerta come un palliativo al costo di grandi aree di Ram, complessità aggiuntiva e sovraccarico di Cpu.

• Funzionamento a 5V e oltre - I core a geometria più piccola operano a tensione interna molto bassa. Tolleranza ai 5 V può essere fornita su un limitato sottoinsieme degli I/O dalla maggior parte dei produttori ma davvero pochi, se non nessuno, è riuscito a offrire un vero funzionamento a 5 V su più che una manciata di pin.

• Extreme low power - Dato che i core di più piccola geometria richiedono un funzionamento a tensioni interne molto basse, tra 0,9 a 1,2 V, hanno anche bisogno di interfacciarsi con periferiche esterne e interfacce funzionanti tra 2 e 3,3 V. Ne derivano linee interne multiple derivate dal Vdd del dispositivo usando l'Ldo on-chip a spese dell'efficienza energetica. Tecniche molte sofisticate di islanding e clock-branching sono state usate per risolvere il problema ma, ad oggi, nessuno dei nuovi core può avvicinarsi più di un ordine di grandezza alle prestazioni di basso consumo delle migliori architetture 8 bit.
Ovviamente, i progressi sono continui e ci sono stati alcuni avanzamenti fondamentali negli ultimi anni e mesi, e molto ci si aspetta nei prossimi dai microcontrollori, specialmente in termini di densità di codice e prestazioni. Qualsiasi applicazione che necessiti reali prestazioni di calcolo trae beneficio dell'utilizzo di architetture maggiori. Il problema, tuttavia, sta nell'estendere questo ragionamento al punto in cui si pensa che qualsiasi e ogni applicazione dovrebbe beneficiare dall'utilizzo di un singolo, comune core a 32 bit.

Auto verso controller
Per molti aspetti, scegliere un microcontrollore è come comprare un'auto: la scelta naturalmente deve essere dettata dal gusto personale, ma deve essere ragionevolmente legata all'uso che faremo di quel veicolo. Per normali viaggi su lunghe distanze, velocità, comfort e prestazioni dovrebbero essere i principali obiettivi e un'auto di grosse dimensioni con un grosso motore turbo diesel potrebbe essere la miglior scelta. Per un uso in città su piccole distanze e parcheggi in piccoli spazi, la miglior scelta potrebbe essere un'utilitaria con motore ibrido o elettrico. Motori diversi offrono prestazioni e consumi molto diversi proprio come i diversi core nella piattaforma di un microcontrollore possono offrire diverse prestazioni di calcolo, consumo di potenza, e facilità d'uso per soddisfare differenti applicazioni. È interessante notare che, a dispetto dell'ampio numero di marche, modelli ed edizioni speciali che i produttori di auto offrono oggigiorno, nessuno di loro ha mai rivendicato che un singolo motore potesse soddisfare qualsiasi cliente.

Le guerre degli eco-sistemi
L'analogia con le auto si può anche estendere alla rete post vendita o sostegno all'ecosistema. Per i microcontrollori ciò include ognuna delle terze parti e i loro prodotti. L'eco-sistema ancora una volta testa l'importanza (o la relativa mancanza) della intercambiabilità dei core. In un particolare eco-sistema, per esempio, ci può essere una vasta scelta di suite di sviluppo concorrenti come Ide, compiler, librerie e strumenti di debug. Tuttavia, ogni terza parte fornitrice dovrà aver lavorato duramente per assicurare che la sua suite non sia troppo facilmente intercambiabile con quelle dei suoi diretti concorrenti. Ognuna dovrà sforzarsi di fornire la più completa esperienza per assicurare fedeltà continuativa, e ricavi, dai propri clienti, indipendentemente dalla intercambiabilità dei core con quello di terze parti fornitrici concorrenti.
Ognuna delle terze parti fornitrici, inoltre, offre strumenti hardware che invariabilmente sono specifici per uno specifico produttore di microcontrollori essendo compressi dallo specifico mix di periferiche e opzioni di pin-out. Infatti, è interessante notare che, ad oggi, non ci siano due processori a 32 bit disponibili nello stesso package e pin-out compatibili a dispetto del fatto che essi condividano esattamente lo stesso core.

Fattori "non-core"

La Core commonality è divenuta un argomento principale di discussione, ma la scelta di microcontrollori specifici è ancora guidata da fattori “non-core” che esistono indipendentemente dal core:

- pin-out compatibility e universalità degli strumenti di sviluppo;

- flessibilità per attingere dalla più ampia scelta di periferiche, taglie di memoria e package;

- capacità di scegliere il giusto mix di periferiche per ogni applicazione;

- L'innovazione dei produttori e l'impegno verso una continua espansione delle funzionalità dei prodotti.
Nessuno di questi fattori è direttamente dipendente dalla scelta di uno specifico core, né beneficia dall'avere una scelta più ristretta di core. Semmai, l'efficienza e l'innovazione richiedono la più ampia scelta possibile in un vivace mercato dove nuove idee vengono continuamente esplorate e rese disponibili per gli ingegneri dell'embedded-design
.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome