[yes 5]

казалось бы - сгенери нетлист и будет обфусцировано так, что лучше не придумаешь...

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

ну и собственно, synplify не умеет flat hierarchy (или же я не умею его заставить растворить иерархию), при этом внутри нетлиста эти модули (их порты ввода вывода, что не дает скомпилится, да и при одинаковых портах с внутренностями нужно аккуратно) подвергаются оптимизации. то есть тот модуль, который инстанциируется в нетлист будет иметь то же имя, но отличный (редуцированный) набор портов. то есть при попытке вставить модуль из нетлиста в исходник возникает конфликт имен/неправильный список портов. наоборот я не пытался пока еще, слишком много текстовых правок требуется, чтобы вычистить нетлист, ну и с неоптимизированными/висящими портами не нравится оставлять.

когда симплифай оптимизирует модуль под разные инстансы, он его переименовывает, причем я не совсем понимаю механизм - иногда просто добавляет номер, иногда иерархический путь к инстансу (upd - в имя добавляются параметры, счетчик generate и т.д., но это не добавляет мне понимания). при этом конфликтов имен/портов в _одном_ запуске нет

я вижу два варианта - в "промежуточном" нетлисте искать этот модуль, переименовывать его и все ссылки на него. но тут возникает некий не автоматический шаг - таких модулей много (десятки), скрипт сразу не придумывается, то есть ошибки и т.п. другой вариант описать эти модули как black box-ы и генерировать нетлист с ними, но тут может ухудшиться оптимизация

может какие-то еще варианты посоветуете, пока я буду ковырять эти? может как-то можно симплифай заставить скомпилить проект в один module?

 

[Avex 1]

Нетлист, как известно, это не sv, а verilog, причем флатованый с точки зрения параметров, дженерейтов и т.д. При конвертации sv->verilog так же флатуются все многомерные шины/интерфейсы sv, c этим ничего не сделаешь.

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

1. флатовать дизайн, начиная с любого уровня иерархии (ungroup)

2. запретить менять список портов конкретного модуля (no_boundary_optimisation) или модуль целиком (set_dont_touch , preserve)

3. запретить пропагировать константы (1 и 0) через логику и - опционально - через триггеры. Опция опасная, т.к. пропагирование констант часто помогает найти ошибку в коде, поскольку тул просто оптимизирует дизайн в ноль :-) Но сталкивался и с таким, когда пропагировать константы просто нельзя - они нужны для работы.

4. запретить пропагировать инверсии через триггеры

5. запретить удалять ненужные и дублирующие триггеры

6. набор правил для формирования имен иерархических модулей (naming conventions) в случае если есть параметры/дженерейты и т.д. и т.п.

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

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

К сожалению, не видел, как выглядит нетлист после синплифай. После DC это нетлист на примитивах из generic библиотеки DC. А вот у кэденса (genus) есть опция выписывать не нетлист на примитивах, а полноценный верилог - конструкции assign, always и т.д.

[des00 25]

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

[dsl2640free 0]

Verilog Obfuscator:

vo_linux_nov05.tar.gz

[Doka 1]

12 minutes ago, dsl2640free said:

vo_linux_nov05.tar.gz

Verilog-1995 - my favorite kind of HDL

[dsl2640free 0]

Verilog обфускатор посвежее

 

HDLObf-HDLObf_antlr_4_7_1_v0.2.tar.gz

[Doka 1]

@yes

1. какая у Вас целевая платформа? Судя по synplify всёже - FPGA?

2. какой кейс обфусцирования: передача кода заказчику / работа над проектом с субподрядчиком, которому не хочется открывать исходники/etc..

 

[yes 5]

8 minutes ago, Doka said:

@yes

1. какая у Вас целевая платформа? Судя по synplify всёже - FPGA?

2. какой кейс обфусцирования: передача кода заказчику / работа над проектом с субподрядчиком, которому не хочется открывать исходники/etc..

 

xilinx - ise+synplify и vivado (но с вивадой проект проще - можно вообще нетлист дать)

цель скрыть исходники/затруднить клонирование/использование IP

-------------------------

обфускатор я посмотрю, но мне сильно меньше нравится. там и проще восстановить (давно смотрел, может сейчас изменилось), ну и использовать тоже проще. все-таки тут не С, чтобы такими методами дурить...

 

upd: как раз vo_linux_nov05.tar.gz смотрел

[Nick_K 0]

27 minutes ago, yes said:

xilinx - ise+synplify и vivado (но с вивадой проект проще - можно вообще нетлист дать)

Так в ISE можно тоже дать *.ngc файлы и не морочится. Или там обязательно синтезировать с помощью симплифая?

[yes 5]

11 minutes ago, Nick_K said:

Так в ISE можно тоже дать *.ngc файлы и не морочится. Или там обязательно синтезировать с помощью симплифая?

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

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

 

в виде ngc дает Гейслер свой FPU, например, то есть практика известная (для АЗИКов он дает верилог нетлист). но я хочу все-таки с исходниками на верилоге все сделать, чтобы не порождать сложноти сборки и т.п.

 

[yes 5]

сделал так как и предполагал, вопрос переименования модулей/инстансов достаточно легко решился (даже не скрипт, а набор команд в jupiter notebook - может кто умеет, тот и редактором справился бы, но мне было так удобнее)

повезло в том, что не было передачи параметров в те модули, которые обфусцировались, так как параметризированный нетлист синплифай генерить не умеет (так как параметров много, то использовался пакадж с константами - естественно, что после генерации нетлиста менять параметры ip нельзя, но это и не требовалось)

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

---------------

резюмируя: метод работает, но не очень удобно, хотелось бы лучше

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

 

upd: вспомнил syn_dspstyle в синплифае - но уже лень проверять (помню, что это всегда сомнительно работало)

[yes 5]

upd2: посмотрел на обфускатор

(кстати откуда он взялся?

похоже

https://github.com/klyone/HDLObf

а не https://sourceforge.net/projects/hdlobf/

)?

там парсер не умеет в SV - то есть синтаксис не разбирает и большую часть просто передает на выход с ошибками - синтаксис разваливается

поискал BNF для SV - все недоделаное.

лучше этого не нашел

https://github.com/RobertBaruch/SystemVerilogParse

но тоже не закончено (не обманули :) ), подвисает ANTLR - наверно ошибки в BNF

------------------------------

вобщем не советую тратить время - там собственно обфускации на пол-экрана кода (при рабочем парсере, если бы он был), проще на питоне написать :)

On 1/15/2020 at 8:45 AM, Aleх said:

 Все это есть в старших синтезаторах, и, я уверен, есть и в младшем - симплифае. Надо только поискать в документации.

я пропустил пост, потому что как раз с DC, который описываете, нет вопросов. там все это есть. а симплифай развивался не из FPGA DC (не помню как назывался синопсиский старый проект, который умер еще в 2000-х), а независимая конторка, которую Синопсис прикупил где-то как раз в конце 2000-х. там и логика работы совсем не такая как в DC и набор команд другой (доступа к базе данных проекта как в DC вообще нету). у DC насколько я помню, можно было выжимать технолоджи-индепендент - не мапированый на целевую архитектуру и параметризированный, то есть в каких-то пределах принимающий параметры и разные инстансы при мапировании. но не пользовался, просто видел, и Синопсис не рекомендовал его для передачи IP

[RobFPGA 27]

Приветствую!

Вот еще парсер SV. Рядом с ним и linter на его базе есть. 

Удачи! Rob.

[yes 5]

открыл исходник этого парсера и удивился: что же они изверги с С++ сделали в этих новых стандартах :), пока дошло, что это вовсе не С++

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