[SM 0]

Блокирующие присваивания - издержки синтаксиса.

 

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

[ViKo 1]

опять спорите? :) Попробуйте и убедитесь. Ни квартус, ни престо категорически не разрешают в одном блоке делать разные виды присваиваний одной переменной.

Так подойдет? С функцией не вышло, пока...

[SM 0]

Так подойдет?

 

Нет, не подойдет. Тут в чем-то обман. Хотя, возможно, что с какой-то версии и поддержали... У меня 9.0. Квартус вообще темная лошадка, изредка такое собирает, что в страшном сне не снилось.

 

Но уж Synopsys DC это 200% что ни у кого не отсинтезирует, я выше цитату из его документации привел конкретно про этот пример.

[Des333 0]

Забавно, так работает:

 

module sub(
   input clk, 
   input sel,
   output reg count
);
     
always @ (posedge clk)
  begin
    count = 1'b0;
    if(sel)
     count <= 1'b1;
  end
     
     
endmodule

 

 

а так, нет:

 

module sub(
   input clk, 
   input sel,
   output reg count
);
     
always @ (posedge clk)
  begin
    count <= 1'b0;
    if(sel)
     count = 1'b1;
  end
     
     
endmodule

 

 

При том, ошибка во втором случае выглядит, как:

Verilog HDL error at <location>: variable "<name>" has mixed blocking and nonblocking Procedural Assignments -- must be all blocking or all nonblocking assignments

 

CAUSE: In a Verilog Design File (.v) at the specified location, you made both blocking and nonblocking Procedural Assignments to one variable in the same Always Construct. Procedural Assignments to the same variable must either all be blocking or all be nonblocking.

 

ACTION: Change or delete one or more assignments so that the Procedural Assignments for the variable are either all blocking or all nonblocking.

 

Как будто, в первом случае этого не происходит. :)

 

 

 

Нет, не подойдет. Тут в чем-то обман. Хотя, возможно, что с какой-то версии и поддержали... У меня 9.0. Квартус вообще темная лошадка, изредка такое собирает, что в страшном сне не снилось.

 

Да, 9.1sp1 Ваш пример уже собирает. Сам "в шоке"  :)

[SM 0]

Как будто, в первом случае, этого не происходит. :)

 

Ну вот и еще глюк у квартуса нашли :smile3046:

Согласно документации должен ругаться. Видимо поэтому, в очередной раз, у viko опять отсинтезировалось то, что не должно было.

[ViKo 1]

Нет, не подойдет. Тут в чем-то обман. Хотя, возможно, что с какой-то версии и поддержали... У меня 9.0. Квартус вообще темная лошадка, изредка такое собирает, что в страшном сне не снилось.

У меня все тот же Quartus 9.0, на картинке все видно. Видимо, у меня "тюнингованный" :)

Лично меня абсолютно не смущает наличие в одном блоке = и <=. Главное, чтобы они не выполнялись одновременно для одной переменной. В данном случае есть проверка условия if..else. Эти части никогда не выполнятся вместе! "Элементарно, Ватсон!"

[Des333 0]

У меня все тот же Quartus 9.0, на картинке все видно. Видимо, у меня "тюнингованный" :)

Лично меня абсолютно не смущает наличие в одном блоке = и <=. Главное, чтобы они не выполнялись одновременно для одной переменной. В данном случае есть проверка условия if..else. Эти части никогда не выполнятся вместе! "Элементарно, Ватсон!"

Может быть, Вы так же легко объясните поведение Квартуса в примерах, приведенных мной выше?  :)

[SM 0]

Лично меня абсолютно не смущает наличие в одном блоке = и <=.

 

Ну вообще мне более чем достаточно того, что Synopsys официально этот пример приводит как несинтезируемый, потому как в квартусе я прототипы компилирую, а окончательный вариант - уже в синопсисе. А квартус - глюкало.

 

Вы так же легко объясните поведение Квартуса в примерах, приведенных мной выше?  :)

Я легко объясню. Повторю... Квартус - глюкало.

 

Главное, чтобы они не выполнялись одновременно для одной переменной.

 

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

[Des333 0]

 

...

 

 

Главное, чтобы они не выполнялись одновременно для одной переменной. В данном случае есть проверка условия if..else. Эти части никогда не выполнятся вместе! "Элементарно, Ватсон!"

 

Уверены?  :)

 

Так работает:

always @ (posedge clk)
begin 
  count = 1'b0;
  count <= 1'b1;
end

 

а так - нет:

always @ (posedge clk)
begin
  count <= 1'b0;
  count = 1'b1;
end

 

Бага  :)

 

 

 

Я легко объясню. Повторю... Квартус - глюкало.  

 

Ну зачем так сразу - "глюкало". Да, иногда бывает  :)

 

А в обшем - вполне даже ничего. 

[ViKo 1]

Может быть, Вы так же легко объясните поведение Квартуса в примерах, приведенных мной выше?  :)

В первом случае, при sel = 1, count однозначно должен стать 1. Сначала - всегда в 0, потом - в зависимости от sel.

Во втором count должен стать 1 по условию sel = 1, но по выходу из блока должен был бы стать 0 из-за неблокирующего присваивания.

 

В последних приведенных вами примерах - все аналогично. Кстати - для понимания присваиваний - лучше не придумать!

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

[SM 0]

В первом случае, при sel = 1, count однозначно должен стать 1. Сначала - всегда в 0, потом - в зависимости от sel.

Во втором count должен стать 1 по условию sel = 1, но по выходу из блока должен был бы стать 0 из-за неблокирующего присваивания.

 

Это все понятно и верно, непонятно другое - ошибку "variable "<name>" has mixed blocking and nonblocking Procedural Assignments -- must be all blocking or all nonblocking assignments" квартус должен выдавать во всех случаях, а то выдает, то не выдает...

[ViKo 1]

Это все понятно и верно, непонятно другое - ошибку "variable "<name>" has mixed blocking and nonblocking Procedural Assignments -- must be all blocking or all nonblocking assignments" квартус должен выдавать во всех случаях, а то выдает, то не выдает...

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

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

[SM 0]

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

Во первых гарантируется, и очень жестко и дважды (внутри sequential block-а - 9.8.1 в IEEE1364, и determinism - 5.4.1 часть 1), а во вторых - гарантируется и то, что неблокирующие апдейтят переменные после блокирующих (9.2.1, 9.2.2), и также гарантируется, что апдейты неблокирующих обязаны быть в порядке их следования в коде (5.4.1 часть 2)

 

так что нет ни одной причины этого бы не делать... Но так "они" решили, что сделать это несинтезируемо, особенно синопсис.

[Leka 1]

так что нет ни одной причины этого бы не делать...

Надо еще рассмотреть варианты с внешними переменными в RHS.

[ViKo 1]

Во первых гарантируется, и очень жестко и дважды (внутри sequential block-а - 9.8.1 в IEEE1364, и determinism - 5.4.1 часть 1), а во вторых - гарантируется и то, что неблокирующие апдейтят переменные после блокирующих (9.2.1, 9.2.2), и также гарантируется, что апдейты неблокирующих обязаны быть в порядке их следования в коде (5.4.1 часть 2)

По первому - тем лучше! Смелее ставьте = и <= :) Именно в такой последовательности!

По второму - там как раз сначала идут блокирующие присваивания, а потом неблокирующие. Приведите пример обратного.

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