В этом примере показано, как спроектировать демонстрационное приложение детектора сигнала на платформе Системы на чипе (SoC) с помощью подхода системного проектирования. Рабочий процесс в этом примере сопоставляет функции приложения на выбранную аппаратную архитектуру.
Приложение детектора сигнала постоянно обрабатывает данные сигнала и классифицирует сигнал или как высокочастотную или как низкую частоту. Сигнал не может измениться между высоким - и низкочастотными классами быстрее, чем 1 мс. Сигнал производится по курсу 10 МГц.
Задайте функциональную архитектуру приложения. На данном этапе реализация компонентов приложения не известна. Можно использовать программное обеспечение System Composer™, чтобы получить функциональную архитектуру.
Эта модель представляет функциональную архитектуру своими основными компонентами программного обеспечения и их связями.
systemcomposer.openModel('soc_signaldetector_func');
Функциональная архитектура приложения состоит из этих компонентов верхнего уровня:
Сгенерируйте сигнал
Предварительно обработайте сигнал
Классифицируйте сигнал
Активируйте светодиоды
Выберите аппаратную архитектуру. Из-за ожидаемой сложности приложений, выберите устройство SoC. Выбранное устройство SoC имеет аппаратную программируемую логику (FPGA) ядро и встраиваемый процессор (ARM) ядро. Можно использовать программное обеспечение System Composer, чтобы получить детали аппаратной архитектуры.
Эта модель представляет аппаратную архитектуру своими основными аппаратными компонентами и их связями.
systemcomposer.openModel('soc_signaldetector_arch');
Если реализации для функциональных компонентов доступны, можно добавить их в функциональную архитектуру как поведения. В System Composer, для каждого функционального компонента, можно соединить поведения реализации как модели Simulink®. Чтобы рассмотреть реализации компонента, дважды кликните каждый компонент в модели функциональной архитектуры.
После того, как вы зададите поведение каждого компонента, можно симулировать поведение целого приложения и проверить его функциональную корректность. Выберите Run в модели функциональной архитектуры. Затем анализируйте результаты классификации сигналов в Инспекторе Данных моделирования. Чтобы изменить тип сигнала, выберите Generate Signal
компонент и затем выбирает Manual Switch block. Подтвердите, что исходный сигнал классифицируется правильно.
После совершенствования функциональной и аппаратной архитектуры выделите различные функциональные компоненты различным аппаратным компонентам, чтобы соответствовать желаемым сравнительным тестам производительности системы. В этом случае некоторые функциональные компоненты ограничиваются как, туда, где в аппаратной архитектуре они могут быть реализованы. Необходимо реализовать Generate Signal
и Activate LEDs
компоненты на ядре FPGA в выбранной аппаратной архитектуре из-за ввода-вывода (ввод-вывод) связи. Сравнительно, можно реализовать Preprocess Signal
и Classify Signal
компоненты или на FPGA или на ядре процессора.
Component Constraint Generate Signal FPGA Preprocess Signal - Classify Signal - Activate LEDs FPGA
В этом примере показано, как использовать три возможных сценария для выделения функциональной архитектуры приложения к аппаратной архитектуре.
Предварительная обработка указателей FPGA и классификация.
Предварительная обработка указателей FPGA и процессор обрабатывают классификацию.
Предварительная обработка указателей процессора и классификация.
System Composer получает эти сценарии как Scenario 1
, Scenario 2
, и Scenario 3
использование редактора выделения.
systemcomposer.allocation.editor
allocSet = systemcomposer.allocation.load('soc_signaldetector_allocation');
Warning: The model 'soc_signaldetector_func' associated with the allocation set 'soc_signaldetector_allocation' has changed and the allocation set needs to be updated. Suggested Actions: • Synchronize changes - Fix
Warning: The model 'soc_signaldetector_arch' associated with the allocation set 'soc_signaldetector_allocation' has changed and the allocation set needs to be updated. Suggested Actions: • Synchronize changes - Fix
Выбор сценария выделения требует нахождения реализации, которая оптимально соответствует требованиям к приложению. Часто можно найти эту реализацию через статический анализ без подробной симуляции. В этом примере используйте статический анализ, чтобы анализировать вычислительные затраты на реализацию различных функциональных компонентов на процессоре и на FPGA.
Стоимость внедрения компонента зависит от необходимых операций расчета. Чтобы определить затраты на внедрение, рассмотрите эти типичные подходы.
Реализация компонента не доступна: Получите вычислительную стоимость от доступных ссылочных реализаций.
Реализация и оборудование доступны: Измерьте или профилируйте стоимость внедрения на оборудовании кандидата.
Реализация доступна, но оборудование не: Оцените стоимость внедрения при помощи алгоритма SoC Blockset™ функция анализатора socAlgorithmAnalyzerReport
.
socModelAnalyzer
функционируйте оценивает количество операций в модели Simulink и генерирует алгоритм отчет анализатора. Чтобы получить количество операций, которые модель выполняет, чтобы затем анализировать стоимость внедрения на процессоре, используйте опцию функции динамического анализа. Чтобы получить количество операторов, алгоритм требует, чтобы затем анализировать стоимость внедрения на FPGA, использовать опцию функции статического анализа. Для примера о том, как использовать socModelAnalyzer
, смотрите эту демонстрационную функцию.
soc_signaldetector_costanalysis
*** Component: 'Preprocess Signal' ADD(+) MUL(*) ______ ______ FPGA Implementation 15 16 Processor Implementation 15300 16320 *** Component: 'Classify Signal' ADD(+) MUL(*) ______ ______ FPGA Implementation 32 18 Processor Implementation 32640 18360
Затраты на внедрение для каждого функционального компонента, полученного в этом коде, вводятся в соответствующие стереотипы в функциональной архитектуре. Чтобы проверить значения, выберите каждый компонент в модели функциональной архитектуры и используйте Property Inspector.
Узнать больше о socModelAnalyzer
, смотрите, что Сравнить КИХ-Реализации Фильтра Используют socModelAnalyzer пример. В этом примере показано, как анализировать вычислительную сложность различных реализаций алгоритма Simulink.
Можно использовать количество операторов или операций, которые требуются для того, чтобы реализовать функциональные компоненты приложения, чтобы решить, как выделить функциональные компоненты аппаратным компонентам. Анализируйте выделения кандидата путем сравнения стоимости внедрения с имеющимися ресурсами FPGA и процессора. Этот пример использует демонстрационные значения в FPGA и компоненты процессора в модели аппаратной архитектуры для доступных ресурсов расчета. Проверьте значения при помощи Property Inspector.
Как правило, анализ не использует количество операторов или операций непосредственно. Скорее количество операторов или операций умножается на стоимость каждого оператора или операции сначала. Стоимость оператора или операций аппаратно-зависима. Определение таких затрат выходит за рамки этого примера.
Для примера о том, как использовать модели стоимости, используйте эту функцию. Заметьте, что мы требуем, чтобы способность FPGA и процессора была больше предполагаемой стоимости внедрения, а также что высота процессора быть между 60 и 90%.
soc_signaldetector_partitionanalysis
FPGA DSPs Used (out of 900) FPGA LUT Used (out of 218600) Processor Instructions/s (out of 1000000000) Processor Headroom (%) Feasible ___________________________ _____________________________ ____________________________________________ ______________________ ________ Scenario 1 34 576 0 100 0 Scenario 2 16 192 326400000 67 1 Scenario 3 0 0 489600000 51 0
На основе результатов Сценарий 2 выполним.
Выборка выборкой данных о процессах FPGA и покадровые процессы процессора. Поскольку длительность задачи процессора может варьироваться, чтобы предотвратить потерю данных, очередь необходима, чтобы содержать данные между FPGA и процессором. В этом случае необходимо установить эти параметры, которые связаны с очередью: формат кадра, количество кадровых буферов и размер FIFO (то есть, количество отсчетов в FIFO). Кроме того, во встраиваемых приложениях длительность задачи может варьироваться между экземплярами различной задачи (например, из-за различных путей к выполнению кода или из-за изменений во время переключения ОС). В результате данные могут быть пропущены в канале памяти. Данные о Потоковой передаче от Оборудования до примера программного обеспечения показывают систематический подход к выбору ранее упомянутых параметров, которые удовлетворяют требованиям к приложению.