[Leka 1]

Как красиво/лаконично описывать конвейеры на HDL ?

Пусть для конкретики есть следующий кусочек алгоритма на Си:

for(k=0; k<n; k++) {
    i=I[k]; j=J[k];
    a=A[i];
    a=a-A[j];
    b=a*a;
    b=b-c;
    b=b*a;
    B[i]=B[i]-b;
    B[j]=B[j]+b;
}

A[ ] и B[ ] - блочная simple dual port ram, д/б 2 такта на каждую итерацию цикла.

Алгоритм не непрерывный, д/б корректное заполнение/опустошение конвейера с флагами запуска/останова.

Таких "кусочков" м/б много, и самых разных, ищется общий лаконичный стиль описания (даже не обязательно на HDL).

Изменено 3 ноября, 2016 пользователем Leka

[Shivers 0]

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

А пишут кто как: кто то разделяет куски кода разных стадий комментариями, а кто то пишет в одну кучу.

[Leka 1]

Из того что я видел, самое полезное - добавлять номер стадии в качестве индекса в название каждой переменной.

Код для симуляции (нестрогий, без указания разрядности и тп), для синтеза блочная память д/б в отдельном модуле):

always@(posedge clk)begin
  
  s<={s,0}; k<={k,0}; i<={i,0}; j<={j,0}; a<={a,0}; b<={b,0}; 
  Bwe=0;
  
  if(s[0])begin Ira=k[0]; Jra=k[0]; end
  if(s[1])begin i[2]<=Ird; j[2]<=Jrd; if(k[1]<n)begin k[0]<=k[1]+1; s[0]<=1; end end
  if(s[2])begin Ara=i[2]; end
  if(s[3])begin Ara=j[3]; a[4]<=Ard; end
  if(s[4])begin a[5]<=a[4]-Ard; end
  if(s[5])begin b[6]<=a[5]*a[5]; end
  if(s[6])begin b[7]<=b[6]-c; end
  if(s[7])begin b[8]<=b[7]*a[7]; Bra=i[7]; end
  if(s[8])begin Bwe=1; Bwa=i[8]; Bwd=Brd-b[8]; Bra=j[8]; end
  if(s[9])begin Bwe=1; Bwa=j[9]; Bwd=Brd+b[9]; end  
  
  Ird<=I[Ira];
  Jrd<=J[Jra];
  Ard<=A[Ara];
  if(Bwe)B[Bwa]=Bwd;
  Brd<=B[Bra];

end

Так примерно ?

 

По симуляции вроде то, что надо (но код обращения к блочной памяти нелаконичен).

Изменено 3 ноября, 2016 пользователем Leka

[aser 0]

Похоже, вопрос не как лаконично, а как правильно.

Как правильно - здесь: http://www.emodel.org.ua/images/em/36-6/Sergienko.pdf

[_sda 0]

Спасибо, давно информацию по этой теме искал.

 

[Leka 1]

Похоже, вопрос не как лаконично, а как правильно.

Лично меня интересует именно как лаконично.

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

Например, для умножения в синтезируемом HDL существует "прозрачное" синтезируемое описание: "a=b*c",

а для более сложных операций (или, допустим, для обращения к блочной памяти) - уже нет.

 

Изменено 20 ноября, 2016 пользователем Leka

[Leka 1]

Для ЯВУ придуманы специальные операторы, упрощающие описание часто встречающихся вспомогательных алгоритмов.

Например операторы цикла: for(), while(), и тп.

В результате общее описание алгоритма становится более наглядным/прозрачным.

 

Для HDL ничего такого не вижу (операторы цикла тут имеют совсем другой смысл).

Не туда смотрю? Есть какие ключевые слова для поиска в инете?

Много написано только про FSM, хотя основная обработка ведется в вычислительных конвейерах.

 

[xvr 12]

Для HDL ничего такого не вижу (операторы цикла тут имеют совсем другой смысл).

Не туда смотрю?

Не на те языки

Есть какие ключевые слова для поиска в инете?

Есть. HLS (high level synthesis), Bluespec SystemVerilog, VivadoHLS, Catapult-C

https://en.wikipedia.org/wiki/High-level_synthesis

 

 

[Leka 1]

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

В С/С++/etc. таких понятий не вижу, в рекламных материалах по HLS тоже.

https://www.moya-planeta.ru/travel/view/kak...inu_mira_14613/

 

[xvr 12]

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

Зависят от языка, с которого синтезируют. В основном это С, и 'базовые понятия' совпадают с таковыми в С (по сути производится синтез с обычной программы на С)

У Bluespec SV база другая (лучше почитать его описание - в двух словах не расскажешь). Но он включает базовые понятия С как подмножество

 

[Leka 1]

Под базовыми понятиями подразумеваю объективные понятия, зависящие от аппаратуры (в данном случае - ПЛИС), но не от выбранного языка описания. Для низкоуровневого синтеза таких базовых понятий немного: 1) комбинационная логика, 2) триггер, 3) синхронный дизайн. Для высокоуровневого синтеза нужны свои объективные понятия, и это не IP-блоки и прочие "кубики". Аппаратура накладывает серьезные ограничения на реализацию произвольного алгоритма (типа, один трамвай не может в маршруте обогнать другой). Базовые понятия как раз и должны задавать эти рамки, которые 1) обеспечат эффективную реализацию описанного алгортима, 2) сделают описание максимально удобным/прозрачным. Полагаю, это д/б связано прежде всего с конвейерами (см пример с трамваем), тк это основной способ организации параллельных вычислений в ПЛИС. В С/С++/и тп нет ровным счетом ничего, что можно было-бы отнести к таким(объективным) высокоуровневым базовым понятиям (тк ЯВУ создавались с оглядкой на процессоры). Есть только низкоуровневая комбинационная логика.

[xvr 12]

HSL, транслирующие с языка С, реализуют на аппаратуре виртуальную С машину и укладывают на нее вашу программу. Так что их базовые понятия совпадают с С. Это последовательное (логически) выполнение логических и арифметических операций и операции передачи управления (циклы и условные). Понятия подлежащей аппаратуры полность скрыты.

1) обеспечат эффективную реализацию описанного алгортима,

Такой задачи не ставилось

2) сделают описание максимально удобным/прозрачным.

А вот это обеспечивается путем отказа от п1 :)

 

Что касается Bluespec SV, то у него есть свои собственные базовые понятия, см http://wiki.bluespec.com/

 

[RobFPGA 35]

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

 

...обеспечат эффективную реализацию описанного алгортима, 2)...

Понятие "эффективно" относительно. Должна быть база относительно которой меряется эта "эффективность". Можно придумать десяток критериев эффективность/оптимальности часто взаимоисключающих друг друга.

 

В С/С++/etc. таких понятий не вижу, в рекламных материалах по HLS тоже.

..

Под базовыми понятиями подразумеваю объективные понятия, зависящие от аппаратуры (в данном случае - ПЛИС), но не от выбранного языка описания. Для низкоуровневого синтеза таких базовых понятий немного: 1) комбинационная логика, 2) триггер, 3) синхронный дизайн. Для высокоуровневого синтеза нужны свои объективные понятия, и это не IP-блоки и прочие "кубики".

Как то не вяжется - на то он и высокоуровневый синтез что как раз и оперирует "блоками" и "кубиками" которые заранее реализованы для выбранной архитектуры и критериев оптимизации. Иначе такой синтез может и не закончится никогда.

 

Использование HLS синтеза с голого С/С++ как раз и делается для того чтобы увеличить ЭФФЕКТИВНОСТЬ ;) использования существующей кодовой базы. А если этого мало то просмотрите SystemC - там как раз добавили такие "объективные понятия".

 

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

Еще и как может! Вы наверное не видели трамвайные одноколейки на которых десяток трамваев курсировали в обе стороны :maniac:

Аппаратура лишь накладывает физические ограничения со знанием которых можно выбрать способ оптимально реализовать ЛЮБОЙ (почти) алгоритм.

 

Просто нужно хотеть не "все и сразу" а чуть более конкретно и по частям :)

 

Успехов! Rob.

 

[Leka 1]

Понятие "эффективно" относительно. Должна быть база относительно которой меряется эта "эффективность".

Относительно низкоуровневого ручного кодирования.

Как то не вяжется - на то он и высокоуровневый синтез что как раз и оперирует "блоками" и "кубиками" которые заранее реализованы для выбранной архитектуры и критериев оптимизации.

SV/VHDL избавляют от необходимости описывать комбинационную логику на базе LUT, но требуют полного описания всех регистров.

От этой рутины (необходимости описывать все вспомогательные регистры и их связи) и надо избавляться.

А готовые IP-блоки между собой соединять, это и в низкоуровневом дизайне можно.

Использование HLS синтеза с голого С/С++ как раз и делается для того чтобы увеличить ЭФФЕКТИВНОСТЬ ;) использования существующей кодовой базы.

Тупиковое направление, имхо. Программы на С/С++ описывают не сам алгоритм, а способ его реализации в процессорной системе.

Чтобы HLS синтез с голого ЯВУ(для процессоров) имел перспективы, надо научиться эффективно решать обратную задачу в общем виде - восстановление собственно алгоритма по его частной реализации - привет "индусам" и всяким там модным парадигмам программирования.

Изменено 21 декабря, 2016 пользователем Leka

[RobFPGA 35]

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

Относительно низкоуровневого ручного кодирования.

Тогда делайте синтез в Matlab - очень эффективное описание алгоритмов. Или Python - модный тренд. Только вот эффективность по объему и скорости полученного дизайна под вопросом.

Ну или наймите индусов - тогда вообще описание алгоритма можно будет делать на естественном языке с матерными констрэйнами :) ( а тут финансовая эффективность может пострадать)

 

Тупиковое направление, имхо. Программы на С/С++ описывают не сам алгоритм, а способ его реализации в процессорной системе.

Чтобы HLS синтез с голого ЯВУ(для процессоров) имел перспективы, надо научиться эффективно решать обратную задачу в общем виде - восстановление собственно алгоритма по его частной реализации - привет "индусам" и всяким там модным парадигмам программирования.

...Не видел но точно знаю!...

Лет 10 назад когда это направление начало активно развивается попробовав пару раз использовать Catapult я тоже так думал. А сейчас использую возможность для синтеза с C/C++ в своих проектах Vivado постоянно. Для определенных задач получается очень эффективно (а иногда и очень ЭФФЕКТНО когда за пару часов выкатываешь заказчику рабочую в FPGA демку его алгоритма )

...Для ЯВУ придуманы специальные операторы, упрощающие описание часто встречающихся вспомогательных алгоритмов.

Например операторы цикла: for(), while(), и тп. В результате общее описание алгоритма становится более наглядным/прозрачным....

Вот Вы и берете уже готовое, наглядное и прозрачное описание алгоритма и синтезируете его для более эффективного исполнения на конкретной аппаратной платформе. В чем же тупик?

 

Удачи! Rob.