[Кнкн 5]

Хотелось бы такое только правильно :

 

module dff1 (q, d, clk, load, data);

input d, clk, load, data;

output q;

reg q;

always @(posedge clk or posedge load)

begin

if (load)

begin

q <= data;

end

else

begin

q <= d;

end

end

endmodule

 

Прошу специалистов помочь.

[des00 25]

Хотелось бы такое только правильно :

 

module dff1 (q, d, clk, load, data);

input d, clk, load, data;

output q;

reg q;

    always @(posedge clk or posedge load)

    begin

      if (load)

        begin

          q <= data;

        end

      else

        begin

          q <= d;

        end

    end

endmodule

 

Прошу специалистов помочь.

<{POST_SNAPBACK}>

дык все правильно, что не так то ? :)

[Кнкн 5]

дык все правильно, что не так то ? :)

<{POST_SNAPBACK}>

 

Синтезируется оно конечно правильно.

Однако синтезатор выдает предупреждение

"A Synthesis/Simulanion mismatch is possible"

и его можно понять - если асинхронная загрузка

разрешена и меняются данные на входе, то они

изменяются и на выходе в синтезированной схеме.

(так и должно быть)

Однако в модели они изменяться не должны.

Поэтому и хотелось бы понять, как написать правильно?

[3.14 0]

2 Кнкн

Правильнее не быват, ничего не поделаешь. Хочешь асинхронный регистр - терпи ругань.

[maxus 0]

3.14 прав. Все симуляторы будут ругаться на подобные вещи. А как будет работать в железе - это уже зависит от реализации регистра самой ПЛИС.

[JB_swamp 0]

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

[dxp 34]

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

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

[sazh 3]

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

В данном случае у триггера задействованы входы асинхронной установки и в 0 и в 1. А управляются сигналом data в противофазе. Значит всегда можно нарваться на запрещенное состояние у триггера.

Если посмотреть на мегафункцию регистра, вряд ли у нее найдется два входа по данным. А у примитива триггера Xilinx или асинхронный CLR или асинхронный PRE. Все вместе не видел. Даже не знаю, что синтезатор у Вас наваяет.

В данном случае должен быть синхронный load. Тогда все чисто и прозрачно.

[Кнкн 5]

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

В данном случае у триггера задействованы входы асинхронной установки и в 0 и в 1. А управляются сигналом data в противофазе. Значит всегда можно нарваться на запрещенное состояние у триггера.

Если посмотреть на мегафункцию регистра, вряд ли у нее найдется два входа по данным. А у примитива триггера Xilinx или асинхронный CLR или асинхронный PRE. Все вместе не видел. Даже не знаю, что синтезатор у Вас наваяет.

В данном случае должен быть синхронный load. Тогда все чисто и прозрачно.

 

Это просто пример использования асинхронной начальной

установки в синхронной системе. Синтезируется это

правильно, и такой пример часто встречается в мануалах

на синтезаторы (у synopsys, например) Единственное, что

здесь не особенно хорошо - потенциальное расхождение

между симуляцией исходного текста и нетлиста после

синтеза. Причина - в описании реакция на load - по фронту,

после синтеза - по уровню. Это от того, что в Verilog

в одном always нельзя задать реакцию по фронту для

одного сигнала и по уровню для другого.

Компилятор от Synplicity в хелпе предлагает решить

эту проблему через введение дополнительных переменных,

оно, конечно, не слишком красиво, зато правильно.

[Edashkin 0]

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

   always @(posedge clk or posedge load)
    begin
      if (load)
          q = data;
      else 
          q = d;
    end

[dxp 34]

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

В данном случае у триггера задействованы входы асинхронной установки и в 0 и в 1. А управляются сигналом data в противофазе. Значит всегда можно нарваться на запрещенное состояние у триггера.

Если посмотреть на мегафункцию регистра, вряд ли у нее найдется два входа по данным. А у примитива триггера Xilinx или асинхронный CLR или асинхронный PRE. Все вместе не видел. Даже не знаю, что синтезатор у Вас наваяет.

В данном случае должен быть синхронный load. Тогда все чисто и прозрачно.

Я не сторонник асинхронного дизайна в ПЛИС, и делать асинхронную загрузку в процессе работы никому бы не рекомендовал. Но при начальной инициализации этот подход, имхо, вполне оправдан - сам так всегда делаю. Правда, там у меня значения загрузки обычно определены - 0 либо 1. Главная причина, побуждающая использовать асинхронную установку - разгрузить рабочую логику.

 

Что касается обсуждаемого описания, то все прекрасно синтезируется. Например, на альтеровском Циклоне. См картинку.

 

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

   always @(posedge clk or posedge load)
    begin
      if (load)
          q = data;
      else 
          q = d;
    end

Блокирующее присваивание при описании синхронной логики - bad style. Не надо так делать.

[Кнкн 5]

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

   always @(posedge clk or posedge load)
    begin
      if (load)
          q = data;
      else 
          q = d;
    end

 

Ругается точно также.

[sazh 3]

//Я не сторонник асинхронного дизайна в ПЛИС, и делать асинхронную загрузку в процессе работы никому бы не рекомендовал. Но при начальной инициализации этот подход, имхо, вполне оправдан - сам так всегда делаю. Правда, там у меня значения загрузки обычно определены - 0 либо 1. Главная причина, побуждающая использовать асинхронную установку - разгрузить рабочую логику.

Все правильно. Значения асинхронной загрузки должны быть определены. Либо 0, либо 1. Тогда используется либо CLR, либо PRE.

У меня Quartus тоже синтезирует Выше приведенный текст. Та же схема как и у Вас. О какой разгрузке рабочей логики идет речь? (Дополнительно два элемента 2И).

Вот интересно посмотреть, что бы выдал какой нибудь Спартан.

А то, что схема ущербна, у меня сомнений не вызывает.

[Кнкн 5]

//Я не сторонник асинхронного дизайна в ПЛИС, и делать асинхронную загрузку в процессе работы никому бы не рекомендовал. Но при начальной инициализации этот подход, имхо, вполне оправдан - сам так всегда делаю. Правда, там у меня значения загрузки обычно определены - 0 либо 1. Главная причина, побуждающая использовать асинхронную установку - разгрузить рабочую логику.

Все правильно. Значения асинхронной загрузки должны быть определены. Либо 0, либо 1. Тогда используется либо CLR, либо PRE.

У меня Quartus тоже синтезирует Выше приведенный текст. Та же схема как и у Вас. О какой разгрузке рабочей логики идет речь? (Дополнительно два элемента 2И).

Вот интересно посмотреть, что бы выдал какой нибудь Спартан.

А то, что схема ущербна, у меня сомнений не вызывает.

 

Поймите, пожалуйста, правильно - мой пример не часть реального проекта,

я тоже не люблю асинхронностей и не использую таких штук на практике.

А если действительно нужно что-то подобное, то лучше использовать примитив.

Заданный вопрос это следствие маленького увлечения исследованием

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

одного сигнала по фронту, а другого по уровню?

Вот решение, не вызывающее предостережений компилятора :

 

wire tmp_set = load & data;

wire tmp_rst = load & ~data;

reg q;

always @(posedge clk or posedge tmp_set or posedge tmp_rst )

begin

if (tmp_rst)

q <= 0;

else if (tmp_set)

q <= 1;

else

q <=d;

end

 

Большое спасибо всем за обсуждение.

[dxp 34]

У меня Quartus тоже синтезирует Выше приведенный текст. Та же схема как и у Вас. О какой разгрузке рабочей логики идет речь? (Дополнительно два элемента 2И).

Если загрузка синхронная, то сигнал загрузки пойдет через LUT данной ячейки. При этом оно отъест часть логики. Т.е. если, к примеру, на вход данной ячейки уже приходят 3 сигнала, что вместе с синхронной загрузкой, которая тоже тащит два сигнала, то все это не сможет быть реализовано в одном LUT'е, придется каскадировать, что есть потеря ресурса и быстродействия. И из-за чего? Из-за начальной загрузки, которая на рантайме вообще в статике находится, не шевелится. Поэтому эту загрузку я всегда выношу в асинхронный вариант. Естественно, там все проще, либо 0, либо 1, т.е. одновременно используется либо PRN, либо CLRN триггера.

 

Вот интересно посмотреть, что бы выдал какой нибудь Спартан.

А то, что схема ущербна, у меня сомнений не вызывает.

Примерно так же.

 

Кстати, в обоих случаях Синплифай выдает предупреждение:

 

Register q with async load is being synthesized in compatability mode. A Synthesis/Simulation mismatch is possible.