Leka 0 22 декабря, 2016 Опубликовано 22 декабря, 2016 (изменено) · Жалоба Вот Вы и берете уже готовое, наглядное и прозрачное описание алгоритма и синтезируете его для более эффективного исполнения на конкретной аппаратной платформе. В чем же тупик? Задачку для своих экспериментов я уже подобрал - упрощенный аналог Algodoo (2D физический движок с графическим редактором и тд). Дано: дешевая ПЛИС уровня Циклона, USB-мышка, VGA-дисплей. Задача: перенести на эту платформу написанную на Си программу для ПК (3.5ГГц проц) в 2х вариантах: 1) без потери производительности, 2) с 10-кратным ускорением. Математику специально упростил, убрав деления и кв.корни (точность моделирования проверил, достаточна). Знаю, как решить "в лоб", но это муторно и совершенно неинтересно. Хочется сохранить лаконичность исходного кода на Си. Естественно, без каких-либо софтовых процессоров и тп. Изменено 22 декабря, 2016 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maverick_ 15 22 декабря, 2016 Опубликовано 22 декабря, 2016 · Жалоба Задачку для своих экспериментов я уже подобрал - упрощенный аналог Algodoo (2D физический движок с графическим редактором и тд). Дано: дешевая ПЛИС уровня Циклона, USB-мышка, VGA-дисплей. Задача: перенести на эту платформу написанную на Си программу для ПК (3.5ГГц проц) в 2х вариантах: 1) без потери производительности, 2) с 10-кратным ускорением. Математику специально упростил, убрав деления и кв.корни (точность моделирования проверил, достаточна). Знаю, как решить "в лоб", но это муторно и совершенно неинтересно. Хочется сохранить лаконичность исходного кода на Си. Естественно, без каких-либо софтовых процессоров и тп. можете поделиться С программой, где "Математику специально упростил, убрав деления и кв.корни (точность моделирования проверил, достаточна)."? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 22 декабря, 2016 Опубликовано 22 декабря, 2016 · Жалоба можете поделиться С программой, где "Математику специально упростил, убрав деления и кв.корни (точность моделирования проверил, достаточна)."? Планирую выложить, но не сейчас. У меня физика упруго деформируемых тел (из "атомов", связанных "пружинками"). Проверял на изгибе балки под собственным весом, по известной формуле для реального материала (дерево/сталь). Для таких материалов относительные упругие деформации малы, поэтому формулы упрощаются: 1/(1+x) ~= 1-x, и тд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 3 ноября, 2021 Опубликовано 3 ноября, 2021 (изменено) · Жалоба Хмм, ровно 5 лет прошло, подниму тему (дело было вечером, делать было нечего - перенес операцию по удалению грыжи, теперь целый месяц нельзя кувыркаться и таскать шпалы). Решил добавить лаконичное обращение к блочной памяти в Верилоговском синтаксисе (лаконичное описание конвейера еще тогда было реализовано). Верилоговский синтаксис - обязательное требование (семантика м/б совсем другая), исходник сначала проходит стандартный синтаксический анализатор для раннего выявления ошибок (а уже потом препроцессор, реализующий требуемую семантику). Такое пришло в голову: sdp A(разрядность_адреса, разрядность_данных); //синтаксически - некий инстанс, семантически - инстанс Simple DP памяти А(выражение_адреса); //в любом месте процедурного блока, синтаксически - task, семантически - запись адреса чтения из памяти A //в любом месте выражения, семантически - чтение данных из памяти А(выражение_адреса, выражение_данных); //в любом месте процедурного блока, семантически - запись данных в память Вроде лаконично для Simple DP (но не True DP), может предложит кто другие варианты в синтаксисе SV ? Изменено 3 ноября, 2021 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 5 ноября, 2021 Опубликовано 5 ноября, 2021 · Жалоба Вроде придумал. В топ-модуле стандартным образом описываются все инстансы памяти со всеми параметрами и переменными, а в блоке использования памяти делается объявление только для препроцессора, без параметров, например: sdp A,B,I,K; Тк все переменные адресов/данных внешние, то препроцессору знать их разрядности не нужно, а в выходном файле такой строчки уже не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 7 ноября, 2021 Опубликовано 7 ноября, 2021 (изменено) · Жалоба Я так давно пишу на своем языке, что привык и думать на нем над любой задачкой, сложнее мигания светодиодом. И сейчас только дошло, что со стороны м/б непонятно, как в одном процедурном блоке можно присваивать и регистровым, и внешним нерегистровым переменным (например, адресный порт блочной памяти). Простой пример на Си: 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 16 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 12 часов назад, Leka сказал: На стандартном Верилоге пришлось-бы разбивать алгоритм на разные always_comb и always_ff, с потерей прозрачности. Или нет? В стандартном Верилоге нет никаких always_comb и always_ff. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 3 hours ago, andrew_b said: В стандартном Верилоге нет никаких always_comb и always_ff Понятно же из контекста, что речь о синтезируем подмножестве семейства Verilog/SV, а не конкретной версии языка. Это общепринятая практика, обозначать все версии языка одним названием: https://ru.wikipedia.org/wiki/Verilog Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба Приветствую! 16 hours ago, Leka said: Я так давно пишу на своем языке, что привык и думать на нем над любой задачкой, сложнее мигания светодиодом. И сейчас только дошло, что со стороны м/б непонятно, как в одном процедурном блоке можно присваивать и регистровым, и внешним нерегистровым переменным (например, адресный порт блочной памяти). Понятно же из контекста, что речь о синтезируем подмножестве семейства Verilog/SV, а не конкретной версии языка. Простите, но IMHO тут кроме вас вам никто не поможет. Поскольку придуманная вами надстройка языка наряд ли кому понятна. И она не имеет отношение к Verilog/SV. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 1 hour ago, RobFPGA said: никто не поможет Жаль. Написание Algodoo на HDL откладывается на следующий Большой взрыв. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба В долгосрочной перспективе язык описания алгоритмов важнее готовых кубиков. Quote Перед нами стол. На столе стакан и вилка. Что они делают? Стакан стоит, а вилка лежит. Если мы воткнем вилку в столешницу, вилка будет стоять. Т.е. стоят вертикальные предметы, а лежат горизонтальные? Добавляем на стол тарелку и сковороду. Они вроде как горизонтальные, но на столе стоят. Теперь положим тарелку в сковородку. Там она лежит, а ведь на столе стояла. Может быть, стоят предметы готовые к использованию? Нет, вилка-то готова была, когда лежала. Теперь на стол залезает кошка. Она может стоять, сидеть и лежать. Если в плане стояния и лежания она как-то лезет в логику «вертикальный-горизонтальный» , то сидение - это новое свойство. Сидит она на попе. Теперь на стол села птичка. Она на столе сидит, но сидит на ногах, а не на попе. Хотя вроде бы должна стоять. Но стоять она не может вовсе. Но если мы убьём бедную птичку и сделаем чучело, оно будет на столе стоять. Может показаться, что сидение - атрибут живого, но сапог на ноге тоже сидит, хотя он не живой и не имеет попы. Так что, поди ж пойми, что стоит, что лежит, а что сидит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба Приветствую! 57 minutes ago, Leka said: В долгосрочной перспективе язык описания алгоритмов важнее готовых кубиков. Высокоуровневых языков описания алгоритмов вагон и маленькая тележка. Начиная с естественных (пойди туда не знаю куда ...) и кончая всякими UML. Проблема лишь в качественном, оптимальном и однозначном трансляторе с этих языков в целевой код. А то что вы делаете IMHO больше похоже не на язык, а на обмазывание кубиков пластилином. Соответственно кубики вроде и липнут но получаются кривые и косые и плохо стыкуются. Те же HLS трансляторы сейчас вполне успешно справляются (с небольшой помощью разработчика в виде атрибутов синтеза) с автоматическим разбиением и оптимальным распределением регистров конвейера. Без всяких ручных извращений с синтаксисом Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 (изменено) · Жалоба 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 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба Приветствую! 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 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 31 minutes ago, RobFPGA said: Когда можно взять тот же исходник на C/C++ и без изменений (или минимальными правками) и десятком констрейнов/атрибутов синтеза получить вполне работоспособный код с нужными распределениями в конвейер. Ну и почему тогда синтез на CPU проводят, а не на FPGA ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться