Rechenergebnisse und Mux oder nicht

Question

Mit Pseudo-Code hier. Gibt es Vor-und Nachteile dieser Stile:

Angenommen, Sie haben einen Alu, die Add tun können, und, oder und xor. Ist es besser, den Code zu haben, dass die möglichen Antworten die ganze Zeit berechnet dann die Antwort auswählen, basierend auf dem Opcode (in diesem Fall ein ein heiß):

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;

Eine Alternative zu Code wäre es wie folgt aus:

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;

Ich habe es auch gesehen, wie:

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

Gibt es Vor-und Nachteile der beiden Verfahren oder tun sie am Ende in etwa gleich kommen?

Answer 1

Denken Sie darüber in Bezug auf die Ebenen der Logik und Lesbarkeit. Die ersten beiden Formen sind in Ordnung in Bezug auf die Lesbarkeit, aber beide verkörpern Priorität unnötig und in mehreren Ebenen der Logik führen. Die dritte Form ist auch nicht so wunderbar durch eine dieser beiden Metriken. Schließlich gibt es keinen ersichtlichen Grund eine heiß verwenden hier über binäre Codierung Codierung. Hier ist, wie ich diesen Code würde:

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

// und später in der immer blockieren:

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

Hier habe ich explizit Werte an die ALU OP-Codes zugeordnet, „magischen Zahlen“ zu vermeiden und machen es einfacher für andere zu verstehen, was passiert. Ich habe auch den Fall, Aussage und angewendet, um eine Richtlinie verwendet, die meine Synthese-Tool sagt, dass nicht mehr als ein Ausdruck angepasst werden kann, so wird keine Prioritätscodierer abgeleitet werden. Ich habe nicht die Zwischensignale nennen (alu_add etc.), da diese triviale Operationen sind, aber ich so oft tun, wenn ich einen bequemen Zugang zu diesen Signalen wollen (sehen ihre Werte nach der Simulation in einer Wellenform-Viewer zum Beispiel).

Sie können erfahren Sie mehr über Fall mit Aussagen effektiv in diesem Artikel von der ausgezeichnete Sunburst Design Website (keine Zugehörigkeit, nur ein ehemaliger Student).

Schließlich über Ihre Frage: „Ist es besser, den Code zu haben, die die möglichen Antworten berechnet die ganze Zeit dann die auf dem Opcode basierte Antwort wählen“ - denken Sie daran, dass Verilog eine Hardware-Beschreibungssprache ist. Alle die Implementierungen auf dieser Seite sind Rechen alles ohnehin die Zeit. Wo sie unterscheiden sich in Ebenen der Logik und Lesbarkeit. Schauen Sie sich auf dieser Seite , die zeigt, dass meine Implementierung hat 1 Ebene der Logik über die Operationen selbst, wo die if-else Implementierung 3 zusätzliche Logikebene hat.

Answer 2

Die ersten beiden die gleiche Logik geben, aber Sie werden einen Riegel auf alu_out bekommen, weil Ihr if else Block (Ihre Prioritätscodierer) keine endgültige else hat. (Dies gilt für Verilog sowieso). Wenn Ihr Timing fest ist, können Sie Probleme mit den langen Pfaden haben, dass ein Prioritätscodierer impliziert.

Auf der dritten Version, werden Sie eine ‚parallele‘ Struktur erhalten, die für das Timing besser sein können. Es wird nicht Verriegelung.

In allen drei Versionen, jede der vier Operationen nomatter was werden klappern weg der Opcode. Dies wird Leistung Auswirkungen haben.

Es ist meine Meinung, dass die erste Version für Klarheit gewinnt, und Sie können an jeden der getrennten Operationen in Ihrem Wellenform-Viewer erhalten beim Debuggen. Es gibt keinen Punkt bei der Codierung auf etwas, das nicht so einfach ist, zu lesen, es sei denn Timing, Fläche oder Leistungsbeschränkungen verletzen.