Эмуляция оборудования продолжает утверждаться как удобный инструмент для совместной проверки и тестирования интеграции аппаратного/программного обеспечения.
Загрузка операционной системы и выполнения программных приложений требует миллиардов циклов — проверки задач, которые побеждают традиционные программные инструменты анализа. Только аппаратные проверки «движка» обеспечивают пропускную способность, необходимую для решения этой проблемы. Именно поэтому аппаратные эмуляции и FPGA прототипы стали обязательными инструментами в проверке сегодняшних новинок.
С аппаратной эмуляцией и FPGA прототипами, разработчики встроенного программного обеспечения могут проверять свои продукты с довольно привлекательной особенностью. Только эмуляция позволит им подтвердить, что программное обеспечение встроенных систем работает с базовым аппаратным обеспечением, поскольку FPGA прототипы не обеспечивают видимость в отладке работы внутренних программ.
Более того, эмуляция, как правило, доступна намного раньше – в процессе проектирования. Таким образом, при использовании эмуляции, процесс разработки может начаться гораздо раньше, чем при использовании FPGA прототипов.
Инженеры могут реализовать преимущества запуска программного обеспечения с помощью эмуляции и на аппаратных средствах тоже. Когда программный продукт запускается на оборудовании в первый раз, практически всегда возникают аппаратные ошибки, пропущенные наиболее эффективными методологиями. Более раннее тестирование позволит снизить цену исправления ошибок проектирования.
Физические исследования
Как правило, разработчики программного обеспечения используют JTAG программаторы для отладки кода, работающего на эмуляторе. Стандарт JTAG определяет набор сигналов и разъемов для чтения и записи на печатной плате через интерфейс с четырьмя выводами. Первоначально он задумывался для испытания плат управления, давая возможность инженерам заглянуть «внутрь упакованного изделия» для определения правильности его работы.
Разработчики поняли, что они могли бы использовать этот же интерфейс для чтения и записи регистров общего назначения в процессорах, расположенных на печатной плате. Возможность читать и писать основные регистры процессора привело к тому, что это стали использовать для отладки программ, работающих на этом процессоре.
Через «умный» интерфейс, встроенный в отладчик (например, Lauterbach’s Trace-32 или ARM’s DS-5) можно отправлять команды для JTAG программатора на получение или установку состояния процессора на плате, подключенной к программатору. Это самый распространенный способ среди разработчиков по запуску и отслеживанию работы программ на «голом железе».
Поскольку программатор JTAG тот инструмент, который обычно используют в дальнейшем цикле проектирования на прототипе печатной платы, разработчики программного обеспечения должны хорошо ознакомиться с его возможностями.
Хотя интерфейс JTAG предоставляет отладчик для непосредственного чтения и записи регистров, для правильной отладки программы необходимо уметь правильно управлять памятью, а также контролировать ход выполнения программы. Для удовлетворения этих потребностей разработчики процессоров добавили регистры, доступ к которым можно получить с помощью отладчика, для записи и чтения с памяти инструкций в процессе выполнения. Это дает отладчику полный доступ ко всем устройства памяти и отображениям файлов в памяти в процессе отладки.
Кроме того, разработчиками включены точки останова регистров и поддержка других схем, чтоб позволить JTAG отладчикам контролировать процесс выполнение программы. Это означает, что с подключением JTAG процессора, отладчик может показать код исходной программы, регистры процессора, память, переменные и стек программы. В результате отладчик может устанавливать точки останова и старта программы, позволяя проводить пошаговую отладку.
Вопросы по работе с JTAG программатором
JTAG позволяет проводить отладку программного обеспечения в режиме эмуляции, но также имеет и свои недостатки. Одним из них является то, что JTAG и тестируемая разработка работают в эмуляторе и имеют свои собственные часы. Для поддержки синхронизации эти часы должны поддерживать постоянную скорость. Если не осуществлять синхронизацию, то связь между отладчиком и тестируемым изделием будет потеряна.
Во многих случаях программатор необходимо сбросить, а иногда необходим сброс настроек и самого тестируемого изделия. Замедление, или даже остановка часов в изделии и программаторе, скорее всего, полезно, так как позволяет зафиксировать и сохранить значения сигналов в изделии. Это также позволяет разработчику видеть состояние тестируемого изделия или силовых сигналов зафиксированными. По сути, разработчики аппаратного обеспечения теряют богатый набор возможностей отладки, в случае не возможности замедления или остановки часов на эмуляторе.
Второй проблемой при использовании JTAG является производительность. Это связано с тем, что и эмулятор, и программатор имеют собственные часы. При обмене данными между этими устройствами возникает определенная проблема. Решением этой проблемы, как правило, становится запуск часов программатора с определенной разницей часов процессора. На прототипах печатных плат, где часы процессора работают с частотой в сотни мегагерц, а то и гигагерц, это не является большой проблемой. В режиме эмуляции, где часы работают с частотой один-два мегагерца, это может приводить к замедлению хода событий.
Например, выполнение одного шага инструкции в ARM Cortex-A57 занимает более четырех миллионов битов JTAG при сканирования цепочки активности. Если часы процессора работают с частотой 2 МГц, а JTAG работает с четвертью частоты (500 кГц), то понадобится восемь секунд для обновления информации в отладчике после нажатия кнопки «шаг».
Еще одной проблемой производительности является время загрузки. Разработчики программного обеспечения используют цепочку сканирования для загрузки программ в устройство через JTAG программатор. Если программа слишком большая, то может понадобиться час или более времени для загрузки ее в исполняющее устройство. Вряд ли такая скорость устроит большинство разработчиков.
JTAG транзактор
Новый подход к использованию JTAG отладчика позволяет смягчить эти проблемы. Система эмуляции позволяет «просматривать» каждый сигнал на плате через специальные схемы и программное обеспечение, встроенные в эмулятор. Вместо того, чтобы пропускать сигнал через модули ввода/вывода и «вытягивать» его из физического устройства, транзактор может использоваться для управления JTAG сигналами при проектировании. Одни и те же значения сигналов приведут к получению тех же значений, что и при использовании физического устройства, при этом обеспечивая те же возможности отладки.
Так как и «испытуемый объект», и устройство JTAG находятся на одном эмуляторе, то снимается вопрос синхронизации часов, поскольку ими управляет эмулятор.
Также это значит и то, что часы на эмуляторе можно остановить или замедлить для выполнения аппаратной отладки, например для снятия осциллограмм. Теперь вопрос времени закрыт для испытуемого устройства JTAG, эта обязанность переносится на систему эмуляции.
Эмулятор способен замедлять и останавливать время, а затем его запускать или ускорять, и при этом связь между отладчиком и платой не теряется. Это позволяет разработчикам использовать полный набор аппаратных средств отладки доступных для эмулятора. Это также дает возможность использовать более сложные испытательные стенды в режиме эмуляции.
Также преимуществом является и то, что часы JTAG работают синхронно с часами процессора и вопрос синхронизации отходит на второй план. Это приводит к трех-четырех кратному увеличению производительности отладчика и повышению его «отзывчивости».
Это не последние преимущества виртуализации соединения. Поскольку осциллограммы могут фиксироваться и выгружаться, то появляется возможность получения информации об объекте походу разработки. Также это можно использовать для «отлова» бросков напряжений и прочих неприятных нюансов.
Виртуализированное подключение к изделию позволяет расширить возможности отладчика. В интерфейс могут включаться сигналы больше, чем просто сигналы JTAG, что позволит отладчику иметь большее влияние на тестируемый объект. В частности это может привести к прямому сбросу настроек.
Если разработка попадет в неопределенное или несоответствующее состояние, отладчик может выдать аппаратный сброс и привести конструкцию обратно в известное состояние. Отладчик может обращаться к триггеру для создания осциллограммы, позволяя разработчику увидеть формы сигналов, которые коррелируют с известным положением в программном обеспечении. Разработчик может установить точки останова программного обеспечения и непосредственно осциллограмм, которые будут «захвачены» вокруг точек останова.
Можно произвольно сохранять и восстанавливать виртуализированное соединение. Поскольку эмулятор имеет полный контроль над состоянием обеих сторон соединения отладчика, сохранения и восстановления возможностей эмулятора можно использовать с разработками, которые имеют подключение к виртуальной JTAG.
Нет необходимости подключения к специально сконфигурированным картам ввода/вывода для загрузки и эмуляции аппаратного обеспечения на огромном количестве плат. Виртуальный датчик обеспечивает большую гибкость в управлении изделием, предлагая инженерным специальным группам способ использования эмуляции аппаратных средств в качестве данных ресурсного центра, разделенного между несколькими проектами и подразделениями.
И, наконец, с виртуальным оборудованием, у разработчиков программного обеспечения пропадает необходимость в наличии физических устройств и их подключении эмуляционному аппаратному обеспечению. Многие инженерные группы, использующие эмуляционное оборудование в качестве центра обработки данных, могут находиться за тысячи километров от центра системы эмуляции, который они используют.
Эмуляция оборудования должна развиваться и обрастать новыми функциями, моделями и возможностями, превращая ее в универсальный инструмент для проверки аппаратных и программных средств различных электронных изделий. Наличие виртуальных инструментов повышает привлекательность огромных центров обработки данных.