[ViKo 1]

Не получил никаких комментариев на свои послания.

Я задал компилировать модуль

module Test (input a, input b, output c);
  always @*
    c <= a & b;
endmodule

И получил результат. Так что кто-то заблуждается по поводу регистров в блоках always

[SM 0]

P.S. Объясните поведение кода и картинок из поста #247?

А что объяснять? Все соответствует стандарту.

 

первый случай:

 

sum <= a+b;

a = x;

b = y;

 

sum выполняется незаблокировано, параллельно и единовременно с a = x, на это время, до окончания a=x, b=y заблокировано. Итого - sum запоминает сумму переменных a и b, которые были на входе в блок, поэтому появляются реальные регистры a и b. параллельно с этим обновляется регистр a новым значением из x. Затем обновляется регистр b из y. Синтезированная схема полностью соответствует стандарту.

 

 

следующее:

 

a = x;

sum <= a+b;

b = y;

 

a=x выполняется, заблокировав все остальное за собой. Как только a обновленно, дальнейшее разблокируется, и sum <= a+b выполняется параллельно и единовременно с b=y. Так как к этому моменту a уже равно x, а "b" хранит значение со входа блока, то оптимизатор вычисляет sum <= x+b. Таким образом триггер "a" ликвидируется за невостребованностью сохраненного в нем значения. ну и вместе с занесением в sum одновременно обновляется и "b" значением из "y". Опять все четко и полностью соответствует стандарту.

 

Как видим - в обоих случаях блокируют вычисления именно блокирующие присваивания. Только в первом случае они ни на что не влияют, и в нем не важно, какой тип присваивания, а во втором - влияют.

 

 

 

Так что кто-то заблуждается по поводу регистров в блоках always

Да нет, это кто-то нашел глюк в каком-то компиляторе....

[ViKo 1]

Да нет, это кто-то нашел глюк в каком-то компиляторе....

А почему бы Вам не признать собственную не полную информированность в данном ("маленьком") вопросе?

[SM 0]

А почему бы Вам не признать собственную не полную информированность в данном ("маленьком") вопросе?

Ну потому как стандарт недвусмысленно это запрещает.

 

"A wire net can be used for nets that are driven by a single gate or continuous assignment.", и третьего не дано.

 

и "Table 30—Legal left-hand side forms in assignment statements"

[ViKo 1]

Ну потому как стандарт недвусмысленно это запрещает.

 

"A wire net can be used for nets that are driven by a single gate or continuous assignment."

 

и "Table 30—Legal left-hand side forms in assignment statements"

Вот пример из стандарта IEEE Std 1800-2005 (возможно, не последний, что имею...), стр 69

module ma   #( parameter p1 = 1, parameter type p2 = shortint )
(input logic [p1:0] i, output logic [p1:0] o);
p2 j = 0; // type of j is set by a parameter, (shortint unless redefined) 
always @(i) begin 
o = i; 
j++; 
end 
endmodule 
module mb;
logic [3:0] i,o;
ma #(.p1(3), .p2(int)) u1(i,o); //redefines p2 to a type of int 
endmodule

По-вашему, i и o - регистры? А такты где?

 

А это что?:

initial, always, always_comb, always_latch, and always_ff proce-

dural blocks;

Изменено 24 марта, 2010 пользователем ViKo

[SM 0]

Вот пример из стандарта IEEE Std 1800-2005 (возможно, не последний, что имею...)

А по-вашему "IEEE Std 1800-2005" это Verilog? По моему это SystemVerilog. А последний верилог был вроде IEEE Std. 1364-2001.

Что касается SV - так тип logic в SV это integer data type, как и reg в V. Т.е. logic эквивалентен reg. Поэтому он может применяться в procedural assignment.

 

А такты где? А нигде. Блок комбинаторный для "o", а для j тактом фактически является любое изменение на i.

[ViKo 1]

А по-вашему "IEEE Std 1800-2005" это Verilog? По моему это SystemVerilog. А последний верилог был вроде IEEE Std. 1364-2001.

Что касается SV - так тип logic в SV это integer data type, как и reg в V. Т.е. logic эквивалентен reg. Поэтому он может применяться в procedural assignment.

 

А такты где? А нигде. Блок комбинаторный для "o", а для j тактом фактически является любое изменение на i.

А я о чем? Вы все еще на Verilog? тогда мы идем к Вам! :)

[SM 0]

А я о чем? Вы все еще на Verilog? тогда мы идем к Вам! :)

А мне от SV пока что ничего в реальной работе не потребовалось... Только чисто в академических целях чутка поигрался... Так что он сам придет, когда понадобится.

[dxp 68]

Почему же синтезатор их не выкидывает, если изменить "=" на "<="?

По той же причине, по какой он их не выкидывает, если sum <= ... написать первым выражением. Синтезатор при анализе кода блока видит три активных события (active events, как в Стандарте написано):

 

Blocking assigment: a = ...

Blocking assigment: b = ...

Evaluation RHS of nonblocking assigment: a + b

 

Они могут выполняться в произвольном порядке, но синтезатор тут не мудрит - в каком порядке они описаны в блоке, в таком он их в очередь и помещает. Далее получается следующее: первое событие обработал - значение а есть, второе событие обработал - значение b есть, третье событие обрабатывает - его аргументы уже вычислены - это результаты обработки двух предыдущих событий.

 

Теперь строится выполнение (реализация): первые два события дают триггеры, третье сумматор и регистр (триггер). Поскольку значения a и b больше нигде не используются, то оптимизатор спокойно выкидывает их триггеры.

 

В случае блокирующих присваиваний происходит следующее: тоже три активных события, но все три - это вычисления RHS (для a, b и sum). И при этом вычислении еще нет значений a, b и sum для этого прохода блока - эти значения появятся только на фазе с. очереди событий (см пост #234), а в данный момент (вычисления RHS) идет фаза а., поэтому синтезатор вынужден брать значения a и b из предыдущего прохода блока, т.е. брать значения из триггеров - и поэтому он при оптимизации не имеет права выкинуть эти триггеры за ненадобностью.

 

В случае с моими картинками (то, что я SM'а просил объяснить) ситуация аналогичная. Если поместить sum <= a + b; перед блокирующими присваиваниями, то при обработке активных событий вычисление RHS (т.е. значения a + b ) оказывается в очереди обработки первым (квартус не мудрит - в каком порядке выражения описаны, в таком и помещает в очередь), и поскольку значения a и b для данного прохода блока еще не получены, то берутся значения из регистров-триггеров, и оптимизатор их выкинуть не может. При перемещение sum <= a + b; между выражениями с блокирующими присваиваниями объяснение аналогичное - порядок активных событий в очереди такой, что при вычислении RHS для sum значение a уже есть, а b еще нету, поэтому триггер a можно выкинуть, а триггер b нельзя.

[SM 0]

Blocking assigment: a = ...

Blocking assigment: b = ...

Evaluation RHS of nonblocking assigment: a + b

 

Они могут выполняться в произвольном порядке,

 

Это просто катастрофическая ошибка принципов верилога!!!!

 

"b=..." не может выполнятся до окончания "a=..", так как "a=.." блокирующее.. ", а "Evaluation of RHS a+b" не может выполняться до окончания "b=", так как b= тоже блокирующее. Это беспрекословное правило из пункта 9.2.1.

 

Это самое "Evaluation of RHS" заблокировано в очереди событий находящимся перед ним блокирующим "b=", и пока "b=" не исполнено полностью, начинаться исполнение "Evaluation of RHS" не имеет права.

[ViKo 1]

Чуток изменил

module Test (input a, input b, output integer c);
  always @*
    c <= a & b;
endmodule

Verilog-2001

Где Вы видите регистры?

Вообще говоря, <= это только указание компилятору присваивать результат на выходе из блока. Все остальное - фиолетово.

Изменено 24 марта, 2010 пользователем ViKo

[SM 0]

Где Вы видите регистры?

А с чего бы их тут видеть??? Их тут и не должно быть.

 

Я говорил не о регистрах, а об обязательности регистрового типа - в данном случае "output integer с".

 

А в том примере, где был глюк синтезатора, было написано "output c" без слова integer. Пост #256, цитирую...

 

 

Не получил никаких комментариев на свои послания.

Я задал компилировать модуль

Код

module Test (input a, input b, output c);
  always @*
    c <= a & b;
endmodule

И получил результат. Так что кто-то заблуждается по поводу регистров в блоках always

 

так что тут, с "output c", никакого результата, кроме ошибки компиляции, получиться не должно было. Пока не указать тип-регистр - reg, integer... Так как по умолчанию подразумевается "output wire c"

[Leka 1]

А теперь поясните пожалуйста, что хотели сказать :) Чтобы остальные поняли.

Пример:

module tst(
  output reg [7:0] q = 0,
  input clk
);
wire [7:0] d = q+1;
always@(posedge clk) begin
    q = 100; 
    q = d;    
end
endmodule

Как проще объяснить поведение этого модуля? Переводом в подходящее эквивалентное представление, имхо. И выяснится, что получится счетчик, а не константа 101.

Изменено 24 марта, 2010 пользователем Leka

[SM 0]

И выяснится, что получится счетчик, а не константа 101.

ну да, верно. А с чего ожидать константу? Чтобы ожидать константу, надо поставить "#1" между q=100; и q=d;

и это несинтезируемое извращение :)

[Leka 1]

Просто пример, что "=" гораздо сложнее для понимания, чем "<=". И зачем нужны эквивалентные представления.