[_Ivan_ 0]

Добрый день.

 

Требуется совет на следующую задачу.

 

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

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

Для начала мне нужно определиться fixed point или float point арифметику мне использовать. Я изначально выбрал первое, так как если самому все писать с нуля, то очень много времени пройдет.

Потом стал вопрос об ошибке расчета величин из-за погрешности перевода fixed-point из float. Для этих целей я хочу использовать матлаб, чтобы если что в некоторых местах изменять разрядность данных, дабы оптимизировать проект по площади. Допустим я делаю простую модель в симулинке, где есть из источника ramp и она расходится на 2 ветки - double и fixed и умножается на коэффициент усиления. Как мне найти ошибку между результатом double и fixed?

 

[RHnd 0]

Почему нельзя вычесть результат одной ветки из результата другой?

[FatRobot 0]

В симулинке, когда у вас готова fxp-модель, то ее можно преобразовать в flp, а потом обратно, с помощь одного чекбокса в model properties (не помню где, но точно помню, что делал).

 

Далее в симулинке есть Fixed-Point Designer, который по сути будет строить гистограмму распределения порядка значений в указанных точках, с тем, чтобы вы смогли оценить требуемую разрядность fxp числа.

[syoma 1]

В симулинке, когда у вас готова fxp-модель, то ее можно преобразовать в flp, а потом обратно, с помощь одного чекбокса в model properties (не помню где, но точно помню, что делал).

Далее в симулинке есть Fixed-Point Designer, который по сути будет строить гистограмму распределения порядка значений в указанных точках, с тем, чтобы вы смогли оценить требуемую разрядность fxp числа.

Да, только порядок действий наоборот.

С начала надо использовать FPD, чтобы преобразовать FLP в FXP. Причем процес интересно автоматизиуемый - нужно просто задать минимальные и максимальные значения на входе и нужную погрешность на выходе, и он сам рассчитает нужную разрядность всех сигналов.

 

Чекбокс в model properties нужен для того, чтобы модель можно было моделировать тем у кого нету Fixed Point Designer. Ну и помоему она ускоряет моделирование.

 

ПС. Кстати после получения fxp модели уже пол-дела сделано для получения ПЛИСовского кода - достаточно только задержки добавить и HDL Coderу скормить.

 

 

[FatRobot 0]

Переход от FXP обратно к FLP нужен прежде всего для оценки шумов FXP-реализации. А то, что там у кого-то чего-то нет - это вторично.

 

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

 

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

 

Такие дела.

 

нужно просто

[_Ivan_ 0]

RHnd, спасибо, что-то я завис. Можно еще тупо построить 2 графика из командной строки матлаба - с помощью plot & hold on

 

syoma, круто! А минимальные и максимальные значения мы задаем на входе первого элемента схемы или это делается где-то в свойствах системы? А где посмотреть про то, как добавлять задержки?(имеется ввиду ступени конвейера, регистровые). И получается есть какой-то другой способ перегона модели в hdl код, кроме code -> hdl code -> generate hdl? Я еще тут немного поигрался, получается все блоки типа синуса, корня и так далее этот генератор делает как экземпляры, а разработчик уже дальше вставляет свой код ядра для вычисления этих величин?

 

Fat Robot, насчет соизмеримости - мне кажется, что вся эта игра с разрядностями для выбора оптимальной погрешности на выходе все-таки очень сильно облегчается с помощью симулинка... Кучу раз переписывать hdl код и симулировать, прикидывать что да как - реально с ним экономится время...

[FatRobot 0]

Речь шла про hdl-кодер, а не про симулинк в целом. Т.е. обычно делается bit-accurate модель в симулинке, дальше кто-то эту модель описывает на яоа. Далее тестовые векторы, сгенерированные в модели, используются для верификации rtl.

 

Если хочется инноваций, то можно

и HDL Coderу скормить

. Но трудозатраты на подготовку модели для этого будут соизмеримы с описанием на яоа. Ну и конечно получившийся в результате код ни для какой серьезной дальнешей работы (sta, p&r и т.п.) не пригоден.

 

Просыпайтесь!

 

Fat Robot, насчет соизмеримости - мне кажется

[syoma 1]

Если хочется инноваций, то можно и HDL Coderу скормить Но трудозатраты на подготовку модели для этого будут соизмеримы с описанием на яоа. Ну и конечно получившийся в результате код ни для какой серьезной дальнешей работы (sta, p&r и т.п.) не пригоден.

Ваши знания по HDL Coderу, как бы это по мягче сказать, слегка устарели, или Вы так и не поняли как пользоваться данным продуктом.

Мы уже 6 лет пользуемя автоматической генерацией HDL Кода. Прошли и Xilinx System Generator и сейчас юзаем HDL Coder вместе с ним. Трудозатраты несоизмеримые, а главное процесс самого кодинга на ЯОА отсутствует, что позволяет самому разработчику алгоритма без знаний HDL, а только со знанием принципов построения ПЛИСов, разрабатывать, проверять и запускать свои алгоритмы в реальном железе.

Ну а на счет серьезной дальнейшей работы - у нас не студенчиские проекты, а вполне реальные системы управления силовой электроникой на сотни мегават на Virtex-6 с гигабитными трансиверами. И все на матлабе.

Понятно, что если важна сильная оптимизация по ресурсам, то нужен ручной кодинг. Но сами по себе проекты, где используются такие ПЛИС обычно не требовательны к минимальной стоимости чипов - в случае чего берется просто больший чип.

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

Что-то я не помню тут больших обсуждений и тем более такого итога.

 

syoma, круто! А минимальные и максимальные значения мы задаем на входе первого элемента схемы или это делается где-то в свойствах системы? А где посмотреть про то, как добавлять задержки?(имеется ввиду ступени конвейера, регистровые).

Как говорил Fat Robot - это зависит от вашей модели. В случае с обратными связями может придется вводить разрядность вручную. Обычно задается для каждого входа индивидуально. Или создается Харнесс - генераторы сигналов нужной амплитуды, чтобы прогнать модель по всем возможным значениям, тогда FPD сам определит максимумы и минимумы.

По задержкам - можно задать вручную в свойствах блока, можно повставлять Delays. В этом HDL Coder немного проигрывает System Generator, так как в последнем задержки в блоках моделируются, а в HDL Codere нет - т.е. нет cycle true. Но зато в HDL Codere есть прикольная вешь, как автоматическия конвееризация - есть несколько каналов, задаешь задержку и шеринг фактор и оно генерит код, в котором один единственный умножитель апсемплируется и используется для всех каналов. А захотел - сгенерит несколько параллельных умножителей. Или что-то посередине.

И получается есть какой-то другой способ перегона модели в hdl код, кроме code -> hdl code -> generate hdl?

Да этим способам уже скоро десяток лет будет вообще-то. Есть Xilinx System Generator. Для Альтеры есть свой тулбокс. Есть у альтиума помоему что-то. HDL Coder, конечно. Смысл в том, что модель можно перегнать в синтезируемый HDL код по клику мышкой.

Я еще тут немного поигрался, получается все блоки типа синуса, корня и так далее этот генератор делает как экземпляры, а разработчик уже дальше вставляет свой код ядра для вычисления этих величин?

Нет. Для каждого блока генерится свой HDL код, либо используется IP библиотека от нужного производителя, которая выполняет данную функцию. Либо заменяется таблицей в BRAM. Все в зависимости от предпочтений. На выходе Вы получите полностью рабочий HDL код, который скармливаете синтезатору и P&R как он есть. Там уже все будет.

Свой код можно добавить если у Вас уже есть своя реализация какой либо функции на HDL либо вы хотите еще больше оптимизировать.

[FatRobot 0]

То что вы рассказываете, это прекрасно. Выводы для области применения hdl-coder'a, исходя из вашего описания, для меня такие:

- Экспериментальные проекты и/или проекты на несерийное количество устройств.

- Нечувствительность к цене целевой fpga

- Нечувствительность к русурсам (gate count) и потреблению

- Нечувствительность к формальному управлению проектами (невозможность сделать diff, merge и т.п. для simulink-модели) Т.е. проекты скорее всего функционально не нагруженные, коллектив разработчиков невелик, нет разделения по специлизациям.

- Уровень ответственности при разработке функционала FPGA скорее всего невелик.

 

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

 

[syoma 1]

То что вы рассказываете, это прекрасно. Выводы для области применения hdl-coder'a, исходя из вашего описания, для меня такие:

- Экспериментальные проекты и/или проекты на несерийное количество устройств.

- Нечувствительность к цене целевой fpga

- Нечувствительность к русурсам (gate count) и потреблению

- Нечувствительность к формальному управлению проектами (невозможность сделать diff, merge и т.п. для simulink-модели) Т.е. проекты скорее всего функционально не нагруженные, коллектив разработчиков невелик, нет разделения по специлизациям.

- Уровень ответственности при разработке функционала FPGA скорее всего невелик.

Первые три - правильно.

Насчет управления проектами - не совсем - да, коллектив разработчиков небольшой - всего 3 с половиной человека. И да, стараемся не делить по специализациям и каждый делает свой проект. Но SVN и diffы очень даже летают, так как для симулинка уже давно есть тулзы, позволяющие сравнивать все и вся. Плюс - широко используется т.н. Model Referencing, т.е. повторное использование отдельных систем в том случае, если в нескольких проектах используется одна и та же функция. Ну и соответственно все интегрировано с системами управления багами и требованиями - для каждой функции есть требование, по нему разрабатывается модель контроллера и верификацационная модель. Все проверяется. И потом другой человек еще делает верификацию в железе. Все требования трассируются до железа. Ну это упрощенно.

Ну и по последнему требованию - совсем не то. В наших проектах ПЛИСины используется в системах управления реального времени. Баг в софте для такой штуки будет стоить от 100 тыс $ тупо взорвавшегося оборудования. Поэтому все проверяется по десять раз до и после.

 

Но вот насчет понимания, где выгода всего этого - дело в том, что огромное количество ошибок и проблем возникает на этапе кодинга - то баг создал, то вдруг оказывается, что то и то нереализуемо в железе и нужно менять весь алгоритм. Ну а если этот кодер просто уволился после проекта - то можно вешаться. Уборка этого звена в разработке намного уменьшает количество ошибок, обнаруженных на конечных стадиях проекта, которые как известно стоят намного больше, чем в его начале. Опять же портация - мигрирование на следующую ПЛИСину сравнительно простое.

 

ПС. Кстати данный подход еще больше применяется для другой целевой архитектуры - Микропроцессоров и Микроконтроллеров. Си-код генерится только так.

[petrov 6]

А откуда в силовой электронике такие полосы сигналов чтобы virtex 6 требовался для их обработки?

[FatRobot 0]

Т.е. я правильно понимаю, что включение в маршрут разработки hdl-coder'a как-то позволяет обойти аппаратные ограничения целевой платформы?

 

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

[syoma 1]

Т.е. я правильно понимаю, что включение в маршрут разработки hdl-coder'a как-то позволяет обойти аппаратные ограничения целевой платформы?

Не позволяет обойти, а позволяет учесть еще на этапе создания и проверки модели алгоритма. Например ту же фиксированную точку - погрешности, разрядности, шумы квантизации и особенности переполнения можно промоделировать задолго до генерации кода. Точно так же с влиянием задержек и регистров.

И в итоге в конце реально получается, что все алгоритмы, что можно представить средствами симулинка, DSP тулбокса или Stateflow легко превращаются в работающий HDL код.

 

А вот если разработчик напихает for loops или еще чего-то такого, а потом скажет - засунь-ка мне это в ПЛИС, да и еще чтобы тактовая была 400МГц и считало оно мне это все за один такт, и результат - как на бумаге и кодер скажет - нефиг делать, не особо вникая в алгоритм - могут приколы получиться...

[FatRobot 0]

Ясно. Если квалификация инженеров такая, как в этом повествовании, то да. Без робота-кодера никак не обойтись.

 

Успехов.

 

А вот если разработчик напихает ..., а потом скажет ..., и кодер скажет...

 

[_Ivan_ 0]

Я посмотрел вот это видео https://www.mathworks.com/videos/introducin...link-81554.html и вроде разобрался

Получил ошибку в 3*10^-3, что для меня приемлимо при ширине слова в 16 бит.

А есть ли документик, где есть описание всех блоков HDL кодера, а то на сайте матворкса утверждают, что у меня нет на него лицензии :rolleyes:

И все таки интересует реализация синуса и корня у HDL кодера в матлабе - это сделано на кордике и есть прям незашифрованный верилог или вхдл файл для установки экземпляра ядра?