Ambienti di sviluppo

In questo corso, scriveremo codice per programmi assembler e per descrivere reti logiche in Verilog. Per entrambi, utilizziamo un ambiente software che è lo stesso (o estremamente simile) a quello che si troverà all'esame.

Editor

Nelle esercitazioni e nella documentazione faremo riferimento a VS Code, che è l'unico editor che si potrà utilizzare all'esame.

Non c'è però nessun obbligo a usare VS Code per le esercitazioni personali, qualunque editor di file di testo andrà bene. Anche un editor da terminale come nano o vim.

Ambiente assembler

Programmare in assembler vuol dire programmare per una specifica architettura di processori. L'architettura x86 è stata rimpiazzata nel tempo da x64, a 64 bit, che è del tutto retrocompatibile. Altre architetture (in particolare, ARM) hanno istruzioni, registri e funzionamento completamente diversi e non sono compatibili con x86. Usare una macchina con architettura diversa è inevitabilmente fonte di problemi.

L'ambiente fornito funziona con Linux x86 (o x64 o amd64, che significano la stessa cosa). Non funziona invece per processori arm64, come quelli usati da Mac o Windows on ARM.

Da una parte, si potrebbe pensare di esercitarsi scrivendo assembler per la propria architettura, anziché quella usata nel corso. Sorgono diversi problemi:

• dover imparare sintassi, meccanismi, registri completamente diversi;
• dover fare a meno o reingegnerizzarsi la libreria usata per l'input-output a terminale;
• dover comunque imparare l'assembler mostrato nel corso, perché quella sarà richiesta all'esame e supportata dalle macchine in laboratorio.

La seconda opzione è usare strumenti di virtualizzazione capaci di far girare un sistema operativo con architettura diversa. Sorge come principale problema l'ergonomicità ed efficienza di questa soluzione, che dipende molto dagli strumenti che si trovano e dalle caratteristiche hardware della macchina, che potrebbero essere non sufficienti.

Per chi ha una macchina ARM, sarà necessario trovare soluzioni di virtualizzazione o usare un'altra macchina dedicata (va bene qualunque cosa di qualunque potenza, purché x86). In ogni caso, non offriamo nessun supporto diretto a tali macchine. Lo ribadisco in rosso, perché chiesto spesso.

Nessun supporto diretto per Mac con ARM

Non testiamo né supportiamo ambienti per Mac con ARM, che non abbiamo a disposizione. Ci è stato detto che UTM può emulare l'architettura x86, affermazione che riportiamo senza alcuna garanzia. Non risponderemo a ulteriori domande a riguardo, soprattutto se parte delle domande frequenti.

Oltre a questioni di architettura, abbiamo anche il sistema operativo, che è rilevante per gestire input e output da terminale. I programmi che scriveremo ed eseguiremo, così come quelli utilizzati per assemblare, gireranno in un terminale Linux. Nei pacchetti forniti e in sede di esame, si usa in particolare Ubuntu 24.04.

Perché Linux?

Perché è molto più facile virtualizzare un ambiente Linux moderno in Windows o Mac che il contrario. In precedenza si usava MS-DOS, un sistema del 1981 facilmente emulabile, ma molto limitante data l'età.

Per assemblare, si usa gcc, per debuggare gdb. Per usarli però sono necessari comandi lunghi, che semplifichiamo usando script Powershell assemble.ps1 e debug.ps1.

Perché Powershell?

Perché Powershell (2006) è object-oriented, e permette di scrivere script leggibili e manutenibili, in modo semplice. Bash (1989) è invece text-oriented, con una lunga lista di trappole da saper evitare.

32 vs 64 bit

In realtà, i processori x86 a soli 32 bit non sono più in commercio da vent'anni. I processori che si trovano oggi sono x64, a 64 bit, e sono in grado di eseguire codice a 32 bit per retrocompatibilità. Nel corso, continuiamo ad usare l'istruction set a 32 bit perché

1. è di complessità ridotta e sufficiente per i nostri scopi didattici,
2. il vecchio ambiente DOS, che qualcuno può trovare ancora utile, supporta solo x86.

Ambiente Verilog

L'ambiente Verilog non ha i problemi di quello assembler, perché quel che compiliamo (una rete simulabile) non è legato sistema operativo o all'architettura della CPU. Basta che si riescano ad installare

• iverilog e vvp
• GTKWave

Versioni dell'ambiente e alternative

informazioni

L'ambiente dell'A.A. 2025/26 è leggermente diverso da quello degli anni precedenti. Le differenze riguardano solo aspetti di installazione e configurazione, il modo di utilizzo rimane pressoché invariato.

Se si ha già un ambiente funzionante, non c'è bisogno di fare nulla.

L'ambiente è fornito in due versioni:

• Windows 11 + WSL2
• Linux nativo o devcontainer

Questi contengono sia istruzioni per installazione e configurazione, sia le cartelle assembler e verilog con i file necessari per scrivere codice.

suggerimento

Tenere presente che non c'è bisogno di utilizzare lo stesso tipo di pacchetto o macchina per assembler e Verilog, le due scelte sono indipendenti.

Ambiente per Windows 11 + WSL2

Download

Questo pacchetto supporta macchine Windows 11 x64, utilizza WSL2 per virtuallizare un sistema Ubuntu 24.04 per assembler, e applicazioni native per Verilog.

WSL2 è un sottosistema di Windows che permette di virtualizzare macchine Linux in modo semplice, e l'integrazione con VS Code tramite l'estensione WSL permette di scrivere codice fuori dalla macchina virtuale ed assemblare ed eseguire dentro la macchina virtuale. Questo ci permette di mantenere un ambiente grafico moderno mentre si lavora con un terminare Linux virtualizzato.

Schema dell'ambiente usato all'esame.

Il pacchetto dell'ambiente contiene le istruzioni passo passo per installare e configurare la macchina virtuale su una macchina Windows 11 con architettura x86.

Per l'ambiente Verilog, invece, ci sono sia installer precompilati qui che codice sorgente qui e qui.

Ambiente per Linux nativo o devcontainer

Download

Questo pacchetto supporta due scenari: una macchina con Linux x64, oppure devcontainers tramite Docker.

Il pacchetto contiene le cartelle assembler e verilog con i file necessari per scrivere codice.

Utilizzo nativo

Per assembler, l'ambiente Linux deve essere in grado di

• Eseguire gli script powershell dell'ambiente
• Assemblare, usando gcc, programmi x86 scritti con sintassi GAS
• Eseguire programmi x86
• Debuggarli usando gdb

Per far questo su Ubuntu 24.04, i pacchetti da installare sono

• build-essential
• gcc-multilib
• gdb
• powershell (guida)

Per Verilog, l'ambiente Linux deve essere in grado di

• Compilare simulazioni con iverilog
• Eseguire simulazioni con vvp
• Visualizzare waveform con gtkwave

Per far questo su Ubuntu 24.04, i pacchetti da installare sono

• iverilog
• gtkwave

Altro software per installazioni minime

Script e istruzioni si basano anche su due altri programmi: wget e file. Di solito sono inclusi di default per installazioni Desktop, ma su installazioni minime (come l'immagine Docker di Ubuntu 24.04) vanno installati manualmente.

Una volta installato il software richiesto, per sviluppare basterà aprire le cartelle con VS Code.

Utilizzo tramite devcontainer

I devcontainer sono un'altra forma di virtualizzazione integrata in VS Code, basata su Docker anziché WSL. Il pacchetto include, nelle cartelle .devcontainer, i Dockerfile che installano il software necessario su immagini Ubuntu 24.04.

Una volta aperta la cartella con VS Code, usare il comando "Riapri in devcontainer".

Alternative fai da te

Un'altra opzione molto utile di VS Code è lo sviluppo remoto tramite SSH usando questa estensione. In questo caso, invece di collegarsi a un ambiente di sviluppo virtualizzato, questo risiede su un'altra macchina a cui ci si collega aprendo un terminale SSH.

Schema di un ambiente che usa SSH.

Da notare che le macchine sono distinte "concettualmente": niente ci vieta di avere una macchina virtuale (e.g. VirtualBox) al posto di una macchina fisicamente distinta.

Testare gli ambienti

I pacchetti includono dei file per testare che l'ambiente sia utilizzabile.

Assembler

Il file test-ambiente.s contiene il codice di un semplice programma che si limita a stampare Ok.. Provare ad assemblarlo, eseguirlo e debuggarlo.

PS /workspaces/assembler> ./assemble.ps1 ./test-ambiente.s
PS /workspaces/assembler> ./test-ambiente                 
Ok.
PS /workspaces/assembler> ./debug.ps1 ./test-ambiente
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
[output di poca utilità]
Breakpoint 1, _main () at /workspaces/assembler/test-ambiente.s:7
7       _main:  nop
(gdb) qq
PS /workspaces/assembler> 

Verilog

Il file test-ambiente.v contiene il codice di una semplice testbench con registro da 1 bit che cambia valore, e stampa Ok. a terminale prima di terminare. Provare a compilare ed eseguire la simulazione, e poi osservarne la waveform.

PS /workspaces/verilog> iverilog -o sim ./test-ambiente.v 
PS /workspaces/verilog> vvp ./sim  
VCD info: dumpfile waveform.vcd opened for output.
Ok.
./test-ambiente.v:10: $finish called at 20 (1s)
PS /workspaces/verilog> gtkwave ./waveform.vcd  
[output di poca utilità]
PS /workspaces/verilog>