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

[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)).
Читать С код (даже детализированный) чтобы что-то понять - тупик.

[Dragon-fly]

Torpeda, спасибо за ответ

5) Что такое "псевдо-процессы" не очень понимаю.

имитация на Си процессов в терминологии VHDL/always в verilog. Только процессы не обязательно разжеванные до манной каши..

Незабудьте указать розрядность и оптимизировать формулу под быстродействие.

да, разумеется. В CatapultC есть шикарный инклудник под это дело. Там все типы от int/uint1 до int/uint63. Те же возможности предоставляются SystemC.

Читать С код (даже детализированный) чтобы что-то понять - тупик.

почему тупик? С Си на асм ведь переводят?
а здесь как бы с Си на verilog.. Не впрямую, но близко к тексту..
и алгоритмы гарантированно отлажены, только не совсем циклоаккуратны в силу недостаточности синтаксиса обычного Си

[Torpeda]

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) Всётаки, посоветую сконцентрироваться на внятно-розжёвано-доходчивом традиционном техническом задании.

[Dragon-fly]

1) "имитация на Си процессов" - ну не знаю - не видал такого.

ну.. после дискуссий, типа вот этой http://electronix.ru/forum/index.php?showt...102338&st=0 не удивляюсь..

по мне, отлаживать псевдо-RTL на Си в сто раз проще, плюс это, как Вы правильно отметили, готовые тестовые среды.

я тоже не в впервые общаюсь с RTL-щиками и вижу, что маршрут проектирования у всех как Бог на душу положит.

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

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

Опыта с CatapultC не имею. Использую только отдельные хэдера из этого пакета.

Немогу оценить простоту трансляции такого С описания в verilog.

По задумке, отличий процессов в обычном Си от них же, написанных на SystemC, всего три:

1) нет явно указываемых портов и списка чувствительности
2) с блоками памяти работаем, как с обычными массивами
3) мультиплексирование сигналов осуществляется "проприетарным" образом
и 4) (опционально) параллельные процессы можно заменить последовательным вызовом при соблюдении тождественности результата (работает для однонаправленных потоков данных)

и как уже сказал, не заморачиваемся на циклоаккуратность..

вижу, с таким маршрутом проектирования никто дел не имел. Странно..

[Torpeda]

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

По задумке, отличий процессов в обычном Си от них же, написанных на SystemC, всего три:

1) нет явно указываемых портов и списка чувствительности
2) с блоками памяти работаем, как с обычными массивами
3) мультиплексирование сигналов осуществляется "проприетарным" образом
и 4) (опционально) параллельные процессы можно заменить последовательным вызовом при соблюдении тождественности результата (работает для однонаправленных потоков данных)

и как уже сказал, не заморачиваемся на циклоаккуратность..

1) "Не бери дурного в голову, а тяжелого в руки" - вот никто и не брал.....

2) Опишите реализацию протокол доступа к асинхронной статической памяти "через обычный масив С" ну или хотя-бы просто тригер....
В RTL, для этого напр. нада кучу тригеров задействовать, а как в С - чесно говоря ума не приложу.

3) "не заморачиваемся на циклоаккуратность."... ну програмисту это может и можно но в RTL....
Это типа летим в соседнюю галактику, не заморачиваясь тем как сделаем антигравитационный двигвтель....