[sazh 5]

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

 

А где это почитать можно. Например у Полякова все по простому - синтез вытекает из свойств операторов присваивания. Все.

Зная свойства операторов, можно делать что угодно, иногда нагляднее с блокирующим.

module bcd_bin2_reg // U.Tietze - Ch.Schenk  page 324
(
input             clk,
input      [15:0] bcd, 
output reg [13:0] bin,
output reg        enable_rd_bin
);

reg  [3:0] ct_bit_bin;
reg [15:0] bcd_rg;
reg [13:0] bin_rg;

function [3:0] correct;
input [3:0] decade;
begin 
correct = (decade > 7) ? (decade - 4'd3) : decade;
end
endfunction

always @ (posedge clk)
begin
enable_rd_bin = (ct_bit_bin == 4'd0);
if (ct_bit_bin == 4'd0)                   begin
bin = bin_rg;
bin_rg = 14'd0;
bcd_rg = bcd;
ct_bit_bin = 4'd14;                       end
else                                          begin
bin_rg = {bcd_rg[0], bin_rg[13:1]};  
bcd_rg = (bcd_rg >> 1);
bcd_rg[3:0] = correct(bcd_rg[3:0]);
bcd_rg[7:4] = correct(bcd_rg[7:4]);
bcd_rg[11:8] = correct(bcd_rg[11:8]);
bcd_rg[15:12] = correct(bcd_rg[15:12]);
ct_bit_bin = ct_bit_bin - 1'b1;                end
end
            
endmodule

[SM 0]

Зная свойства операторов, можно делать что угодно, иногда нагляднее с блокирующим.

Именно так. А не зная или плохо зная - отмазываться какими-то странными надуманными ограничениями их применения.

[Des333 0]

Что-то тут не топик, а сплошной холивар. :)

Давайте еще про использование оператора goto в ЯП вспомним.

 

 

Лично я не люблю смешивать блокирующие и неблокирующие присваивания, но при этом огромного криманала в этом не вижу.

Иногда, даже в простом коде, это может быть полезно.

 

always @ (posedge clk)
begin
  a = massiv_nomer_odin[index] + massiv_nomer_dva[index];
  b = massiv_nomer_tri[index] + massiv_nomer_chetire[index];
  sum <= a + b;
end

 

Надеюсь, идея понятна. :)

[SM 0]

Лично я не люблю смешивать блокирующие и неблокирующие присваивания, но при этом огромного криманала в этом не вижу.

 

Надеюсь, идея понятна. :)

 

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

[dxp 53]

Это лишь Ваше IMHO, что такой стиль плох. Лично меня запутывает, когда есть лишние always, которых могло бы и не быть. Краткость => минимум лишних слов и действий => понятность и простота. И все средства языка хороши для того, чтобы добиться краткости записи и ликвидаци лишних сущностей.

Тогда что же вы такие длинные имена пишите - prio, intvect, intrq? Писали бы p, iv, irq. Еще короче, а значит понятнее и проще. Надеюсь, этот простой пример наглядно демонстрирует нелогичность вашего постулата.

 

Что касается неприсутствия в правой части - вернитесь к примеру с делителем - там это присутствие абсолютно полное.

Там совсем другой пример вида: a = f(a); А я говорил про случай с перекрестными связями. У вас в обоих примерах простой код без пересечений, и в контроллере прерываний в том числе простой код из непересекающихся блоков.

 

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

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

 

Ваш первый вариант неверен, так как prio меняется только если есть соответутвующий ему irq. Я же написал - это контроллер прерываний с приоритетами. Прерывание вызывает тот блок, от которого есть *_irq и чей *_ip (приоритет конкретного блока - тут трех таймеров и уарта) выше. Если *_irq не было, то и сравниваться/меняться с его *_ip ничего не должно.

*_ip - это что? Константы? Переменные? Из примера это не понятно.

 

Ваш второй вариант абсолютно правилен, но он не красив и запутан наличием лишнго блока, которого могло бы не быть. Чтобы понять сущность описания в Вашей записи надо прочитать два блока и мысленно их объединить, что вызывает некоторое торможение при чтении такого кода.

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

[SM 0]

*_ip - это что? Константы? Переменные? Из примера это не понятно.

Естественно переменные (опять странный вопрос - были бы константы, или вписал бы цифры, или отметил бы это отдельно). Приоритет соответствующего модуля, который может запрашивать прерывание. Его, как и вектор прерывания, и запрос на прерывание, выдает сам модуль, а задает его программист микроконтроллера, записывая данное в регистр вектора и приоритета модуля.

 

В моем варианте как раз все упрощено до предела - "мухи" отделены от "котлет". И при необходимости расширять код нет "пространства" для ошибок.

Это ваше IMHO такое, а не безапелляционно упрощено. Меня такой код запутывает и часто вводит в заблуждение.

 

Кстати, это классический способ, применяемый для описания КА. И возник он не на пустом месте, а как раз ввиду необходимости иметь более простой и надежный способ описания больших КА.

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

 

Тогда что же вы такие длинные имена пишите - prio, intvect, intrq?

Вот не надо мух с котлетами перемешивать. Понятность имен это одно, а понятность описания логики - другое. Понятность имен краткостью недостижима, а понятность логики и структуры - в первую очередь ей и определяется.

[dxp 53]

always @ (posedge clk)
begin
  a = massiv_nomer_odin[index] + massiv_nomer_dva[index];
  b = massiv_nomer_tri[index] + massiv_nomer_chetire[index];
  sum <= a + b;
end

 

Надеюсь, идея понятна. :)

Идея не понятна, извините. У вас тут sum получается значение a + b, которое было на момент прихода положительного фронта clk. Т.е. значения a и b, вычисляемые в первых двух выражениях, в третьем выражении на данном такте не участвуют. Какой сакральный смысл оформлять их блокирующими присваиваниями? Да, тут разницы нет, т.к. нет взаимных связей между выражениями, но необходимость использования блокирующих присваиваний все равно не ясна. a, b и sum - это триггеры при синтезе, "физика" работы триггера - записать данные на входе по фронту. А тут выходит, что вроде a и b хоть и равноправные триггеры, но а срабатывает вперед, чем b, что на самом деле не так. Чем в этом хорошего?

[SM 0]

А тут выходит, что вроде a и b хоть и равноправные триггеры,

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

[sazh 5]

тут, вообще то, выходит что a и b совсем не триггеры, а промежуточные нерегистровые переменные.

 

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

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

[SM 0]

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

Меня не ввел. Мне такое описание нравится, оно красиво, понятно, и в тоже время кратко. А то, что слово "reg" вовсе не означает наличие регистра, думаю, любой школьник на сегодня уже знает.

[SergeyF 0]

Меня не ввел. Мне такое описание нравится, оно красиво, понятно, и в тоже время кратко. А то, что слово "reg" вовсе не означает наличие регистра, думаю, любой школьник на сегодня уже знает.

Не знаю как школьники :), но по опыту работы со студентами знаю, что с регистровыми/комбинаторными схемами и блокирующими/неблокирующими присваиваниями у начинающих проблемы. Я по опыту обучения пришел к выводу, что начинать лучше так, как написал dxp. Да и сам так чаще всего пишу.

[SM 0]

что начинать лучше так, как написал dxp.

Так и я об этом чуть выше писал - что начинать надо именно так, что в академических целях это все и придумано. А как придет понимание - можно задуматься о красоте и краткости.

[sazh 5]

Я по опыту обучения пришел к выводу, что начинать лучше так, как написал dxp. Да и сам так чаще всего пишу.

 

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

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

[SM 0]

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

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

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

[Des333 0]

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

 

Варнинги - это да.  :)

 

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

 

Но потом понял, что иногда это бывает очень удобно. 

 

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

 

 

... a, b и sum - это триггеры при синтезе...

 

Здрасте...

 

 

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

 

Естественно :)

 

 

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

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

Вы читайте внимательно. Там же все написано.

Лично я так не пишу, потому что люблю использовать блокирующее присваивание только для комбинационки. Потому что так привык.

 

Но! При этом я понимаю, зачем люди пишут по-другому, и ничего плохого в этом не вижу (некоторое время назад был совсем против, но взгляды поменялись). Естественно, код должен продолжать оставаться читаемым и понятным.

 

 

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