Перейти к содержанию

    

Verilog + modelsim. Несколько драйверов у сигнала

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
15 часов назад, Aleх сказал:

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

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

Просто я обычно пишу на 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 переучиться... Тем более давно хотел изучить т.к там много инструментария для написания тестов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
9 часов назад, AVR сказал:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 hours ago, Aleх said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, DimaG said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, hdl_student said:

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

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

Quote

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
6 hours ago, DimaG said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти