Jump to content

    

Hardware in the Loop from the MATLAB/Simulink Environment

Есть любопытный документ на сайте Альтеры: https://www.altera.com/content/dam/altera-w...in-the-loop.pdf.

Там о вкомпиливаемом Matlab API в ПЛИС, по которому можно закачать свои данные, обработать в рилтайме, выкачать результаты, показать красиво всё. Ну и в том числе для моделирования/верификации может использоваться, всё зависит от скорости интерфейсов конкретного кита. Типа, сейчас по Ethernet можно обмениваться с "хостом", осенью в свежих релизах -- по PCIe...

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

Есть ли среди форумчан приобщившиеся к такому новому витку цивилизации ? Могут поделиться конкретным опытом или продуктивными прямыми ссылками на документацию, желательно по-русски, что куда писать/нажимать в этих горах софтов, чтобы всё зашевелилось, и старый софт-бенч на SV стал рисовать красивые картинки, помечать проблемные места в прямо МатЛабе ?

Я лично пока на старте раскопок, всё в голове перепутано...

Share this post


Link to post
Share on other sites

Если у вас стандартный маршрут разработки "bit-accurate модель - rtl описание - верификация rtl c использованием векторов из модели", то не очень понятно, зачем этот этап с HIL. Куда его втиснуть?

 

Ну и простой вопрос: вот вы собрали большой проект для верификации в таком окружении. Он естественно заработал с ошибками. Что вы делаете дальше?

Share this post


Link to post
Share on other sites

Fat Robot, насколько понимаю, HIL хорош тогда, когда Вы применяете модельно-ориентированный подход. То есть из Матлаба кодогенерируете HDL, сравнивая результат с работой исходной модели. Собственно, Матлаб делает это в автомате.

В таком случае, до HIL у Вас должно всё заработать на модели.

Сам не пробовал, но на семинарах присутствовал :biggrin:

 

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

HIL само по себе не ускоряет моделирование, как некий FPGA-ускоритель. Скорее, замедляет, нежели если бы Вы всё написали сразу на Си. Все правильно говорите, на сборку проекта под ПЛИС уйдет время.

Этот инструмент, как написал выше, стоит рассматривать только в концепции модельно-ориентированного подхода и сквозного проектирования посредством Матлаба. Такой подход сам по себе, как уверяют ребята из Softline :biggrin:, экономит время при проектировании, т.к. позволяет устранить системные ошибки на начальном этапе, и по прочим причинам.

Edited by x736C

Share this post


Link to post
Share on other sites
Такой подход сам по себе, как уверяют ребята из Softline :biggrin:, экономит время при проектировании, т.к. позволяет устранить системные ошибки на начальном этапе, и по прочим причинам.

довольно сильное утверждение, типа "матлаб заменяет мозги" ;)

Share this post


Link to post
Share on other sites
довольно сильное утверждение, типа "матлаб заменяет мозги" ;)

Такого утверждения никто не делал. Речь немного о другом.

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

Есть определенный workflow, который лучше посмотреть на сайте Mathworks. Он подразумевает вначале работу с требованиями, по которым потом составляются тесты, которые должны покрыть все эти требования. Потом создается модель. Затем она переводится из плавучки в целочисленную. Потом SIL, PIL и HIL. :biggrin: И т.д.

Для всего этого есть свои инструменты. Такой подход мне импонирует. Есть в этом какая-то логичная сущность бытия. :laughing:

То есть, раз Вы уже сделали модель, то зачем делать двойную работу, которая сама по себе "багогенная". Потом Вы меняете что-то в модели или в железе, и должны бесконечно актуализировать то одно, то другое.

Mathworks заявляет, что Си-автокод в среднем на 10% менее эффективен, чем ручной. Коллега утверждает, что кодогенератор при правильном подходе сгенерил у него более оптимальный код. Он не сразу пришел к такому результату. Долго можно дискутировать. И это уже оффтоп. Что касается HDL-кодирования, то у нас пробы были фактически с негативным результатом. Наверное, мы просто не научились его готовить. И я слабо представляю такой подход для создания HEVC-кодека, например.

Share this post


Link to post
Share on other sites

Если у меня есть работоспособная модель, и я из модели получаю верифицированный RTL средствами матлаба или силами rtl-инженеров, то на каком этапе проектирования появляется HIL?

 

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

 

Fat Robot, насколько понимаю, HIL хорош тогда, когда Вы применяете модельно-ориентированный подход. То есть из Матлаба кодогенерируете HDL, сравнивая результат с работой исходной модели. Собственно, Матлаб делает это в автомате.

В таком случае, до HIL у Вас должно всё заработать на модели.

Share this post


Link to post
Share on other sites

...Наше начальство съездило на эти столичные семинары, ему крючков накидали неконкретных и ссылок на былые семинары не в виде avi-файлов, а с сайта, которые почему-то принципиально не глядятся через наши прокси, и тамошние "продвигатели" хотят срубить кучу К баксов за невнятное ПО и бросить опять 1 на 1 с просторами интернета без русскоязычного ноу-хау с подробным описанем каждого шага для "трактористов", ибо гениев в России и тем более на периферии пока остаётся немного, и их занимают нещадно.

Есть ещё крючок, что результаты верификации с помощью железа появятся быстрей что в Квесту, что в МатЛаб...

Вот же ж и хочется бывалого кого-то встретить на наших просторах для "вилки", ибо демократия такая штука, что верить нельзя даже Мюллерам. И вдруг у него есть то самое HIL-ое ноу-хау на 1 страничке, от которого Щастие наступит нам бедным... Тогда уж и К$ не жалко ;)

Хотя я лично не представляю, как исполнение SV-модели Квестой можно запхнуть в ПЛИСину, чтобы она там и сравнивала сразу результаты: только в хосте моделить вроде бы можно по-старинке на интерпретируемом языке типа С++, а в железо по быстрому каналу слать готовое для сравнения, и в итоге ускорится только моделирование самого "железа" в Квесте, которое тоже бывает жутко медленным по много-тысячно-строчным моделям с еле-задержками, предоставляемым обычно автором внешнего блочка.

...Ибо те тысячи листов и ссылок, что надо лопатить сейчас, вместо 20 листов "MatLab+QuestaSim для чайников", и есть признак негениальности Запада, который берёт всегда числом + извратом, а не умением, и прячет слегка имеющиеся умения довольно далеко, чтобы толкнуть их за отдельные баксы. По крайней мере, в видимых и выставляемых на продажу решениях со всей мощью пиара.

Ну и простой вопрос: вот вы собрали большой проект для верификации в таком окружении. Он естественно заработал с ошибками. Что вы делаете дальше?

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

Или "в бою" что-то случается нехорошее и неповторябельно, там вообще тысячи кадров и секунд могут пройти до "взрыва", СигналТапком что-то хлопается, пытаются создаться аналогичные условия в бенче, и ловится редко когда глюк в первом же часе-кадре...

Если повторябельность достигнута, для чего верификация и существует в принципе, то по времянке уже автор HDL-кода разберётся в косяках, и в железо выведет новых КТ, обстреляет подозрительные места, за несколько итераций полечит. Если компиляция -- час, а ждать ошибку через HIL не сутки, а полчаса, то выигрыш явно есть.

"Официальный" путь маткадников с выставлением требований, рождением красивой модели, генерацией "умного" кода и "аутоматичной" доказухой всего остального по всем возможным DO-* нас ещё не встретил в тёмных переулках с толстым томиком на нашей мове, тут бы хоть ляповые зависюхи фифошек на коленке подковать... И ПЛИСоводы не очень горят желанием терять свои годами отлаживаемые проекты, если кто(что)-то умный "вдруг" всё гениально разрулит... ;) И я даже в принципе не верю во все эти ИИ, наблюдаю за дикостью текущего мира...

Вообще предлагаю своим давно и настойчиво -- давайте всю обработку видео проверять на детских картинках регрессирующих размеров 32х32, 24х24, 16х16, 8х8... Практика показывает, что потом растяжение до "часовых" 2000х1500 не находит новых глюков в принципе ! Ну кроме детских с ошибками в разрядностях чего-то на 1-2, ловимых мгновенно, а в динамике все основные ошибочные ситуации случаются в пайплайнах, когда концы/начала строк приходят рядом и немного рандомно, концы кадров тоже частые, раз 10 в секунду со всеми сочетаниями -- и вероятность влезть в непросмотренный взглядом "творца" логический путь и сочетание состояний/переходов повышается на порядки.

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

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

Ну или другой форум, другое место на этом для воплей ?.. ;)

Share this post


Link to post
Share on other sites

Неплохая страница http://www.mathworks.com/help/hdlverifier/...l-workflow.html, чтобы начать разбираться в этом ворохе вопросов (звучит как FIL в интерпретации Mathworks, FPGA-in-the-Loop), хотя бы приблизительно -- что за чем жать, чтобы приблизиться к "мечте".

Но там есть ссылка "Set Up FPGA Development Board", которая приводит к запуску команды "fpgaBoardManager" Матлаба, где в диалоге уже есть кнопка "Get More Boards...", которая директно лезет в интернет на сайт Mathworks и ругается на его отсутствие в нашей закрытой локалке.

И также есть кнопка "Add Board from File", хотящая описание нашей платы для Матлаба в формате xml.

У кого-то есть оффлайновые БД разных плат, ну или хотя бы файл для нашей "Cyclone V SoC development kit" ?

Или как его родить в само-платном редакторе без опыта ?..

Она позиционируется как не очень серъёзная -- по Ethernet обмены с ней недоступны, только JTAG, но какая уж есть...

А то меня даже на сайте Mathworks не считают особо легальным юзером после регистрации, кое-куда не пускают, требуют цифры лицензий, которых на местном ftp: с дистрами нету. Точней, боюсь, что эти 5х5 уже засвечены и закрыты... ;)

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

Share this post


Link to post
Share on other sites

"оффлайновые БД разных плат" устанавливаются вместе с симулинком и данная плата там была.

У вас на предприятии работают люди, которые прошли в данном направлении чуть дальше - можно уточнить у них ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this