Внутрисхемная отладка ПЛИС Microsemi

Информация о продукте

Технические характеристики

• Тип устройства: Microsemi SmartFusion2 SoC FPGA
• Дата выхода: май 2014 г.
• Возможности отладки: внутрисхемная отладка ПЛИС, встроенный логический анализатор
• Максимальная частота сбора данных: до 100 МГц

Абстрактный
ПЛИС являются мощными элементами проектирования встраиваемых систем со многими преимуществами.tagда, но эти устройства могут иметь сложную конструкцию со сложными проблемами конструкции, которые необходимо отладить. Отслеживание проблем конструкции, таких как ошибки определения, проблемы взаимодействия системы и ошибки синхронизации системы, может быть сложной задачей. Включение возможностей внутрисхемной отладки в ПЛИС может значительно улучшить отладку оборудования и избежать бесчисленных часов разочарования. В этой статье описывается несколько различных подходов к внутрисхемной отладке для ПЛИС, определяются ключевые компромиссы и посредством exampПроектирование, ориентированное на устройство Microsemi SmartFusion®2 SoC FPGA, покажет, как можно использовать новые возможности для ускорения отладки и тестирования.

Введение

FPGA являются распространенными и мощными элементами дизайна и теперь встречаются практически в каждой встроенной системе. С ростом емкости, включением сложных функциональных блоков на кристалле и усовершенствованных последовательных интерфейсов эти устройства также могут иметь сложные проблемы дизайна, которые необходимо отладить. Отслеживание таких проблем, как ошибки определения функций (на уровне FPGA или системы), проблемы взаимодействия функциональных систем, проблемы синхронизации системы и проблемы точности сигнала между микросхемами (например, шум, перекрестные помехи или отражения) становится намного сложнее при использовании усовершенствованных FPGA. Моделирование, безусловно, является большой помощью в выявлении многих проблем дизайна, но многие взаимодействия в реальном мире не проявятся, пока дизайн не будет реализован в оборудовании. Было разработано несколько различных методов отладки сложных проблем дизайна для упрощения процесса. Тщательное понимание каждого из этих ключевых методов, включая различные передовыеtagэс и дезадванtagда, полезно при рассмотрении того, какая техника или комбинация техник подойдет для конкретного дизайна.
БывшийampПроект ПЛИС, предназначенный для устройства Microsemi SmartFusion2 SoC ПЛИС, может быть использован для демонстрации некоторых преимуществtagэс и дезадванtages этих стандартных методов, а также новейшие возможности отладки в схеме. Этот иллюстративный примерampВ этом разделе будет показано, как можно использовать различные методы для ускорения выявления и устранения проблем с оборудованием во время отладки оборудования.

Почему отладка ПЛИС является критически важным аспектом проектирования и разработки систем?
FPGA имеют две основные модели использования, которые отличают их от других элементов дизайна. FPGA могут использоваться в производственном продукте или могут использоваться в качестве средства разработки для проверки или прототипирования концепции производственного дизайна. При использовании в качестве производственного средства FPGA могут быть гораздо более гибкой целью, чем средства производства на базе ASIC или CPU. Это особенно важно для нового проекта, который еще не был реализован в оборудовании. Проекты с различными архитектурными вариантами могут быть легко созданы и протестированы, чтобы определить оптимальный проект. FPGA с процессорами на кристалле (SoC FPGA) также позволяют совмещать обработку на базе CPU с функциями аппаратного ускорения на базе FPGA. Эти передовыеtages может значительно сократить время, необходимое для проектирования, проверки, тестирования и анализа отказов при разработке новых продуктов.
При использовании для прототипирования проекта, возможно, для производства ASIC, гибкость FPGA является ключевым преимуществом. Фактическая аппаратная платформа, даже та, которая не работает на полной скорости, значительно упрощает получение подробных показателей производительности системы, данных анализа пропускной способности и результатов проверки концепции архитектуры. Поддержка FPGA для усиленных реализаций стандартных шин отрасли (таких как PCIe®, Gigabit Ethernet, XAUI, USB, CAN и других) упрощает тестирование, связанное с этими интерфейсами. Новейшие семейства FPGA с процессорами ARM на кристалле (SoC FPGA) упрощают прототипирование реализаций со встроенными процессорами. Ранее разработанный код процессора можно перенести в прототип, а новый код создавать параллельно с проектированием оборудования.

Это сочетание стандартного процессора со стандартными интерфейсными шинами позволяет использовать большую экосистему доступных библиотек кода, драйверов, функциональных API, операционных систем реального времени и даже полных операционных систем для гораздо более быстрого создания рабочего прототипа. Кроме того, после того, как проект будет затвердевшим, прототип FPGA может быть использован для захвата обширных наборов тестов моделирования (как для стимула, так и для ответа), которые отражают фактические системные данные. Эти наборы данных могут быть бесценными при создании окончательных симуляций для ASIC или другой производственной реализации. AdvantagИспользование ПЛИС в качестве прототипа проекта может значительно сократить время проектирования, проверки, тестирования и анализа отказов при реализации конечного продукта.
В обеих этих распространенных моделях использования ПЛИС гибкость ПЛИС как объекта проектирования является ключевым преимуществом.tagе. Это означает, что многие изменения и итерации дизайна будут нормой, и, таким образом, возможность быстрой отладки ошибок дизайна будет иметь решающее значение для включения как можно большего количества вариантов дизайна. Без эффективной отладочной возможности большая часть advantage гибкости дизайна FPGA будет уменьшена из-за дополнительного времени, необходимого для отладки. К счастью, FPGA также могут предоставлять дополнительные аппаратные функции, которые значительно упрощают отладку в реальном времени. Прежде чем рассматривать эти возможности, давайте сначала рассмотрим наиболее распространенные типы проблем, с которыми может столкнуться дизайн FPGA, чтобы у нас была надлежащая база для оценки эффективности и связанных с этим компромиссов различных инструментов отладки.

Распространенные проблемы при отладке проектов ПЛИС

Наряду с расширенными возможностями, которые привносят современные ПЛИС, связанная с этим возросшая сложность затрудняет создание безошибочных проектов. Фактически, было подсчитано, что отладка может занять более 50% цикла проектирования встроенной системы. Поскольку давление времени выхода на рынок продолжает сжимать цикл разработки, аппаратная отладка исходной системы откладывается на второй план — слишком часто предполагая, что верификация (сама по себе большой процентtage графика разработки), выловит все ошибки до первоначального запуска системы. Давайте рассмотрим несколько распространенных типов системных проблем, чтобы лучше понять трудности, с которыми столкнется типичный дизайн во время первоначального запуска системы.

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

Нарушения синхронизации также могут быть результатом низкой точности сигнала между интегральными схемами, в частности, в системах с несколькими шинами питания для каждой схемы. Низкая точность сигнала может привести к шуму сигнала, перекрестным помехам, отражениям, избыточной нагрузке и проблемам электромагнитных помех (EMI), которые часто проявляются как нарушения синхронизации. Проблемы с электропитанием, такие как переходные процессы (в частности, во время запуска или выключения системы), изменения нагрузки и высокие напряжения рассеивания мощности, также могут приводить к загадочным ошибкам, часто нелегко отследить до источника питания. Даже если конструкция полностью правильная, проблемы изготовления платы могут привести к ошибкам. Неисправные паяные соединения и неправильно прикрепленные разъемы, напримерample, может быть источником ошибок и может даже зависеть от температуры или расположения платы. Использование передовых методов упаковки FPGA может затруднить зондирование сигналов на печатной плате, поэтому простое получение доступа к желаемому сигналу часто может быть проблематичным. Часто многие проблемы проектирования не создают немедленной ошибки и должны распространяться по проекту, пока ошибка фактически не проявится. Отслеживание исходной ошибки до первопричины часто может быть разочаровывающей, сложной и трудоемкой задачей.

Напримерample, один неправильный бит в таблице перевода может не привести к ошибке, пока не пройдет много циклов. Некоторые из инструментов, которые мы обсудим далее в этой статье, которые используют специализированное внутрисхемное отладочное оборудование, специально нацелены на то, чтобы сделать эти «охоты за ошибками» более быстрыми и простыми. Прежде чем углубляться в детали этих инструментов, давайте сначала рассмотрим популярную программную отладочную технику моделирования, чтобы лучше понять advantagэс и дезадванtagПримеры использования моделирования для отладки.

Использование моделирования для отладки
Обычно при моделировании дизайна все реальные компоненты внутри и вне дизайна моделируются математически как программные процессы, которые выполняются последовательно на стандартном ЦП. Применение широкого спектра стимулов к дизайну и проверка ожидаемого вывода по сравнению с моделированным выводом дизайна — это простой способ обнаружить большинство очевидных ошибок дизайна. Окно, показывающее типичный запуск моделирования, приведено на рисунке 1 ниже. Явное преимуществоtage моделирования против аппаратной отладки заключается в том, что моделирование может быть выполнено в программном обеспечении — не требуется фактического аппаратного проектирования и испытательного стенда. Моделирование может быстро обнаружить множество ошибок проектирования, в частности, связанных с неправильными спецификациями, непониманием требований интерфейса, ошибками функций и многими другими «грубыми» типами ошибок, которые легко обнаруживаются с помощью простых векторов стимулов.

Моделирование особенно эффективно, когда проектировщику доступны обширные комбинации стимулов, а полученные результаты хорошо известны. В этих случаях моделирование может провести почти исчерпывающую проверку проекта. К сожалению, большинство проектов не имеют легкого доступа к обширным тестовым наборам, и процесс их создания может занять очень много времени. Создание тестового набора, который охватывает 100% проекта, практически невозможно для больших проектов на основе ПЛИС, и необходимо использовать сокращения, чтобы попытаться охватить ключевые элементы проекта. Другая сложность с моделированием заключается в том, что это не «реальная» реализация и она не может отлавливать асинхронные события, быстрые системные взаимодействия или нарушения синхронизации. Наконец, процесс моделирования может быть очень медленным, и если требуется много итераций, моделирование быстро становится самой трудоемкой и часто самой дорогостоящей частью процесса разработки.

В качестве альтернативы (или, возможно, лучше сказать, в качестве дополнения к моделированию) разработчики FPGA обнаружили, что они могут добавить отладочное оборудование в конструкцию FPGA, чтобы наблюдать и контролировать ключевые сигналы внутри устройства. Эти методы изначально разрабатывались как специальные подходы, но постепенно превратились в стандартную стратегию отладки оборудования. Такое использование возможностей отладки внутри схемы дает значительные преимуществаtages для проектов на основе ПЛИС, а в следующем разделе будут рассмотрены три наиболее распространенные стратегии и их различные преимущества.tagэс и дезадванtagес.

Распространенные подходы к внутрисхемной отладке для ПЛИС
Наиболее распространенные методы реализации возможностей отладки в схеме FPGA используют встроенный логический анализатор, внешнее испытательное оборудование или специализированное оборудование для зондирования сигналов, встроенное в структуру FPGA. Встроенный логический анализатор обычно реализуется с использованием структуры FPGA и вставляется в проект. JTAG порт используется для доступа к анализатору, а полученные данные могут быть отображены на ПК. При использовании внешнего тестового оборудования тестируемая конструкция ПЛИС модифицируется таким образом, чтобы выбранные внутренние сигналы ПЛИС направлялись на выходные контакты. Затем эти контакты можно наблюдать через внешнее тестовое оборудование. При использовании специального оборудования для зондирования сигналов широкий выбор внутренних сигналов может быть считан в реальном времени. Некоторые реализации зондов могут даже использоваться для записи в регистры или ячейки памяти, что еще больше расширяет возможности отладки. Давайте рассмотрим более подробно передовыеtagэс и дезадванtages каждого из этих методов, а затем посмотрите на примерample design, чтобы увидеть, как эти различные подходы могут повлиять на общее время отладки.

Внутрисхемный отладчик ПЛИС - встроенный логический анализатор
Концепция встроенного логического анализатора стала прямым результатом возможностей отладки в схеме ad-hoc, которые разработчики реализовали, когда впервые появились ПЛИС. Встроенные логические анализаторы добавили новые возможности и устранили необходимость для разработчика разрабатывать собственный анализатор. Большинство ПЛИС предлагают эти возможности, а сторонние компании предлагают стандартные анализаторы (Identify® от Synopsys — один из популярных эксample), которые могут легко взаимодействовать с инструментами более высокого уровня для дальнейшего повышения производительности.

Функциональность логического анализатора вставляется в проект, используя структуру FPGA и встроенные блоки памяти в качестве буферов трассировки, как показано на рисунке 2. Также создаются ресурсы запуска, чтобы можно было легко выбирать и захватывать сложные взаимодействия сигналов. Доступ к анализатору для управления и передачи данных обычно осуществляется через стандартный JTAG порт для упрощения требований к интерфейсу. Полученные данные могут быть отображены на ПК с использованием общего viewпрограммное обеспечение и обычно отражает выходной сигнал логического симулятора viewстиль.

AdvantagПреимущества этого подхода в том, что не используются дополнительные контакты ввода-вывода ПЛИС, а только стандартные контакты JTAG сигналы. Ядра IP встроенного логического анализатора обычно относительно недороги и в некоторых случаях могут быть опцией для существующих инструментов синтеза FPGA или моделирования. В некоторых случаях встроенный логический анализатор может также предоставлять дополнительные выходы на неиспользуемых входах/выходах, если это удобнее. Один из недостатковtages этого подхода заключается в том, что требуется большое количество ресурсов FPGA. В частности, если используются буферы трассировки, это уменьшит количество доступных блоков памяти. Если необходим широкий буфер, это также будет компромиссом против глубины памяти (поскольку использование более широкой памяти приводит к меньшей глубине памяти) — большой недостатокtage при использовании меньших устройств. Возможно, самым большим недостатком этого метода является то, что каждый раз при изменении размещения зондов необходимо перекомпилировать и перепрограммировать конструкцию. При использовании большого устройства этот процесс может занять значительное время. Из-за способа размещения зондов сигналов в конструкции может быть сложно сопоставить временные соотношения сигналов. Кроме того, задержки между зондами сигналов не являются постоянными, и поэтому временные соотношения трудно сравнивать. Это представляет особую сложность при сравнении асинхронных сигналов или сигналов из разных временных областей.

Внутрисхемная отладка ПЛИС – внешнее тестовое оборудование
Использование кода отладки внутри схемы в сочетании с внешним испытательным оборудованием было естественным развитием, когда внешний логический анализатор уже был доступен для системного тестирования. Создав простой код отладки для идентификации и выбора внутренних тестовых сигналов и применения их к вводам/выводам ПЛИС, как показано на рисунке 3, можно было использовать расширенные возможности анализатора (такие как большие буферы трассировки, сложные последовательности запуска и множественные viewing options) для создания простых, но мощных сред отладки. Более сложные внутрисхемные возможности для расширенных опций запуска могут минимизировать количество необходимых выходов. Напримерample, выбор конкретных адресов на широкой шине может оказаться невозможным, если требуются внешние контакты.
Использование внутренней логики FPGA значительно снижает требования к вводу/выводу и может даже искать определенные шаблоны адресов (возможно, последовательность вызова и возврата) для отладки более сложных проблем. Если доступен общий пользовательский интерфейс, это может упростить кривую обучения и повысить производительность.

AdvantagПреимущества этого подхода в том, что он использует стоимость внешнего испытательного оборудования, и, таким образом, нет дополнительных затрат на инструмент. Некоторые ядра IP отладочной схемы доступны у производителей оборудования или производителей ПЛИС и могут быть очень дешевыми или даже бесплатными. Количество ресурсов ПЛИС, необходимых для реализации логики выбора сигнала, очень мало, и поскольку функция трассировки выполняется с использованием внешнего логического анализатора, не требуется никакой блочной памяти. Поскольку логика выбора недорога, может также поддерживаться большое количество каналов с широким запуском. Логический анализатор может работать как в режиме синхронизации, так и в режиме состояния, что помогает изолировать некоторые проблемы синхронизации.
ДисадванtagНедостатком такого подхода может быть необходимость приобретения логического анализатора, если он еще не выделен для проекта. Этот недостатокtage может быть достаточно, чтобы отговорить от этого подхода во многих случаях. Обратите внимание, однако, что некоторые недорогие варианты логических анализаторов становятся доступными, которые используют ПК или планшет для отображения, что делает этот вариант гораздо более экономически эффективным для простых требований отладки.
Количество потребляемых выводов ПЛИС может быть еще одним недостатком.tage и если необходимо наблюдать за широкими шинами, необходимо значительное планирование компоновки платы и добавление отладочных разъемов. Это требование в большинстве случаев трудно предсказать на ранней стадии проектирования и является еще одной нежелательной сложностью. Подобно подходу встроенного логического анализатора, стратегия внешнего тестирования требует перекомпиляции и перепрограммирования проекта, когда требуется каждый новый эксперимент.

Общий недостатокtagПреимущества этих двух методов — использование ресурсов на кристалле (что также может повлиять на временные характеристики конструкции и создать дополнительные требования к отладке), необходимость перекомпиляции и перепрограммирования конструкции (что может добавить часы или даже дни к графику отладки), предварительное планирование, необходимое для определения вероятных сценариев тестирования, и использование дополнительных ресурсов ввода-вывода кристалла создали потребность в подходе без этих недостатков. Одним из ответов стало добавление выделенной отладочной логики в структуру FPGA на некоторых устройствах. Результатом стала внутрисхемная отладка с использованием аппаратных зондов.

Внутрисхемная отладка ПЛИС – аппаратные датчики
Использование аппаратных зондов значительно упрощает методы внутрисхемной отладки для ПЛИС. Эта техника, реализованная как функция Live Probe на устройствах SmartFusion2®SoC FPGA и IGLOO®2 FPGA, добавляет выделенные линии зонда в структуру ПЛИС для наблюдения за выходом любого бита регистра логического элемента. Как показано на блок-схеме на рисунке 4, аппаратные зонды доступны в двух каналах зонда A и B.

Выбранные выходы регистра (точки зонда), как и тот, который находится в нижней части рисунка, направляются над двумя каналами зонда и, если выбрано, могут быть применены либо к каналу A, либо к каналу B. Эти сигналы каналов реального времени затем могут быть отправлены на выделенные контакты Probe A и Probe B на устройстве. Сигналы Probe A и Probe B также могут быть внутренне направлены на встроенный логический анализатор.

Обратите внимание, что временные характеристики штырьков зонда являются регулярными и имеют незначительное отклонение от одной точки зонда к другой, что значительно упрощает сравнение временных характеристик сигналов реального времени. Данные могут быть получены на частоте до 100 МГц, что делает их подходящими для большинства целевых конструкций.
Возможно, самое важное — это то, что местоположения точек зонда, поскольку они не выбираются как часть реализованного проекта (они выбираются через выделенное оборудование, пока проект выполняется на ПЛИС), можно быстро изменить, просто отправив данные выбора на устройство. Не требуется перекомпиляция и перепрограммирование проекта.
Чтобы еще больше упростить использование функции Live Probe, соответствующий инструмент отладочного программного обеспечения имеет доступ ко всем местоположениям сигналов зонда через автоматически сгенерированный отладочный файл. file. Как показано на рисунке 5, имя сигнала можно выбрать из списка сигналов и применить к нужному каналу. Это можно сделать даже во время работы проекта, чтобы зондирование в проекте было непрерывным и очень эффективным.

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

Как показано на рисунке 6, возможность Live Probe выбирать сигналы «на лету» позволяет быстро и легко изменять наблюдаемые сигналы без необходимости перекомпиляции проекта. Внешний логический анализатор или осциллограф может легко наблюдать за зондируемыми сигналами, как показано в верхней правой части рисунка на выделенных выходных контактах зонда. В качестве альтернативы (или, может быть, даже в дополнение) можно использовать внутренний логический анализатор (блок идентификации ILA, показанный на рисунке) для наблюдения за контактами зонда. Сигналы зонда могут быть захвачены ILA и наблюдаться в окне формы сигнала. Расположение зондов можно изменять без необходимости перекомпиляции целевого проекта.
Обратите внимание, что дополнительные возможности запуска и трассировки можно использовать для улучшения функциональности зонда, что упрощает обнаружение даже сложных проблем в конструкции.

Дополнительные возможности отладки оборудования также доступны на устройствах SmartFusion2 SoC FPGA и IGLOO2 FPGA. Одна из этих возможностей, называемая Active Probe, может динамически и асинхронно считывать или записывать в любой бит регистра логического элемента. Записанное значение сохраняется в течение одного тактового цикла, поэтому нормальная работа может продолжаться, что делает его очень ценным инструментом отладки. Active Probe представляет особый интерес, если требуется быстрое наблюдение за внутренним сигналом (возможно, просто для проверки того, что он активен или находится в желаемом состоянии, как сигнал сброса), или если необходимо быстро протестировать логическую функцию, записав в точку зонда
(возможно, для инициирования перехода конечного автомата путем быстрой установки входного значения для изоляции проблемы потока управления).

Другая отладочная возможность, предоставляемая Microsemi, — это отладка памяти. Эта функция позволяет разработчику динамически и асинхронно считывать или записывать данные в выбранный блок SRAM-матрицы FPGA. Как показано на снимке экрана инструмента отладки (рисунок 7), при выборе вкладки «Блоки памяти» пользователь может выбрать нужную память для считывания, выполнить снимок памяти, изменить значения памяти, а затем записать значения обратно на устройство. Это может быть особенно полезно для проверки или настройки буферов данных, используемых в портах связи для ориентированного на вычисления блокнота или даже для кода, выполняемого встроенным ЦП. Отладка сложных ошибок, зависящих от данных, значительно ускоряется и упрощается, когда память можно наблюдать и контролировать так быстро.

После отладки проекта может быть желательно отключить возможности отладки оборудования для защиты конфиденциальной информации. Злоумышленник может использовать эти же возможности для считывания критически важной информации или изменения системных настроек, которые могут обеспечить легкий доступ к конфиденциальным частям системы. Microsemi добавила функции, позволяющие разработчику защитить устройство после завершения отладки. Напримерample, доступ к Live Probe и Active Probe может быть заблокирован, чтобы полностью отключить функцию как возможное средство атаки (это даже исключает возможность активности зонда, создающей какие-либо шаблоны в токе питания, которые могут быть использованы для попытки косвенного наблюдения за данными зонда). В качестве альтернативы, доступ к выбранным частям проекта может быть заблокирован, чтобы предотвратить доступ только к этим разделам. Это может быть удобно, если только часть проекта должна быть защищена, оставляя остальную часть проекта доступной для полевых испытаний или анализа ошибок.

Сравнительная таблица внутрисхемной отладки
Теперь, когда есть подробный отчетview Из трех основных методов отладки внутрисхемного оборудования была создана сводная диаграмма, показанная на рисунке 8, которая подробно описывает различные преимущества.tagэс и дезадванtages каждого метода. Помня, что некоторые методы могут использоваться совместно (Live Probe и Internal Logic Analyzer (ILA), например, Synopsys Identify, например)ample), мы можем увидеть основные сильные и слабые стороны каждой методики. Набор возможностей отладки внутрисхемного оборудования (Live Probe, Active Probe и Memory Debug — совместно называемые SmartDebug) являются самыми слабыми по сравнению с другими методиками, когда речь идет о количестве доступных зондов (красный круг), и слабее лучших (желтый круг), когда рассматривается скорость захвата (внешнее тестовое оборудование может быть быстрее).
Методы на основе ILA, такие как Synopsys Identify, являются самыми слабыми по сравнению с другими методами и при рассмотрении требований к ресурсам FPGA. Методы на основе внешнего тестового оборудования являются самыми слабыми по ряду соображений, включая стоимость, влияние сроков проектирования и накладные расходы на перемещение зонда (из-за необходимости перекомпилировать проект). Возможно, оптимальным решением является сочетание SmartDebug и одного из других методов, так что слабость SmartDebug в количестве каналов может быть смягчена, а недостаток перемещения точки зондаtagТакже сократились и другие методы.

Классификации сигналов
Можно провести полезное различие между некоторыми наиболее распространенными типами сигналов, и это может помочь при планировании подхода к отладке. Напримерample, сигналы, которые не изменяются, кроме как во время запуска системы, такие как сброс системы, сброс блока или регистры инициализации, можно классифицировать как статические сигналы. К этим типам сигналов наиболее эффективно получить доступ через средство, которое может легко наблюдать, а также управлять сигналом, без необходимости в длительном цикле перекомпиляции. Active Probe — превосходное средство для отладки статических сигналов. Аналогично, сигналы, которые изменяются чаще, но остаются статичными большую часть времени, можно классифицировать как псевдостатические и также наиболее эффективно отлаживать с помощью Active Probe. Сигналы, которые часто изменяются, такие как сигналы часов, можно классифицировать как динамические и к ним не так легко получить доступ через Active Probe. Live Probe — лучший выбор для наблюдения за этими сигналами.

Простой пример использования отладки

Теперь, когда мы лучше понимаем различные варианты внутрисхемной отладки, давайте рассмотрим простую конструкцию.ample, чтобы увидеть, как работают эти методы. На рисунке 9 показана простая конструкция FPGA в устройстве SmartFusion2 SoC FPGA. Подсистема микроконтроллера (MSS) сбрасывается блоком CoreSF2Reset Soft IP. Входами этого блока являются сброс при включении питания, сброс пользовательской структуры и внешний сброс. Выходами являются сброс пользовательской структуры, сброс MSS и сброс M3. Симптомы ошибки заключаются в том, что на входах/выходах нет активности, хотя устройство успешно выходит из состояния POR. На рисунке также показаны три различных варианта отладки этой ошибки: синий ящик (обозначенный ETE) предназначен для метода внешнего тестового оборудования; зеленый ящик (обозначенный ILA) предназначен для метода внутреннего логического анализатора; и оранжевый ящик (обозначенный AP) предназначен для метода активного зонда. Мы предполагаем, что потенциальными первопричинами ошибки являются неправильно утвержденные входы сброса в блоке CoreSF2Reset Soft IP.

Давайте теперь рассмотрим процесс отладки для трех ранее описанных внутрисхемных методов.

Внешнее испытательное оборудование
Используя этот метод, предполагается, что тестовое оборудование доступно и не используется более приоритетным проектом. Кроме того, важно заранее спланировать, чтобы некоторые входы/выходы ПЛИС были доступны и могли быть легко подключены к тестовому оборудованию. Наличие заголовка на печатной плате, напримерample, было бы очень полезно и минимизировало бы время, потраченное на попытки идентифицировать и подключиться к «вероятному подозреваемому» или потенциальному замыканию контактов во время зондирования. Проект необходимо будет перекомпилировать, чтобы выбрать сигналы, которые мы хотим исследовать. Надеюсь, нам не придется «снимать луковицу» и выбирать дополнительные сигналы для дальнейшего исследования, поскольку часто наше первоначальное исследование приводит только к большему количеству вопросов. В любом случае, процесс перекомпиляции и перепрограммирования может занять значительное количество времени, и если он приводит к нарушениям синхронизации, требуется перепроектирование (мы все знаем, насколько утомительной может быть попытка решить проблемы с замыканием синхронизации, в частности, когда вы вносите изменения в проект, чтобы найти ошибку в проекте — весь процесс может занять от нескольких минут до нескольких часов)! Также важно помнить, что если в проекте нет свободных пользовательских вводов-выводов, этот метод не может быть реализован. Более того, этот метод структурно навязчив в проекте — и ошибки, связанные с синхронизацией, могут исчезать или появляться снова между итерациями.

Внутренний логический анализатор
Используя этот метод, ILA необходимо вставить в проект с использованием ресурсов структуры, а затем перекомпилировать. Обратите внимание, что если ILA уже был создан, сигналы, которые мы хотим исследовать, могли не быть инструментированы, что также потребует перекомпиляции. Этот процесс рискует изменить исходный проект и нарушить временные ограничения. Если временные ограничения соблюдены, проект необходимо перепрограммировать и повторно инициализировать. Весь этот процесс может занять несколько минут или даже часов, если время перекомпиляции велико и требуется несколько проходов. Этот подход является структурно навязчивым и может привести к проблемам, аналогичным тем, которые описаны при использовании вышеприведенного метода.

Активный зонд
Используя этот метод, Active Probe может быть направлен на источник различных сигналов сброса, все из которых поступают от выходов регистров (как это принято в любой хорошей практике цифрового проектирования). Сигналы выбираются по одному из меню Active Probe, показанного на рисунке 10 ниже. Выбранные значения сигналов могут быть считаны и отображены в окне данных Active Probe. Любые неверные утверждения легко идентифицируются. Этот тест может быть выполнен немедленно, без необходимости перекомпилировать и перепрограммировать устройство, и он не является структурно или процедурно навязчивым. Весь процесс занимает всего несколько секунд. Этот метод также может создать управляемость (изменение значений асинхронно), которую не позволят два других метода. В этом конкретном примереampт. е. сигнал сброса, поступающий от регистра, можно легко проверить и обнаружить, что он находится в активном состоянии.

Мгновенное переключение сигнала сброса может быть достигнуто путем асинхронного манипулирования регистром, генерирующим сигналы сброса.

Более сложный вариант использования отладки
Представленный выше проект очень прост и полезен в качестве введения в использование описанных методов проектирования, но более сложный примерample может быть еще более показательным. Во многих случаях интересующий сигнал не является статическим сигналом, как это было в нашем простом example, но является динамическим. Обычный динамический сигнал — это промежуточные часы, возможно, используемые для синхронизации рукопожатия для последовательного интерфейса. На рисунке 11 показана такая конструкция с пользовательским ядром Soft IP, в данном случае — настраиваемым последовательным интерфейсом, подключенным к системной шине APB. Симптомы ошибок заключаются в том, что на пользовательском последовательном интерфейсе нет активности, и что когда мастер шины APB инициирует транзакцию для доступа к последовательному интерфейсу, он переходит в состояние исключения, указывающее на неправильное рукопожатие. Эти условия, по-видимому, исключают статическую причину, такую ​​как неправильный сигнал сброса, поскольку конечный автомат транзакции, по-видимому, не работает с ожидаемой скоростью и, таким образом, вызывает исключение. Предполагается, что первопричиной является генератор тактовой частоты в пользовательском ядре IP.

Если он не работает на правильной частоте, могут возникнуть описанные ошибки.

В этой ситуации, вероятно, лучшей стратегией будет заменить подход Active Probe на Live Probe. Это показано на рисунке выше оранжевым полем LP, с использованием JTAG сигнал для выбора источника зонда.

Внешнее испытательное оборудование
В этом случае методология очень похожа на ранее описанный простой пример.ample. Пользовательский тактовый сигнал выводится на контрольную точку (надеюсь, на заголовок), и требуется длительная перекомпиляция. Также может быть полезно вывести опорный сигнал, возможно, системный тактовый сигнал, который используется для синхронизации IP пользователя в качестве сигнала сравнения. Мы снова столкнемся с необходимостью перекомпиляции и перепрограммирования, поэтому весь процесс может занять значительное количество времени.

Внутренний логический анализатор
Этот случай очень похож на простой пример.ample. ILA должен быть вставлен или определен желаемый сигнал, а также выполнен цикл перекомпиляции и перепрограммирования. Все ранее описанные проблемы по-прежнему приводят к значительному времени цикла отладки. Однако есть дополнительная сложность. Часы, которые управляют ILA, должны быть синхронными и, в идеале, намного быстрее по отношению к часам, которые будут наблюдаться из ядра Soft IP пользователя. Если эти часы асинхронны или не имеют правильных временных соотношений, сбор данных будет непредсказуемым и возможным источником путаницы для процесса отладки.
Обратите внимание, что если пользовательский Soft IP-тактовый сигнал не генерируется на кристалле (возможно, он восстанавливается из последовательного интерфейса), разработчику может потребоваться добавить модуль тактового сигнала для генерации более быстрого тактового сигнала ILA с использованием дополнительных ресурсов и, возможно, создания нарушения синхронизации.

Живой зонд
Используя этот метод, Live Probe может быть быстро направлен на источник пользовательских часов и любой другой источник часов из регистра, чтобы отследить основную причину ошибки. Live Probe покажет выбранные выходные сигналы в реальном времени, и таким образом будет намного проще определить любые временные соотношения между сигналами. Весь процесс занимает всего несколько секунд.

Другие функции отладки для последовательных интерфейсов
Также важно отметить, что в устройствах SmartFusion2 SoC FPGA и IGLOO2 FPGA имеется множество дополнительных возможностей отладки, которые можно использовать на последовательных интерфейсах, как в предыдущем примере.ample дизайн, где ошибки еще более сложны. SERDES Debug, напримерample, предоставляет специальные возможности отладки для выделенных высокоскоростных последовательных интерфейсов. Некоторые из функций отладки SERDES включают поддержку теста PMA (например, генерацию шаблонов PRBS и тестирование обратной связи), поддержку нескольких конфигураций теста SERDES с реконфигурацией на уровне регистров, чтобы избежать использования полного потока проектирования для внесения изменений в конфигурацию, и текстовые отчеты, показывающие настроенные протоколы, регистры конфигурации SERDES и регистры конфигурации Lane. Эти функции значительно упрощают отладку SERDES и могут использоваться совместно с Live Probe и Active Probe для дальнейшего ускорения отладки сложных схем.
Ранее описанный инструмент отладки памяти также может использоваться в сочетании с отладкой SERDES для ускорения тестирования. Поскольку буферы памяти можно быстро и легко проверять и изменять с помощью отладки памяти, можно быстро создавать «тестовые пакеты» и наблюдать результаты обратной связи или межсистемных коммуникаций. Разработчик может использовать эти возможности и, таким образом, минимизировать необходимость в специализированных «тестовых жгутах», которые потребляют дополнительную структуру FPGA и могут повлиять на синхронизацию чипа.

Заключение
В этой статье подробно описаны несколько различных подходов к реализации внутрисхемной отладки для ПЛИС и СнК ПЛИС — использование интегрированного логического анализатора, использование внешнего испытательного оборудования и использование специализированных схем зондирования, интегрированных в структуру ПЛИС. Было показано, что добавление специализированных и специализированных схем зондирования, таких как Active Probe и Live Probe, предлагаемых Microsemi на устройствах SmartFusion2 SoC ПЛИС и IGLOO2 ПЛИС, значительно ускоряет и упрощает процесс отладки. Было показано, что возможность быстро изменять выбор внутренних сигналов (без необходимости выполнять очень трудоемкий цикл перекомпиляции и перепрограммирования) и возможность зондирования внутренних сигналов (без необходимости использовать структуру ПЛИС и потенциально вносить нарушения синхронизации) являются основными преимуществамиtages при отладке проектов FPGA. Кроме того, было описано использование нескольких методологий, которые могут работать вместе, чтобы обеспечить еще более комплексные возможности отладки. Наконец, два примераampДля иллюстрации компромиссов между описанными методами были приведены примеры использования отладки.

Узнать больше

1. ПЛИС IGLOO2
2. SmartFusion2 SoC FPGA

Корпорация Microsemi (Nasdaq: MSCC) предлагает комплексный портфель полупроводниковых и системных решений для связи, обороны и безопасности, аэрокосмической и промышленной отраслей. Продукты включают в себя высокопроизводительные и радиационно-стойкие аналоговые интегральные схемы со смешанными сигналами, FPGA, SoC и ASIC; продукты управления питанием; устройства хронометража и синхронизации, а также решения для точного времени, устанавливающие мировой стандарт времени; устройства обработки голоса; РЧ-решения; дискретные компоненты; технологии безопасности и масштабируемая защита отamper продукты; ИС Power-over-Ethernet и промежуточные модули; а также возможности и услуги индивидуального проектирования. Штаб-квартира Microsemi находится в Алисо Вьехо, Калифорния, и насчитывает около 3,400 сотрудников по всему миру. Узнайте больше на www.microsemi.com.

© 2014 Корпорация Microsemi. Все права защищены. Microsemi и логотип Microsemi являются товарными знаками корпорации Microsemi. Все другие товарные знаки и знаки обслуживания являются собственностью их соответствующих владельцев.

Штаб-квартира корпорации Microsemi

• Один Предприятие, Алисо-Вьехо, Калифорния 92656, США
• В пределах США: +1 800-713-4113
• Снаружи США: +1 949-380-6100
• Продажи: +1 949-380-6136
• Факс: +1 949-215-4996
• Электронная почта: sales.support@microsemi.com

Часто задаваемые вопросы

• В: Какова максимальная частота сбора данных устройством?
  A: Устройство поддерживает сбор данных на частоте до 100 МГц, что подходит для большинства целевых конструкций.
• В: Нужно ли перекомпилировать проект при использовании схем датчиков для отладки?
  A: Нет, расположение точек датчика можно быстро изменить без необходимости перекомпиляции проекта или перепрограммирования.

Документы/Ресурсы

Внутрисхемная отладка ПЛИС Microsemi [pdf] Инструкции Внутрисхемная отладка ПЛИС, отладка ПЛИС, отладка

Ссылки

• Руководство пользователя