[Des333 0]

мне тоже кажется что схемы разные. Просто мы видим разные условия формирования выхода о2, по таблице истинности они различны, как может быть одна схема?

 

Да никак не может быть, они разные 100%.

 

Если что-то синтезирует одинаково -- то это бага в синтезаторе.

Вот и хочу узнать, что за САПР, какая версия.

[Mad_kvmg 0]

Да никак не может быть, они разные 100%.

 

Если что-то синтезирует одинаково -- то это бага в синтезаторе.

Вот и хочу узнать, что за САПР, какая версия.

Синтез обеих схем дает :

i1 не подключен,

i2 напрямик на o1,

о2 посажен на gnd.

Проверьте на своих синтезаторах.

 

Это пример, приведенный в контексте, почему рекомендуется при описании комбинаторики не использовать if else,

и почему не только latch, но и разная трактовка X со стороны синтезатора и симулятора причина потенциальных проблем.

 

[Des333 0]

Синтез обеих схем дает :

i1 не подключен,

i2 напрямик на o1,

о2 посажен на gnd.

Проверьте на своих синтезаторах.

 

Мне кажется, Вам нужно нарисовать 2 таблицы истиности.

Думаю, за пару минут Вы поймёте, что не правы.

 

Если на поймёте, то выложите, плиз, Ваши таблицы сюда -- вместе проанализируем.

 

Это пример, приведенный в контексте, почему рекомендуется при описании комбинаторики не использовать if else,

и почему не только latch, но и разная трактовка X со стороны синтезатора и симулятора причина потенциальных проблем.

 

Это пример того, что разные схемы дают разный результат.

[lembrix 0]

Сдается мне, в оригинальном примере где-то присутствовал Х. Но он потерялся, а без него фокуса не получится.

[Mad_kvmg 0]

Сдается мне, в оригинальном примере где-то присутствовал Х. Но он потерялся, а без него фокуса не получится.

Оригинал был таков

module test (
    input  wire i1,
    input  wire i2,
    output reg  o1,
    output reg o2);

always @ (i1 or i2) 
  case ({i1, i2}) 
    2'b00:       o1 = 1'bX;
    2'b01:       o1 = 1'bX;
    2'b10:       o1 = 1'b0; 
    2'b11:       o1 = 1'b1; 
    default:     o1 = 1'bX;
  endcase 

always @ (i2 or o1) 
   if (o1) o2 = 1'b0; 
   else    o2 = i2; 

endmodule

[lembrix 0]

Ну понятно, для симулятора это разные схемы:

(1 | X) = 1,

а (o1==1) = FALSE, при o1 =Х .

 

А для синтезатора X означает, что он может оптимизировать схему как ему надо.

Изменено 18 сентября, 2017 пользователем lembrix

[Mad_kvmg 0]

Мне кажется, Вам нужно нарисовать 2 таблицы истиности.

Думаю, за пару минут Вы поймёте, что не правы.

Если на поймёте, то выложите, плиз, Ваши таблицы сюда -- вместе проанализируем.

Это пример того, что разные схемы дают разный результат.

Да пардон, это я, что то погнал. Конструкция через always не эквивалентна конструкции через assign.

[Des333 0]

Да пардон, это я, что то погнал. Конструкция через always не эквивалентна конструкции через assign.

 

Ничего страшного. Все иногда ошибаются :)

[Mad_kvmg 0]

Ну понятно, для симулятора это разные схемы:

(1 | X) = 1,

а (o1==1) = FALSE, при o1 =Х .

 

А для синтезатора X означает, что он может оптимизировать схему как ему надо.

Поэтому и различный результат моделирования netlis и RTL.

 

 

 

Так все же какова будет схема функционально эквивалентная исходной,

но с одинаковым результатом моделирования RTL и netlist?

[lembrix 0]

Поэтому и различный результат моделирования netlis и RTL.

Результат то различный, но в обоих случаях не неправильный. Что попросили, то и получили. И вывод и этого примера, как по мне,такой, что не надо использовать "Х". А "if else" можно спокойно использовать и для комбинационных схем.

[yes 5]

Позанудствую немного.

В ряде стандартов и рекомендаций говориться, что для описания комбинаторики не стоит использовать if else конструкцию,

либо case, либо через ?. Аргумент такой, что можно получить различный результат моделирования RTL описания и netlist.

Сам, ей Богу, ни разу с таким не сталкивался, но не просто также это рекомендуют...

 

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

 

ну и чтоб два раза не бегать - я за тех кто пишет поведенческие конструкции, а не смесь always c assign, как в добрые 90-е :)

 

[Des333 0]

ну и чтоб два раза не бегать - я за тех кто пишет поведенческие конструкции, а не смесь always c assign, как в добрые 90-е :)

 

А поведенческое -- это always или assign?

[cdg 0]

А поведенческое -- это always или assign?

wait, @, forever ...

P/S/

[Kopart 0]

Позанудствую немного.

В ряде стандартов и рекомендаций говориться, что для описания комбинаторики не стоит использовать if else конструкцию,

либо case, либо через ?. Аргумент такой, что можно получить различный результат моделирования RTL описания и netlist.

Тут все становится понятно и логично, когда с таким столкнешься и поищешь способы исправления "таких различий".

Это из-за специфики нетлиста ASIC и Х-состояния.

 

Здесь описано почему такая рекомендация не позволяет "выстрелить себе в ногу" лишний раз

http://www.verilogpro.com/systemverilog-ve...mism-pessimism/

A different way to address if…else X optimism is with the conditional operator:

condition ? expression_if_true : expression_if_false

 

Но никто не будет всё переписывать только через "condition ?", поэтому в VCS добавлена отдельная опция xprop=tmerge/xmerge.

Она позволяет избавится от различий при симуляции описании содержащих if else. Но есть глюки и заметно снижает скорость симуляции.

Здесь подробнее про нее написано: http://www.verilogpro.com/x-propagation-with-vcs-xprop/