résultats et calcul MUX ou non

Question

En utilisant du code pseudo ici. Y at-il des avantages et des inconvénients à ces styles:

Disons que vous avez un alu qui peut faire ajouter, ou et XOR. Est-il préférable d'avoir un code qui calcule les réponses possibles tout le temps puis sélectionnez la réponse en fonction de l'opcode (dans ce cas, un chaud):

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;

Une alternative serait de coder comme ceci:

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;

Je l'ai vu aussi comme:

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 );

Y at-il des avantages et des inconvénients de ces deux méthodes ou ils sortent de la même à la fin?

Answer 1

Pensez à cela en termes de niveaux de la logique et la lisibilité. Les deux premières formes sont très bien en termes de lisibilité, mais les deux incarnent inutilement priorité et donneront lieu à plusieurs niveaux de logique. La troisième forme est pas non plus si merveilleux par l'une de ces mesures. Enfin, il n'y a aucune raison apparente d'utiliser le codage d'un chaud ici au codage binaire. Voici comment je coder ceci:

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

// et plus tard, dans votre bloc toujours:

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

Ici, j'ai explicitement les valeurs attribuées aux opcodes ALU, en évitant des « nombres magiques » et le rendre plus facile pour les autres de comprendre ce qui se passe. Je l'ai aussi utilisé la déclaration de cas et appliqué une directive qui indique mon outil de synthèse pas plus d'une expression peut être adaptée, donc pas codeur de priorité ne pourra être déduite. Je n'ai pas nommé les signaux intermédiaires (alu_add etc.) parce que ce sont des opérations futiles, mais je souvent quand je veux un accès facile à ces signaux (voir leurs valeurs après la simulation dans une visionneuse de forme d'onde par exemple).

Vous pouvez en savoir plus sur l'utilisation de déclarations de cas efficacement dans cet article de la excellente site de conception de rayon de soleil (pas d'affiliation, juste un ancien étudiant).

Enfin, au sujet de votre question: « Est-il préférable d'avoir un code qui calcule les réponses possibles tout le temps puis sélectionnez la réponse en fonction de la opcode » - rappelez-vous que Verilog est un langage de description du matériel. Toutes les mises en œuvre sur cette page sont tout calculent tout le temps de toute façon. Elles diffèrent des niveaux de la logique et la lisibilité. Jetez un oeil à cette page , ce qui montre que ma mise en œuvre a 1 niveau de la logique au-delà des opérations elles-mêmes, où la mise en œuvre if-else a 3 niveaux supplémentaires de la logique.

Answer 2

Les deux premières donnera la même logique, mais vous obtiendrez un verrou sur alu_out parce que votre bloc if else (votre codeur de priorité) n'a pas else final. (Cela est vrai pour Verilog de toute façon). Si votre timing est serré, vous pouvez avoir des problèmes avec les longs chemins qu'un codeur de priorité implique.

Sur la 3ème version, vous obtiendrez une structure plus « parallèle » qui peut être mieux pour le moment. Il ne se verrouillera pas.

Dans les trois versions, chacune des quatre opérations seront claquements loin nomatter ce que l'opcode. Cela aura des conséquences de puissance.

Il est de mon avis que la première version gagne pour plus de clarté, et vous pouvez obtenir à chacune des opérations distinctes dans votre lecteur de forme d'onde lors du débogage. Il ne sert à coder en place quelque chose qui n'est pas aussi facile à lire, sauf si le calendrier, la zone ou les contraintes électriques souffrent.