[Des333 0]

module test(
  input   clk_i,
  input   rst_i,
  
  input   sel_i,
  input   data1_i,
  input   data2_i,

  output reg  data_o
);


always_ff @(posedge clk_i, posedge rst_i)
  begin
    case(sel_i)
      1: data_o <= data1_i;
      0: data_o <= data2_i;
    endcase  
  end



endmodule

 

 

 

 

 

Даже варнинга нет.

 

А если case убрать - то ошибку выдает, как и положено.

 

 

[ViKo 1]

Проблема не в case, а в always_ff, чувствительном к двум фронтам одинаково.

Вот так-то работает :)

always_ff @(posedge clk_i)

 

Цитата из IEEE Std 1800-2009 раздел 9.2.2.4

The always_ff procedure imposes the restriction that it contains one and only one event control and no

blocking timing controls.

[des00 25]

Даже варнинга нет.

А если case убрать - то ошибку выдает, как и положено.

это не бага, это фича, если память не изменяет сие было еще в 6ой версии

 

 

Проблема не в case, а в always_ff, чувствительном к двум фронтам одинаково.

фраза в стандарте относилась к другому, в примере des333 все законно

 

[ViKo 1]

фраза в стандарте относилась к другому, в примере des333 все законно

Можете пояснить?

 

upd. Сам проверил. Действительно, для кода

  always_ff @(posedge clk_i, posedge rst_i) begin
    data_o <= data1_i;
  end

варнинг выдается (не ошибка), а для case нет.

[des00 25]

Можете пояснить?

фраза

The always_ff procedure imposes the restriction that it contains one and only one event control and no blocking timing controls.

означает что в блоке always_ff не может использоваться никакой событийный контроль, кроме того что описан в списке чувствительности. Например ничего не мешает написать так (вопрос зачем делать так оставим без ответа)

always @(posedge clk) begin 
    @(posedge pipa);
    popa = #4ns popa_logic;
    bla-bla-bla;
end

SV запрещает подобное, т.к. always_ff это способ описания регистровой логики, введенный в том числе для облегчения жизни всяким линтерам.

 

[Des333 0]

upd. Сам проверил. Действительно, для кода

  always_ff @(posedge clk_i, posedge rst_i) begin
    data_o <= data1_i;
  end

варнинг выдается (не ошибка), а для case нет.

Добавьте if - будет Вам ошибка  :)

 

это не бага, это фича, если память не изменяет сие было еще в 6ой версии

Ну и фича - с if ошибка, с case даже варнинга нет. :)  

 

Чем они вообще руководствовались?

 

 

 

[des00 25]

Чем они вообще руководствовались?

сие нам не ведомо, надо просто помнить про эту фичу %)

 

[sazh 5]

always_ff @(posedge clk_i, posedge rst_i)
  begin
    case(sel_i)
      1: data_o <= data1_i;
      0: data_o <= data2_i;
    endcase  
  end

 

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

И ищем ошибку.

Как это тонко.

 

[Des333 0]

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

И ищем ошибку.

Как это тонко.

 

Я из Вашего поста не понял, это ко мне претензия или к разработчикам?

 

 

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

 

 

[ViKo 1]

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

Поддерживаю. Уже непонятно, в каком из случаев if или case "истина", а где "ложь", с точки зрения разработчиков Quartus. На что ориентироваться? Вот так пропустишь что-нибудь, и не узнаешь...

[des00 25]

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

если есть возможность напишите баг репорт %)

 

[vea 0]

Тема старая, но актуальности не потеряла - в Quartus 11.1sp2 ситуация такая же.

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

always_ff @(posedge clk_i)

и при ипользовании case, и при if всё нормально отрабатывает, триггер на месте, а при

always_ff @(posedge clk_i, posedge rst_i)

либо ошибка (if), либо комбинаторика (case).

Не могу понять, как надо думать?

И следует ли избегать case?