[des00 25]

мне оба подхода понятны и легко читаемы, смотря код des333 сразу вспомнил VHDL с его переменными %)

 

мой путь был графика (целых 2 дня) -> AHDL -> Verilog -> VHDL -> SystemVerilog и могу легко работать с любыми видами описания %)

[Des333 0]

мне оба подхода понятны и легко читаемы, смотря код des333 сразу вспомнил VHDL с его переменными %)

 

мой путь был графика (целых 2 дня) -> AHDL -> Verilog -> VHDL -> SystemVerilog и могу легко работать с любыми видами описания %)

А я помню, как некоторое время назад был на другой стороне барикад и не понимал, зачем использовать такое описание, которое, как я считал, затрудняет понимание, а Вы мне еще в пример VHDL с переменными приводили  :)

[sazh 3]

сразу вспомнил VHDL с его переменными

 

Ну да. Оператор := не понимая сколько пользователей VHDL по Вашему мнению использует в процентном отношении?

[Leka 0]

Блокирующие присваивания - костыли в языке "с однократным присваиванием". Долой костыли!

 

:bb-offtopic: Task-и - тоже костыли, и весьма кривые. :crying:

[SM 0]

Блокирующие присваивания - костыли в языке "с однократным присваиванием". Долой костыли!

:bb-offtopic: Task-и - тоже костыли, и весьма кривые. :crying:

Вы просто не умеете их готовить :)

[SergeyF 0]

По мне, так начинать надо с примитивов графического редактора.

Могу поспорить, что не нарисуют делитель на 2 на j-k триггере.

Это чтобы ripple clock сделать, что-ли?

 

Ну без этого просто не надо допускать к обучению HDL.

А как тема начиналась. Высокоуровневые описания... :)

[SM 0]

Высокоуровневые описания... :)

Так верно все... Чтобы качественно писать высокоуровневые, надо быть асом низкоуровневых, чтобы отлично понимать, что и как в результате получится. Это как работа с процессором - начинаем с чтения документации на ядро, ассемблер, периферию... Осваиваем его на низком уровне. А потом дорастаем до того, что можно начинать программировать под него на ЯВУ, когда понимаем, что и как на нем описанное будет происходить в реальности. Даже у врача - чтобы грамотно применить какую нибудь комплексную процедуру, он должен отлично понимать, как она повлияет на те или иные части организма вплоть до клеток.

 

Так и тут. А наоборот - дилетантство...

[des00 25]

Ну да. Оператор := не понимая сколько пользователей VHDL по Вашему мнению использует в процентном отношении?

вот именно по этому, как уже говорил SM, обучаться надо в академическом стиле, а разобравшись в основах переходить на красоту описания %)

[dxp 53]

Здрасте...

Здрастье, здрастье.

 

А никакой триггер там никуда не просится. Ни с точки зрения языка, ни с точки зрения синтезатора.

Правда? А вот ква считает по-другому:

module slon 
(
    input            clk, 
    input            rst,

    input      [7:0] x,
    input      [7:0] y,

    output reg [7:0] a,
    output reg [7:0] b,
    output reg [7:0] sum
);

//reg [7:0] a;
//reg [7:0] b;


always_ff @(posedge clk) begin
    a = x;
    b = y;
    sum <= a + b;

end

 

Вот вам и здрасьте. Как видим, триггеры присутствуют в полный рост. Но тут не все просто. Если всмотреться, то видно, что хотя объектами a и b являются триггеры, но на вход сумматора операнды подаются совсем не те значения, которые поименованы a и b. :cranky: Возникает вопрос: так сумма-то чего у нас тут получается? Сумма объектов a и b или сумма входных значений этих объектов?

 

Кстати, если закомментарить порты a и b, и раскомментарить объявления регистров a и b, то триггеры действительно исчезают (остаются только сумматор и триггер sum). Но это происходит не потому, что их там не должно быть "ни с точки зрения языка, ни с точки зрения синтезатора", а потому, что синтезатор просто их выкинул при оптимизации, т.к. на них за пределами блока ссылок нет. А когда они есть (как в первом варианте), то триггеры там никуда не делись, и объекты a и b ими и являются. И с точки зрения языка, и с точки зрения синтезатора.

 

Но понятнее, почему на вход сумматора подаются не значения этих объектов, а значения их входов, не становится. Обратимся к первоисточнику, то бишь к Стандарту. Читаем про присваивания.

 

Блокирующие:

 

A blocking procedural assignment statement shall be executed before the execution of the statements that

follow it in a sequential block (see 9.8.1). A blocking procedural assignment statement shall not prevent the

execution of statements that follow it in a parallel block (see 9.8.2).

 

 

Неблокирующие:

 

The nonblocking procedural assignment allows assignment scheduling without blocking the procedural

flow. The nonblocking procedural assignment statement can be used whenever several variable assignments

within the same time step can be made without regard to order or dependence upon each other.

<...>

The nonblocking procedural assignments shall be evaluated in two steps as discussed in Clause11. These

two steps are shown in the following example:...

 

Далее там идет пример, в котором показано, как вычисляются значения правой части выражений на первом шаге и как на втором шаге происходит собственно присваивание.

 

Но из этих цитат все равно не ясно, как же правильно, точнее что должно выполняться вперед - вычисление RHS (Right Hand Side value) для неблокирующих присваиваний или выполнение блокирующих. Обращаемся к разделу: 11. Scheduling semantics, а точнее к подразделу 11.3 The stratified event queue:

 

The Verilog event queue is logically segmented into five different regions. Events are added to any of the

five regions, but are only removed from the active region.

 

a. Active events occur at the current simulation time and can be processed in any order.

b. Inactive events occur at the current simulation time, but shall be processed after all the active events

are processed.

c. Nonblocking assign update events have been evaluated during some previous simulation time, but

shall be assigned at this simulation time after all the active and inactive events are processed.

d. Monitor events shall be processed after all the active, inactive, and nonblocking assign update

events are processed.

e. Future events occur at some future simulation time. Future events are divided into future inactive

events and future nonblocking assignment update events.

 

The processing of all the active events is called a simulation cycle.

 

И далее:

 

The freedom to choose any active event for immediate processing is an essential source of nondeterminism

in the Verilog HDL.

<...>

11.4.2 Nondeterminism

One source of nondeterminism is the fact that active events can be taken off the queue and processed in any

order.

 

Что же получается? Что порядок выполнения активных событий на данном шаге симуляции не определен! Т.е. симулятор волен сперва вычислить RHS для выражений и с неблокирующими присваиваниями (с целью последующего апдейта LHS выражений с такими присваиваниями), а потом выполнять блокирующие. А волен поступить наоборот. А может вообще вычислить RHS для части неблокирующих, потом выполнить часть блокирующих, затем еще вычислить RHS для оставшихся неблокирующих и т.д. И синтезатор в рамках Стандарта также волен поступать аналогично. Что мы и видим у ква на примере выше. Вся эта картина наглядно показана:

 

Резюмируя. Порядок выполнения выражений в этом коде не определен. Писать такой код - искать себе грабли на пустом месте. И предупреждения выдаются совершенно законно, а объяснение:

Варнинг он же не просто так, а чтобы человек лишний раз поглядел, не случайно ли он в одном always намесил того и другого. А когда не намешано - точно известно, что так и задумано было.

 

мимо кассы. Если оно так задумано было, то только лишь от непонимания.

 

тут, вообще то, выходит что a и b совсем не триггеры, а промежуточные нерегистровые переменные. так как даю 100 к 1, что они вне блока не задействованы.

Они всегда триггеры. По правилам языка. Другое дело, что из-за неопределенности порядка обработки выражений, описанной выше, компилятор может взять значения с их входа, а не выхода, а сами триггеры выкинуть при оптимизации (что и имеет место в случае с квартусом). И дело тут не в блокирующих/неблокирующих присваиваниях, а порядке обработки активных событий, который (порядок) не определен. И предупреждение на эту тему более, чем уместно - результат будет непредсказуем. Кстати, квартус тут на эту тему молчит, что совсем не гуд.

 

Переменная reg. По фронту клока триггер просится. А его не будет. Ввел в заблуждение и доволен. Вне процесса просится описание.

Вне коллектива товарищ трудится.

Меня не ввел. Мне такое описание нравится, оно красиво, понятно, и в тоже время кратко.

Ну, тут остается только посоветовать пересмотреть собственные стереотипы и комплексы насчет правил написания кода на верилоге (и не только).

 

А где это почитать можно.

А вот, кстати в том же источнике:

 

Ну, и весь файлик целиком:Advanced_verilog_coding.rar Очень внятно все и с картинками. Рекомендую ознакомиться с мнением закомплексованных и забитых стереотипами чуваков. Каждый волен писать, как вздумается, в произвольном стиле, если нравится закладывать в код потенциальные грабли. Я предпочитаю пользоваться отработанными и хорошо себя зарекомендовавшими себя на практике стилями (см документик), т.к. мне хватает борьбы с прикладными задачами.

[SM 0]

Правда? А вот ква считает по-другому:

Вы, на мой взгляд, допустили преднамеренную грубую ошибку. Объявив a и b как output, несмотря на то, что автор подтвердил, что a и b нигде, кроме как внутри always, не задействованы. И тем самым намерено исказили смысл того, для чего были применены блокирующие присваивания.

 

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

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

 

 

Ну, тут остается только посоветовать пересмотреть собственные стереотипы и комплексы насчет правил написания кода на верилоге (и не только).

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

[dsmv 0]

Наблюдая за этой дискуссией прихожу к выводу что VHDL всё-таки лучше. Потому что в VHDL принципиально разделены переменные и сигналы.

Компилятор контролирует их применение и не даёт возможности сделать ошибки подобного рода.

:rolleyes:

[SM 0]

Компилятор контролирует их применение и не даёт возможности сделать ошибки подобного рода.

:rolleyes:

Ага, поэтому VHDL в академических целях и лучший. Пока такие ошибки человек в принципе делает. Потом же он начинает "доставать" своими излишествами.

[dxp 53]

Вы, на мой взгляд, допустили преднамеренную грубую ошибку. Объявив a и b как output, несмотря на то, что автор подтвердил, что a и b нигде, кроме как внутри always, не задействованы. И тем самым намерено исказили смысл того, для чего были применены блокирующие присваивания.

Никакой ошибки я не сделал. В регистровом always блоке любые присваивания - и блокирующие и неблокирующие порождают триггеры! Я это утверждал. И это факт! А то, что неиспользованные триггеры компилятор выкинул, так это оптимизация. Давайте, уберите с выхода объявления sum, компилятор и триггеры объекта sum выкинет - тогда сможете смело объявить, что регистровые блоки вообще триггеров не порождают.

 

 

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

Какой определенности? Что эти блокирующие присваивания гарантируют? Что выполняются вперед неблокирующих? Чушь! Покажите место в Стандарте, где это сказано? Я вам выше привел обилие цитат и картинок, где все разжевно.

 

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

Про код:

reg a, b, c;
always @(posedge clk) begin
    ...
    a = x;
    b = y;
    c <= a + b;
end

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

 

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

 

Наблюдая за этой дискуссией прихожу к выводу что VHDL всё-таки лучше. Потому что в VHDL принципиально разделены переменные и сигналы.

Компилятор контролирует их применение и не даёт возможности сделать ошибки подобного рода.

:rolleyes:

Если VHDL и лучше, то вряд ли в этом. Это как на Си - можно писать надежные программы, а можно говнокод. Язык позволяет. И именно "позволительность" языка и дает возможность достигать большой эффективности. И есть в стандарте четко сказано, что такие-то и такие вещи порождают неопределенное поведение, то не надо так писать, только и всего. Квалификация и компетентность от разработчика, конечно, требуются. Т.ч. что лучше/хуже - это пустой спор.

[dsmv 0]

Ага, поэтому VHDL в академических целях и лучший. Пока такие ошибки человек в принципе делает. Потом же он начинает "доставать" своими излишествами.

 

Ошибки человек всегда делает. Причём чем проще ошибка, тем сложнее её отыскать. Поэтому "излишества" они совершенно не лишние.

[SM 0]

Какой определенности? Что эти блокирующие присваивания гарантируют? Что выполняются вперед неблокирующих? Чушь! Покажите место Стандарте, где это сказано?

 

Вы бы хоть стандарт почитали, прежде чем такое писать. 9.2.1. Определеннее некуда.

 

A blocking procedural assignment statement shall be executed before the execution of the statements that

follow it in a sequential block

 

насчет порождения триггера - да, он порождается. Я это и не отрицал. Я утверждаю, что породившись, он умирает. И это соответствует смыслу того, что писал автор.

 

 

Какая у вас цель, когда вы участвуете в дискуссиях на форуме? Поднять собственное понимание или посамоутверждаться?

Побороться с застойными, на мой личный взгляд, принципами и подходами.