[Raven 11]

7 hours ago, Leka said:

 Ни разу не сталкивался со случаем разного синтеза always_comb и always@*.

Вот что говорит об этом Сазерленд в "SystemVerilog for Design" (6.2.1, part "always_comb versus always @*"), основные мысли:

1. always @* does not have combinational logic semantics - и из-за этого много чего может отличаться между результатами симуляции и синтеза
 

Quote

 

The inferred sensitivity list of Verilog’s @* is a convenient shortcut, and can simplify modeling complex procedural blocks with combinational logic. However, the @* construct does not require that the
contents of the general-purpose always procedural block adhere to synthesizable combinational logic modeling guidelines.

The specialized always_comb procedural block not only infers the combinational logic sensitivity list, but also restricts other procedural blocks from writing to the same variables so as to help ensure
true combinatorial behavior. In addition, always_comb executes automatically at time zero, to ensure output values are consistent
with input values, whereas the @* sensitivity list will only trigger if at least one of the inferred signals in the list changes.

 

 

2. @* might infer an incomplete sensitivity list - возможен неполный список чувствительности со всеми вытекающими последствиями (неожиданные latches, отличия между симуляцией и синтезом, а может и вовсе не собраться дизайн):

Quote

The Verilog @* might not infer a complete sensitivity its when functions are used to structure large blocks of combinational logic. The sensitivity list inferred by always @* only looks at the signals read
directly by the always procedural block. It does not infer sensitivity to the signals read from within any functions called by the procedural block.

Quote

The following example illustrates the difference in sensitivity lists
inferred by @* and always_comb. In this example, the procedural
block using @* will only be sensitive to changes on data. The
always_comb procedure will be sensitive to changes on data,
sel, c, d and e

 

function decode; // function with no inputs
begin
  case (sel)
    2'b01: decode = d | e;
    2'b10: decode = d & e;
    default: decode = c;
  endcase
end
endfunction

The following infers only @(data):

always @* begin
  a1 = data << 1;
  b1 = decode();
  ...
end

The below infers @(data, sel, c, d, e):

always_comb begin
  a2 = data << 1;
  b2 = decode();
  ...
end

 

[Мур 1]

11 hours ago, RobFPGA said:

Потому что правильность реализации функционала в FPGA это не тоже самое что и правильность  функционирования всей системы.  Понятное дело это связанные вещи но если прощелкал системщик,  выдав неправильное ТЗ программисту или FPGAшнику, или программист накосячил и не  проверил свою работу, то корректный и полный сим может показать и доказать это. А просто дебаг глюков софта через FPGA к верификации работы FPGAшника отношения не имеет. Это как раз и есть этап  системной интеграции.  Который по большому счету должен делается уже на проверенной прошивке.  

Вы безусловно правы!  Это классика...

Моя вина в том, что не приучил начальство следовать протоколу разработки.  В 80% случаев на исходе реализации начинаются просьбы добавить то, поменять это...  Хорошо бы эдак...

Да начальство на самом деле не в курсе проблем с системой! Просьбы идут от коллег. Таких же как и я...  Что я не способен подвинуться?...   Вот так оно в реале!

А об этом я могу только мечтать...

 

[dxp 56]

21 час назад, RobFPGA сказал:

У меня другая статистика. Уже был ряд проектов (и не маленьких) в которых отладка проекта в железе не понадобилась вообще.

+1. При правильном подходе (адекватных моделях и грамотном описании) отладка в железе может понадобиться в основном потому, что на симе не удаётся сымитировать все кейсы, которые реально имеют место быть.

[dxp 56]

8 часов назад, Raven сказал:

1. always @* does not have combinational logic semantics - и из-за этого много чего может отличаться между результатами симуляции и синтеза

Опередили: тоже хотел пример с функцией в always @* привести. 

Ещё одно важное отличие: в начальный момент (момент времени 0) always_comb всегда делает единоразовый прогон, хотя его переменные ещё не триггернулись - это соответствует поведению аппаратной логики. always @* будет ждать триггера. Если, например, есть два блока, которые влияют на триггеринг друг друга, то они будут стоят и ждать, кто первый пнёт. Это тоже не соответствует поведению логики на синтезе.

Ну, и третье заметное отличие в том, что в always @* допускается писать в переменную из разных блоков, а в always_comb нет. Конечно, на синтезе эта ошибка проявится, но лучше, когда это ловится раньше. Поэтому синтезируемый код, предназначенный для описания комбинационной логики, однозначно целесообразнее писать с использованием always_comb. Его именно для этого и ввели в язык.

[_4afc_ 25]

1 hour ago, dxp said:

Опередили: тоже хотел пример с функцией в always @* привести. 

Ещё одно важное отличие: в начальный момент (момент времени 0) always_comb всегда делает единоразовый прогон, хотя его переменные ещё не триггернулись - это соответствует поведению аппаратной логики. always @* будет ждать триггера. Если, например, есть два блока, которые влияют на триггеринг друг друга, то они будут стоят и ждать, кто первый пнёт. Это тоже не соответствует поведению логики на синтезе.

Ну, и третье заметное отличие в том, что в always @* допускается писать в переменную из разных блоков, а в always_comb нет. Конечно, на синтезе эта ошибка проявится, но лучше, когда это ловится раньше. Поэтому синтезируемый код, предназначенный для описания комбинационной логики, однозначно целесообразнее писать с использованием always_comb. Его именно для этого и ввели в язык.

А зачем так писать вообще? Это стиль SV?

 

Если логика без клока - пишем: assign a=b^c;

Если триггер - пишем: always (posedge clk) a<=b^c;

 

зачем эти чудеса типа always @* и  always_comb?

 

[andrew_b 16]

5 часов назад, _4afc_ сказал:

зачем эти чудеса типа always @* и  always_comb?

Cложную логику проще и понятнее описать через if/then, чем через ?:. А if/then можно только в always.

[RobFPGA 30]

3 hours ago, _4afc_ said:

зачем эти чудеса типа always @* и  always_comb?

Как выше заметили в always_*  можно использовать все  многообразие операторов, не только if,  а и for,  case*  локальные временные переменные  для промежуточных расчетов, .... Что очень удобно и упрощает написание и чтение кода.    

 

[des00 25]

On 1/5/2022 at 7:16 PM, RobFPGA said:

Уже был ряд проектов (и не маленьких) в которых отладка проекта в железе не понадобилась вообще. Ну и на это заявление с ужасом и слезами смотрят все разработчики ASIC     

Подтверждаю. При более менее полном плане верификации, покрывающем не только корректные режимы работы IP но и не корректные, аппаратная отладка может вообще не понадобиться. Но умение разрабатывать верификационное окружение не всякому дается и порой требует усилий больше чем разработка RTL кода) 

При этом это не всегда UVM и им подобные системы, те же ЦОС системы хорошо отлаживаются в режиме Co-Simulation.

ЗЫ. А по сути темы присваиваний, в свое время прочел от корки до корки стандарты VHDL-93, Verilog-2001, SystemVerilog 3.1a. После этого вопросов о том, почему тот или иной код так работает, никогда не возникало)  

19 hours ago, dxp said:

Ну, и третье заметное отличие в том, что в always @* допускается писать в переменную из разных блоков, а в always_comb нет.

Есть тут правда неудобство, причем зависящее от разных ПО. Если переменная это упакованная структура и есть часть константных полей, а часть регистровых, то софт ругается по формальным признакам. Хотя с точки зрения аппаратуры все нормально)