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

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

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

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

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

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

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

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

Бизнес проекты это отдельная тема, и раз у Вас нестыковка, то лучше и не парьтесь: скорее всего это используется для понижения стоимости ваших услуг, в этом случае в ход идут все методы.

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

Я в данном случае от лица программистов спрашиваю.

1) Я вас правильно понял, что у вас фактически есть С модель будущего устройства? Если да - то хорошо, верификаторы такое любят.
Только надо её подключаемой к симулятору сделать.
Verilog напр. может работать напрямую с чистым С. А есчё лутше сразу SystemVerilog референс модель делать.
2) Есть внятное описание - удивительно, но этого может и хватить.
3) Есть сложные циклограммы взаимодействия модулей - нарисуйте их в виде автоматов Мура\Мили - поможет
4) clock-gating в лутшем случае начинается на этапе RTL, а то и бекенда.
5) Что такое "псевдо-процессы" не очень понимаю.
Математику лутше добить до уровня аппаратно реализуемых блочков - сумматоров, умножителей...
Незабудьте указать розрядность и оптимизировать формулу под быстродействие.
Да и simulink модель на таком уровне поможет сильно.
6) Что внутри вашей програмной модели - никого не интересует (см. п.1)).
Читать С код (даже детализированный) чтобы что-то понять - тупик.

Torpeda, спасибо за ответ



имитация на Си процессов в терминологии VHDL/always в verilog. Только процессы не обязательно разжеванные до манной каши..



да, разумеется. В CatapultC есть шикарный инклудник под это дело. Там все типы от int/uint1 до int/uint63. Те же возможности предоставляются SystemC.



почему тупик? С Си на асм ведь переводят?
а здесь как бы с Си на verilog.. Не впрямую, но близко к тексту..
и алгоритмы гарантированно отлажены, только не совсем циклоаккуратны в силу недостаточности синтаксиса обычного Си

1) "имитация на Си процессов" - ну не знаю - не видал такого. Немогу оценить простоту трансляции такого С описания в verilog.

2) Если вы работаете в CatapultC - то типа теоритически он вам должен с математики сгенерить реализабельный verilog насколько я его знаю....
Какраз что вы и хотите - конвертит С в verilog. Ну как минимум для DSP алгоритмов.
Неужели CatapultC не сгенерил RTL ? Поделитесь опитом работы с CatapultC...

3) Си на Асм таки переводят - компилятором......

Не вы первый програмист ум которого бударажит идея типа "конвертации" С в RTL (verilog).
Mentor даже такой (и единственный) конвертер изобрёл - CatapultC.
А практически - такое пока не работает, тем более в общем случае....

4) Всётаки, посоветую сконцентрироваться на внятно-розжёвано-доходчивом традиционном техническом задании.

ну.. после дискуссий, типа вот этой http://electronix.ru/forum/index.php?showt...102338&st=0 не удивляюсь..

по мне, отлаживать псевдо-RTL на Си в сто раз проще, плюс это, как Вы правильно отметили, готовые тестовые среды.

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

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

Интересно, есть ли люди, бравшие за основу специально переработанные исходники на Си? Не может быть, чтобы мировая практика не знала таких примеров.

Опыта с CatapultC не имею. Использую только отдельные хэдера из этого пакета.




По задумке, отличий процессов в обычном Си от них же, написанных на SystemC, всего три:

1) нет явно указываемых портов и списка чувствительности
2) с блоками памяти работаем, как с обычными массивами
3) мультиплексирование сигналов осуществляется "проприетарным" образом
и 4) (опционально) параллельные процессы можно заменить последовательным вызовом при соблюдении тождественности результата (работает для однонаправленных потоков данных)

и как уже сказал, не заморачиваемся на циклоаккуратность..

вижу, с таким маршрутом проектирования никто дел не имел. Странно..

1) "Не бери дурного в голову, а тяжелого в руки" - вот никто и не брал.....

2) Опишите реализацию протокол доступа к асинхронной статической памяти "через обычный масив С" ну или хотя-бы просто тригер....
В RTL, для этого напр. нада кучу тригеров задействовать, а как в С - чесно говоря ума не приложу.

3) "не заморачиваемся на циклоаккуратность."... ну програмисту это может и можно но в RTL....
Это типа летим в соседнюю галактику, не заморачиваясь тем как сделаем антигравитационный двигвтель....

Torpeda, так ведь и в "Word-е" циклоаккуратными схемами не морочатся..

Сообщение отредактировал Dragon-fly - Jul 13 2012, 12:48

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

по поводу 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 не будет

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

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

yes, благодарю за содержательный ответ!

стало быть, если верилогер шарит в СистемСи, ему давать задание в виде готового проекта (помимо документации) самое милое дело?

Очень интересно с практической точки зрения.
А немогли-бы вы предоставить пример кода на SystemC который легко (студент) может преобразовать в VLOG?
Интересна в первую очередь требуемая для этого степень детализации описания цифры...

Писать на таком уровне смысла нет - проще сразу на hdl будет.
Можно попробовать чуть выше - на уровне транзакций, но без понимания общей концепции хорошего мало получится.

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

вобщем так и делали,

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

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

ну а всякие сложности/объяснения в сопроводительной доке - визио

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

SC просто интрумент достаточно широкого применения - от синтезируемой RTL до абстрактных untimed алгоритмов. в какой стадии передавать верилог кодерам зависит от коллектива и задачи

Он для того и создавался - чтобы удовлетворить по максимуму потребности.
Переваривать ТЗ в таком виде сложновато будет для сложной системы. Использовать получится когда в голове будет полная картина - для перепроверки.
Для программиста кубическая интерполяция - просто одна строчка в коде, а на уровне RTL - уже 4х ступенчатый конвейер будет выходить. И хорошо если обратных связей мало, да шаг фиксированный.