Raven 11 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 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. Thealways_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 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 11 hours ago, RobFPGA said: Потому что правильность реализации функционала в FPGA это не тоже самое что и правильность функционирования всей системы. Понятное дело это связанные вещи но если прощелкал системщик, выдав неправильное ТЗ программисту или FPGAшнику, или программист накосячил и не проверил свою работу, то корректный и полный сим может показать и доказать это. А просто дебаг глюков софта через FPGA к верификации работы FPGAшника отношения не имеет. Это как раз и есть этап системной интеграции. Который по большому счету должен делается уже на проверенной прошивке. Вы безусловно правы! Это классика... Моя вина в том, что не приучил начальство следовать протоколу разработки. В 80% случаев на исходе реализации начинаются просьбы добавить то, поменять это... Хорошо бы эдак... Да начальство на самом деле не в курсе проблем с системой! Просьбы идут от коллег. Таких же как и я... Что я не способен подвинуться?... Вот так оно в реале! А об этом я могу только мечтать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 21 час назад, RobFPGA сказал: У меня другая статистика. Уже был ряд проектов (и не маленьких) в которых отладка проекта в железе не понадобилась вообще. +1. При правильном подходе (адекватных моделях и грамотном описании) отладка в железе может понадобиться в основном потому, что на симе не удаётся сымитировать все кейсы, которые реально имеют место быть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 8 часов назад, Raven сказал: 1. always @* does not have combinational logic semantics - и из-за этого много чего может отличаться между результатами симуляции и синтеза Опередили: тоже хотел пример с функцией в always @* привести. Ещё одно важное отличие: в начальный момент (момент времени 0) always_comb всегда делает единоразовый прогон, хотя его переменные ещё не триггернулись - это соответствует поведению аппаратной логики. always @* будет ждать триггера. Если, например, есть два блока, которые влияют на триггеринг друг друга, то они будут стоят и ждать, кто первый пнёт. Это тоже не соответствует поведению логики на синтезе. Ну, и третье заметное отличие в том, что в always @* допускается писать в переменную из разных блоков, а в always_comb нет. Конечно, на синтезе эта ошибка проявится, но лучше, когда это ловится раньше. Поэтому синтезируемый код, предназначенный для описания комбинационной логики, однозначно целесообразнее писать с использованием always_comb. Его именно для этого и ввели в язык. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_4afc_ 25 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 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 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 5 часов назад, _4afc_ сказал: зачем эти чудеса типа always @* и always_comb? Cложную логику проще и понятнее описать через if/then, чем через ?:. А if/then можно только в always. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 6 января, 2022 Опубликовано 6 января, 2022 · Жалоба 3 hours ago, _4afc_ said: зачем эти чудеса типа always @* и always_comb? Как выше заметили в always_* можно использовать все многообразие операторов, не только if, а и for, case* локальные временные переменные для промежуточных расчетов, .... Что очень удобно и упрощает написание и чтение кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 7 января, 2022 Опубликовано 7 января, 2022 · Жалоба 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 нет. Есть тут правда неудобство, причем зависящее от разных ПО. Если переменная это упакованная структура и есть часть константных полей, а часть регистровых, то софт ругается по формальным признакам. Хотя с точки зрения аппаратуры все нормально) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться