Pull to refresh

Comments 15

такой, вопрос, какая достижима производительность, есть ли оповещение при пропуске отсчетов. Интересует производительность десятки и сотни мегабайт в секунду (поток видеокадров)? Возможна ли синхронизация потока, по началу кадра или строки?
ps: у вас кажется были универсальные платы PCI-E, можно ли такой же фокус провернуть с ними? то есть захватить большой поток с PCI-E сразу в матлаб?
pss: к сожалению, обычно приходится отдельно захватывать данные и загружать в матлаб ( что очень не производительно, а современные потоки доходят до 10-40Гбит в секунду…
Здесь главный вопрос — режим захвата однократный или непрерывный?
Если однократный — то определяется только возможностями аппаратуры по скорости регистрации сигнала. Если регистрировать в память при ПЛИС — 8-12 Гбайт/с. Если регистрировать в память компьютера, то зависит от интерфейса связи. Для USB 3.0 это 300 Мбайт/с. На PCI-Express до 13 Гбайт/с.
А если интересует непрерывный режим — то тогда уже надо учитывать скорость обработки в Matlab. Надо что он успел обработать блок данных до прихода следующего.
По такой технологии можно обеспечить скорость передачи в Matlab до 13 Гбайт/с.
У нас сейчас нет готового решения для захвата видеопотока, но я готов обсудить такую задачу. Сделать можно.
Спасибо за ответ.
Режимы как однократные (большие потоки ограниченные памятью ЭВМ,), так и непрерывные (скорость соответствует скорости обработки или регистрации).
Приятно, что достижимая скорость соответствует пропускной PCIE.
Бывает, возникают задачи принять скоростной поток по оптике, смотрим на ваши платы… но опыта и знаний по ним не хватает и берем какой-нибудь CameraLinkHS (максимальная пропускная способность 2.6Гбайта на слот).
Мы на текущий момент используем следующий лайв-хак: захватываем данные своим ПО и сразу же перекладываем на локальный (127.0.0.1) сокет IP, а далее вычитываем матлабом из сокета. Но в такой реализации есть ограничение на максимальный поток(сотни мегабайт в секунду, точно не помню)
Еще раз спасибо за статью, будем иметь ввиду.
Существует OpenSource проект easyLink. В этом проекте разработана библиотека классов для подключения к Simulink.

Последний коммит в 15 году((

Затруднена отладка DLL
Неудобно смотреть вывод printf()
Перекомпиляция DLL требует выхода из MATLAB

1.Зачем отлаживать в симулинке? Можно использовать же тестовые фреймворки!
2. Я так понял его вообще невозможно смотреть. Но на этот случай надо просто правильно писать систему логирования.
3. Может вы просто не делали unloadlibrary?
Последний коммит в 15 году((

Ну если проект достиг совершенства, то зачем коммиты :-)

1. Симулинк как раз и является тестовым фреймворком. И мне нужен полный контроль за моим кодом. Как за тем что есть в схеме симулинка, так и за тем что в DLL и программах управления аппаратурой. Я этого достиг.

2. Про тестовый вывод — printf() как раз и является системой логирования. Простой и очень эффективной. И легко переносимой между разными программами. Ну вот я его и использую. Причём везде, в том числе и в программах с GUI.

3. Может. Вот только я не вижу места где бы я мог его вызвать. У меня есть код DLL на С++, есть S-Function которая вставляется в схему Simulink. А вот отдельного m-файла нет. И вроде бы он не предполагается. Я не прав?
Ну если проект достиг совершенства, то зачем коммиты :-)

Это очень хорошо, то вот что делать когда matlab поменяет API, будет очень неприятно остаться без поддержки
1. Симулинк как раз и является тестовым фреймворком. И мне нужен полный контроль за моим кодом. Как за тем что есть в схеме симулинка, так и за тем что в DLL и программах управления аппаратурой. Я этого достиг.

Интересное мнение. А какие вы нашли у него преимущества по сравнению с другими фреймворками для тестирования? Хотя бы по сравнению с Google Test и Ctest+Cmake…
2. Про тестовый вывод — printf() как раз и является системой логирования. Простой и очень эффективной. И легко переносимой между разными программами. Ну вот я его и использую. Причём везде, в том числе и в программах с GUI.

printf — всего лишь ф-ция вывода в терминал. И вы сами написали что матлаб обламывает с такой отладкой. Более менее простую систему логирования можно посмотреть на qDebug в QT.
3. Может. Вот только я не вижу места где бы я мог его вызвать. У меня есть код DLL на С++, есть S-Function которая вставляется в схему Simulink. А вот отдельного m-файла нет. И вроде бы он не предполагается. Я не прав?

А вы не могли бы показать код S-Function. Кстати, статье как раз кода оч не хватает…
Это очень хорошо, то вот что делать когда matlab поменяет API, будет очень неприятно остаться без поддержки

Это общая проблема работы с Open Source — всё на свой страх и риск.

Интересное мнение. А какие вы нашли у него преимущества по сравнению с другими фреймворками для тестирования? Хотя бы по сравнению с Google Test и Ctest+Cmake…

Если сравнивать с Google Test и другими системами unit тестирования то Simulink конечно другой. В более общем смысле — это система тестирования и разработки чего-то. Например алгоритмов, или других вещей. И да, возможность создать тесты и провести регрессионное тестирование там тоже есть.
А вы не могли бы показать код S-Function. Кстати, статье как раз кода оч не хватает…

Так его то и нет. Есть код DLL: https://github.com/dsmv/simulink_sm/blob/master/simulink_sm/src/mex/sm_adc.cpp

ИМХО лучше вместо USB использовать Ethernet. В Симулинке для этого есть стандартные блоки, типа UDP, не надо возиться с DLL-ками и еще меньше мороки с отладкой, так как трафик можно смотреть прямо в Wireshark. Вы можете повесить сколько угодно плат без проблем с конфигурацией. Выше уже подсказали лайвфак с локальными сокетами, но с ПЛИС это можно сделать напрямую.


Еще проблема данного подхода в том, что у вас генератор->АЦП синхронизируется самостоятельно. А в реальной жизни генератор может быть отдельно, а АЦП отдельно и запуск надо синхронизировать через ПК — а тут непредвиденные задержки начнут мешать.

Ethernet сразу ограничивает скорость обмена. А главное — накладывает ограничения на выбор аппаратуры. Предложенный подход не накладывает ограничений на интерфейс связи. USB взят исключительно для примера, что бы удобнее было подключиться к ноутбуку. А так конечно напрашивается применение модулей на основе PCI Express.

По поводу синхронизации — в данном примере АЦП стартует по фронту сигнала «START», этот сигнал формируется генератором. Но разумеется вместо генератора может быть и другой источник.
С точки зрения Simulink непредвиденные задержки на ПК совершенно не мешают. Он просто ждёт когда сигнал старта пройдёт через sm_adc и вернётся обратно. Это будет всё тот же момент модельного времени.
Ethernet сразу ограничивает скорость обмена. А главное — накладывает ограничения на выбор аппаратуры. Предложенный подход не накладывает ограничений на интерфейс связи. USB взят исключительно для примера, что бы удобнее было подключиться к ноутбуку. А так конечно напрашивается применение модулей на основе PCI Express

PCIexpress требователен по физическому интерфейсу — карта должна либо стоять прямо в в материнке, а всякие iPass с оптикой не очень хорошо дружат. А с Ethernet — у вас на плате SFP слот — туда можно все что угодно впихнуть — от меди и до оптики на 10км. По скоростям, да PCIe еще выигрывает за счет количества линий, но у вас обработка в компьютере все равно будет медленней, чем пропускная способность канала, так что выше все равно не надо.


ПС. Мы протестировали Ethernet 10Гбит и серьезно думаем перелезть с PCIe Gen2 на Ethernet для связи ПЛИС<->PC. Получается гораздо проще в разработке и сопровождении.

Плата с PCI Express не обязательно должна стоять в компьютере, мы активно используем внешние модули на PCI Express. Есть стандарт для медного кабеля, есть и оптические удлинители.
Для ускорения обработки данных в компьютере есть различные способы, включая видеокарты, ПЛИС, сигнальные процессоры. Ну и от самого алгоритма обработки тоже зависит. Например я умею проверять 64-х битный счётчик на скорости 11 Гбайт/с.
Решение с вводом данных в Simulink через Ethernet является альтернативным подходом. Оно вас устраивает — и это хорошо. В статье приведён другой, более мощный подход. Вот он устраивает меня.
Если не ошибаюсь, то Artix-ы, используемые в статье, 10Гбит Ethernet не умеют, только гиг.
Теоретически есть возможность подключения. Надо использовать внешний преобразователь из 4x3.125 Гбит/с в 10 Гбит/с. Но для 10G Ethernet своих сложностей хватает. У меня вот сейчас есть устойчивое соединение с 10G коммутатором, а вот с сетевой платой Intel — не получается. И не хватает времени разобраться.
Надо использовать внешний преобразователь из 4x3.125 Гбит/с в 10 Гбит/с.

Вас понял, благодарю.

Ну да, там трансиверы только 6,6Гбит умеют.

Sign up to leave a comment.

Articles