[Des333 0]

В общем, надо писать нормальные конструкции и никаких проблем тогда не будет. :)

[ViKo 1]

Компилил то, что Вы предложили (т.е. не Вы, а Leka).

module tst( a, b );
output reg a=0; 
output reg b=0; 
always@* begin
  a <= b;
  b <= 0; 
  b <= 1;
end
endmodule

Происходит вот что, как я думаю. Поначалу a=0, b=0. Блок должен сработать, когда b<=1. Задаст a<=b=1, потом b<=0, потом b<=1. После этого никаких событий (изменений) больше не возникает. Никаких вечных циклов. Вечное ожидание.

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

[Leka 0]

Синтезаторы-то нормально воспринимают такую конструкцию.

[SM 0]

Никаких вечных циклов.

 

По стандарту - вечный цикл.

 

always @* в данном случае эквивалентно always @( b )

 

далее происходит так.

 

1) "reg b = 0" вызывает update event для b.

2) always срабатывает.

3) выполняетися evaluation event для begin...end

4) и 5) и 6) выполняются три update event-а для a, b и b, порожденные evaluation event-ом 3)

7) update евент для b активирует always. ну и GOTO 2) так как никаких "#" не стоит, и все это происходит внутри одного момента-кванта времени и опять есть активный евент.

 

Синтезаторы-то нормально воспринимают такую конструкцию.

так на то они и синтезаторы, что у них нет этого геморроя с event-ами, их очередью и активацией. Это все чисто для моделирования, и ни для чего более. А синтез идет по правилам вычисления statement-ов, которые вполне прозрачны. Расставляйте #-ки, и проблем не будет. b <= #1 0; Синтезатор их проигнорит, а симулятор не зависнет - это азы.

 

UPD: У синтезаторов и стандарт свой - IEEE 1364.1-2002

[Leka 0]

Вечного цикла быть не должно:

a <= b;
b <= 0;
b <= 1;

вроде как эквивалентно:

a <= b;
RHS = 0;
RHS = 1;
b <= RHS;

а этот код воспринимается симулятором без проблем, выдавая:

a=1 b=1, как и в случае:

a <= b;
b <= 1;

[ViKo 1]

Что вызывает начальный заход в блок? Висели себе a и b в нуле, никого не трогали.

Событие - это изменение сигналов, к которым чувствителен блок.

Дальше, действительно, при выходе из блока b=0, тут же b=1 - вот и событие.

А началось с чего?

[Leka 0]

Инициализация? Было "x", стало "0".

[ViKo 1]

Инициализация? Было "x", стало "0".

Похоже.

Причем, даже такой модуль

module tst( a, b );
  output reg a; 
  output reg b = 0; 

  always @(a) begin
    b = 1;
  end
endmodule

Синтезируется в a=0, b=1

[SM 0]

Событие - это изменение сигналов, к которым чувствителен блок.

 

Так оно было... Вначале, при инициализации, "x" -> "0", запустившее весь процесс. А потом внутри блока стоит явный перепад, хоть и мгновенный, сначала "b <= 0" потом "b <= 1". Именно поэтому убийство "b <= 0" и устраняет вечный цикл. И в этом есть еще разница между "b=0; b=1;" и "b<=0; b<=1;" - то в первом случае два апдейта происходят внутри вычисления одного и так активного эвалюшн-евента (вычисления блока begin...end), соотв. value change ничего не делает (евент и так активный, ну и еще раз ему статус активности установили), и не висим, ну а при неблокирующих - по любому два отдельных апдейт-евента, выполняющихся уже после того, как евалюшн-евент полностью вычислен, вот и все вешаются - запускаем все заново.

 

 

Синтезируется в a=0, b=1

 

На самом деле в "a=x" - ноль это просто совпадение... Что "x" нулем оказался.

[Leka 0]

module tst(a, b);
output reg a = 0; 
output reg b = 0; 
always @* begin
  a <= a | b;
  b <= 1;
  b <= 0; 
end

синтезируется в a=0 b=0, так что можно считать, что b <= 1 никогда не исполняется.

[Des333 0]

module tst(a, b);
output reg a = 0; 
output reg b = 0; 
always @* begin
  a <= a | b;
  b <= 1;
  b <= 0; 
end

синтезируется в a=0 b=0, так что можно считать, что b <= 1 никогда не исполняется.

 

 

А как оно должно исполняться то?

 

Что, сигнал b должен чуть-чуть времени побыть нулем, потом чуть-чуть единицей?  :)

 

Вы представляете схему того, что Вы пишите?

[Leka 0]

А как оно должно исполняться то?

Точно так-же, как и:

module tst(a, b);
output reg a = 0; 
output reg b = 0; 
always @* begin
  a <= a | b;
  b <= 0; 
end

те наличие/отсутствие "b <= 1;" перед "b <= 0;" не должно влиять на синтез и симуляцию. А на практике - влияет: вечный цикл в симуляторе с "b <= 1;".

 

В-общем, для себя решил не подмешивать ложку "=" в бочку "<=" только ради симуляции.

[Des333 0]

...

В-общем, для себя решил не подмешивать ложку "=" в бочку "<=" только ради симуляции.

 

Так у Вас тут нигде "=" и не используются.

[dxp 53]

В общем, надо писать нормальные конструкции и никаких проблем тогда не будет. :)

+1000!

 

Все эти

 

always @(posedge clk)
    if(...) 
        count = ...;
    else
        count <= ...;

не более, чем плод неаккуратности - нету тут ни смысла, ни замысла, обыкновенный г..внокод. Это пример того, как не надо писать, после него и остальные примеры не вызывают ни доверия, ни желания рассматривать их в качестве референтных.

 

* * *

 

Что касается плясок с начальным запуском always @*, то давно существует приличная альтернатива в виде always_comb, который всегда в нулевой момент времени (начало симуляции) производит один прогон, не зависимо от того, изменялись ли объекты, которые входят в его список чувствительности. Есть и другие полезные преимущества always_comb перед always @* - такие как более четкие правила посторения списка чувствительности (у always @* список чувствительности может быть неполным в случае применения функций, использующих чтение переменных, не переданных в качестве аргументов в функцию). Имеет смысл использовать возможности SystemVerilog'а - он не только для верификации полезен, но и усовершенствовал подобные вещи.

 

* * *

 

des333

К вам вопрос. Возвращась к нашей дискуссии. Вот смотрите, допустим, что ваша трактовка правильна - т.е. событие "вычисление RHS" является частью выражения, и поэтому блокирующие присваивания в силу того, что блокируют все нижеидущие выражения, гарантировано выполняются вперед. Т.е.:

always @(posedge clk) begin
    ...
    a = x;
    b <= a;
    ...
end

a гаранировано получает значение x до вычисления RHS следующего присваивания, т.е. по сути этот код эквивалентен:

always @(posedge clk) begin
    ...
    a = x;
    b <= x;
    ...
end

 

Тогда рассмотрим такой вариант:

always @(posedge clk) begin
    ...
    b <= a;
    a = x;
    ...
end

Каков будет тут порядок по вашему мнению? Т.е. тут, как видите, блокирующее присваивание идет после, и вычисление RHS не блокируется выражением a = x. Но блокирует ли событие "вычисление RHS" идущее ниже выражение a = x? Про это ничего, вроде, не сказано (я не нашел). Т.е. гарантируется ли порядок вычисления, описанный в этом варианте? Или имеем неоднозначность? :)

[Des333 0]

des333

К вам вопрос.

 

...

 

 

Каков будет тут порядок по вашему мнению? Т.е. тут, как видите, блокирующее присваивание идет после, и вычисление RHS не блокируется выражением a = x. Но блокирует ли событие "вычисление RHS" идущее ниже выражение a = x? Про это ничего, вроде, не сказано (я не нашел). Т.е. гарантируется ли порядок вычисления, описанный в этом варианте? Или имеем неоднозначность? :)

На мой взгляд, неоднозначности не будет.

 

 

Вначале произойдет "вычисление RHS", затем блокирующее присваивание, а после "non blocking assign update event".

 

В итоге a будет равно x, а b будте равно предыдущему значению a.

 

 

 

 

Основываюсь на том, что  "non blocking assign update event" менее приоритетный, чем "active events"(которые как раз и могут выполняться в любом

 

порядке, если они не в последовательном блоке) и чем "inactive events". 

 

Пункты 5.3 - 5.4