Microprocessore a 16 bit in tecnologia CMOS 45nm

Transcript

1 Descrizione Microprocessore a 16 bit in tecnologia CMOS 45nm Realizzare interamente un semplice microprocessore Pico a 16 bit, partendo dalla unità logico-aritmetica (ALU) fino ad arrivare al microcontrollore. ALU (unità logico/aritmetica) Inizialmente ho preso familiarità con la suite di sviluppo Cadence Design Systems, in particolare ho preso familiarità con il tool NC-SIM e con la scrittura iniziale di un primo listato VHDL di prova. Il primo passo per realizzare il microprocessore è quello di realizzare l'unità logico-aritmetica (ALU). Tale componente è suddiviso in due sottosezioni: un blocco aritmetico; un blocco booleano; un multiplexer che seleziona l'uscita dei due blocchi (operazione aritmetica o booleana). Stefano Guerra Pagina 2

2 UNITA ARITMETICA Di seguito è riportato lo schema del blocco aritmetico. Tale blocco si realizza tramite utilizzo di alcuni componenti: 1. un moltiplicatore di Booth; 2. un addizionatore di tipo Ripple Carry; 3. un blocco logico chiamato "b_op" che consente di realizzare le funzioni di incremento, decremento, sottrazione. Da ricordare, inoltre, che l'operazione di moltiplicazione di due numeri binari da 16 bit produce un risultato da 32bit di cui solo i 16 bit più significativi vengono utilizzati, mentre gli altri 16 bit non verranno presi in considerazione. Il multiplexer selezionerà l uscita del blocco aritmetico. Tabella di verità del blocco b_op Da osservare che sfruttando il riporto entrante dell'addizionatore si riescono a realizzare le seguenti operazioni aritmetiche su i due ingressi A e B (assumendo una rappresentazione dei numeri in complementi a due). Di seguito viene riportata la tabella di verità. Stefano Guerra Pagina 3

3 Dopo aver progettato accuratamente il blocco aritmetico sono passato allo sviluppo del componente, cioè una descrivere in VHDL del blocco aritmetico. library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; --Blocco aritmetico dell'alu entity aritm is port( A : in std_logic_vector(15 downto 0); --Operando A B : in std_logic_vector(15 downto 0); --Operando B zero, invert, c, m : in std_logic; --Segnali di selezione dell'operazione Z : out std_logic_vector(15 downto 0) --Uscita A ); end aritm; architecture mix of aritm is component b_op port( B : in std_logic_vector(15 downto 0); zero, invert : in std_logic; B_out : out std_logic_vector(15 downto 0) ); end component; --Segnali ausliari signal B1, S, T, c_slv : std_logic_vector(15 downto 0); --Segnali interni di b_op, somma, prodotto e carry signal A_s, B_s, B1_s, c_s : signed(15 downto 0); --Segnali numeric per l'utilizzo degli operatori signal S_s : signed(15 downto 0); --di numeric_std signal T_s : signed(31 downto 0); begin --Istanza del componente b_op C1 : b_op port map ( B => B, zero => zero, invert => invert, B_out => B1 ); A_s <= signed(a); --Cast dei segnali a signed B_s <= signed(b); c_slv <= " " & c; --c è il bit di carry-in, va espanso su 16 bit e convertito a signed c_s <= signed(c_slv); B1_s <= signed(b1); S_s <= A_s + B1_s + c_s; --Somma T_s <= A_s * B_s; --Prodotto S <= std_logic_vector(s_s); --Riconversione a std_logic_vector T <= std_logic_vector(t_s(31 downto 16)); Stefano Guerra Pagina 4

4 with m select --Selezione del risultato Z <= S when '0', --Operazioni additive T when '1', --Prodotto (others => '0') when others; end mix; library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity b_op is port( B : in std_logic_vector(15 downto 0); --Ingresso Dati zero, invert : in std_logic; --Segnali di controllo dell'operazione B_out : out std_logic_vector(15 downto 0) --Uscita Dati ); end b_op; architecture dataflow of b_op is signal sel : std_logic_vector(1 downto 0); --Segnale ausiliario usato per compattare il codice assegn. begin sel <= zero & invert; with sel select --Compatta zero e invert --Selezione dell'operazione B_out <= B when "00", not B when "01", (others => '0') when "10", (others => '1') when "11", (others => 'Z') when others; end dataflow; library IEEE; use IEEE.STD_LOGIC_1164.ALL; USE ieee.std_logic_arith.all; use ieee.numeric_std.all; entity Moltiplicatore is generic (size: integer :=16); Port ( A : in STD_LOGIC_VECTOR (size-1 downto 0); B : in STD_LOGIC_VECTOR (size-1 downto 0); T : out STD_LOGIC_VECTOR(size-1 downto 0) ); end Moltiplicatore; architecture Behavioral of Moltiplicatore is signal mya,myb : signed(size-1 downto 0); signal myt : signed(31 downto 0); begin mya <= signed(a); myb <= signed(b); myt <= mya*myb; T <= STD_LOGIC_VECTOR(myT (31 downto 16)); end Behavioral; Stefano Guerra Pagina 5

5 library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity ripple_carry is generic (size: integer :=16); port( a,b : in std_logic_vector (size-1 downto 0); ); end ripple_carry; cin : in std_logic; s : out std_logic_vector (size-1 downto 0); cout : out std_logic architecture structural of ripple_carry is component f1 port( a,b,ci : in std_logic; s,co : out std_logic ); end component f1; for all : f1 use entity work.full_adder(gate); signal carry : std_logic_vector (size downto 0); begin carry(0) <= cin; FA1 to 2 : FOR i IN 0 TO size-1 GENERATE FA: entity work.full_adder(gate) PORT MAP (a(i),b(i),carry(i),s(i),carry(i+1)); END GENERATE; cout <= carry(size) xor carry(size-1); end structural; library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity Full_Adder is port( a,b,ci : in std_logic; s,co : out std_logic ); end Full_Adder; architecture gate of Full_Adder is begin s <= (a xor b xor ci); co <= ((a and b) or (a and ci) or (b and ci)); end gate; Stefano Guerra Pagina 6

6 library ieee; use ieee.std_logic_1164.all; entity multiplexer is port( T : in std_logic_vector(15 downto 0); S : in std_logic_vector(15 downto 0); M : in std_logic; Z : out std_logic_vector(15 downto 0) ); end multiplexer; architecture dataflow of multiplexer is begin Z <= S when m='0' else T; end dataflow; Descritto il componente in VHDL lo poi compilato con "nclaunch" per verificare che non ci siano errori. Da osservare che la libreria worklib che si trova nell' interfaccia di "nclaunch" contiene il modulo aritmetico, per il quale nclaunch riporta la definizione di entity ed una o più definizioni di architecture (è possibile, infatti, per la stessa entity definire più architecture ed utilizzarle selettivamente a seconda del tipo di simulazione che si vuole effettuare). A questo punto per testare il corretto funzionamento del componente (blocco aritmetico) è necessario scrivere il test-bench. Le condizioni che voglio verificare sono riportate in tabella dove A e B sono i valori e Z è il risultato atteso (i valori espressi in tabella sono numeri decimali). library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity test_aritm is end test_aritm; architecture behavioral of test_aritm is Stefano Guerra Pagina 7

7 component aritm port( A : in std_logic_vector(15 downto 0); B : in std_logic_vector(15 downto 0); zero,invert,c,m : in std_logic; Z : out std_logic_vector(15 downto 0) ); end component; signal A,B,Z : std_logic_vector(15 downto 0); signal op : std_logic_vector(3 downto 0); begin cut: aritm port map( A => A, B => B, zero => op(1), invert => op(2), c => op(0), m => op(3), Z => Z ); stimulus: process begin A <= std_logic_vector(to_signed(99,16)); B <= std_logic_vector(to_signed(43,16)); Op <= "0000"; wait for 10 ns; assert Z = std_logic_vector(to_signed(142,16)) report "errore in A+B" severity warning; A <= std_logic_vector(to_signed(99,16)); B <= std_logic_vector(to_signed(43,16)); op <= "0010"; wait for 10 ns; assert Z=std_logic_vector(to_signed(99,16)) report "errore in A" severity warning; A<= std_logic_vector(to_signed(99,16)); B<= std_logic_vector(to_signed(43,16)); op<="0011"; wait for 10 ns; assert Z=std_logic_vector(to_signed(100,16)) Stefano Guerra Pagina 8

8 report "errore in A+1" severity warning; wait; end process; end behavioral; UNITA LOGICA Blocco logico realizza tutte le 16 possibili funzioni booleane di due variabili. Essa, per ciascun bit di A e B, utilizza un multiplexer 4-1. Di seguito è mostrato lo schema a blocchi per descrivere il componente. I valori dei segnali f3 f2 f1 f0 determinano quale delle possibili funzioni booleane viene implementata. I 16 possibili valori del vettore f3 f2 f1 f0 realizza la seguente funzione booleana. Di seguito viene riportato la tabella di verità. Stefano Guerra Pagina 9

9 library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity bool is port( A,B : in std_logic_vector(15 downto 0); f3, f2, f1, f0 : in std_logic; W : out std_logic_vector(15 downto 0) ); end bool; architecture Structural of bool is component Multiplexer4 is port( A,B : in std_logic_vector(15 downto 0); S : in std_logic_vector(3 downto 0); O : out std_logic_vector(15 downto 0) ); end component; for all : Multiplexer4 use entity work.multiplexer4(behavioral); signal selezione : std_logic_vector (3 downto 0); begin selezione<=(f0,f1,f2,f3); end Structural; mux : Multiplexer4 port map (A,B,selezione,W); Stefano Guerra Pagina 10

10 library ieee; use ieee.std_logic_1164.all; entity mux4_1 is port( a, b : in std_logic; --Variabili f3, f2, f1, f0 : in std_logic; --Funzione logica w : out std_logic --Uscita ); end mux4_1; architecture dataflow of mux4_1 is signal aux : std_logic_vector(1 downto 0); begin aux <= a & b; with aux select --Segnale ausiliario per semplificare il with\select end dataflow; w <= f3 when "11", f2 when "10", f1 when "01", f0 when "00", 'Z' when others; Dopo aver compilato i listati e verificato che non ci siano errori nella descrizione del blocco bool, sono passato alla scrittura del test-bench per verificare che il componente abbia il funzionamento atteso. Di seguito vengono riportati in una tabella i casi di test più significativi per verificare al meglio il componente: Stefano Guerra Pagina 11

11 library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity bool_tb is end bool_tb; architecture behavioral of bool_tb is component bool port( A : in std_logic_vector(15 downto 0); B : in std_logic_vector(15 downto 0); f3 : in std_logic; f2 : in std_logic; f1 : in std_logic; f0 : in std_logic; W : out std_logic_vector(15 downto 0) ); end component; signal A, B : std_logic_vector(15 downto 0); signal f : std_logic_vector(3 downto 0); signal W : std_logic_vector(15 downto 0); begin cut : bool port map ( stimulus : process A => A, B => B, f3 => f(3), f2 => f(2), f1 => f(1), f0 => f(0), W => W ); begin A <= " "; B <= " "; f <= "0000"; wait for 10 ns; assert W = " " report "errore in 0" severity warning; A <= " "; B <= " "; f <= "0001"; wait for 10 ns; assert W = " " report "errore in A nor B" severity warning; A <= " "; B <= " "; Stefano Guerra Pagina 12

12 f <= "0011"; wait for 10 ns; assert W = " " report "errore in not A" severity warning; A <= " "; B <= " "; f <= "0101"; wait for 10 ns; assert W = " " report "errore in not B" severity warning; A <= " "; B <= " "; f <= "0110"; wait for 10 ns; assert W = " " report "errore in A xor B" severity warning; A <= " "; B <= " "; f <= "1010"; wait for 10 ns; assert W = " " report "errore in B" severity warning; A <= " "; B <= " "; f <= "1100"; wait for 10 ns; assert W = " " report "errore in A" severity warning; A <= " "; B <= " "; f <= "1110"; wait for 10 ns; assert W = " " report "errore in A or B" severity warning; A <= " "; B <= " "; Stefano Guerra Pagina 13

13 f <= "1111"; wait for 10 ns; assert W = " " report "errore in 1" severity warning; end process; end behavioral; wait; UNITA LOGICO-ARITMETICA Dopo aver realizzato i due componenti e verificato il corretto funzionamento tramite il test-bench, li ho collegati in modo opportuno aggiungendo un ulteriore multiplexer che stabilisce se deve essere compiuta un operazione logica o aritmetica. Di seguito viene riportato il listato (top model) dell' unità logico-aritmetica (ALU). library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity alu is port( end alu; ); A,B : in std_logic_vector(15 downto 0); opcode : in std_logic_vector(4 downto 0); W : out std_logic_vector(15 downto 0) Stefano Guerra Pagina 14

14 architecture Behavioral of alu is COMPONENT aritm PORT( A : IN std_logic_vector(15 downto 0); B : IN std_logic_vector(15 downto 0); Zero : IN std_logic; invert : IN std_logic; c : IN std_logic; m : IN std_logic; Z : OUT std_logic_vector(15 downto 0) ); END COMPONENT; for all: aritm use entity work.aritm(structural); COMPONENT bool PORT( A : IN std_logic_vector(15 downto 0); B : IN std_logic_vector(15 downto 0); f3 : IN std_logic; f2 : IN std_logic; f1 : IN std_logic; f0 : IN std_logic; W : OUT std_logic_vector(15 downto 0) ); END COMPONENT; for all: bool use entity work.bool(structural); component Multiplexer port( I0: in std_logic_vector(15 downto 0); I1: in std_logic_vector(15 downto 0); S: in std_logic; O: out std_logic_vector(15 downto 0) ); end component; for all: Multiplexer use entity work.multiplexer(behavioral); signal S,T : std_logic_vector(15 downto 0); signal bit0,bit1,bit2,bit3,m : std_logic; begin bit0 <= opcode(0); bit1 <= opcode(1); bit2 <= opcode(2); bit3 <= opcode(3); m <= opcode(4); aritmetica boolea mux : aritm port map(a,b,bit3,bit2,bit1,bit0,s); : bool port map(a,b,bit3,bit2,bit1,bit0,t); : multiplexer port map(s,t,m,w); end Behavioral; Stefano Guerra Pagina 15

15 Dopo aver scritto il listato (top model del componenete) e verificato che non ci siano errori, ho realizzato il testbench per verificare che il componente abbia il funzionamento atteso. LIBRARY ieee; USE ieee.std_logic_1164.all; ENTITY Test_Alu IS END Test_Alu; ARCHITECTURE behavior OF Test_Alu IS COMPONENT alu PORT( A : IN std_logic_vector(15 downto 0); B : IN std_logic_vector(15 downto 0); opcode : IN std_logic_vector(4 downto 0); W : OUT std_logic_vector(15 downto 0) ); END COMPONENT; --Inputs signal A : std_logic_vector(15 downto 0) := (others => '0'); signal B : std_logic_vector(15 downto 0) := (others => '0'); signal opcode : std_logic_vector(4 downto 0) := (others => '0'); --Outputs signal W : std_logic_vector(15 downto 0); BEGIN -- Instantiate the Unit Under Test (UUT) uut: alu PORT MAP ( A => A, B => B, opcode => opcode, W => W ); Stefano Guerra Pagina 16

16 stim_proc: process begin -- hold reset state for 100 ns. wait for 100 ns; A<=" "; -- A=99 B<=" "; -- B=43 wait for 100 ns; opcode<="10000"; wait for 50 ns; opcode<="11000"; wait for 50 ns; opcode<="11010"; wait for 50 ns; opcode<="10110"; -- Operazioni di Moltiplicazione wait for 50 ns; B<=" "; -- B=111 wait for 50 ns; opcode<="11100"; wait; end process; END; wait for 50 ns; opcode<="11101"; wait for 50 ns; B<=" "; -- B=43 Stefano Guerra Pagina 17

17 SINTESIDELLA ALU DEL PROCESSORE Una volta progettato il circuito in VHDL e verificato che abbia il funzionamento atteso in fase di progettazione, è necessario sintetizzarlo utilizzando una libreria di celle standard. Tali celle sono sottocircuiti che realizzano operazioni molto semplici (un esempio tipico di cella standard può essere una porta NAND a due o più ingressi, oppure una cella AOI). La fase di sintesi permette di passare da una generica descrizione VHDL del circuito ad una sua descrizione strutturale che utilizzi come componenti le sole celle standard di libreria. Completata la fase di sintetizzazione, il circuito può essere facilmente implementato, piazzando su silicio le celle necessarie e collegandole tra di loro in modo opportuno. Per poter realizzare il datapath realizzato in precedenza utilizzeremo una libreria di celle standard in tecnologia CMOS a 45nm con tensione di alimentazione ad 1.1V. Il programma di sintesi ha bisogno per funzionare, oltre che della descrizione VHDL del circuito, anche di una descrizione accurata delle celle di libreria utilizzate. Un formato molto diffuso per la descrizione delle librerie di celle standard è il formato liberty, sviluppato dalla Synopsys, uno dei leader mondiali nella realizzazione di strumenti software per il CAD di circuiti integrati. Il file contenente la descrizione liberty della libreria è: NangateOpenCellLibrary_typical_conditional_ccs_mod.lib Come si può osservare il file è diviso in due parti: parte dichiarativa, ed una seconda parte contenente la descrizione delle celle standard. 1. Nella parte dichiarativa vengono fissate le unità di misura, i valori di tensione, temperatura e processo con i quali sono state ottenute le prestazioni delle celle, alcune tabelle di riferimento che verranno successivamente utilizzate per descrivere il funzionamento delle celle. 2. La seconda parte del file, invece, contiene una lista di tutte le celle standard che possono essere utilizzate nella sintesi. La cella standard che utilizzeremo è una cella NAND a 2 ingressi e con driving strength pari ad 1 (X1). In generale in una libreria di celle standard esistono più celle che implementano la stessa funzionalità (ad esempio esistono più celle che implementano la funzionalità di una NAND a 2 ingressi), ma che si differenziano per la driving strength. Una cella con maggiore driving strength è realizzata utilizzando MOSFETS con gate più larga ed è in grado di pilotare carichi maggiori e di commutare con una maggiore velocità. Nella descrizione della cella viene riportata l occupazione d area, e la dissipazione di potenza statica. Segue poi la lista dei pin della cella. Per i pin di ingresso sono indicati i valori di capacità di carico ed il massimo tempo di transizione consentito. Per i pin di uscita viene riportata la funzione booleana calcolata dalla cella, la massima capacità di carico che il pin può pilotare e il massimo tempo di transizione consentito sul pin. Inoltre, per ciascun pin di uscita viene riportato il corrispondente ritardo e la dissipazione di potenza dinamica. Sintesi generica Il primo passo è quello di caricare i files vhdl scritti in precedenza nel sintetizzatore. Di seguito riporto un esempio di come ho caricato i files VHDL: 1. read_vhdl hdl/bool.vhd 2. read_vhdl hdl/aritm.vhd 3. read_vhdl hdl/alu.vhd Successivamente per poter effettuare la sintesi dovrò trasformare il circuito descritto in vhdl in termini di alcuni componenti elementari, definiti generici, non appartenenti ad un particolare libreria di celle standard. Stefano Guerra Pagina 18

18 I componenti elementari del sintetizzatore sono: flip-flop, operatori booleani, operatori aritmetici e altre macro di libreria. Il comando per effettuare questa sintesi è il seguente: " do_build_generic". Il risultato della sintesi può essere trasformato nuovamente in un file vhdl, e questo è utile per vedere come opera il sintetizzatore. Con il comando "write_vhdl hier hdl/sintesi1.vhd" il sintetizzatore genera il file sintesi1.vhd nella sottocartella denominata hdl. Di seguito riporto un elenco dei blocchi aritmetici che sono stati individuati dal sintetizzatore. Il sintetizzatore, quindi, riporterà il file e la linea di codice cui faranno riferimento i vari blocchi. Sintesi con celle standard Il passo successivo nel processo di sintesi consiste nel caricare nel sintetizzatore la libreria di celle standard. A tal fine utilizzerò un semplice script di automazione "script/config.tcl". Di seguito riporto il contenuto di tale scripts. Questo primo script mi serve per settare alcuni parametri della sintesi. Lo script legge due file liberty contenenti la descrizione delle celle standard negli angoli di processo fast e tipico. Le ultime istruzioni servono per definire il modo in cui il sintetizzatore deve effettuare l analisi della velocità del circuito. In particolare, il Stefano Guerra Pagina 19

19 sintetizzatore è istruito ad utilizzare l angolo di processo fast per caratterizzare i ritardi del circuito quando siamo interessati a verificare violazioni nel tempo di hold, mentre utilizza l angolo di processo tipico per determinare la massima frequenza di funzionamento del circuito. Eseguo lo script, digitatando nella finestra di comando del sintetizzatore: source script/config.tcl Effettuo il Mapping del circuito utilizzando le celle standard di libreria con il comando: do_optimize effort high Lancio quindi il comando: report_area hier cells ed ho verificato che il blocco che occupa più area è proprio il moltiplicatore nel modulo aritmetico, mentre le celle standard più utilizzate sono INV_X4 invertitori a 4 bit. Stefano Guerra Pagina 20

20 Timing analysis Microprocessore a 16 bit in tecnologia CMOS 45nm Passo ora ad effettuare la timing analysis del circuito per valutarne i ritardi massimi. Si noti che al momento non ho ancora imposto alcun vincolo al progetto e quindi l ottimizzatore non ha effettuato particolari modifiche al circuito al fine di renderlo più veloce o per ridurne l area. Per ottenere il ritardo massimo utilizzo il comando: report_timing late -unconstrained Ho analizzato l output di tale comando al fine di verificare dove passa il cammino corrispondente al ritardo massimo e quali celle sono coinvolte. Dopo una rapida analisi si è potuto constatare che il cammino critico passa per il blocco aritmetico e in particolare per il moltiplicatore, proprio come mi aspettavo, le celle coinvolte sono per lo più blocchi di porte 2 2-AND into 2-NOR usate nel blocco moltiplicatore. Nel caso in cui volessi il ritardo minimo: report_timing early -unconstrained Stefano Guerra Pagina 21

21 Sintesi con vincoli temporali e scripts di sintesi Al fine di proseguire con la sintesi è necessario indicare al sintetizzatore quali sono i requisiti di velocità del circuito. A parità di funzionalità, infatti, il circuito può essere implementato con celle più o meno veloci. Realizzare un circuito più veloce del necessario richiede l utilizzo di celle più grandi le quali comportano una maggiore dissipazione di potenza. Di conseguenza il sintetizzatore cercherà di realizzare un circuito che vada esattamente alla velocità richiesta (o poco più veloce) in modo da ottimizzare la dissipazione di potenza e l'area occupata. Nel mio caso ho un sistema puramente combinatorio. Il sintetizzatore richiede comunque la definizione di un riferimento temporale (segnale di clock) i cui fronti sono necessari per definire i tempi di arrivo degli ingressi ed i tempi richiesti per le uscite. Per definire i vincoli temporali ho utilizzato uno script di automazione, script/constraints.tcl. Di seguito ho riportato il contenuto di tale scripts. Con il comando create_clock si definisce un segnale di riferimento, di periodo 10ns, denominato my_clk. Il comando successivo, set_input_delay, definisce il ritardo (rispetto al fronte del clock) con cui si presentano i segnali di ingresso. Il comando set_output_delay definisce invece un ritardo aggiuntivo fra l uscita del sistema combinatorio ed il nodo in cui verificare la temporizzazione. Le ultime due linee del file sono inserite al fine di modellare accuratamente ritardo del sistema combinatorio. Il comando set_input_transition definisce il tempo di salita dei segnali di ingresso, mentre il comando set_load stabilisce la capacità di carico presente sulle uscite. Dopo aver lanciato tale script ho effettuato nuovamente la timing analysis. Ecco di seguito un estratto della timing analysis effettuata: Provando a modificare il parametro set_input_transition (0,150), triplicandolo ed eseguendo nuovamente la timing analysis dopo aver applicato i vincoli, si può facilmente verificare che il ritardo che si modifica è l ArrivalTime come mostrato di seguito: Stefano Guerra Pagina 22

22 Dopo aver riportato il parametro al suo valore originario, modificando il set_load (0,030) ed eseguendo nuovamente la timing analysis dopo aver applicato i vincoli, in questo caso si può notare che anche in questo caso cresce l ArrivalTime come mostrato di seguito: Dopo aver riportato i parametri ai valori originari, ho modificato lo script dei vincoli riducendo il periodo a 2.5ns. Dalla timing analysis come si può notare si ottiene uno slack negativo: i vincoli di timing non sono più verificati. Tramite il sintetizzatore ho sintetizzato nuovamente il circuito, in modo da soddisfare il vincolo sul ritardo massimo, minimizzando al contempo l area con il comando: do_optimize reclaim_maximum_area Al fine di ripetere più volte la sintesi, variando il massimo ritardo richiesto al circuito, ho effettuato la modifica del file constraints.tcl aggiungendo la variabile $periodo, come mostrato di seguito: Ho quindi eseguito con il comando: Ed ho analizzato i risultati generati nei file di log nella cartella reports. In particolare ho potuto analizzare come cambiano le prestazioni del circuito al variare del constraint sulla velocità, per facilitare la lettura ho generato questa tabella riepilogativa. Variabile periodo [ns] Slack [ns] bgx_shell f script/flow.tcl Minimo periodo di funzionamento Area [um^2] Architettura moltiplicatore ed addizionatore 5 ns 2,03 2, ,35 ripple/ booth ripple 2,5 ns 0,04 2, ,77 ripple/ booth ripple 2,2 ns 0,01 2, ,80 booth ripple 2 ns 0,01 1, ,06 booth ripple 1,8 ns 0 1,8 1579,77 booth ripple 1,6 ns 0 1,6 1644,15 booth ripple Stefano Guerra Pagina 23

23 Sintesi del Data-path del processore Il Datapth, oggetto di questa esercitazione, include la ALU sviluppata in precedenza, il registro che contiene il dato in ingresso dalla memoria, l accumulatore che immagazzina il risultato prodotto dall ALU ed un semplice blocco combinatorio che fornisce un uscita alta qualora il valore dell accumulatore sia zero. Di seguito riporto i listati dell'intero Datapath con il relativo test-banch per verificare il corretto funzionamento. library ieee; use ieee.std_logic_1164.all; entity zero_detector is port( data : in std_logic_vector(15 downto 0); --Data In zero : out std_logic --Segnale di rilevamento dello zero ); end zero_detector; --Architettura di tipo behavioral architecture behavioral of zero_detector is begin process (data) variable aux : std_logic := '0'; --Variabile ausiliaria inizializzata a 0 --impiegata per ottenere asseganzione immediate begin if (data = " ") then --Se data è 0 mette a 1 l'uscita aux := '1'; end if; zero <= aux; end process; end behavioral; Stefano Guerra Pagina 24

24 library ieee; use ieee.std_logic_1164.all; --Registro a 16 bit attivo sul fronte di salita del clock con reset sincrono e segnale di enable entity reg16 is port( data : in std_logic_vector(15 downto 0); --Data In clk, en, reset : in std_logic; --Segnali di controllo (clock, reset, enable) q : out std_logic_vector(15 downto 0) --Data Out ); end reg16; --Architettura di tipo behavioral architecture behavioral of reg16 is begin --Processo sensibile al clock process (clk) begin if rising_edge(clk) then --Quando si verifica il fronte di salita if (reset = '1') then --controlla il reset, se non è attivo q <= (others => '0'); --reset attivo: azzera il registro elsif (en = '1') then --controlla l'enable q <= data; --en attivo: scrive data in ingresso end if; end if; end process; end behavioral; library ieee; use ieee.std_logic_1164.all; --Blocco datapath che riceve un operando e il codice operatico dall'esterno --ed esegue l'operazione eventualmente con un operando interno di accumulazione. entity datapath is port( DataIn : in std_logic_vector(15 downto 0); --Operando opcode : in std_logic_vector(4 downto 0); --Codice operativo reset, LoadData, LoadAcc, clk : in std_logic; --Segnali di controllo z : out std_logic; --Segnale di rilevamento dello zero C, DataOut : out std_logic_vector(15 downto 0) --Operando e risultato dell'alu ); end datapath; --Architettura di tipo structural architecture structural of datapath is --L'alu riceve i ingressi da un registro data1 e da un registro acc1 accumulatore --in più è presente un blocco che rileva il risultato nullo component alu Stefano Guerra Pagina 25

25 port( end component; component reg16 port( ); end component; A, B : in std_logic_vector(15 downto 0); opcode : in std_logic_vector(4 downto 0); W : out std_logic_vector(15 downto 0) ); data : in std_logic_vector(15 downto 0); clk, en, reset : in std_logic; q : out std_logic_vector(15 downto 0) component zero_detector port( data : in std_logic_vector(15 downto 0); zero : out std_logic ); end component; signal acc_in, acc_out, op : std_logic_vector(15 downto 0); --Segnali di collegamento interni begin alu1 : alu port map( A => acc_out, --Operando letto dall'uscita di acc1 B => op, --Operando letto dall'uscita di data1 opcode => opcode, W => acc_in ); data1 : reg16 port map( ); acc1 : reg16 port map( ); data => DataIn, clk => clk, en => LoadData, reset => reset, q => op data => acc_in, clk => clk, en => LoadAcc, reset => reset, q => acc_out zero1 : zero_detector port map( C <= op; DataOut <= acc_out; end structural; ); data => acc_out, zero => z Stefano Guerra Pagina 26

26 Sintesi Ho effettuato ora la sintesi dell intero blocco Datapath. A differenza della ALU, il circuito Datapath è sequenziale ed ha un pin di clock. Questa informazione va passata al sintetizzatore nel file constraint.tcl. In questo modo considero due ritardi diversi per la logica in ingresso nella verifica dei tempi di setup (250ps) e di hold (200ps). Modello di timing per il vincolo sul tempo di setup Nel mio caso, non c è alcuna logica in_to_reg, per cui il valore dell input delay non è critico. La logica reg_to_out si limita al circuito che verifica quando l accumulatore è zero ed è quindi anch essa non critica. Posso ora in definitiva aspettarmi che il limite per il periodo del clock sia dettato dalla logica reg_to_reg. Ho modificato lo script flow.tcl in modo da caricare tutti i file vhdl necessari alla sintesi ed ho effettuato, quindi la Stefano Guerra Pagina 27

27 sintesi del circuito, dopo aver posto il periodo del clock a 2.5ns. Posso notare che tra gli avvisi che il sintetizzatore rilascia dopo la fase di elaborazione (comando do_build_generic) adesso compare quello relativo alla presenza di flip-flop nel circuito. Tramite il comando report_timing late ho controllato se il vincolo sul tempo di setup (ritardo massimo) è verificato. Ho notato che il cammino critico appunto parte dal registro Data_reg e termina nel registro Accum_reg. Modello di timing per il vincolo sul tempo di hold Ho quindi controllato il vincolo sul tempo di hold, digitando il comando report_timing early. Come ho mostrato di seguito il vincolo sul tempo di hold è stato correttamente rispettato e non ho avuto bisogno di utilizzare celle con dispositivi più piccoli (e quindi più lente) oppure introdurre dei buffer fittizi che aumentano il ritardo minimo del sistema. I comandi utilizzati sono: do_fix_hold resize e do_fix_hold buffer. Effetto delle non-idealità del clock Da ricordare che la presenza di non idealità del segnale di clock (jitter, skew) può introdurre notevoli problemi di sincronizzazione. In fase di sintesi, posso portare in conto questi fenomeni definendo l incertezza relativa ai fronti del clock. A tale scopo, ho modificato il file constraints.tcl nel seguente modo. Stefano Guerra Pagina 28

28 Effettuo nuovamente la sintesi e la timing analysis. In che modo l incertezza sui fronti del clock influenza l analisi dei ritardi? Come si può notare inserendo un incertezza di soli 100ps lo slack si attesta a zero nel modello di timing per il vincolo sul tempo di setup, mentre scende di ben 140ps (0,14ns) nel modello di timing per il vincolo sul tempo di hold. Avendo completato la sintesi del datapath, ho ora salvato tutti i risultati ottenuti, per poter effettuare analisi successive. A tal fine ho inserito come ultimo comando del file flow.tcl il richiamo ad un altro script: source script/write_output.tcl Tale script serve per preparare i file necessari per la successiva fase di place&route del circuito. Lo script inoltre crea due file nella cartella sim: il file circuit.vhd che rappresenta una netlist vhdl del circuito sintetizzato ed un file circuit.sdf che contiene le informazioni necessarie per annotare i ritardi del circuito sintetizzato. Ho creato dunque la sottocartella denominata sim ed ho eseguito, quindi il file flow.tcl. Stefano Guerra Pagina 29

29 Simulazione post-layout con annotazione dei ritardi Trovare nel file circuit.sdf la stinga NOR2_X1: Le righe IOPATH riportano i ritardi (tempi di salita e tempi di discesa) per i due archi temporali: ingresso A1 => uscita ZN ed A2 => uscita ZN. Si hanno due valori per ognuno dei tempi, che corrispondono ai due casi fast e slow per i quali è stata richiesta la valutazione dei ritardi; il caso typical non è stato considerato. Altre istanze della medesima cella sono riportati di seguito. Ora effettuo la simulazione con l annotazione dei ritardi tramite "nclaunch". Nella directory è presente un file denominato: "NangateOpenCellLibrary_typical_conditional_mod.v". Tale file contiene la descrizione delle celle standard. Compilo il tutto anche il file sdf. Nella finestra che si attiva scrivere il nome del file sdf da compilare, ovvero circuit.sfd che generato il compilatore chiamando il file in uscita circuit.sdf.x. Ho generato ora lo snapshot eseguibile richiamando uno script e digitando il seguente comando nella finestra di "nclaunch" input link.cmd. Posso verificare che la fase di annotazione sia esente da errori. Ho effettuato la simulazione del circuito. Oltre ai port del datapath, ho individuato i segnali che rappresentano l uscita della ALU e ho visualizzato l andamento. Ho annotato i ritardi e controllato i risultati ottenuti con quelli previsti in fase di sintesi. Stefano Guerra Pagina 30

30 Placement and Routing del datapath Nelle precedenti esercitazioni il datapath di pico è stato sintetizzato in una netlist contenente una descrizione strutturale del circuito. Per completare il progetto bisogna piazzare le celle che compongono la netlist del circuito sul silicio e collegarle tra di loro (fasi di placement and Routing, P&R). Il tool che utilizzerò a questo scopo è SoC Encounter della Cadence. Le celle standard (in colore celeste chiaro) sono organizzate su righe tutte della stessa altezza. Le linee orizzontali in blu più scuro rappresentano linee di metal 1 (il livello più basso di metallo disponibile nella tecnologia che utilizzeremo). Esse sono utilizzate per portare i segnali di alimentazione e massa (VDD e GND) a tutte le celle. Inoltre due strisce verticali rosse, in metal 2, sono utilizzate per alimentare le celle a partire dal centro delle righe. Le stripes si collegano a tutte le linee di alimentazione orizzontali assicurando il collegamento tra tutte le linee di VDD e tutte le linee di GND. Sul perimetro del circuito vengono piazzati i pin di ingresso e di uscita. Inoltre un piccolo spazio di margine è lasciato tra la zona in cui sono piazzate le celle ed il perimetro del circuito. Per consentire un agevole collegamento delle linee di alimentazione, sia le stripes che le linee orizzontali di alimentazione sono portate sul perimetro del circuito. I puntini in celeste rappresentano i pin delle singole celle, che vanno collegati tra di loro. Si noti come, anche per un circuito piccolo come quello mostrato in figura, il routing prevede il collegamento di moltissimi pin e non è praticamente realizzabile senza l ausilio di un software per il CAD. Oltre al piazzamento delle celle su silicio ed al loro collegamento, la fase di P&R di un circuito integrato permette di effettuare due operazioni fondamentali: la realizzazione dell albero del clock (che consente di inviare il segnale di clock a tutti i registri con uno skew controllato) e l ottimizzazione del circuito tenendo in conto gli effetti parassiti dovuti ai collegamenti tra le celle (in-place optimization). Durante l ottimizzazione, le celle del path critico possono essere sostituite con altre che implementano la stessa funzione ma sono realizzate con transistor più grandi. Inoltre durante la fase di ottimizzazione è possibile bufferizzare celle aventi un elevato fanout con l ausilio di invertitori e buffer. Le fasi che seguirò per realizzare il P&R del circuito sono schematizzate nella figura seguente. Stefano Guerra Pagina 31

31 Configurazione Per effettuare il P&R ho bisogno dei due file prodotti in fase di sintesi: la netlist verilog del circuito (final_synt.v) ed il file dei constraints (synthesized_const.sdc). Quest ultimo file contiene gli stessi constraints adoperati in fase di sintesi, riscritto in una sintassi utilizzabile dal programma di P&R. Copiato questi due file nella sottocartella denominata synt. Sono necessarie ulteriori informazioni per inizializzare il progetto. È infatti opportuno definire dove posizionare i pin di ingresso/uscita lungo la periferia del blocco. La posizione dei pin del mio circuito è definita nel file denominato pin_locations.io. Ritrovo in questo file alcuni terminali del datapath (il clock, il reset, il bus C di ingresso ecc.). La lettera dopo il nome del pin rappresenta il lato del layout in cui il pin verrà posizionato (N sta per Nord, W per ovest ecc.); il numero successivo rappresenta il metal utilizzato per il pin (4 indica che il pin sarà accessibile in metal-4 ecc.). Stefano Guerra Pagina 32

32 Il bus DataOut sarà disponibile sul lato sud del circuito mentre il bus DataIn in parte sul lato est ed in parte sul lato ovest; tutti gli altri segnali saranno accessibili sul lato nord. Completare il file aggiungendo i terminali mancanti. Utilizzo il metal-4 per i terminali sui lati North e South ed il metal-3 per i terminali sui lati East e West. Posso ora attivare SoC Encounter con il comando: Agendo sui menù è possibile effettuare interattivamente le varie fasi necessarie del processo di P&R. Come già accennato, la prima operazione da effettuare è caricare la netlist sintetizzata in precedenza, con i constraints, le informazioni di timing relative alle celle standard e la posizione dei pin. Bisogna inoltre fornire al programma di place&route il layout delle celle standard. In effetti, in questa fase è sufficiente disporre di una versione semplificata del layout, il cosiddetto formato LEF. L acronimo LEF sta per Library Exchange Format ed il file LEF rappresenta una descrizione ridotta del layout delle celle standard, in cui viene riportato solamente il posizionamento dei metalli all interno di ciascuna cella standard. La descrizione LEF delle celle contiene tutto ciò che serve al router per collegare fra di loro i terminali delle celle. Ora posso lanciare il primo script da eseguire. Tale scripts è scripts/config.cmd. Questo script si limita a fissare il nome del progetto, il nome dei terminali di alimentazione e gli identificativi che permettono al tool di riconoscere i buffer e gli invertitori all interno della libreria. Queste celle sono gestite in maniera particolare dal tool per realizzare l albero di clock e per bufferizzare i segnali con un elevato fanout. Lo script esegue inoltre una preliminare analisi dei ritardi del circuito; i risultati della timing analysis vengono salvati in una cartella denominata tim_preplace. Infine, il progetto viene salvato nel file loaded.enc. Il primo script da eseguire è: encounter source scripts/config.cmd nel terminale di encounter può essere visualizzato il risultato della timing analysis ed annotate gli slack che ho ottenuto. I risultati dettagliati della analisi sono disponibili nella cartella tim_preplace. Posizionato in questa Stefano Guerra Pagina 33

33 cartella. Il file che termina con.summary riporta un sunto degli slack. I files che terminano con.tarpt riportano un analisi dettagliata dei percorsi critici del circuito. Infine i file si dividono tra: quelli che analizzano i ritardi sulla logica di input (in2reg); quelli che analizzano i ritardi tra registri interni al circuito (reg2reg); quelli che analizzano i ritardi sulla logica di output del circuito (reg2out); quelli che analizzano i ritardi sulla logica che unisce gli ingressi alle uscite (in2out). Si può notare in questa fase che lo slack ottenuto è migliore rispetto a quanto previsto in fase di sintesi; il programma di P&R infatti non adotta alcun wireload model ed, al momento, non include nessuna stima per il ritardo delle interconnessioni. Stefano Guerra Pagina 34

34 Floorplan Il prossimo passo da eseguire consiste nel fissare la pianta (in inglese floorplan) del circuito che voglio realizzare. Nella determinazione del floorplan si decide la forma che deve avere il circuito, le dimensioni geometriche complessive, il posizionamento delle linee di alimentazione. Con i valori indicati istruisco encounter a realizzo un floorplan dimensionato opportunamente rispetto all occupazione d area delle celle che compongono il progetto. In particolare dico ad encounter di voler realizzare un floorplan rettangolare (ratio Height/Width=0.7) di cui le celle standard occupino il 60% dello spazio (campo core utilization). Inoltre prevedo di lasciare lateralmente al core del circuito uno spazio vuoto delle dimensioni di In generale utilizzo le altre opzioni, avrò potuto scegliere di fornire al tool i valori assoluti di larghezza ed altezza del floorplan invece di calcolare tali valori in funzione dell area occupata dalle celle standard. Notate, infine, che decido di non lasciare alcuno spazio fra una riga di celle e la successiva. Il 40% di spazio in più sarà utilizzato in fase di ottimizzazione o riempito da encounter con celle fittizie (filler); lo spazio sopra le celle (incluse le celle filler) verrà utilizzato per il routing. Passo ora alla definizione delle linee di alimentazione. In questo modo definisco delle strisce verticali di metal2 per le alimentazioni. Le linee di alimentazione e massa avranno ampiezza 0.8um e saranno distanti fra loro di 0.8um. Utilizzo tre coppie di linee; le due più esterne saranno piazzate a 5um dai bordi est ed ovest del blocco. Stefano Guerra Pagina 35

35 Placement Una volta realizzato il floorplan è possibile passare alla fase di placement. Lo script contenente i comandi per questa fase si trova nella cartella scripts, nel file scripts/place.cmd. Lo script, oltre ad effettuare il placing, controlla la presenza di errori e riporta il risultato del controllo nel file datapath.checkplace. Inoltre esegue una nuova analisi dei ritardi del circuito, i cui risultati sono salvati nella cartella tim_prects. Eseguo lo script. Al termine dell esecuzione, oltre a piazzare le celle, il tool realizza delle connessioni. Tali connessioni sono in realtà fittizie: il tool di placing effettua quello che viene detto un trial route (un collegamento di tentativo) che serve esclusivamente per stimare le capacità delle interconnessioni. Stefano Guerra Pagina 36

36 In-place Optimization L ottimizzazione del circuito viene realizzata con lo script scripts/ipo.cmd. Si richiede al tool di ottimizzare il circuito in modo da ottenere uno slack di 100ps su tutti i cammini (parametro targetslack). Lo script, inoltre, esegue una nuova analisi dei ritardi del circuito. Stefano Guerra Pagina 37

37 Dopo aver eseguito lo script ho effettuato un controllo sull occupazione di area del circuito per verificare di quanto è aumentata. Analisi dei ritardi del circuito ottenuti nelle varie fasi del progetto. I file con i risultati si trovano nelle cartelle tim_preplace, tim_prects (dopo il placing ma prima dell ottimizzazione) e tim_prects_opt (dopo l ottimizzazione). In ciascuna di queste cartelle analizzo i file _all.tarpt che riporta l analisi dettagliata di tutti i percorsi critici del circuito. Annoto il path critico nei diversi casi e verifico l effetto dell ottimizzazione sul path critico. In particolare è molto importante l analisi dei percorsi reg2reg. In caso di violazioni sui percorsi di input e di output, infatti, è possibile agire sui circuiti che sono a monte o a valle del datapath per risolvere il problema. Nel caso, invece, di violazioni su percorsi reg2reg i vincoli di progetto non potranno essere rispettati. Stefano Guerra Pagina 38

38 Albero di clock Microprocessore a 16 bit in tecnologia CMOS 45nm Il prossimo passo è la realizzazione dell albero di clock. Per effettuare questa operazione mi servirò dello script cts.cmd e del file di configurazione clock.cts. Quest ultimo file viene caricato in fase di sintesi dell albero di clock e contiene i constraints riguardanti la sua realizzazione. In particolare riporta: 1. il nome del pin di clock; 2. il valore massimo e minimo del ritardo sull albero di clock; 3. il valore massimo di skew accettabile; 4. il tempo di transizione massimo consentito sui segnali di clock; 5. il nome delle celle da utilizzare come buffer per la realizzazione dell albero; 6. la cella che si ipotizza pilotare l albero e che determina la driving strength della logica a monte dell albero di clock. Lo script cts.cmd esegue la sintesi dell albero del clock, l analisi dei ritardi del cricuito e salva due file di report: un file verilog con la netlist completa anche dei buffer dell albero di clock, ed una serie di files di report. Eseguo lo script ed apro il file html di report con il web browser. Come posso notare, poiché il circuito Datapath include pochi flip-flop, l albero di clock consente di ottenere uno skew limitatissimo. Inoltre, nella cartella tim_postcts trovo i file con l analisi dei ritardi del circuito. Ho analizzato l effetto che la sintesi dell albero di clock ha avuto sulle prestazioni del circuito. Verrà evidenziato l albero di clock, con diversi colori per i registri, a seconda dello skew. Stefano Guerra Pagina 39

39 Routing Eseguo a questo punto il routing finale del circuito con lo script scripts/route.cmd. Invece di eseguire questo script con il comando source utilizzo la funzione di copia/incolla di linux per dare ad encounter i comandi contenuti nello script uno per volta. Il primo comando serve per aggiungere al layout le celle filler. Queste particolari celle contengono solo le due linee di alimentazione e non contengono transistors. Sono però necessarie a riempire gli spazi vuoti del core assicurando quindi il collegamento delle linee orizzontali in metal 1 che collegano i segnali VDD e GND delle celle. Il secondo comando (sroute) serve per collegare tutte le net di VDD e GND orizzontali e per prolungarle fino al bordo della cella. Il comando source scripts/nanoroute.cmd richiama un altro script contenente le opzioni ed il comando vero e proprio di routing. Eseguo il comando; sono sufficienti alcuni secondi a completare il routing. Il programma riporta la lunghezza complessiva delle interconnessioni per i vari livelli di metal disponibili e le vie di collegamento necessarie. Controllare quali sono i livelli di metal più utilizzati. Stefano Guerra Pagina 40

40 Eseguo, infine, l ultimo comando contenuto nello script route.cmd per salvare il progetto. Controllo Stefano Guerra Pagina 41

41 A questo punto posso analizzare il circuito e verificare che esso rispetti le regole di processo (connettività e dimensioni) posso controllare che il circuito rispetti le regole di processo. Salvataggio finale L ultimo script che eseguo è contenuto nel file outputs.cmd. All interno di questo script vengono effettuate varie operazioni. Innanzitutto viene effettuata una finale analisi dei ritardi del circuito i cui risultati vengono salvati nella cartella tim_final. Viene poi creato il file final.ctsrpt con l analisi dell albero del clock. Vengono inoltre generati diversi file contenenti descrizioni alternative del layout del datapath. Tra queste c è la descrizione di tipo LEF (che permette di utilizzare il circuito realizzato all interno di un circuito più grande come se fosse una cella standard o, più precisamente, una macro), la descrizione liberty e la descrizione gds. Quest ultimo formato è molto importante poiché contiene tutti i layer del layout ed è il formato principale di rappresentazione dei layout dei circuiti integrati. Stefano Guerra Pagina 42

42 La parte finale dello script analizza con approccio statistico la dissipazione di potenza del circuito. L interfaccia grafica di encounter colorerà diversamente le celle del layout per mettere in evidenza le celle che dissipano più potenza. Stefano Guerra Pagina 43

43 Provo poi ad aumentare la percentuale di occupazione al fine di minimizzare l area complessiva del circuito. Per fare questo dovo ricaricare lo stato del progetto contenuto nel file loaded.enc. Dove poi modificare la percentuale di occupazione nel comando floorplan contenuto nel file floorplanning.cmd e rieseguire tutti gli script fino all ultimo. Per aiutarmi a ricordare la giusta sequenza con cui eseguire gli script potete mi sono aiutato con il file flow.cmd, che contiene la lista completa di tutti gli script utilizzati. Con l aiuto degli script, effettuo nuovamente la fase di place&route, aumentando la percentuale di occupazione del circuito. Riempito così le altre righe della tabella. Provo, inoltre, ad inserire un valore di percentuale di occupazione ancora maggiore ed ho notato che per 0.80 si ottiene uno spacing violation, in pratica il tool Encounter non riesce a piazzare tutti gli elementi del circuito (dato che il 20% è rappresentato dai terminali di I/O). Dopo aver rieseguito nuovamente il place&route con 0.75 di percentuale di occupazione, attraverso l apposito menù di encounter (Display => Physical view => Min/Max paths, dopo aver attivato nuovamente il clock tree browser) ho evidenziato i due registri per i quali il ritardo sul clock assume il valore minimo e massimo. Prendo quindi nota della posizione fisica del morsetto di clock di questi due registri: questa informazione mi verrà utile in seguito quando effettuo una simulazione circuitale della distribuzione del clock, al fine di controllare il valore dello skew. Stefano Guerra Pagina 44

44 Primo Registro Secondo Registro X Y Simulazione a livello transistor Nelle esercitazioni precedenti ho visto come simulare circuiti descritti con linguaggi HDL e come stimare le loro prestazioni sulla base di una caratterizzazione di alto livello come quella del formato liberty o del formato SDF. Per avere una stima più precisa dei ritardi di un circuito e della sua dissipazione di potenza è buona norma effettuare una simulazione più accurata possibile, che modelli il funzionamento dei singoli transistor. Nel caso particolare dei circuiti VLSI la fase di simulazione deve, da un lato, garantire una stima delle prestazioni del circuito sufficientemente accurata, dall altro deve permettere la simulazione di circuiti molto grandi (composti da decine di migliaia di transistors) in tempi ragionevoli. Per garantire l accuratezza della simulazione utilizzeremo per i MOSFET una caratterizzazione basata su modello BSIM versione 4. L acronimo BSIM sta per Berkeley Short-channel IGFET (insulated gate FET) Model. Tale modello è stato sviluppato al fine di avere un modello compatto che permetta di portare in conto tutti i fenomeni presenti nei MOSFET con gate submicrometrica. I file contenenti i modelli BSIM dei transistor che utilizzo si trovano nella cartella $HOME/NCSU-FreePDK45-1.3/FreePDK45/ncsu_basekit/models/hspice/tran_models/ All interno trovo tre sottocartelle contenenti i modelli dei transistors per il caso nominale, il caso fast ed il caso slow. Accedo alla cartella models_nom ed edito con nedit il file NMOS_VTL.inc. Questo file contiene il modello BSIM del MOSFET a canale n. Come posso notare, il modello BSIM utilizza un numero molto elevato di parametri. Nella tabella che segue sono riportati i parametri fondamentali del MOSFET a canale n che Stefano Guerra Pagina 45