Wave Sheet

Qualche volta può essere utile riflettere con carta e penna e nel ragionare sulle forme d'onda può essere comodo disporre di un foglio predisposto appositamente per abbozzare qualche idea.

Voglio condividere con voi un template che ho creato, da stampare in orizzontale:

L'utilizzo è abbastanza intuitivo, nella riga iniziale è possibile scrivere il titolo del foglio mentre sulle righe a sinistra il nome dei vari segnali il cui contenuto sarà scritto all'interno delle forme d'onda.

Spero vi faccia risparmiare tempo e magari contribuisca ad un maggiore ordine anche con questi antichi strumenti. 

NB: Sebbene sia possibile ottenere un risultato analogo con una tabella l'aspetto è più intuitivo per degli elettronici

Scarica il template WaveSheet

FPGA: Engineering Change Orders

Sintesi dell'articolo: Modifichiamo senza una ricompilazione completa alcune parti del progetto come la frequenza di uscita del PLL tramite gli strumenti ECO di Quartus.

Durante il ciclo di sviluppo purtroppo le specifiche possono cambiare all'ultimo minuto, queste modifiche sono chiamate in gergo ECO (Engineering Change Orders) e possono  in alcuni casi essere introdotte per compensare problemi di design del sistema.

Vediamo un ipotetico caso semplificato di ECO e di come Quartus possa venirci ancora un volta incontro.

Supponiamo di avere un design su logiche programmabili ad elevata complessità, quindi con tempi di compilazione elevati, e di avere una specifica iniziale di frequenza di 300 MHz ma di aver scelto un dispositivo troppo lento per implementare a tale velocità il design. Purtroppo ci accorgiamo verso il completamento dei lavori che tale frequenza non è raggiungibile.

Il sistema, al solo scopo di facilitare la comprensione, è rappresentato semplicemente nel diagramma da un doppio moltiplicatore con pipeline.

Il design utilizza come usuale un PLL per generare la frequenza di sistema e dopo aver tanto atteso visualizziamo il fatidico Timing requirements not met da Quartus. La frequenza massima per il nostro sistema che TimeQuest riporta supera di poco i 250 MHz.

Non avendo ulteriore tempo a disposizione decidiamo di accettare 250 MHz come frequenza del nostro sistema.

La procedura "standard" richiederebbe di modificare i parametri del PLL e ricompilare il progetto, così facendo innanzitutto non è detto che la frequenza massima dopo la modifica sia sempre superiore ai 250 MHz.

E' però possibile evitare la compilazione completa, che in sistemi complessi può richiedere diverse ore, cambiando solamente le proprietà relative al PLL, vediamo come.

Nel report di compilazione del Fitter andiamo innanzitutto ad individuare la sezione PLL Usage nella categoria Resource Section, facendo click col pulsante destro sul pll scegliamo Locate Node / Locate in Resource Property Editor.

Verranno visualizzate le proprietà del PLL come mostrato nell'immagine seguente

I campi senza sfondo grigio sono modificabili, cambiamo quindi il moltiplicatore del clock da 6 a 5 nel nostro caso per ottenere un clock di uscita di 250 MHz al posto dei 300 MHz.

Il valore M del moltiplicatore verrà aggiornato di conseguenza e tutti i campi modificati verranno evidenziati in rosso.

Ricordiamo infatti l'equazione della frequenza di uscita del PLL in modalità normale:

Altre equazioni come quelle per la variazione della fase ad esempio sono reperibili nella documentazione di Altera.

Scegliamo adesso Edit / Check and Save All Netlist Changes per applicare le modifiche fatte

Dopo una breve compilazione parziale, composta dalla fase di Fitter parziale ed Assembler del file di programmazione il progetto a 250 MHz sarà pronto per essere caricato sulla FPGA  per la validazione.

Prima però eseguiamo TimeQuest per controllare se abbiamo effettivamente risolto tutti i problemi, le violazioni dei tempi di Setup sono sparite ed andando nella scheda Clocks è possibile vedere che la frequenza in uscita dal PLL è effettivamente stata modificata a 250 MHz.

Non ci rimane che provare il design a 250 MHz.

NB: TimeQuest Timing Analyzer è evidenziato di rosso perché sono presenti alcuni percorsi non vincolati nel design che però non hanno criticità per il semplice design utilizzato da esempio per illustrare le funzionalità ECO.

Quartus ci offre inoltre tramite la finestra Change Manager richiamabile dal menù View / Utility Windows che ci da un resoconto delle modifiche ECO così attuate

Lo strumento permette di esportare in file .TCL le modifiche o di riportare il tutto alla situazione originaria.

Questo flusso di sviluppo rapido è molto utile anche durante l'ottimizzazione di progetti in continua modifica per evitare di eseguire una doppia compilazione se la frequenza desiderata non è raggiungibile.

Oltre al PLL è possibile modificare altre celle elementari così come lo standard, lo slew rate ed il current strenght dei pin di I/O.

NB: A causa della differente struttura dei PLL nei dispositivi Cyclone V le funzionalità ECO non sono supportate, è possibile però utilizzare l'IP Altera PLL Reconfig come descritto nell'application notes 661 di Altera per variare i parametri del PLL a tempo di esecuzione.

FPGA: Scripting con TCL

Software EDA (Electronic Design Automation) come Quartus, Vivado, ISE e Synplify Pro utilizzato da diversi produttori di FPGA tra cui la nuova startup cinese Gowin, condividono tutti il linguaggio di scripting TCL (Tool Command Language) per l'automazione di task comuni.

Vediamo innanzitutto come creare ed eseguire un semplice script TCL con Quartus.

Creiamo un nuovo progetto e scegliamo File / New / Tcl Script File e scriviamo all'interno del nuovo file la seguente riga:

puts "Hello World"

Salviamo il file col nome hello_world.tcl ed andiamo sul menù Tools / TCL Scripts...

Si presenterà la seguente schermata, premiamo Run dopo aver selezionato il nostro script.

Un messaggio ci confermerà della corretta esecuzione dello script ma non apparirà alcun messaggio "Hello World" a video. 

Per visualizzare l'output degli script è necessario aprire la relativa finestra andando su View / Utility Windows / Tcl Console

La prima riga conterrà il comando di esecuzione del file di script, chiamato in automatico dalla pressione del pulsante Run precedentemente. E' naturalmente possibile richiamare gli script dalla console TCL scrivendo direttamente il comando source nomefile.tcl.

Sotto al comando è possibile osservare il semplice output che ha generato il nostro script.

Vediamo adesso uno script di maggiore utilità progettuale.

Spesso si ha la necessità di creare molteplici configurazioni di testbench partendo da file già esistenti, l'operazione come abbiamo visto in precedenza richiede diversi passaggi, tra cui la compilazione delle impostazioni del testbench tramite l'interfaccia grafica che è sotto riportata per referenza:

Al crescere del numero dei file l'operazione diventa meccanica e molto fastidiosa, col seguente script TCL possiamo configurare automaticamente in un attimo tutti i nostri testbench, di cui alcuni eventualmente saranno ritoccati manualmente, risparmiando ad ogni modo una notevole quantità di tempo.

Tramite il comando set assegniamo dei valori a delle variabili che potranno essere richiamati tramite la sintassi $nome_variabile.

Nel nostro caso avremo le variabili dir, ext, design_instance_name e run_sim_for a cui assoceremo dei valori fissi.

- dir specifica la cartella contenente i file di testbench

- ext specifica l'estensione dei file di testbench, se non abbiamo problemi di compatibilità con altri software come ad esempio Xilinx ISE, possiamo anche utilizzare l'estensione .vht per differenziare i file di testbench rispetto agli altri.

- design_instance_name specifica il nome dell'istanza sotto test, naturalmente tutte le istanze nei testbench dovranno chiamarsi allo stesso modo.

- run_sim_for specifica il tempo di esecuzione, al pari del campo "End simulation at" nella finestra di dialogo di Quartus sopra mostrata.

E' altresì importante che nei testbench il nome della "entity vuota" corrisponda al nome del file per un corretto funzionamento di questo script. Per necessità diverse è possibile partire da questo script per modificarlo comunque a piacere.

Nelle righe seguenti avviene una ricerca dei file con l'estensione scelta nella cartella specificata dopodiché per ogni file viene estratto il nome senza estensione ed utilizzato per il richiamo dei comandi set_global_assignment specifici di quartus per l'impostazione dei testbench.

Altri EDA dispongono di comandi specifici per l'automazione di diversi task, è necessario quindi consultare la documentazione di ogni software specifico per tali comandi.

NB: Il file .qsf associato al progetto Quartus è a tutti gli effetti uno script TCL creato automaticamente tramite l'interfaccia del programma durante il normale utilizzo, aprendo il file con un editor di testo è possibile visualizzare i comandi per incorporarli nei propri script, se non si vuole ricorrere alla documentazione di Scripting.

Scarica il file materiale dell'articolo

Buona automazione con gli script TCL

FPGA: Xilinx ISE ed Internet Explorer 11

Oggi vediamo una piccola fix per risolvere un problema che può nascere nel tool di sviluppo Xilinx ISE e nei suoi accessori.

Seppur il software ISE sia ormai superato da Vivado è ancora necessario per poter sviluppare per famiglie di dispositivi come Spartan-6, Virtex-6, Coolrunner e le generazioni precedenti.

Un problema che può verificarsi (verificato su Windows 7) dopo l’aggiornamento di Internet Explorer all’ultima versione è la mancanza di funzionamento di ChipScope Inserter ed ChipScope Pro Analyzer con messaggi di errore come “Can't load ..\..\java6\nt\jre\bin\client\jvm.dll.”

Per risolvere la problematica aggiungiamo nella variabile d’ambiente PATH i seguenti valori se non presenti:

C:\Xilinx\14.7\ISE_DS\ISE\\lib\nt;C:\Xilinx\14.7\ISE_DS\ISE\\bin\nt;C:\Xilinx\14.7\ISE_DS\ISE\bin\nt;C:\Xilinx\14.7\ISE_DS\ISE\lib\nt;C:\Xilinx\14.7\ISE_DS\ISE\..\..\..\DocNav;C:\Xilinx\14.7\ISE_DS\PlanAhead\bin;C:\Xilinx\14.7\ISE_DS\EDK\bin\nt;C:\Xilinx\14.7\ISE_DS\EDK\lib\nt;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\powerpc-eabi\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnuwin\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\arm\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\linux_toolchain\nt_be\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\linux_toolchain\nt_le\bin;C:\Xilinx\14.7\ISE_DS\common\bin\nt;C:\Xilinx\14.7\ISE_DS\common\lib\nt;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\

E’ anche possibile creare una variabile dell’utente al posto della variabile di sistema per risolvere in modo ancora più rapido ed evitare di controllare tutti i percorsi esistenti.

Dove è possibile naturalmente adattare alla propria versione di ISE i PATH e rimuovere il percorso per la versione Java di Oracle se non installata.

Cyclone V SoC: Ethernet senza router con DE1-SoC

La documentazione di Terasic per la DE1-SoC è ben fatta e seguendo il manuale e gli esempi si sarà in grado di programmare il processore ARM, usare l'area logica programmabile e capire l'interazione tra queste due componenti.

Sul sito web è presente un'immagine pronta all'uso di un sistema Linux Console che è possibile scrivere su una scheda MicroSD da almeno 4GB come descritto nella DE1-SoC Getting Started Guide o nel tutorial Using Linux on the DE1-SoC.

Riassumendo è necessario:
- preparare la MicroSD ed inserirla nella DE1-SoC
- impostare tutti i dip switch sul retro della scheda su OFF per configurare la FPGA dal processore ARM all'avvio
- accendere il sistema
- collegare il cavo micro USB al PC
- Utilizzare programmi come Putty per aprire un terminale con la DE1-SoC

Nell'immagine la configurazione di default (AS) della scheda una volta aperta dalla scatola e sotto le varie configurazioni possibili, da notare l'ordine [4:0] utilizzato nella tabella

 

 

L'utilizzo del cavo USB può però essere sostituito dal cavo Ethernet, che utilizzeremo anche per la comunicazione col pc nelle nostre applicazioni nei prossimi articoli. Il vantaggio principale è la maggiore velocità di comunicazione raggiungibile tramite Ethernet, la scheda supporta infatti la velocità Gigabit contro i 115200 bps della seriale.

 

Nella documentazione di Terasic, nel documento My_First_HPS, è mostrato un esempio di configurazione con router, il che toglie però un po' di praticità al tutto in quanto necessario router con alimentatore, due cavi ethernet, etc..

 

Avere sottomano un router gigabit non è poi cosa scontata vista l'ampia diffusione di router a 10/100 Mbps. E' sicuramente più comune invece avere solamente un portatile con scheda di rete Gigabit.

 

NB: Per l'utilizzo della velocità Gigabit è importante avere un cavo CAT5e o superiore di buona qualità. Cavi non adatti avranno impatto sulla velocità della comunicazione.

 

 

 

Vediamo come rendere il nostro ambiente più snello collegando direttamente il pc alla scheda con un singolo cavo ethernet.

 

Una volta collegati alla DE1-SoC da terminale (tramite USB) digitiamo:

 

vi /etc/network/interfaces

 

per editare il file di configurazione delle interfacce di rete tramite il programma testuale vi.

Ricordo che vi ha due modalità di funzionamento: inserimento e comandi.

Inizialmente il programma è in modalità comandi, premiamo "i" per passare alla modalità inserimento ed inseriamo:

iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
broadcast 192.168.0.255

al posto di

iface eth0 inet dhcp

che possiamo semplicemente commentare ponendo il cancelletto (#) all'inizio della riga.

Dopodichè premiamo ESC per tornare in modalità comandi e scriviamo ":wq" (senza virgolette) e battiamo invio per salvare ed uscire.

Così facendo utilizzeremo un IP statico al posto di un IP dinamico che senza un router è "macchinoso" assegnare. Riavviamo tramite il comando "reboot" la DE1-SoC.

Nella scheda di rete sul pc, collegata alla DE1-SoC, impostiamo invece i seguenti parametri

 

La configurazione è terminata, adesso sarà possibile accedere alla DE1-SoC senza router tramite l'IP 192.168.0.3, tramite SSH per esempio, mentre il PC avrà IP 192.168.0.2.

 

E' naturalmente possibile adattare gli indirizzi IP in base alle proprie esigenze, è importante che non ci siano conflitti con altri indirizzi IP presenti nella vostra rete.

 

Vedremo nel prossimo articolo come configurare DS-5 per navigare il filesystem tramite SFTP ed il terminale SSH integrato per evitare di tenere aperti più programmi durante lo sviluppo, proprio con la sola connessione ethernet così configurata.

Cyclone V SoC: Gli strumenti di sviluppo per ARM

La scheda DE1-SoC come dice il nome e come abbiamo già anticipato, include un SoC (System On Chip) composto da una logica programmabile FPGA ed un processore ARM in un unico chip.

Diamo ora uno sguardo a quali sono gli strumenti di sviluppo per questo nuovo SoC.

La FPGA è programmabile come di consueto tramite Quartus II, il processore ARM necessita invece dell'installazione della SoC Embedded Design Suite (SoC EDS), una suite di sviluppo disponibile anch'essa come Quartus nella versione gratuita Web Edition o nella versione a pagamento Subscription Edition.

La differenza principale è la possibilità nella versione a pagamento di sviluppare bare-metal, ovvero di programmare il processore al livello più basso, senza un sistema operativo, e di utilizzare il compilatore di casa ARM. Generalmente se si necessità di funzionalità avanzate come la comunicazione di rete si opta per un sistema dotato di un sistema operativo, lo sviluppo bare-metal è quasi sempre relegato ad applicazioni real-time dove è necessario un determinismo maggiore.

La versione gratuita limita lo sviluppo ad applicazioni Linux/Android tramite GCC ma in molti casi questo non rappresenta un grosso limite. Lo sviluppo bare-metal di processori complessi come l'ARM Cortex A9 non è "consigliato" nei progetti più comuni mentre può avere più senso sviluppare applicazioni e driver specifici per Linux.

Per un elenco completo delle differenze tra le due versioni rimando alla pagina ufficiale.

Vediamo adesso cosa include il SoC EDS:






- ARM DS-5: l'ambiente di sviluppo basato su Eclipse che include praticamente tutto quello di cui si ha bisogno per lo sviluppo di applicazioni basate su Linux.

 

- Hardware Libraries: librerie di basso livello denominate HWLIB che contengono API per l'utilizzo dei GPIO, I2C, SPI, etc.. per il solo sviluppo bare-metal

 

- Configuration Tools: tool come il Device Tree Generator utili per il solo sviluppo bare-metal

 

- Examples: esempi, quasi tutti per lo sviluppo bare-metal.

 

Come è possibile intuire utilizzeremo sostanzialmente il solo ARM DS-5 con il compilatore GCC incluso nell'installazione.

L'utilizzo del compilatore GCC in ambiente Windows non è consigliato da Altera e presenta problemi non presenti nella versione Linux. Ad esempio nella versione attuale (GCC 4 inclusa in DS-5) si hanno problemi di compilazione con programmi contenenti istruzioni NEON. E' quindi consigliabile innanzitutto installare SoC EDS su un sistema Linux in caso di problemi.

E' da notare che è possibile utilizzare il compilatore gratuito GCC per lo sviluppo bare-metal anche senza l'utilizzo di DS-5, tramite makefile per esempio, anche se vedremo solamente lo sviluppo di applicazioni Linux sul processore ARM, lasciando a chi volesse intraprendere lo sviluppo bare-metal alla corposa documentazione disponibile.

FPGA: Cyclone V SoC e DE1-SoC

La DE1-SOC è una scheda di sviluppo prodotta da Terasic per poter progettare rapidamente con le FPGA Cyclone V SE con processore ARM Cortex-A9 dual-core di cui parleremo ancora prossimamente.

La nuova serie Cyclone V è divisa in ben sei varianti diverse:

La dev-board in oggetto è equipaggiata col modello 5CSEMA5F31C6 di cui sono riportate sotto le risorse principali:

Come abbiamo visto nell'articolo precedente in questa nuova serie di FPGA le risorse logiche sono rappresentate in prima istanza dagli ALM, seppur vengano ancora riportati i LE per un confronto rapido con le vecchie serie.

Rispetto alla scheda DE0-Nano, utilizzata nei precedenti articoli, abbiamo risorse logiche quasi quattro volte maggiori (22k LE contro 85k LE), per design di complessità maggiore.

La memoria integrata nelle FPGA (SRAM) sta rapidamente aumentando generazione dopo generazione, ne troviamo a disposizione 4450 Kbit (0.5 MBytes circa) tra blocchi M10K e MLAB.

I blocchi M10K sono blocchi di memoria dedicati da 10 Kbit mentre il 25% degli ALM è configurabile come memoria distribuita (similarmente a quanto avviene nelle FPGA Xilinx) usando gli MLAB da 640 bit.

Facendo un rapido conto 480 Kbit di MLAB totali vogliono dire 768 MLAB da 640 bit, il 25% degli ALM è circa 8018 ALM, quindi approssimando un MLAB è realizzato da fino a 10 ALM, come infatti viene descritto nella documentazione. Quindi ogni ALM "ibrido" contribuisce con ben 64 bit, rispetto ai 4 bit presenti negli ALM "ordinari".

Rispetto alla serie Cyclone IV gli MLAB (già presenti su altre serie di fascia più alta) sono una interessante novità per ottimizzare la creazione di piccole memorie come registri a scorrimento, piccole FIFO, etc.

Continuando la lettura della tabella ogni Variable-precision DSP può implementare due moltiplicatori a 18x18 bit con accumulatore, ma può essere configurato anche diversamente, per implementare un singolo moltiplicatore 27x27 bit con accumulatore ad esempio. Anche in questo caso il numero di moltiplicatori 18x18 è riportato per confrontare rapidamente il dispositivo con vecchi modelli.

Con HPS si intende Hard Processor System, ovvero il processore ARM integrato. Il vantaggio principale rispetto a soluzioni discrete (ovvero un chip per la FPGA ed un chip per il processore ARM, collegati tramite piste su pcb) è sicuramente la riduzione del BOM (Bill of Materials) ma anche sotto il profilo prestazionale una connessione molto veloce tra la FPGA e l'ARM con bande fino a 128 Gbps di picco.

Seppur l'integrazione comporti risparmi sul fronte economico ed energico un possibile svantaggio è la riduzione dell'area dissipabile termicamente. Con due package è possibile montare due sistemi di dissipazione del calore distanti e quindi non interferenti significativamente, ad esempio due dissipatori passivi se il calore generato non è molto, mentre con un unico package lo spazio è minore e quindi le difficoltà ad estrarre il calore sono maggiori. Resta da valutare per la propria applicazione quindi se il power-saving e quindi il minor calore generato dovuto all'integrazione riesce a compensare la maggior difficoltà di mantenere il chip nelle migliori condizioni operative.

HPS e FPGA sono messi in comunicazione tramite dei canali dedicati, alcune risorse come alcuni PLL, I/O e Hard Memory Controller sono collegati direttamente all'HPS, altri alla parte FPGA del chip come è possibile notare dalla tabella sopra.

Ricordo però che tramite i canali di comunicazione è possibile però sfruttare ad esempio gli I/O HPS dalla parte FPGA, anche se ciò richiede un'apposita configurazione.

Lo standard LVDS o comunque gli altri standard differenziali purtroppo non sono utilizzabili in modo sicuro su questa scheda di sviluppo perché la tensione degli I/O, VCCIO, è fissata a 3.3v mentre lo standard LVDS prevede solamente tensioni da 2.5v, per comunicazioni seriali ad alta velocità è necessario guardare ad altre schede di sviluppo, con connettori appositi per l'alta velocità, resistenze di terminazione, linee con impedenze controllate, etc..

Lo speed-grade della FPGA è il più veloce (-6), ideale per ridurre le problematiche di tempistiche e creare design ad elevate frequenze.

Come abbiamo potuto accennare nel precedente articolo la dissipazione del calore può presentare un problema, un semplice design di esempio (come un semplice sommatore ad 8 bit) mostra infatti una Core Static Thermal Power Dissipation stimata in condizioni tipiche di circa 411 mW mentre nelle condizioni peggiori 538 mW.

La scheda prevede il montaggio di un dissipatore con eventuale ventola tramite due fori posti a circa 55 mm lungo la diagonale del chip principale.

E' anche predisposta per un connettore a 3 pin per il collegamento della ventola, di cui però solamente due sono collegati come mostra lo schema seguente.

Dove DNI indica Do Not Installed, ovvero il componente non è presente ma è possibile acquistarlo ed aggiungerlo in quanto predisposto il pcb.

SM2T3V3A è un diodo di protezione TVS unidirezionale, per cortocircuitare a massa segnali con tensioni al di fuori del range [-0.3v,3.6v] circa che potrebbero danneggiare la delicata FPGA.

FDV305N è un NMOS utilizzato in saturazione (come interruttore) per accendere e spegnere la ventola dalla FPGA.

Visto il calore che anche i design di prova forniti da Terasic generano ho provveduto subito al montaggio di un dissipatore con ventola per rimanere sul lato sicuro.

Per non invalidare la garanzia o comunque avere possibili problemi nella sostituzione visto che la scheda è arrivata da poche settimane, non ho installato il connettore ed i componenti aggiuntivi per collegare la ventola ma ho preferito alimentarla esternamente quando necessario.

Il vantaggio è anche che così facendo è possibile regolare la tensione della ventola e non è necessario modificare i progetti pre-esistenti per l'attivazione del pin della ventola se necessario.

Sotto un immagine del risultato finale ed alcuni consigli

- Montando due piccoli distanziali aggiuntivi sul lato inferiore del PCB (sono presenti solo 4 distanziali inferiori) è possibile aumentare la resistenza meccanica della scheda. Porre comunque leggerezza durante operazioni di avvitatura/svitatura. 

- Tra FPGA e dissipatore stendere un sottile strato di pasta termoconduttiva di buona qualità

- Per rimuovere il dissipatore dopo aver rimosso i push-pin non tirarlo verso l'alto ma farlo ruotare per staccare la pasta termoconduttiva, per evitare di esercitare pressioni tali da rompere il package della FPGA.

- Per non perdere di estetica e mantenere la possibilità di installare il pannello in plexiglass sostituire i quattro distanziali superiori (stand-off) con alcuni leggermente più alti in base all'altezza della ventola. Ho utilizzato una ventola con dissipatore a basso profilo per far rientrare comunque il tutto nella busta antistatica e nella scatola originale .

- Porre attenzione alla pressione esercitata da dissipatori con push-pin, regolare le molle per non applicare tensioni fuori dalle massime supportate dal package BGA.

In alternativa è possibile utilizzare dei dissipatori passivi generici (senza ventola), magari a basso profilo se adeguati alla dispersione del calore prodotto, con un thermal pad per una rapida sostituzione.

Ho inoltre applicato un piccolo dissipatore (7x7x4mm) sul piccolo integrato che è possibile vedere in foto sopra. Si tratta dell'Ethernet transceiver siglato ksz9021rl che durante l'utilizzo intensivo con trasmissioni Gigabit Ethernet diventa discretamente caldo.

Buona sperimentazione in sicurezza.