Jump to content

    
Sign in to follow this  
Leka

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

Recommended Posts

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

Задачку для своих экспериментов я уже подобрал - упрощенный аналог Algodoo (2D физический движок с графическим редактором и тд).

Дано: дешевая ПЛИС уровня Циклона, USB-мышка, VGA-дисплей.

Задача: перенести на эту платформу написанную на Си программу для ПК (3.5ГГц проц) в 2х вариантах:

1) без потери производительности, 2) с 10-кратным ускорением.

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

Знаю, как решить "в лоб", но это муторно и совершенно неинтересно.

Хочется сохранить лаконичность исходного кода на Си. Естественно, без каких-либо софтовых процессоров и тп.

Edited by Leka

Share this post


Link to post
Share on other sites
Задачку для своих экспериментов я уже подобрал - упрощенный аналог Algodoo (2D физический движок с графическим редактором и тд).

Дано: дешевая ПЛИС уровня Циклона, USB-мышка, VGA-дисплей.

Задача: перенести на эту платформу написанную на Си программу для ПК (3.5ГГц проц) в 2х вариантах:

1) без потери производительности, 2) с 10-кратным ускорением.

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

Знаю, как решить "в лоб", но это муторно и совершенно неинтересно.

Хочется сохранить лаконичность исходного кода на Си. Естественно, без каких-либо софтовых процессоров и тп.

можете поделиться С программой, где "Математику специально упростил, убрав деления и кв.корни (точность моделирования проверил, достаточна)."?

Share this post


Link to post
Share on other sites
можете поделиться С программой, где "Математику специально упростил, убрав деления и кв.корни (точность моделирования проверил, достаточна)."?

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

Проверял на изгибе балки под собственным весом, по известной формуле для реального материала (дерево/сталь).

Для таких материалов относительные упругие деформации малы, поэтому формулы упрощаются: 1/(1+x) ~= 1-x, и тд.

 

Share this post


Link to post
Share on other sites
 
Хмм, ровно 5 лет прошло, подниму тему (дело было вечером, делать было нечего - перенес операцию по удалению грыжи, теперь целый месяц нельзя кувыркаться и таскать шпалы).
 
Решил добавить лаконичное обращение к блочной памяти в Верилоговском синтаксисе (лаконичное описание конвейера еще тогда было реализовано).
Верилоговский синтаксис - обязательное требование (семантика м/б совсем другая), исходник сначала проходит стандартный синтаксический анализатор для раннего выявления ошибок (а уже потом препроцессор, реализующий требуемую семантику). 
Такое пришло в голову:
sdp A(разрядность_адреса, разрядность_данных); //синтаксически - некий инстанс, семантически - инстанс Simple DP памяти  
А(выражение_адреса); //в любом месте процедурного блока, синтаксически - task, семантически - запись адреса чтения из памяти
A //в любом месте выражения, семантически - чтение данных из памяти
А(выражение_адреса, выражение_данных); //в любом месте процедурного блока, семантически - запись данных в память
 
Вроде лаконично для Simple DP (но не True DP), может предложит кто другие варианты в синтаксисе SV ?
 
Edited by Leka

Share this post


Link to post
Share on other sites

Вроде придумал. В топ-модуле стандартным образом описываются все инстансы памяти со всеми параметрами и переменными, а в блоке использования памяти делается объявление только для препроцессора, без параметров, например:

sdp A,B,I,K;

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

Share this post


Link to post
Share on other sites

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

Простой пример на Си:

if(run)
	  for(int i=0; i<100; i++)
	    C[i]=A[i]*A[i] + B[i]*B[i];

  

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

simpleDP A, B, C;
	begin
	  pipe [3:0][7:0] i;
	  pipe [3:2][15:0] A2, B2;
	  stage(0, run);
	    i=0;
	  stage(1, i<99);
	    A(i); B(i); i=i+1;
	  stage(2);
	    A2=A*A; B2=B*B;
	  stage(3);
	    C(i, A2+B2);
	  stage();
	end

Весь алгоритм в одном процедурном блоке, синтезируется правильно.

На стандартном Верилоге пришлось-бы разбивать алгоритм на разные always_comb и always_ff, с потерей прозрачности.

Или нет?

Edited by Leka

Share this post


Link to post
Share on other sites
12 часов назад, Leka сказал:

На стандартном Верилоге пришлось-бы разбивать алгоритм на разные always_comb и always_ff, с потерей прозрачности.

Или нет?

В стандартном Верилоге нет никаких always_comb и always_ff.

Share this post


Link to post
Share on other sites
3 hours ago, andrew_b said:

В стандартном Верилоге нет никаких always_comb и always_ff

Понятно же из контекста, что речь о синтезируем подмножестве семейства Verilog/SV, а не конкретной версии языка.

Это общепринятая практика, обозначать все версии языка одним названием:  

https://ru.wikipedia.org/wiki/Verilog

 

Share this post


Link to post
Share on other sites

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

16 hours ago, Leka said:

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

Понятно же из контекста, что речь о синтезируем подмножестве семейства Verilog/SV, а не конкретной версии языка.

Простите, но IMHO тут кроме вас вам никто не поможет. Поскольку придуманная вами надстройка языка наряд ли кому понятна. И она не имеет отношение к Verilog/SV.

 

Удачи! Rob.

Share this post


Link to post
Share on other sites

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

Quote

Перед нами стол. На столе стакан и вилка. Что они делают? Стакан стоит, а вилка лежит. Если мы воткнем вилку в столешницу, вилка будет стоять. Т.е. стоят вертикальные предметы, а лежат горизонтальные? Добавляем на стол тарелку и сковороду. Они вроде как горизонтальные, но на столе стоят. Теперь положим тарелку в сковородку. Там она лежит, а ведь на столе стояла. Может быть, стоят предметы готовые к использованию? Нет, вилка-то готова была, когда лежала. Теперь на стол залезает кошка. Она может стоять, сидеть и лежать. Если в плане стояния и лежания она как-то лезет в логику «вертикальный-горизонтальный» , то сидение - это новое свойство. Сидит она на попе. Теперь на стол села птичка. Она на столе сидит, но сидит на ногах, а не на попе. Хотя вроде бы должна стоять. Но стоять она не может вовсе. Но если мы убьём бедную птичку и сделаем чучело, оно будет на столе стоять. Может показаться, что сидение - атрибут живого, но сапог на ноге тоже сидит, хотя он не живой и не имеет попы. Так что, поди ж пойми, что стоит, что лежит, а что сидит.

 

Share this post


Link to post
Share on other sites

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

57 minutes ago, Leka said:

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

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

 

Те же  HLS трансляторы сейчас вполне успешно справляются (с небольшой помощью разработчика в виде атрибутов синтеза)  с автоматическим разбиением и оптимальным распределением регистров конвейера. Без всяких ручных извращений с синтаксисом :wink2: 

 

Удачи! Rob.

Share this post


Link to post
Share on other sites
1 hour ago, RobFPGA said:

А то что вы делаете IMHO больше похоже не на язык, а на обмазывание кубиков пластилином.

Нет, именно язык, никаких кубиков нет (то, что касается упрощения описания блочной памяти и конвейера, это очень небольшая надстройка, компенсирующая отсутствие соответствующих базовых понятий в Верилоге). 

А язык - Verilog c одним только изменением - тип присваивания определяется не типом операции, а типом переменной.

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

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

Простой пример, стандартный Verilog:

module top(clk, a, b, c);
input clk, a;
output b, c;
var [7:0] a, b;
reg [7:0] c;
always_comb
begin
  b = a;
end
always@(posedge clk)
begin
  c <= a;
end
endmodule
	

и мой:

module top(a, b, c);
input a;
output b, c;
var [7:0] a, b;
reg [7:0] c;
begin
  b = a;
  c = a;
end
endmodule
	

Весь транслятор - менее 300 строк на Паскале.  

В результате исходник дизайна больше похож на программу, а не на описание схемы.

1 hour ago, RobFPGA said:

Проблема лишь  в  качественном, оптимальном и однозначном трансляторе с этих языков в целевой код.

Именно это меня и интересует, а вовсе не "высокоуровневый синтез". 

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

Edited by Leka

Share this post


Link to post
Share on other sites

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

26 minutes ago, Leka said:

Нет, именно язык, никаких кубиков нет (то, что касается упрощения описания блочной памяти и конвейера, это очень небольшая надстройка, компенсирующая отсутствие соответствующих базовых понятий в Верилоге). 

Я  этот ваш подход помню еще сначала темы, поэтому и считаю это "обмазыванием" кубиков из V/SV пластилином. И хоть вам кажется что кубики сами "липнут", но четкости и ясности исходного V/SV уже нет. Зато есть ограничения, неоднозначности, чтение и понимание кода затруднительно, а задача распределения вычисление в конвейер все так же решается руками.   :unknw:

26 minutes ago, Leka said:

Весь транслятор - менее 300 строк на Паскале.  

Зачем? Когда можно взять тот же исходник на C/C++  и без изменений (или минимальными правками) и десятком констрейнов/атрибутов синтеза получить вполне работоспособный код с нужными распределениями в конвейер. 

Я лет 5 назад проводил эксперимент. У меня в дизайне была функция  для расчета неких коэффициентов в выходном массиве из значений нескольких входных  массивов. Изначально она работала в CPU и для ускорения вычислений решил перенести ее в FPGA. Набор стандартных операций типа sin/cos/sqrt/div/log/...  и алгоритм на ~3 десятка строк C кода (float/double fixed/point).  И после того как я за несколько дней синтезировал ее в HSL я попробовал реализовать ее целиком вручную в SV. И мне стоило огромного труда чтобы разложить алгоритм в конвейер хоть как то напоминающий конвейер из HLS. Именно логически разложить, а не описать это в коде SV. Конечно если бы я на все операции ставил независимые отдельные модули вычисления sin/cos/sqrt/div/log/... это было бы немного проще но объем железа был бы в несколько раз больше при лишь незначительном увеличении частоты. Ну а времени это заняло в десяток раз больше чем синтез HLS. 

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

Удачи! Rob.

Share this post


Link to post
Share on other sites
31 minutes ago, RobFPGA said:

Когда можно взять тот же исходник на C/C++  и без изменений (или минимальными правками) и десятком констрейнов/атрибутов синтеза получить вполне работоспособный код с нужными распределениями в конвейер. 

Ну и почему тогда синтез на CPU проводят, а не на FPGA ?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this