[Golikov 0]

тогда это какая-то жесткая обманка. Потому что даже симулятор считает что это не так...

 

то есть aload стоит в 1, клока нет, adata меняется и за ней меняется выход?

[SM 13]

Это называется synthesis/simulation mismatch. Вполне себе обычное явление при описании таких вот схемотехнических элементов.

 

Еще раз - учите правила синтеза, синтезируемые конструкции, и во что они синтезируются.

[Golikov 0]

я уже прекратил повторять еще раз...%)

 

но ваще это нечестная наколка, так не должно быть...

 

то есть когда я пишу

 

always @(posedge clk or posedge reset)
begin
   if(reset == 1'b1)
     signal <= init_val;
   else 
     signal <= ~signal;
end

 

то у меня signal будет беситься вслед за init_val, даже без клоков и стабильно reset? хрень какая-то.... хотя наверное это просто заложено в парсер. Что такого рода конструкции синтезить так.

 

а если я хочу чтобы signal менялся вслед за init_val но только по клокам, как это описать? а чтобы при ресете запомнил первое состояние что было по фронту и не менялся более?

[SM 13]

а если я хочу чтобы signal менялся вслед за init_val но только по клокам, как это описать? а чтобы при ресете запомнил первое состояние что было по фронту и не менялся более?

 

Для синтеза - никак. Нет таких схемотехнических элементов-примитивов, которые способны исполнить такое Ваше желание. Повторю в стопятисотый раз - Вы описываете схему, синтезатор ее строит, PAR (place and route) - разводит на конкретный кристалл. Если Вы описываете некий элемент, который физически нельзя синтезировать, он и не будет синтезирован. А как правильно описывать те или иные физически реализуемые блоки - есть документация у синтезатора.

Для моделирования - пожалуйста, нет проблем, например, из разных always пишите в один reg.

[Golikov 0]

понятно...

То есть схема ведет себя так, потому что иначе вести себя не может, уверен что пока%)...

спасибо за легбез

 

 

[SM 13]

То есть схема ведет себя так, потому что иначе вести себя не может

 

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

[Golikov 0]

наверное да, но все бывает....

[topor_topor 0]

тогда это какая-то жесткая обманка. Потому что даже симулятор считает что это не так...

 

то есть aload стоит в 1, клока нет, adata меняется и за ней меняется выход?

http://quartushelp.altera.com/12.1/mergedP..._file_dffea.htm

смотрите таблицу истинности Inputs/Output: aload стоит в 1, клока нет, adata меняется и за ней меняется выход

Если у вас не так - симуляционная модель с ошибкой

 

 

[SM 13]

Если у вас не так - симуляционная модель с ошибкой

 

Тут речь совсем о другом - о том, что симуляция описания высокого уровня (на verilog) при изменении adata не даст измений на выходе (из-за того, что adata нет в списке чувствительности), а при симуляции post-synthesis - даст, так как синтезируется DFFEA. Кстати, VHDL этим не страдает, из-за того, что там if (clk'event) внутри процесса, а adata включено в список чувствительности, в отличие от верилога, где posedge стоит в заголовке процесса (блока always).

[topor_topor 0]

always @(posedge clk or posedge reset)
begin
   if(reset == 1'b1)
     signal <= init_val;
   else 
     signal <= ~signal;
end

 

то у меня signal будет беситься вслед за init_val, даже без клоков и стабильно reset? хрень какая-то....

а если я хочу чтобы signal менялся вслед за init_val но только по клокам, как это описать? а чтобы при ресете запомнил первое состояние что было по фронту и не менялся более?

Никакая ни хрень.

" если я хочу чтобы signal менялся вслед за init_val но только по клокам, как это описать?" - так как и описано.

тут "signal НЕ БУДЕТ беситься вслед за init_val" а только когда posedge clk or posedge reset. Это синхронный тригер с асинхронным ресетом.

 

[SM 13]

Это синхронный тригер с асинхронным ресетом.

Неа :) Если init_val - это явно определенная константа, то да. Если же динамически меняющийся сигнал - то синтезируется именно DFFEA, где reset будет заведен на aload, а init_val на adata, со всеми вытекающими synthesis/simulation mismatch!!!!

[topor_topor 0]

Тут речь совсем о другом - о том, что симуляция описания высокого уровня (на verilog) при изменении adata не даст измений на выходе (из-за того, что adata нет в списке чувствительности), а при симуляции post-synthesis - даст, так как синтезируется DFFEA. Кстати, VHDL этим не страдает, из-за того, что там if (clk'event) внутри процесса, а adata включено в список чувствительности, в отличие от верилога, где posedge стоит в заголовке процесса (блока always).

Хм.... после синтеза мы имеем всего-то нетлист. В симулятор на место DFFEA должна загрузится verilog модель этого компонента.

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

Всё тот-же verilog....

 

--------------------------

module LATCH
(    
   E,           // Enable
   D,           // Input   
   Q           // Out
);

input  E;
input  D;
output Q;

reg  Q;
always @ (D or E)
begin
       // Enable
       if(E)
          Q <= D;
    end
end
endmodule

Не вижу проблем......

[SM 13]

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

Потому, что для синтеза мы ставим конкретную определенную синтезируемую конструкцию, которая по ее определению приводит к синтезу DFFEA. А поведение самого DFFEA (скорее всего) описано уже несинтезируемым primitive (verilog UDP's), такое описание при моделировании уже учитывает все нюансы реальной работы DFFEA.

 

Кстати, это касается только синхронных триггеров с асинхронной загрузкой. Так как чисто латчи мы всегда описываем через always @*, set/reset через загрузку констант, которые по определению меняться не могут, а вот когда гибрид синхронных и асинхронных загрузок, тогда нарываемся на такое.

 

Не вижу проблем......

Так вы от темы то не увиливайте в сторону. Где тут clk? Где тут синхронный data?

 

кстати, можно обойти стороной эту проблему:

wire arst = aload && !data;
wire aset = aload && data;

always @(posedge clk or posedge arst or posedge aset)
if (arst)
  ff <= 1'b0;
else if (aset)
  ff <= 1'b1;
else if (ena)
  ff <= data;

 

Но тут возникает вопрос... Поймет ли синтезатор, что надо применить DFFEA, и его aload/adata? Не факт. Может тупо синтезировать логику на set/reset, как и описано (что может привести к глитчам на них, и соотв. сбоям). Так как рекомендовано то описывать асинхронную загрузку совсем не так.

[topor_topor 0]

Неа :) Если init_val - это явно определенная константа, то да. Если же динамически меняющийся сигнал - то синтезируется именно DFFEA, где reset будет заведен на aload, а init_val на adata, со всеми вытекающими synthesis/simulation mismatch!!!!

Таки да.... если init_val динамически меняющийся сигнал....

Так я и говорю - нефиг мыслить "програмированием на верилоге", надо описывать схему - тогда мысли о таких извращениях в голову и не приходят и думать чё за хрень на віходе тож не приходится...

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

Вот я даж и не обратил внимания что init_val это не 1'b0 :)

 

[SM 13]

Так я и говорю - нефиг мыслить "програмированием на верилоге", надо описывать схему

Я об этом тоже всегда говорю! От этого [почти] все беды, ошибки и тупые вопросы.