Jump to content

    

вопрос обфускации верилог кода (SV)

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

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

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

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

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

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

 

Share this post


Link to post
Share on other sites

Нетлист, как известно, это не 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 и т.д.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
12 minutes ago, dsl2640free said:

vo_linux_nov05.tar.gz

Verilog-1995 - my favorite kind of HDL :crazy:

Share this post


Link to post
Share on other sites

@yes

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

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

 

Share this post


Link to post
Share on other sites
8 minutes ago, Doka said:

@yes

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

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

 

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
27 minutes ago, yes said:

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

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

Share this post


Link to post
Share on other sites
11 minutes ago, Nick_K said:

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

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

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

 

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

 

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this