Добрый день,
Кто-нибудь встречал парсер языка verilog (в частности verilog-netlist)?
Желательно open-source на Си/Си++

Посмотрите открытые проекты.
Например Icarus Verilog, Verilator, Odin II, Verilog-to-Routing (VTR), ABC (университет беркли занимается).
У всех есть чтение из верилог файлов, соответственно и парсер должен быть.

Спасибо, за ответ.
Да, я тоже об этом думал. В частности смотрел в сторону Verilator, но судя по комментариям у них на форуме, чтобы извлечь парсер из симулятора и сделать его удобным для работы нужно "попотеть". Этот вариант я не отрицаю, но может есть уже готовые парсеры на си/си++?

распарсить верилог - относительно несложно.
вопрос в другом - какова конечная цель этого процесса.
вы ведь так и не указали её.

Зачем изобретать велосипед?
Конечная цель - возможность менять/генерировать код.

Кстати, я в стандарте verilog не нашёл описания подмножества netlist-конструкций языка.
Кто-нибудь знает какой-нибудь документ, который регламентирует, что должно быть в netlist?

т.е. вам нужно неким образом обрабатывать синтезируемое подмножество конструкций verilog-а
верно?

нет, что должно быть после синтеза: verilog-netlist

то, что после синтеза, обычно называют gate-level netlist.
часто используют verilog-perl
но посмотрите до кучи
https://github.com/cliffordwolf/yosys

Я кстати слышал про yosys (используется в edaplayground.com), правда не знаю проще ли будет из него вытащить парсер, чем из verilator.

Есть ли в каких-нибудь стандартах описание gate-level netlist на яызке verilog? Что примечательно, на edif стандарт есть.

А вы видели своими глазами гейт-нетлист?
Трудно придумать что то проще.
Но формально, это верилог, поэтому и описывается стандартом верилог.

Если хотите сделать что то свое, я бы посоветовал почитать описание классов verilog-perl. Там очень доходчиво все обясняется - что есть и для чего использутся. Учитывая популярность (люди реально это используют) verilog-perl, если сможете повторить все их классы - точно не прогадаете.

Я тоже заинтересован в Сишных библиотеках для нетлист-парсера, но ничего дельного найти не смог.

p.s. более того, я уже поднимал этот вопрос на форуме. Помнится, SM присоветовал обратить внимание на ruby-gem.
Нашел эту тему: http://electronix.ru/forum/index.php?showtopic=126074

видел, но хотел бы знать формальные требования.
хотелось бы видеть что-то типа стандарта IEEE Std 1364.1™-2002, где прописано синтезируемое подмножество verilog.
Иначе получается, что хочу, то пишу в netlist.


ruby жеж тоже интерпретируемый язык?
К тому же нет желания изучать для себя новые языки.
Пока Verilator более интересен тем, что написан на С++ и что поддерживает systemverilog, т.е. есть куда расти в случае чего.

Ваш интерес стандартом показывает, что с нетлистом вы толком не работали. Тогда зачем это все, какова цель? Что хотитет получить в итоге?

Гейт-нетлист, это исключительно иерархический верилог, содержащий обявление проводов и подключение ими модулей. Есть конструкции ассайн (в т.ч. на 1 и 0). И все, больше ничего нет, поскольку нижний уровень - несинтезируемые модели элементов, т.е. библиотека. Даже инверсий нет. Еще раз - почитайте описание классов Verilog-perl, сразу станет ясно, с чем имеют дело при парсинге нетлиста. Отдельный стандарт вы не найдете, имхо

с нетлистом, действительно особо не работал. Хотя и был небольшой опыт разбора verilog, используя индусскую библиотеку на java (фиговая).
Вот Вы говорите, что нет инверсий, есть провода и подключение ими модулей - это мне понятно, так как всё отображается на экземпляры селлов.
А почему установка в 1 и 0 делается ассайнами, а не селлами?
Ещё некоторые синтез-щие компиляторы вставляют перед селлами атрибуты, например, yosys вставляет имя исходного файла и номер строки в этом файле, которому соответствует селл.
Т.е. парсер возможно должен уметь обрабатывать атрибуты.

А вы не собирали базу селлов производителей?
В каком формате они обычно хранятся?
Взять например, altera - у них есть библиотека симуляции селлов на верилог и других HDL. Извлекать оттуда описание селлов неудобно, а откуда еще можно выдрать эти описания я не нашел.

Дико любопытно, а зачем это все надо? Не слишком ли фундоментально подходите?

присвоения - имеют физический смысл в виде соединения двух проводников при помощи транзистора.
в случае 0 или 1 это тоже самое - соединение нужного проводника с проводником VCC или с проводником GND - также при помощи транзистора.


у ячейки могут быть различные конфигурации, которые легко, кратко и ясно описываются одним аттрибутом с человекочитаемым именем, но "в железе" выбираются соединением десятка, сотни а то и двух сотен проводников с выбором 0-1 по каждому.


если вы про ту что для синтеза - то это у всех производителей считается закрытой информацией. В абстрактном виде - да, вам какую-то условную блок-схему покажут, но в реальности у какого-нибудь LUT от ПЛИС есть не просто 4 входа, а ещё два десятка конфигурационных соединений, программирующих этот LUT.
для проведения симуляции они не нужны, и пользователю ПЛИС про них знать вообще не надо. А вот для расчета таймингов во время Place & Route - нужны, ну и для получения окончательной прошивки конечно же.


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

Работа с нетлистом подразумевает разработку для ASIC. А для асика используются в 99% (для РФ) синтезатор DC или RC, либо экстракция из IC или Энкаунтера. А они не выписывают никаких атрибутов, хоть и имеют собственные (настраиваемые) шаблонные правила для выписки названий селлов в нетлисте. Установки в 1 и 0 выписываются ассайнами, либо отдельным Tie селлами -и так и так, надо все уметь делать.

Про Альтеру сразу забудьте, там совсем другая жизнь. И библиотека в общем случае не нужна. Просто потому, что она в формате Liberty, и в формате верилога для моделирования (таблицы), которые упаришься парсить. Так что плагин-библиотеку для парсера Вам придется писать самому - под каждую конкретную библиотеку, с которой будете работать. Так проще всего. Если очень горит пощупать руками - гугл, либо добейте 50 постов и поищите на местном фтп (нужен доступ в 'свои'). Чтонибудь да найдете.
Лично я делал в виде плагина - для каждой либы создал подключаемый файл с таблицей из названия селлов, и их функции.

И все же интересно - у Вас конкретная задача, или просто любопытство?
Под большую часть задач уже что то написано, так или иначе. Верилог парсят уже 20 лет как :-)

или с бмк и структурированными асиками =)

2 TC У альтеры есть университетская программа (QUIP). Там в документации есть описание синтаксиса vqm файлов. Это внутренний формат, промежуточный между map и fit.
VQM_reference

Тем временем прошло 2 года с того момента, как я задал вопрос на этом форуме... Я написал парсер нетлистов и функционал по его обработке за последние несколько месяцев. И хотел бы поделиться опытом. К сожалению выложить парсер не могу (т.к. права принадлежат работе) и рассказать зачем он нужен тоже. Это был очень интересный для меня опыт разработки.
Разработка самого парсера оказалась самой простой задачей. Самое сложное для меня было разработать структуры, которые хранят информацию о нетлисте, и функции, которые в дальнейшем обрабатывают нетлист. Сложность также была из-за того, что я старался разработать структуры, которые в будущем можно было бы использовать для хранения информации о более сложных конструкциях verilog.
Для разработки парсера использовались следующие средства: flex, bison, c++.
Итак, если кто-нибудь захочет написать verilog-парсер вот несколько советов:
1) В стандарте верилог очень хорошо описан формальный синтаксис в виде БНФ, который практически в готовом виде копируется (с небольшими доработками) во flex и bison файлы. Только нужно удалить неиспользуемые конструкции (как в моем случае мне нужно было только подмножество для описания нетлиста). Так как bison генерирует LR-парсеры, представленную в стандарте грамматику БНФ нет необходимости дорабатывать.
2) flex и bison поставляются с очень хорошими мануалами. Их надо прочесть в первую очередь. Кроме того мне очень помогла книжка "Ахо А.-Компиляторы_ принципы, технологии и инструментарий". В ней можно найти описание структур и описание процесса генерации кода. Читать следует java-версию книжки. Описаные принципы подходят и для с++ программ. Также парсер можно написать полностью на java, спасибо bison-у, который поддерживает язык Java. Я выбрал C++, т.к. считаю его более универсальным и прозводительным.
3) Читайте код открытых проектов verilator и yosys. Оттуда можно почерпнуть многие идеи. На изучение кода данных проектов может уйти уйма времени. Для меня было проще написать свой парсер, чем разобраться как все устроено в данных проектах, т.к. кода в них очень много, комментариев практически нет, код читабельностью не блещет. Я потратил небольшое время на изучение кода и некоторые идеи из данных проектов мне показались очень полезными. Кстати, оба проекта также используют flex и bison.

Что касается нетлиста, если он получен с помощью DC, готовтесь к разбору следующих конструкций: не-ANSI заголовок модуля, сам модуль, экземпляры модулей, конкатенации, assign, объявления скалярных и векторные wire и портов, escaped идентификаторы, ссылки на диапазон линий портов и wire и т.д. Если нетлист получен с помощью Precision, все может быть сложнее. Кроме того нужно взять откуда-нибудь описание элементов. Например, мой парсер выдает ошибку, если встречает неизвестный элемент или неизвестный порт элемента. Информацию об элементах можнно взять, например, из Liberty файла, или библиотеки элементов моделирования ПЛИС или ASIC, или создать свой файл с описанием и т.д.
Если у кого-нибудь возникли вопросы, могу попытаться на них ответить.

Достаточно редкая задача, написание такого парсера. Зачем он может быть нужен простому смертному, кроме создания обфускатора (деобфускатора) - мыслей нет.
Хотя еще конкретно по verilog/vhdl плохо обстоят дела с автоматическими форматировщиками исходных текстов (beautifier).

Вы себе не представляете, сколько у меня мыслей как использовать данный парсер. Например, вынести какую-нибудь линию одного из внутренних иерархических элементов в порт модуля верхнего уровня для анализа сигналов данной линии с помощью осциллографа. Возможность автоматической модификации нетлиста открывает большие возможности.

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

В Воронеже пошли по пути задействования Quartus для парсинга, подмосковный Миландр задействовали Yosis. У меня теплится надежда, что Ваш работодатель в тайне пилит российскую ПЛИС
Хотя быть может оба примера не подходят, им ведь главное не парсинг для анализа, а передача дальше по цепочке своих САПР...

Не угадали, у меня задача была совсем другая, не берите в голову. Я сам был бы рад, если бы с российскими ПЛИС и их средами разработки было бы все хорошо и с удовольствием поучаствовал бы в создании какой-нибудь российской САПР. Потому что сейчас приходится работать с БМК, для которых софт не очень. В настоящее время должны допиливать ковчег. Вообще, я слышал многие САПР синтеза и моделирования используют библиотеку verific (QuestaSim, VCS, Design Compiler, RTL Compiler, Synplify, and Precision) для парсинга SystemVerilog. Возможно нашим мешают санкции купить данную библиотеку, а возможно новый ковчег как раз будет ее и использовать. Конечно, парсер это только часть задачи, есть еще куча других задач, но начать с чего-то надо. Кстати, когда тестил свой парсер, хотел синтезнуть сдвигающий регист, состоящий из более 100000 триггеров. DC и Precision не справились с задачей, просто вылетали с ошибкой. Так что у них там тоже не все так хорошо на больших проектах. Моя программа хоть и не синтезирует код, но нетлисты такого размера и более обрабатывает, хотя памяти жрет дофига, поэтому есть желание использовать базу данных для хранения информации о нетлисте.

Спасибо за отзыв, очень любопытно!

По собственному опыту (я писал парсер для сильного видоизменения нетлиста на Verilog-Perl) советую потестить с разными версиями DC/RC/Genus. Даже в DC от релиза к релизу бывают изменения. К примеру, я сталкивался с тем, что в DC одной версии к каждому неиспользуемому порту подключается *LOGIC0*, а в другой версии заводится цепь с assign XXX=0; , а потом уже эта цепь заводится на все порты. В общем, бывают всякие чудеса, надо хорошенько все тестить.
На Verilog-Perl я проблем почти не имел, поскольку библиотека отлажена уже много лет. Но зато и код не защитить, не скомпилировать в бинарник. Т.е. я понимаю, почему Вы затеяли писать все с нуля.

Про Liberty - удивлен что используете. Зачем это Вам? А если уж решили все проверять, то и LEF грузите - бывает что нетлист выгружен с ключем physical, когда и цепи питания и аналог выписываются - их в Liberty может и не быть, зато в LEF присутствуют обязательно.

Мое личное мнение, что без SV для ПЛИС можно прожить. Ему самое место в вышеперечисленном софте моделирования, а то что ПЛИС будут поддерживать лишь Verilog то это не беда.

Пока протестил с DC 2013 и 2016, проблем не обнаружил, но конечно тесты нужны получше. Как появится возможность, проверю с RC/Genus.
При необходимости расширения Verilog-Perl возможно могли возникнуть проблемы с их лицензией. Также это довольно сложный проект, который тащит за собой много функционала, который мне не нужен. Отсутствие опыта разработки парсеров также затрудняло понимание кода, сейчас стало гораздо проще.
Мне нужна лишь небольшая информация из Liberty файлов, а до уровня LEF я не доходил, так как такой задачи не было.


У нас многие RTL-щики на verilog плюются, разбаловались SV, но согласен, если была бы поддержка хотя бы verilog было бы уже хорошо.



Под необходимостью расширения Verilog-Perl я имел ввиду их ядро парсера, которое написано на C++ с применением flex и bison (судя по содержимому git-репозитория Verilog-Perl). Причем похоже, что flex и bison файлы полностью взяты из verilator-а.

Здравствуйте, я честно говоря, не совсем уверена не фотоп ли, но мне попалась под руку эта ветка и я смело спрошу у вас. Как можно перевести Verilog в форму логической схемы как в Ковчеге? Оставить в Veriloge не вариант, т.к. я пишу диплом и руководитель скорее всего захочет большую и красивую логическую схему. Открытые проекты, которые нашла в интернете в основном в формате кода, по крайней мере форматы схем мне ещё не встретились. Извините если вопрос глупый, я если честно пока плохо понимаю во что ввязалась. Надеюсь что вы мне ответите и заранее спасибо. ^_^

Вам также, как представляет свой код ТС в этой ветке, нужно?

Как вариант сделать синтез в ISE / Quartus. САПР сам соберет схему.

В целом да, мне нужна логическая схема на уровне триггеров и базовых элиментов вроде инверторов и разного рода исключающих или. Короче я картинку сделала того что есть в его библиотеках.


Спасибо, ушла гуглить.

Если Вы действительно хотите помощи, лучше озвучьте задание полностью. Тут могут дать действительно хорошие советы !

Только лучше в другой теме.

О каком "ковчеге" идет речь?

САПР "КОВЧЕГ"