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

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

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

Сообщение отредактировал Fitc - May 29 2015, 18:05

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

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

Кстати, я в стандарте 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. Извлекать оттуда описание селлов неудобно, а откуда еще можно выдрать эти описания я не нашел.

Сообщение отредактировал Fitc - Jun 1 2015, 17:51

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

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


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


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


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