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

[Dragon-fly]

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

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

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

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

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

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

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

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

[Torpeda]

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

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

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

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

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