вычислить результаты и мультиплексировать или нет

Question

Здесь используется псевдокод.Есть ли плюсы и минусы у этих стилей:

Допустим, у вас есть alu, который может выполнять сложение, и, или и xor.Лучше ли иметь код, который постоянно вычисляет возможные ответы, а затем выбирать ответ на основе кода операции (в данном случае один горячий):

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;

Альтернативой может быть такой код:

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;

Я также видел это как:

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

Есть ли плюсы и минусы у того или иного метода или в конечном итоге они получаются примерно одинаковыми?

Answer 1

Подумайте об этом с точки зрения уровня логики и читабельности.Первые две формы хороши с точки зрения читабельности, но обе неоправданно воплощают приоритет и приводят к большему количеству уровней логики.Третья форма также не так хороша ни по одному из этих показателей.Наконец, нет очевидной причины использовать здесь горячее кодирование вместо двоичного кодирования.Вот как бы я это закодировал:

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

// и позже в вашем блоке Always:

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

Здесь я явно присвоил значения кодам операций ALU, избегая «магических чисел» и облегчая другим понимание того, что происходит.Я также использовал оператор case и применил директиву, которая сообщает моему инструменту синтеза, что не может быть сопоставлено более одного выражения, поэтому ни один кодировщик приоритета не будет выведен.Я не назвал промежуточные сигналы (alu_add и т. д.), потому что это тривиальные операции, но я часто делаю это, когда мне нужен удобный доступ к этим сигналам (например, просмотр их значений после моделирования в программе просмотра сигналов).

Вы можете узнать больше об эффективном использовании операторов Case в Эта статья из отличного Дизайн Санберст сайт (никакой принадлежности, просто бывший студент).

Наконец, что касается вашего вопроса: «Лучше ли иметь код, который все время вычисляет возможные ответы, а затем выбирает ответ на основе кода операции» — помните, что Verilog — это язык описания оборудования.В любом случае все реализации на этой странице все время все вычисляют.Они различаются уровнем логики и читабельности.Взгляни на эта страница, который показывает, что моя реализация имеет 1 уровень логики помимо самих операций, тогда как реализация if-else имеет 3 дополнительных уровня логики.

Answer 2

Первые два будут иметь ту же логику, но вы получите защелку. alu_out потому что твой if else блок (ваш приоритетный кодер) не имеет финального else.(В любом случае это верно для Verilog).Если у вас сжатые сроки, у вас могут возникнуть проблемы с длинными путями, которые предполагает приоритетный кодер.

В третьей версии вы получите более «параллельную» структуру, которая может быть лучше с точки зрения синхронизации.Он не защелкнется.

Во всех трех версиях каждая из четырех операций будет выполняться независимо от кода операции.Это будет иметь последствия для власти.

По моему мнению, первая версия выигрывает по ясности, и вы можете получить доступ к каждой отдельной операции в средстве просмотра сигналов при отладке.Нет смысла кодировать что-то, что не так легко прочитать, если только не мешают ограничения по времени, площади или мощности.