[Flip-fl0p 4]

Приветствую уважаемые посетители форума. Решил изучить verilog(SystemVerilog)  на уровне большем чем "читаю и плачу". Написал простенький проектик, запустил проверку синтаксиса в modelsim. И с ужасом обнаружил у себя ошибку. И ужаснулся я не от того, что у меня ошибка ( в конце концов я не волшебник, а только учусь). А ужаснулся я от того, что у меня один сигнал имел несколько драйверов, и modelsim даже не пискнул об этом, гад такой. В vhdl можно было применить unresolved тип, и горя не знать. Хотя в последнее время, применение любого типа, отличного от std_logic_vector - это потенциальные проблемы, т.к почти все, сгенерированное vivado, понимает только этот гадский тип, посему всю красоту строгой типизации в vhdl можно даже и не пытаться применять,

т.к написание " прокладок" занимает неадекватно много времени... Так, вот если по теме: как такие ошибки(несколько драйверов у сигнала) обнаружить в verilog, ну или на худой конец как заставить modelsim истошно вопить об этом ?

P.S. За орфографию сильно не ругайте, тыкаю одним пальцем в телефон, трясясь в автобусе...

[Darky777 0]

Из-за подобных случаев перешел на QuestaSim. В нем много инструментария, но мне он нравится потому, что он дотошнее проверяет проект и соответственно чаще ругается. 

[Flip-fl0p 4]

Я на работе попросил коллегу проверить в questasim код, где несколько драйверов у сигнала. Результат получился аналогичный. Может где в файлике modelsim.ini надо подкрутить настройку, для более параноидальной проверки синтаксиса ?

[one_eight_seven 3]

Насколько помню, ошибкой это считают синтезаторы, симуляторы же просто показывают X, но не ругаются.

[Flip-fl0p 4]

Тоже возникло такое ощущение. Т.к quartus или vivada - показывают такие ошибки. Однако в modelsim гораздо проще проверять синтаксис, поскольку тот-же vivado эти ошибки проверяет на стадии синтеза. Но синтез у него непозволительно долгий ( от 2 минут), что очень неудобно.

[des00 25]

вы бы это, стандарт бы прочитали, что ли) читается за пару дней, с кружкой чая как художественная литература. Тогда бы не было подобных вопросов: wire vs logic, always vs always_ff/always_latch/always_comb

Изучать методом научного тыка, оно похвально, у вас есть время, силы и желание на исследования. Но куда проще, сразу узнать причину, прочитав стандарт)

ЗЫ. Обьем стандарта пугать не должен, т.к. там много кода в примерах. И качество подачи материала в стандрате SV-2007 (~1500 станиц)  на голову выше чем в том же  VHDL 93(~200 страниц). Читается легко)

ЗЗЫ. Более того. В шапке подфорума форума, есть перевод стандарта на русский. Спасибо за это активным энтузиастам форума, они молодцы

[Avex 1]

Много драйверов одной цепи - не ошибка, такое делают, к примеру, в тристейт-шинах. Тулы синтеза обычно выдают ворнинг на такие цепи, а симулятор показывает то, что подсовывают модели: к примеру, логический ноль, единицу, третье состояние, или подтяжку (если есть в модели), либо - Х если один драйвер с нулем а второй с единицей. ПЛИС обычно не имеют внутри тристейт-драйверов, поэтому почти всегда выдаст ошибку синтеза. Другими словами, если Вы допустили ошибку, но имеете тесты со 100% покрытием, то в этой цепи в одном из тестов будет Х, ошибка ловится. Либо, проще, попробовать засунуть в ПЛИС.

[Flip-fl0p 4]

15 часов назад, Aleх сказал:

Много драйверов одной цепи - не ошибка, такое делают, к примеру, в тристейт-шинах. Тулы синтеза обычно выдают ворнинг на такие цепи, а симулятор показывает то, что подсовывают модели: к примеру, логический ноль, единицу, третье состояние, или подтяжку (если есть в модели), либо - Х если один драйвер с нулем а второй с единицей. ПЛИС обычно не имеют внутри тристейт-драйверов, поэтому почти всегда выдаст ошибку синтеза. Другими словами, если Вы допустили ошибку, но имеете тесты со 100% покрытием, то в этой цепи в одном из тестов будет Х, ошибка ловится. Либо, проще, попробовать засунуть в ПЛИС.

Так это понятно и так 

Просто я обычно пишу на VHDL и там есть тип resolved, т.е. тип при котором у сигнала может быть несколько драйверов, и результат определяется специальной функцией разрешения. Но также есть типы unresolved (std_ulogic, bit) где функция разрешения не определена, и сигнал не может иметь несколько драйверов. Соответственно применяя типы std_ulogic, bit у меня в любой программе (Questasim, Modelsim, Quartus, Vivado и пр..) будет ошибка на стадии проверки синтаксиса. Думал в Verilog/SystemVerilog есть встроенный механизм защиты от таких ошибок. Пойду читать стандарт на  SystemVerilog. Может чего интересного прочитаю.

P.S. А причиной почему я хочу освоить Verilog стало то, что единственный тип в VHDL, который поддерживается генератором IP ядер в Vivado - это std_logic/std_logic_vector. Более того если я создам какой-то свой модуль и вытащу его на блок дизайн, то vivado для моего блока создаст "прокладку" где единственным типом будет std_logic/std_logic_vector. Хотя в моем модуле совершенно другие типы. И из-за этого будет куча ошибок, например при запуске Modelsim. А писать дополнительно "прокладку" для вивадовской "прокладки" - есть занятие глупое и бессмысленное. В общем поддержка VHDL в Vivado (Да и в Quartus не особо лучше) сделана крайне убого, поскольку главная фишка языка - строгая типизация.

Проще на Verilog переучиться... Тем более давно хотел изучить т.к там много инструментария для написания тестов.

[1891ВМ12Я 0]

Действительно Modelsim не выдает на это ошибку, но на правах предположения, наверняка можно включить некую опцию, чтобы подобная проверка осуществлялась.

 

Я искренне люблю Verilog и не замечаю в нем его несовершенства, но подобная ошибка multiple drivers очень редко возникает, и очень редко когда может потратить максимум час на поиск причины проблем. Так что я бы не пытался искать такие ошибки.

[Avex 1]

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

И в очень редких случаях малтидрайв действительно нужен. К примеру, мультиплексор 32х1 гораздо быстрее работает на трибуфах, чем с полным дешифратором состояний на комбинационной логике. Или, иногда блоки памяти имеют тристейт выходы (тот же мультиплексор). Это очень не рядовые ситуации.

[iosifk 3]

9 часов назад, AVR сказал:

но подобная ошибка multiple drivers очень редко возникает, 

Давайте проведем эксперимент.

Я думаю, что дело происходит так. Есть например контроллер SPI и у него есть триггер готовности на передачу. Так вот, скорее всего, сделано так. В одном процессе - в передаче данных, триггер взводится по окончании передачи. А в другом процессе - в чтении готовности на передачу - триггер явно сбрасывается. Причем в обеих кусках текста написано явно "триггер" <= 0 или "триггер" <= 1. Соответственно получаем ошибку. А теперь попробуем изменить описание. Отдельно описываем триггер, и у него должны быть входы РАЗРЕШЕНИЯ установки в 0 и в 1. А в двух описанных выше кусках кода вместо явного обращения к триггеру, пишем активизацию сигналов РАЗРЕШЕНИЯ. И на этом проблема будет закрыта.  

[DimaG 0]

20 hours ago, Aleх said:

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

И в очень редких случаях малтидрайв действительно нужен. К примеру, мультиплексор 32х1 гораздо быстрее работает на трибуфах, чем с полным дешифратором состояний на комбинационной логике. Или, иногда блоки памяти имеют тристейт выходы (тот же мультиплексор). Это очень не рядовые ситуации.

Подскажите, о какой ПЛИС идет речь? Насколько я знаю, tristate buf обычно только в IO пинах есть. Те реализовать мультиплексор на tristate buf внутри FPGA в принципе нельзя..

[hdl_student 0]

1 hour ago, DimaG said:

Подскажите, о какой ПЛИС идет речь? Насколько я знаю, tristate buf обычно только в IO пинах есть. Те реализовать мультиплексор на tristate buf внутри FPGA в принципе нельзя..

Синтезатор имитирует tristate buf с помощью обычного мультиплексора с условием. Коллега имел в виду, что конкретный мультиплексор на tristate buf описать проще и нагляднее.

[DimaG 0]

1 hour ago, hdl_student said:

Синтезатор имитирует tristate buf с помощью обычного мультиплексора с условием. Коллега имел в виду, что конкретный мультиплексор на tristate buf описать проще и нагляднее.

Да, я понимаю, что tristate внутри FPGA так или иначе выльются в мультиплексоры. Просто заинтересовала фраза: 

Quote

мультиплексор 32х1 гораздо быстрее работает на трибуфах, чем с полным дешифратором состояний на комбинационной логике

думал, может что упустил..

[likeasm 0]

6 hours ago, DimaG said:

Да, я понимаю, что tristate внутри FPGA так или иначе выльются в мультиплексоры. Просто заинтересовала фраза: 

думал, может что упустил..

Если заняться археологией, то было такое, например, в XC4000, назывался BUFE.