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

[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

[yes]

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

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

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

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

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

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

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