[Leka 1]

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

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

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

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

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

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

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

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

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

[Maverick_ 15]

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

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

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

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

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

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

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

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

[Leka 1]

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

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

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

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

 

[Leka 1]

 

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

 

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

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

Такое пришло в голову:

sdp A(разрядность_адреса, разрядность_данных); //синтаксически - некий инстанс, семантически - инстанс Simple DP памяти  

А(выражение_адреса); //в любом месте процедурного блока, синтаксически - task, семантически - запись адреса чтения из памяти

A //в любом месте выражения, семантически - чтение данных из памяти

А(выражение_адреса, выражение_данных); //в любом месте процедурного блока, семантически - запись данных в память

 

Вроде лаконично для Simple DP (но не True DP), может предложит кто другие варианты в синтаксисе SV ?

 

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

[Leka 1]

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

sdp A,B,I,K;

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

[Leka 1]

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

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

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, с потерей прозрачности.

Или нет?

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

[andrew_b 17]

12 часов назад, Leka сказал:

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

Или нет?

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

[Leka 1]

3 hours ago, andrew_b said:

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

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

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

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

 

[RobFPGA 35]

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

16 hours ago, Leka said:

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

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

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

 

Удачи! Rob.

[Leka 1]

1 hour ago, RobFPGA said:

никто не поможет

Жаль. Написание Algodoo на HDL откладывается на следующий Большой взрыв.

[Leka 1]

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

Quote

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

 

[RobFPGA 35]

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

57 minutes ago, Leka said:

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

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

 

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

 

Удачи! Rob.

[Leka 1]

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, чтобы облегчить написание сложных алгоритмов. 

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

[RobFPGA 35]

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

26 minutes ago, Leka said:

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

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

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.

[Leka 1]

31 minutes ago, RobFPGA said:

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

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