[andrew_b 17]

Пример, пожалуйста,

Не будет. Я на верилоге не пишу.

 

для варианта с однократным присваиванием всех переменных в блоке. За исключением присваивания 'z.

А что, количество переменных имеет значение?

 

Подождём знатоков верилога.

[krux 8]

Пример, пожалуйста, для варианта с однократным присваиванием всех переменных в блоке. За исключением присваивания 'z.

претензии здесь могут быть только к вашему ужасному coding style.

поскольку внутри нормальных м/сх не может быть никаких шин с z-состоянием, то любые описания должны быть вынесены на TOP-уровень, на самый верх, с описанием вида

inout wire1;
wire wire1;
assign wire1 = oe ? wire1_drv : 1'bz;

другие формы описания не имеют практического физического смысла.

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

 

В голом итоге, я позволю себе сделать маленькое такое наблюжение: в отличие от VHDL, язык Verilog позволит вам выстрелить в себе в ногу, если вы того пожелаете. Считать это свободой манёвра или недостатком - каждый решает сам.

[Leka 1]

coding style

Никакого отношения к этому мой пример не имеет.

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

 

другие формы описания не имеют практического физического смысла

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

Изменено 11 декабря, 2016 пользователем Leka

[RobFPGA 35]

Приветствую!

 

Надеюсь, такое исключение только для 'z, тк это свойство однократного присваивания(независимость от порядка) очень удобно на практике.

придумали себя Это такое правило для Вы?

 

Действительно очень удобно для меня - но слегка непонятно для Вас. :)

 

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

"математический формализм" подразумевает строгое соответствие правилам а не свободное их трактование.

Попробуете применить этот формализм для ПОШАГОВОГО анализа того что же должно получится в Вашем примере - тогда будет понятно в чем же были "неправы" создатели Quartus.

поскольку внутри нормальных м/сх не может быть никаких шин с z-состоянием, то любые описания должны быть вынесены на TOP-уровень, на самый верх, с описанием вида

...

Не надо быть столь категоричным - Virtex-E был в свое время вполне нормальной мс и имел внутри полноценные BUFT для построения шин

Да и времена описания BUFT только в TOP давно уже прошли в связи с развитием алгоритмов синтезаторов.

 

 

Удачи! Rob.

[Leka 1]

придумали себя Это такое правило для Вы?

В русском языке нет такого правила, а в Верилоге есть (за исключением присваивания 'z).

Опровергнуть легко, достаточно придумать хотя-бы один пример:

always_comb begin
  a = ...;
  b = ...;
  c = ...;
end

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

(Только проверять надо не по RTL Viewer, а Technology Map Viewer, или в железе).

Изменено 11 декабря, 2016 пользователем Leka

[RobFPGA 35]

В русском языке нет такого правила, а в Верилоге есть (за исключением присваивания 'z).

Простите какое именно правило Verilog нужно опровергнуть? можно ссылку на стандарт.

 

Удачи! Rob.

 

[Leka 1]

Мой тезис - синтез не зависит от перестановок однократных присваиваний в процедурном блоке.

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

 

[RobFPGA 35]

Приветствую!

 

Мой тезис - синтез не зависит от перестановок однократных присваиваний в процедурном блоке.

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

Аааа... это Ваш тезис а не правило Verilog. Тогда жду Ваш строгий анализ что же тут получится

 

module aaaa (
  input clk,
  input  [7:0] din0 ,
  input  [7:0] din1 ,
  output [7:0] dou0,
  output [7:0] dou1
);

reg [7:0] a0,b0,c0;

always @(posedge clk) begin
  a0 = din0;
  b0 = a0;
  c0 = b0;
end

reg [7:0] a1,b1,c1;

always @(posedge clk) begin
  a1 = din1;
  c1 = b1;
  b1 = a1;
end

assign dou0=c0;
assign dou1=c1;

endmodule

Удачи! Rob

 

[Leka 1]

В процедурном блоке с @(posedge clk) нет понятия дельта-цикла, как и в блоке initial.

А это важно для принципа однократного присваивания:

http://electronix.ru/forum/index.php?showt...t&p=1466550

Для опровержения жду только пример c always_comb, как в своих примерах выше.

И даже "рыбу" дал: http://electronix.ru/forum/index.php?showt...t&p=1468016

С always_ff принцип однократного присваивания реализуется неблокирующими присваиваниями (и такое описание триггеров соответствует общепринятому стилю).

[RobFPGA 35]

Приветствую!

 

Мой тезис - синтез не зависит от перестановок однократных присваиваний в процедурном блоке.

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

пример выше

В полном соответсвии с Вашими требованиями - однократное присваивание, в процедурном блоке

В процедурном блоке с @(posedge clk) нет понятия дельта-цикла, как и в блоке initial.

А это важно для принципа однократного присваивания:

Ух ты! Как же так? :crying:

 

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

 

Для опровержения жду только пример c always_comb, как в своих примерах выше.

...

always_comb при синтезе это "синтаксический сахар" для замены assign. В этом контексте переменные (reg, logic) описывают связи а не состояния переменных во времени.

 

С always_ff принцип однократного присваивания реализуется неблокирующими присваиваниями (и такое описание триггеров соответствует общепринятому стилю).

Можете заменит в приведенном примере always @(posedge clk) на always_ff @(posedge clk) и сравнить результаты синтеза.

И почему при этом вышеприведенный пример не обеспечит Вашего принципа? Ведь с точки зрения синтеза Verilog описание тригеров ПРАВИЛЬНО как при использовании '=' так и '<='. Ну а общепринятый стиль в понятие стандарта не входит.

 

Очень хочется услышать Ваши рассуждения (пусть и добрые) о Вашем принципе однократного присваивания.

Почему это вдруг always @(posedge clk) обделен (и я считаю абсолютно несправедливо :1111493779: ) дельта-циклами по отношению к initial (который вобще игнорируется при синтезе) а тем более always_ff @(posedge clk). Это вобще возмутительно! (сынок кидает родителя) :)

 

Удачи! Rob.

[Leka 1]

пример выше

В полном соответсвии с Вашими требованиями - однократное присваивание, в процедурном блоке

Просто забыл о блокирующем присваивании в always@(posedge clk), так что уточняю требование - только в always_comb, без @(posedge clk). У меня верилоговский код перед скармливанием Квартусу прогоняется через отдельную программу, которая просто не пропустит блокирующие присваивания триггерам в always@(posedge clk).

always_ff пишу тут для краткости, подразумевая наличие в блоке @(posedge clk).

А под always_comb подразумеваю отсутствие в блоке @(posedge clk) и latch.

 

А с inout такая история.

Код USB-мышки переносил в другой проект, и сунул кусок кода(с 3-мя состояниями) прямо в "чужой" always_comb, не глядя - все-равно потом править и причесывать. И очень удивился, что мышка перестала работать.Тк много лет успешно использую независимость однократных присваиваний от перестановок - сильно упрощает поиск ошибок и модификацию кода.

Теперь знаю, что с 'z такое не прокатит, и обставил эти грабли красными флажками.

Изменено 12 декабря, 2016 пользователем Leka

[Грендайзер 0]

Доброе утро (день, вечер, ночь) коллеги. Продолжаю изучать верилог, и снова выскочило несколько вопросов. Уверен, что подобные вопросы уже поднимались, но найти пока не смог. Итак:

1) Хочу написать простейший генератор синуса. Значения хочу занести в регистр, что бы считывать их от туда в процессе работы. В VHDL я подобное делал следующим образом:

type sin_coeff is array (0 to 99) of integer range -1024 to 1024;
constant coeff : sin_coeff := (0, 64, 128...

Как создать массив в Verilog я понимаю. Но вот как его инициализировать... Где то прочёл, что подобные вещи можно сделать с помощью блока initial, однако в книжках по верилогу везде написано, что этот блок не синтезируем. Как выйти из этой ситуации?

2) Подскажите пожалуйста вопрос по тестбенчу. Допустим мне надо задать входное воздействие для некоторого модуля. И допустим значений этого вектора много. Естественно прописывать все их в файле тестбенча не удобно и я прописываю их в отдельном .txt файле. Чтение я осуществляю с помощью команд $readmemb и $readmemh которые считывают значения входных данных представленных в двоичном и шестнадцатеричном форматах соответственно. А есть ли способ считывать значения представленные в десятичном формате?

[Leka 1]

Как создать массив в Verilog я понимаю. Но вот как его инициализировать...

Проще всего инициализировать упакованные массивы:

reg signed [99:0][11:0] sin_coeff ={ ..., 128, 64, 0};

 

[Грендайзер 0]

Скажите, а "упакованные массивы" обычный верилог поддерживает или это SV?

[Leka 1]

Упакованные массивы, это SV (и самое полезное, что в нем есть).

Если софт позволяет, проще включить поддержку SV, и писать на Верилоге, используя из SV только упакованные массивы.

Упакованные массивы можно передавать через порты, присваивать, и тд.