Написал простую функцию, расчет положения при падении объекта в воздухе. На вход подаются текущие координаты (in_x, in_y), текущая скорость (in_spdx, in_spdy), масса объекта(mass), коэффициенты для горизонтального/вертикального сопротивления воздуха (R_x, R_y) и частота дискретизации (sample_time).
Сначала вычисляю конечные составляющие скорости: вертикальную составляющую с учетом силы тяжести и коэффициента сопротивления воздуха, и вертикальную просто с учетом коэффициента сопротивления воздуха.
Потом вычисляю координаты, при этом беру скорость как среднее арифметическое от начальной/конечной скоростей.
Это для понимания ситуации, код MATLAB привожу ниже:



Соответственно, тестовое окружение для него работает следующим образом. Беру большие массивы нулей, даю в первом значении начальные условия, задаю коэффициенты и массу, и последовательно забиваю массивы числами пока объект не достигнет земли (т.е. пока текущая координата y(i) не станет отрицательной или равной нулю) либо пока не кончится массив. Код ниже, содержит два теста:



Теперь собственно описание проблемы:
Попытка сгенерировать для этого кода вариант с фиксированной точкой приводит к следующей ошибке:
-------------- output variable : out_x --------------
Matrix dimensions must agree.
При этом графики строятся, но на них показан бред - объект вместо того, чтобы плавно падать, стремительно взлетает ввысь. Моделирование исходного кода заканчивается успешно и без ошибок/предупреждений.
Еще выяснилось, что:
Деление пополам (при вычислении среднего арифметического) кодер заменяет на смещение на разряд, при этом благополучно игнорируя знаковость. А поскольку для вертикальной координаты делимое, как правило, отрицательно - ясно почему взлетает объект.
Также выяснилось, что масса благополучно округляется с единицы на ноль, в результате чего моделирование готового fixed point тестового окружения приводит к куче ошибок типа деления на ноль.
Самое печальное, что попытки зафиксировать типы для значений не решают проблемы, выставлял для всех переменных ufix16_En24, ставил для массы целочисленный тип, но все равно в результатах получался бред.

Есть у кого предложения по решению этих проблем?

Сообщение отредактировал LiNED - Sep 17 2012, 13:53

Поставил 2.0001 вместо 2, строго задал fraction length побольше, теперь хоть он нормально делит, и ошибка не такая большая. Но все равно это только костыль...

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

/me наслушавшись манагеров и саппортеров матлаба

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

Спасибо.

Для ЦОС однозначно надо уходить в МАТЛАБ ( Xilinx System Generator- 9 лет только положительного).
Для HIGH speed Serial mgt gtp - по прежнему VHDL.

хмм, вот это положительное можете немного расшифровать ?

Ну т.е. что кроме фильтров вы генерировали с матлаба, использовали симулинк или m файлы, какое по вашему качество реализации получилось ? Интересует не столько Xilinx/Altera DSP Builder, а чистый нативный HDL кодер.

Чистый нэтивный не пользую. У Xilinx явно более высокое качество IP CORE.
Проекты - ну например - блоки 802.16 e, приемник и передатчик DVB-T, UMTS, LTE, различные широкополосные цифровые приемники и пеленгаторы , со-вычислители .
А что все про фильтры . Все что Вы сумеете математически сформулировать можно сделать и очень быстро(можно вставки делать и на m языке и на vhdl verilog).
Просто нет доступа у некоторым скоростным специфическим блокам и сj множеством клоков определенный опыт нужен.

Спасибо за ответ. А про вставки, если m код, то это Embedded Function, а если RTL то это какой компонент ? и моделировать его через мосты к симулятору ?

m язык же конечно ограниченный (if ,case, for, типы данных , регистры .......) Но и это очень даже ничего.
Моделировать Vhdl verilog указывая симулятор внешний .
RTL какой компонент - не понял?

В том смысле что моделировать через EDA Simulation Toolbox %) медленно и печально %) думал может матлаб уже научился что-то большее понимать. А как там с многотактовой обработкой cycle accurate при конвейеризации систем, в том числе с обратными связями ? Матлаб не балуется изменением латентностей ?

Simulink моделирует раз в 10 быстрее VHDL симуляторов.
Я не пользуюсь вставками на vhdl verilog, достаточно m языка.
Обратные связи работают - но есть нюансы.
Задержки из страссированной ПЛИС можно посмотреть прямо в Simulink.
Изменение задержек конечно же исключено.
Все схемы конвейерные , в чем проблемы?

Вот простой пример, собрал блок, который работает при отношении тактовой к символьной ну положим 8 раз, можно использовать многотактную обработку. Матлаб учтет это обстоятельство и сделает латентность ну положим 6 тактоов. Но потом, например, я увеличил порядок фильтра в 2 раза, то матлаб останется в тех же 6 ти тактах или сам увеличит количество слоев логики, сделает латентность ну положим 8 и тихо про это промолчит ?

Или другой пример, написал я код на m языке, который должен исполняться за 2 такта, а при синтезе матлаб решил его разогнать по тактовой, напихал регистров и сделал его исполняющимся за 4 такта. Такая ситуация возможна ?

Вообще фраза МАТЛАБ промолчит как бы ....
Simulink это система моделирования - любое Ваше изменение во первых видно при моделировании . И можно извлечь VHDL и перемоделировать в моделсиме (если не верите ).
Про фильтр - у него есть выход готовности данных. Хотя его задержку можно посчитать и в уме. При проектировании фильтров используются IP core с подробным описанием, в том числе и latency. Все решает Ваше задание для корки.
Про второй вопрос про m - файл ситуация невозможна. Ну как бы работали сложные проекты под полностью забитые virtexы - если бы задержки "разгонялись" ??? сами , ага в state machine ????
Просто надо начать работать - появится понимание нюансов.

Хмм, IP корки мне не интересны. Мне интересен натурный HDL кодер. На демонстрации которую матлабовцы показывали по россии, конвейеризация m файлов выглядела так, вместо a = b написали a1 = b, a = a1 (без каких либо квалификаторов и тегов) и получили прирост тактовой в ~5 раз, за счет конвейризации и увеличения латентности на 1 такт. При этом для моделирования этого m файла в матлабе, это "пустые" операции и задержки не будет. Т.е. модель и железо тут разошлись.

На всякий случай я говорил за m-язык Xilinx System Generator.
Тут какойто господин на форуме говорил что уверенно овладел Matlab HDL генерацией - это к нему.