[ElrondTelvanni 0]

Я занимаюсь разработкой различных модулей для ПЛИС, как интерфейсных, так и DSP (цифровые приёмопередатчики, адаптивные системы авторегулировки, модемы для КВ-связи). Сейчас пишу всё исключительно вручную на systemverilog, без использования каких-либо IP-ядер и инструментов высокоуровневого синтеза. Модели предварительно отлаживаю в matlab/simulink. Получается вполне экономично по ресурсам, но очень долго и довольно сложно отлаживать. Сейчас параллельно развиваются всякие тулзы для HLS - matlab HDL coder, altera DSP builder, mentor/calypso catapult-C, Vivado HLS (вряд ли применим к альтеровским ПЛИС). Имеет ли кто-нибудь опыт применения этих систем? Стоит ли изучать эти методы разработки, или лучше потратить это время на совершенствование в разработке RTL-кода?

[iosifk 3]

Я занимаюсь разработкой различных модулей для ПЛИС, как интерфейсных, так и DSP (цифровые приёмопередатчики, адаптивные системы авторегулировки, модемы для КВ-связи). Сейчас пишу всё исключительно вручную на systemverilog, без использования каких-либо IP-ядер и инструментов высокоуровневого синтеза. Модели предварительно отлаживаю в matlab/simulink. Получается вполне экономично по ресурсам, но очень долго и довольно сложно отлаживать. Сейчас параллельно развиваются всякие тулзы для HLS - matlab HDL coder, altera DSP builder, mentor/calypso catapult-C, Vivado HLS (вряд ли применим к альтеровским ПЛИС). Имеет ли кто-нибудь опыт применения этих систем? Стоит ли изучать эти методы разработки, или лучше потратить это время на совершенствование в разработке RTL-кода?

Я слушал семинары Ксайлинкса про HLS...

Такое впечатление, что это хорошо работает для обработки видео, когда каждый клок стробирует принимаемые данные. А если системные клоки отдельно, то тут у них не работает. Скажем так, лектор не смог объяснить, что надо написать в Си, чтобы задействовать En - сигнал разрешения для триггеров....

Хотя возможно за год что-то и поменялось у них...

 

[ElrondTelvanni 0]

iosifk

Ну это всё мелочи и частности, меня в первую очередь интересует личный успешный или наоборот, провальный опыт применения какого-либо подобного инструмента в реальном проекте размером 10-50K LE's.

[litv 0]

Xilinx System Generator -уже 14 лет как стоит.

Matlab HDL CODER - пока нет.

[des00 25]

Получается вполне экономично по ресурсам, но очень долго и довольно сложно отлаживать.

Не могу понять чего там долгого то ? Если работаете давно, то библиотека своих кубиков уже есть, провести работы что бы сделать ее больше reusible. Затем берем симулинк, ставитм co-simulation и отлаживем RTLку по эталону. В железе запускается с полпинка. Например SC модем с нуля скидывается недели за 3, отлаживается еще где то 2-4 недели.

 

Ну а вообще инструменты полезные, но если есть своя библиотека блоков, то не особо нужные.

 

ЗЫ. Хотя судя по темам на форуме, если при слове цифровой фир фильтр испытываете ужас, вместо осознания что это 30 строк кода и 5-10 минут работы, то да. полезный инструмент :)

 

Matlab HDL CODER - пока нет.

между прочим ЕМНИП тулбокс 12к$ стоит :)

 

[RobFPGA 28]

Приветствую!

 

Есть пока небольшой опыт работы в Vivado HLS. Перенос ряда функций обработки данных из С в железо.

В основном математика в float, double. Чипы -Virtex5, Virtex7

В принципе все работает что уже хорошо, НО естественно оптимальность по ресурсам ожидать не приходится.

При этом естественно пришлось потратить прилично времени на эксперименты - что реально получается в железе из того как это написано на C. Тут обеспечена ломка стереотипов и выверт мозгов.

 

Прямой перенос логики работы с RTL (мултиклоки, enable, и.т.д) на С тут как раз вреден - так как наиболее продуктивно получается работать на функциональном уровне, объединяя затем синтезированные с C модули в RTL.

 

Мое мнение - если натаскается то на на сегодня уже вполне рабочая технология для применения (особенно для больших чипов).

 

Успехов! Rob.

 

 

 

[ElrondTelvanni 0]

des00

Кубики самописные разумеется есть, почти на все случаи жизни. Дело-то не в них. Основная проблема - писать FSM, который будет давать задания и забирать результаты у этих кубиков. Иначе говоря - data flow control & resourse sharing. Когда FSM разрастается на 500+ строк кода - это уже получается неповоротливый монстр, который очень трудно поддерживать, отлаживать и тем более что-то менять. По моим представлениям, HLS-тулза должна облегчать жизнь именно путём автоматизации, стандартизации и систематизации при разработке таких FSM.

ЗЫ: цена тулза не имеет значения, мы ведь все знаем, где их можно достать. :)

[des00 25]

Основная проблема - писать FSM, который будет давать задания и забирать результаты у этих кубиков. Иначе говоря - data flow control & resourse sharing. Когда FSM разрастается на 500+ строк кода - это уже получается неповоротливый монстр, который очень трудно поддерживать, отлаживать и тем более что-то менять.

А может лучше религию поменять и не писать таких монстров ? КА не более 10-20 состояний. Если больше, надо либо дробить, либо МПА (микропрограммный), либо софт проц.

ЗЫ: цена тулза не имеет значения, мы ведь все знаем, где их можно достать. :)

Это пока тулза не начала стучать производителю где она запускается и пока производитель серьезно этим не озаботиться (были прецеденты).

 

По моим представлениям, HLS-тулза должна облегчать жизнь именно путём автоматизации, стандартизации и систематизации при разработке таких FSM.

ИМХО там будет банальный AXI-like handshake + перебор состояний. Тот же монстр, но скрытый от вас.

[ElrondTelvanni 0]

des00

На мысли об использовании HLS меня навёл тот факт, что формула из двух строк в матлабе (алгоритм NLMS для системы линеаризации) при реализации в ПЛИС потребовала автомата на ~40 состояний из ~500 строк(это без учёта нескольких специализированных вычислительных модулей) и около трёх месяцев на разработку. Слишком долго и слишком много кода для такой мелкой формулы.

[des00 25]

На мысли об использовании HLS меня навёл тот факт, что формула из двух строк в матлабе (алгоритм NLMS для системы линеаризации) при реализации в ПЛИС потребовала автомата на ~40 состояний из ~500 строк(это без учёта нескольких специализированных вычислительных модулей) и около трёх месяцев на разработку. Слишком долго и слишком много кода для такой мелкой формулы.

Если вы про

y = coe*x;
pow = sum(|x|^2);
err = y - y_ref; 
coe = coe + 2*mu*conj(err)*x/pow;

То, как-то уж шибко долго вы это делали. ИМХО на лицо слабая структурно-функциональная проработка задачи. В свое время NLMS FIR based эквалайзер был написан за 2 дня и отлажен в co-simulation где то за это же время.

[fguy 5]

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

из минусов - все ядро работает в тактах шины управления, получить рабочие такты выше 120 МГц на более менее сложном ядре нереально

[serjj1333 0]

На мысли об использовании HLS меня навёл тот факт, что формула из двух строк в матлабе (алгоритм NLMS для системы линеаризации) при реализации в ПЛИС потребовала автомата на ~40 состояний из ~500 строк(это без учёта нескольких специализированных вычислительных модулей) и около трёх месяцев на разработку. Слишком долго и слишком много кода для такой мелкой формулы.

 

Матлаб он такой, клёвый :rolleyes: там можно и в одну строчку написать такого, что потом год можно в железе запиливать :rolleyes:

 

Ну а так, если вы хотите связываться с HLS, то у вас скорее всего большая ПЛИС, т.к. генерируемые коды не оптимизированны и пожирают ресурсы. А если так, то это пойдёт только на этапе прототипирования, потому что когда посмотрят, куда вы ПЛИС тратите такую толстую и дорогую, вам докинут полосы или каналов и всё придётся переписывать, чтоб уложиться. Если у вас ПЛИС не очень большая, то тогда точно ручками придётся оптимизировать. А если у вас много распределённой арифметики, то, как вам тут уже советуют, стоит посмотреть в сторону софт процессоров или даже SoC.

Изменено 24 июля, 2015 пользователем serjj

[des00 25]

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

из минусов - все ядро работает в тактах шины управления, получить рабочие такты выше 120 МГц на более менее сложном ядре нереально

Если говорить за матлаб, в свое время тестировал, методом анализа генерируемого кода получал соответствие ручному кодированию 5-10% по ресурсу и времянке. Но усилий затратил столько, что руками быстрее бы все написал. Вполне возможно что плавучкой все будет веселее, пока руки не дошли до этого.

[petrov 6]

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

 

Это про получение HDL из симулинк модели?

 

[des00 25]

Это про получение HDL из симулинк модели?

в точку. делал фильтры, ресамплеры на фарроу, эквалайзер, декодер витерби, рида-соломона.

 

Причем был забавный момент : не мог понять почему альтеровский декодер витерби весит 500 плиток, а матлабовский где то 1500 - 2000, расковырял код обоих и выяснил что альтеровский читерил (не искал состояние с минимальной метрикой), а матлабовский делал честно. Когда в альтеровском поставил работать честно, то получил сравнимый результат :)