Интересует мнение 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-е" циклоаккуратными схемами не морочатся..

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

по поводу 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х ступенчатый конвейер будет выходить. И хорошо если обратных связей мало, да шаг фиксированный.

Насколько я знаю, последние версии катапульта синтезируют системс в верилог или vhdl.

Дело не в кубической интерполяции или алгоритмах CORDIC.

В оригинале правильно пишут, зачем придумали SystemC:

"Abstract: SystemC® is defined in this standard. SystemC is an ANSI standard C++ class library
for system and hardware design for use by designers and architects who need to address complex
systems that are a hybrid between hardware and software"

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

Чтобы после отладки и кодирования на верилог никаких сюрпризов не было.

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

Основной RTL-щик, с которым взаимодействую, относится к systemC враждебно, говорит, что полноценных синтезов начиная сверху и до самого кремния на этом SystemC по всей Америке дай бог парочка будет. А для понимания исходников слишком дотошное прописывание в СистемСи каждой шины только во вред. То есть он сторонник полуфабриката на обычном Си (со всей документацией есессно).

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





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



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

но тут два момента - на системном уровне нужно понимать эти конвееры/задержки, и упоминавшаяся связь исходник-нетлист