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

[Dragon-fly]

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

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

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

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

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

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

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

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

[vetal]

А немогли-бы вы предоставить пример кода на SystemC который легко (студент) может преобразовать в VLOG?

CODE

SC_MODULE(DFF)
{
sc_in<sc_logic> CLK,CLR,CE,D;
sc_inout<sc_logic> Q;
void Register();
SC_CTOR(DFF) {
SC_METHOD(Register)
sensitive << CLK << CLR;
}
};



void DFF::Register()
{
if(sc_logic(CLR) == '0')
{
#ifdef DEBUG
printf("CLK rising edge for DFF\n");
#endif
if(sc_logic(CE) == '1')
{
#ifdef DEBUG
printf("CE active\n");
#endif
Q = D;
}
else {
#ifdef DEBUG
printf("CE inactive\n");
#endif
}
}
else {
#ifdef DEBUG
printf("CLR active - reseting\n");
#endif
Q = sc_logic('0');
}
}

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

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

[yes]

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

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

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

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

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

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

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

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