risultati di calcolo e mux o no

Question

Utilizzando pseudo codice qui. Ci sono pro e contro di questi stili:

Diciamo che avete un'ALU che può fare aggiungere, AND, OR e XOR. E 'meglio avere il codice che calcola le possibili risposte per tutto il tempo, quindi selezionare la risposta in base al codice operativo (in questo caso un caldo):

alu_add = a + b;
alu_and = a & b;
alu_or  = a | b;
alu_xor = a ^ b;

...

if(opcode[0])      alu_out = alu_add;
else if(opcode[1]) alu_out = alu_and;
else if(opcode[2]) alu_out = alu_or;
else if(opcode[3]) alu_out = alu_xor;

Un'alternativa sarebbe quella di codice in questo modo:

if(opcode[0])      alu_out = a + b;
else if(opcode[1]) alu_out = a & b;
else if(opcode[2]) alu_out = a | b;
else if(opcode[3]) alu_out = a ^ b;

Ho visto anche come:

alu_add = a + b;
alu_and = a & b;
alu_or  = a | b;
alu_xor = a ^ b;

...

alu_out = 
  ( 8{opcode[0]} & alu_add ) |
  ( 8{opcode[1]} & alu_and ) | 
  ( 8{opcode[2]} & alu_or ) |
  ( 8{opcode[3]} & alu_xor );

Ci sono pro e contro per entrambi i metodi o se invece vengono fuori circa lo stesso alla fine?

Answer 1

Pensate a questo in termini di livelli di logica e leggibilità. Le prime due forme sono soddisfacenti in termini di leggibilità, ma entrambi incorporano priorità inutilmente e provocheranno più livelli logici. La terza forma inoltre, non è così meraviglioso da uno di questi parametri. Infine, non c'è alcun motivo apparente per usare la codifica di un caldo qui sopra codifica binaria. Ecco come mi piacerebbe codice L':

parameter ALU_ADD = 2'b00;
parameter ALU_AND = 2'b01;
parameter ALU_OR  = 2'b10;
parameter ALU_XOR = 2'b11;

reg [1:0]  opcode;  // 2 bits for binary coding vs. 4 for one-hot

// e più tardi, nel vostro sempre blocco:

case (opcode)  // synopsys parallel_case
    ALU_ADD: alu_out = a + b;
    ALU_AND: alu_out = a & b;
    ALU_OR:  alu_out = a | b;
    ALU_XOR: alu_out = a ^ b;
endcase

Qui ho esplicitamente assegnati valori ai codici operativi ALU, evitando "numeri magici" e rendendo più facile per gli altri a capire cosa sta succedendo. Ho anche usato l'istruzione case e applicato una direttiva che racconta il mio strumento di sintesi che non più di un'espressione può essere abbinato, in modo che nessun codificatore di priorità verrà dedotto. Io non nomino i segnali intermedi (alu_add etc.) perché queste sono operazioni banali, ma io spesso faccio quando voglio un comodo accesso a quei segnali (vedendo i loro valori dopo la simulazione in un visualizzatore di forme d'onda, per esempio).

È possibile ulteriori informazioni sull'utilizzo dichiarazioni caso efficacemente in questo articolo dal eccellente Sunburst design sito (nessuna affiliazione, solo un ex studente).

Infine, circa la vostra domanda, "E 'meglio avere il codice che calcola le possibili risposte per tutto il tempo, quindi selezionare la risposta in base al codice operativo" - ricordate che Verilog è un linguaggio di descrizione hardware. Tutte le implementazioni di questa pagina sono Computing tutto tutto il tempo comunque. Esse differiscono in livelli di logica e leggibilità. Date un'occhiata a questa pagina , il che dimostra che la mia applicazione ha 1 livello logico oltre le operazioni stesse, in cui l'attuazione if-else ha 3 livelli aggiuntivi di logica.

Answer 2

I primi due vi darà la stessa logica, ma si otterrà un fermo sul alu_out perché il blocco if else (il codificatore di priorità) non ha else finale. (Questo è vero per Verilog comunque). Se i tempi sono stretti, si possono avere problemi con i lunghi sentieri che un codificatore di priorità implica.

Il 3 versione, si otterrà una struttura piu 'parallelo', che può essere meglio per la temporizzazione. Non sarà fermo.

In tutte e tre le versioni, ciascuna delle quattro operazioni saranno rumorosamente via nomatter ciò che il codice operativo. Ciò avrà implicazioni di potenza.

E 'mia opinione che la prima versione vince per chiarezza, e si può ottenere in ciascuna delle operazioni separate nel visualizzatore di forme d'onda durante il debug. Non ha senso nella codifica qualcosa che non è così facile da leggere a meno che i tempi, area o di potere vincoli sono male.