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

[Dragon-fly]

Интересует мнение RTL-щиков, каковым я сам не являюсь.

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

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

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

Вопрос: в какой форме и до какой степени разжеванности хотели бы видеть входные материалы исполнители (те, кто будет кодировать схему на verilog)?

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

В качестве доп. вопросов:
- кому логичнее озаботиться вопросом clock-gating и соответствующей модификацией алгоритмов?
- до какой степени программисты должны дробить код на псевдо-процессы?

Специально обращу внимание, что вопрос не о SystemC, CatapultC, матлабных тулзах и пр..
Речь лишь о золотой референсной модели, но с максимальным приближением к RTL. В какой форме ее лучше всего организовать?

[yes]

универсального метода, то есть гарантировано лучшего решения для всех случаев, нет

по поводу gated-clock заморачиваться не стоит, это умеют делать автоматом тулзы синтеза.
то есть автоматизировано.

по поводу SystemC тоже не стал бы так сразу отметать - это замечательный механизм для ручного перехода от поведенческой модели (С/С++ и т.п.) к синтезируемому коду (RTL)
раньше были даже тулзы для синтеза из SystemC описаний, но увы - злобный бизнес их пожрал (я имею в виду не катапульт и подобные очень умные синтезаторы, которые неизвестно чего насинтезируют, превращая untimed в timed, да и нет у меня практического опыта с ними; а RTL описания на SC)

но даже с тем что есть - с ручным переписыванием SC в VLOG, иметь системсишную модель очень полезную. мы достаточно сложную модель на SC давали [толковому] студенту и его VLOG в успешном тэйпауте пригодился

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

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

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

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

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

--------- UPD ---------

ну советов, имхо, надавали вредных :

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

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

НО !

циклоаккуратность/псевдопроцессы, которые в нормальной терминологии называются RTL (register-tranfer-level) это момент ключевой
то есть должен быть человек, который понимает в чем тут фишка, иначе никакой флоу не поможет
автоматизировать этот процесс, имхо, не удалось - поэтому тут основной момент

как это описывать - вбил в гуголь systemc rtl - сотни тыщь ответов. если перегнать модель в этот RTL вопросов не вызывает, то наверно и проблем с таким flow не будет

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

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