[bogaev_roman 0]

Есть кусок следующего кода:

always @(posedge rx_outclock or negedge rx_locked or negedge rst_)
  begin
    if(~rst_)
      begin
        rx_locked_t <= 1'b0;
      end
    else
       begin
        rx_locked_t <= rx_locked;
       end
end

Смущает, что используется два управляющих сигнала rx_locked и negedge rst_. В качестве сброса используется один, а второй поступает на информационный вход, ну а подобных триггеров мне не известно.

Ну и квартус выдает предупреждение:

Critical Warning (10237): Verilog HDL warning at cntrl_.v(168): can't infer register for assignment in edge-triggered always construct because the clock isn't obvious. Generated combinational logic instea

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

Вопрос: насколько критично предупреждение и можно ли подобную конструкцию все-таки реализовать на триггере?

Заранее спасибо.

Изменено 24 мая, 2010 пользователем bogaev_roman

[st232bd 0]

Может проблемма не в Verilog, а в кристалле, который вы используете. У него нет тригеров с тремя входами синхронизации, вот и ругается, что уложить не может, только как комбинаионную схему.

Изменено 24 мая, 2010 пользователем st232bd

[masics 0]

по-моему, это ошибка предыдущего разработчика. На всякий случай, если можете, посмотрите какая была реализация в оригинальном проекте (и предупреждение, если было). Но, я думаю, можно убрать "negedge rx_locked" и получить FF в чистом виде.

[glock17 0]

Смущает, что используется два управляющих сигнала rx_locked и negedge rst_. В качестве сброса используется один, а второй поступает на информационный вход, ну а подобных триггеров мне не известно.

 

По-хорошему так, как описано в коде, вообще не делается. Если сигнал rx_locked - асинхронный, то его нужно сначала синхронизировать с rx_outclock:

 

reg rx_locked_a, rx_locked_s;

always @(posedge rx_outclock) rx_locked_a <= rx_locked;
always @(posedge rx_outclock) rx_locked_s <= rx_locked_a;

 

а затем сделать примерно так:

 

always @(posedge rx_outclock or negedge rst_)
begin
    if(!rst_) rx_locked_t <= 1'b0;
    else    rx_locked_t <= rx_locked_s;
end

[des00 25]

negedge rx_locked

вот это выкидывай, явно ошибка разработчика, а не заметил он ее при отладке потому, что варнинги синтезатора не читал, а код потенциально рабочий, выстрелит раз в пятилетку, да и то на глюк спишут %)

[sazh 3]

Смущает, что используется два управляющих сигнала rx_locked и negedge rst_.

 

Скорее всего он хотел aclr по negedge rx_locked

 

always @(posedge rx_outclock or negedge rx_locked or negedge rst_)
if(~rst_)                    rx_locked_t <= 1'b0;
else if(~rx_locked )    rx_locked_t <= 1'b0;
else                          rx_locked_t <= rx_locked;

[bogaev_roman 0]

Всем Всем спасибо за советы, действительно сигнал negedge rx_locked там ни к чему, так и сказал, что варнигни не читал и просто ошибся :)

[Des333 0]

вот это выкидывай, явно ошибка разработчика, а не заметил он ее при отладке потому, что варнинги синтезатора не читал, а код потенциально рабочий, выстрелит раз в пятилетку, да и то на глюк спишут %)

 

Почему потенциально рабочий?

 

Там же вообще триггера не будет. Или Вы думаете, что автор кода его и не хотел?

[des00 25]

Почему потенциально рабочий? Там же вообще триггера не будет. Или Вы думаете, что автор кода его и не хотел?

Хоть и не телепат, но мне кажется что этот триггер и был синхронизатором, а потом этот сигнал locked шел на какой нить статусный регистр, читаемый раз в пятилетку в еще один регистр какого нибудь проца. Метастабильность проц даже не увидит, а выстрелить такой код сможет только в случае когда кто нить повесит на него прерывание по фронту и будет долго ковырять почему схема при определенном положении звезд дает сбои %)

[bogaev_roman 0]

Хоть и не телепат, но мне кажется что этот триггер и был синхронизатором, а потом этот сигнал locked шел на какой нит статусный регистр

Именно так оно и было :)

[Des333 0]

Хоть и не телепат...

Именно так оно и было :)

 

Все-таки, телепат!  :)

[aprox 0]

Там же вообще триггера не будет. Или Вы думаете, что автор кода его и не хотел?

Вот вам и verilog! В AHDL таких глупостей в принципе не бывает.

[Des333 0]

Вот вам и verilog! В AHDL таких глупостей в принципе не бывает.

 

А вы с C знакомы?

 

Там вообще если написать

if( var = 5)

...

Будет не сравнение, а присвоение.

Ужасно тупой язык! В ассемблере такого нет!

[bogaev_roman 0]

Вот вам и verilog! В AHDL таких глупостей в принципе не бывает.

Это не верилог такой, это разработчик такой. Может человек просто описался. :laughing:

[ViKo 1]

Просто логически неправильно подавать один и тот же сигнал rx_locked и на тактовый вход триггера, и на вход данных.

В AHDL "такую глупость" тоже никто не мешает сделать :)