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

[Dragon-fly]

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

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

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

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

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

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

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

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

[vetal]

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

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

[Dragon-fly]

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

Дело не в кубической интерполяции или алгоритмах 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 по всей Америке дай бог парочка будет. А для понимания исходников слишком дотошное прописывание в СистемСи каждой шины только во вред. То есть он сторонник полуфабриката на обычном Си (со всей документацией есессно).

Сообщение отредактировал Dragon-fly - Jul 20 2012, 10:06