Статьи и публикации
Разработка и тестирование целочисленного сумматора с AXI-Stream интерфейсами. Часть 1
Введение
В данном цикле статей будет представлен процесс разработки и тестирования RTL-модулей на языке Verilog. В качестве примера будет рассмотрен целочисленный сумматор с AXI-Stream интерфейсами. Мы разберем некоторые приемы и паттерны, часто используемые при проектировании цифровых устройств. Также мы покажем типовую структуру тестового окружения для проверки RTL-модулей.
Описанное нами окружение будет состоять из отдельных компонентов, у каждого из которых будет своя конкретная задача. При правильном подходе к разработке этих компонентов их можно будет повторно использовать в других тестовых окружениях. Мы начнем двигаться от простого к сложному и для начала разработаем целочисленный сумматор с сигналами валидности для входных и выходных данных.
В данном цикле статей будет представлен процесс разработки и тестирования RTL-модулей на языке Verilog. В качестве примера будет рассмотрен целочисленный сумматор с AXI-Stream интерфейсами. Мы разберем некоторые приемы и паттерны, часто используемые при проектировании цифровых устройств. Также мы покажем типовую структуру тестового окружения для проверки RTL-модулей.
Описанное нами окружение будет состоять из отдельных компонентов, у каждого из которых будет своя конкретная задача. При правильном подходе к разработке этих компонентов их можно будет повторно использовать в других тестовых окружениях. Мы начнем двигаться от простого к сложному и для начала разработаем целочисленный сумматор с сигналами валидности для входных и выходных данных.
Разработка и тестирование целочисленного сумматора с AXI-Stream интерфейсами. Часть 2
Введение
В предыдущей части мы разработали целочисленный сумматор с сигналами валидности входных и выходных данных. Однако, на практике довольно часто приходится организовывать более сложное взаимодействие между модулями. Недостатком нашего сумматора является то, что при выдаче данных он не проверяет, готов ли приемник их получить. Это может привести к потере результатов суммирования и некорректной работе всего устройства. Чтобы избежать потери данных при передаче, нужны дополнительные управляющие сигналы, которые формируют протокол взаимодействия между модулями. Простым и очень популярным интерфейсом является AXI-Stream, поэтому его мы и рассмотрим.
AXI-Stream интерфейс
В своем самом простом виде AXI-Stream интерфейс состоит всего из трех сигналов:
В предыдущей части мы разработали целочисленный сумматор с сигналами валидности входных и выходных данных. Однако, на практике довольно часто приходится организовывать более сложное взаимодействие между модулями. Недостатком нашего сумматора является то, что при выдаче данных он не проверяет, готов ли приемник их получить. Это может привести к потере результатов суммирования и некорректной работе всего устройства. Чтобы избежать потери данных при передаче, нужны дополнительные управляющие сигналы, которые формируют протокол взаимодействия между модулями. Простым и очень популярным интерфейсом является AXI-Stream, поэтому его мы и рассмотрим.
AXI-Stream интерфейс
В своем самом простом виде AXI-Stream интерфейс состоит всего из трех сигналов:
Разработка и тестирование целочисленного сумматора с AXI-Stream интерфейсами. Часть 3
Введение
В предыдущей статье мы познакомились с основами работы AXI-Stream протокола и модифицировали наш сумматор, чтобы он был совместим с этим интерфейсом. Также было отмечено, что из-за увеличения сложности сумматора встает проблема в его тестировании. Напрямую генерировать все возможные входные воздействия достаточно сложно из-за большого количества их различных вариантов. Еще утомительней каждый раз вручную просматривать временные диаграммы в поисках ошибок. Нам нужен другой подход, и именно это мы будем обсуждать в этой статье.
Direct Testing
Для начала рассмотрим метод, который чаще всего применяется начинающими разработчиками для проверки своих модулей. В качестве примера возьмем простой комбинационный сумматор. Напишем тестовое окружение, которое будет подавать на входы сумматора несколько пар слагаемых, имеющих наперед заданные значения. Такое окружение, например, может иметь следующий вид:
В предыдущей статье мы познакомились с основами работы AXI-Stream протокола и модифицировали наш сумматор, чтобы он был совместим с этим интерфейсом. Также было отмечено, что из-за увеличения сложности сумматора встает проблема в его тестировании. Напрямую генерировать все возможные входные воздействия достаточно сложно из-за большого количества их различных вариантов. Еще утомительней каждый раз вручную просматривать временные диаграммы в поисках ошибок. Нам нужен другой подход, и именно это мы будем обсуждать в этой статье.
Direct Testing
Для начала рассмотрим метод, который чаще всего применяется начинающими разработчиками для проверки своих модулей. В качестве примера возьмем простой комбинационный сумматор. Напишем тестовое окружение, которое будет подавать на входы сумматора несколько пар слагаемых, имеющих наперед заданные значения. Такое окружение, например, может иметь следующий вид:
Разработка и тестирование целочисленного сумматора с AXI-Stream интерфейсами. Часть 4
Введение
В предыдущей части был рассмотрен основной подход, применяемым для тестирования сложных цифровых устройств - constraint random testing. Мы узнали, как автоматизировать проверку корректности работы устройства с помощью сравнения его выходов с эталонной моделью. Тестовые окружения, работающие по такому принципу, называются self-test testbench. Мы увидели из каких компонентов строятся тестовые окружения и разработали структуру окружения для проверки сумматора с AXI-Stream интерфейсами. В этой статье мы перейдем от теории к практике и покажем, как реализовать это окружение на языке Verilog.
Тестовое окружение для проверки сумматора
Напомним структуру тестового окружения, которое мы хотим описать.
В предыдущей части был рассмотрен основной подход, применяемым для тестирования сложных цифровых устройств - constraint random testing. Мы узнали, как автоматизировать проверку корректности работы устройства с помощью сравнения его выходов с эталонной моделью. Тестовые окружения, работающие по такому принципу, называются self-test testbench. Мы увидели из каких компонентов строятся тестовые окружения и разработали структуру окружения для проверки сумматора с AXI-Stream интерфейсами. В этой статье мы перейдем от теории к практике и покажем, как реализовать это окружение на языке Verilog.
Тестовое окружение для проверки сумматора
Напомним структуру тестового окружения, которое мы хотим описать.
Разработка и тестирование целочисленного сумматора с AXI-Stream интерфейсами. Часть 5
Введение
Этой частью завершается серия статей, рассказывающих о разработке и тестировании сумматора с AXI-Stream интерфейсами. Мы покажем, как можно улучшить тестовое окружение за счет добавления возможности его настройки без повторной перекомпиляции исходников. Также мы модифицируем драйверы и мониторы AXI-Stream интерфейса, чтобы их можно было повторно использовать в других окружениях и проектах.
Настройка окружения с помощью +args
В текущей реализации тестового окружения все настройки вынесены в отдельный файл tb_defines.vh, и их значения задаются с помощью директивы ``define`. Это может вызывать некоторые неудобства, так как конкретные значения параметров окружения должны быть известны уже на этапе компиляции. Если мы, например, захотим изменить настройки сторожевого таймер, то нам придется заново пересобирать всё окружение. Для больших проектов эта процедура может занимать много времени, поэтому на нужен другой подход.
Этой частью завершается серия статей, рассказывающих о разработке и тестировании сумматора с AXI-Stream интерфейсами. Мы покажем, как можно улучшить тестовое окружение за счет добавления возможности его настройки без повторной перекомпиляции исходников. Также мы модифицируем драйверы и мониторы AXI-Stream интерфейса, чтобы их можно было повторно использовать в других окружениях и проектах.
Настройка окружения с помощью +args
В текущей реализации тестового окружения все настройки вынесены в отдельный файл tb_defines.vh, и их значения задаются с помощью директивы ``define`. Это может вызывать некоторые неудобства, так как конкретные значения параметров окружения должны быть известны уже на этапе компиляции. Если мы, например, захотим изменить настройки сторожевого таймер, то нам придется заново пересобирать всё окружение. Для больших проектов эта процедура может занимать много времени, поэтому на нужен другой подход.
Реализация Avalon-MM Master в виде конечного автомата на VHDL
Введение
Шина Avalon-MM является одной из стандартных шин передачи данных, используемых в ПЛИС фирмы Intel. Использование этой шины в своих модулях для передачи данных существенно повышает их возможность повторного применения и повышает надежность проектов. Также упрощается интеграция модулей в проект с помощью Platform Designer.
Принципы работы шины Avalon-MM
Шина Avalon-MM используется для передачи данных между модулями проекта. Она позволяет выполнять запись данных в модуль либо чтение данных из модуля обращаясь к нему как к блоку памяти.
На шине Avalon-MM существует определенная иерархия модулей. Обязательно должен быть контроллер - Master, который управляет всеми транзакциями передачи данных по шине. Остальные модули выступают в роли подчиненных - Slave. Каждый Slave на шине имеет определенный адрес или диапазон адресов, в которые Master может писать данные или читать из этих адресов. На рис. 1 представлен вариант конфигурации шины Avalon-MM.
Шина Avalon-MM является одной из стандартных шин передачи данных, используемых в ПЛИС фирмы Intel. Использование этой шины в своих модулях для передачи данных существенно повышает их возможность повторного применения и повышает надежность проектов. Также упрощается интеграция модулей в проект с помощью Platform Designer.
Принципы работы шины Avalon-MM
Шина Avalon-MM используется для передачи данных между модулями проекта. Она позволяет выполнять запись данных в модуль либо чтение данных из модуля обращаясь к нему как к блоку памяти.
На шине Avalon-MM существует определенная иерархия модулей. Обязательно должен быть контроллер - Master, который управляет всеми транзакциями передачи данных по шине. Остальные модули выступают в роли подчиненных - Slave. Каждый Slave на шине имеет определенный адрес или диапазон адресов, в которые Master может писать данные или читать из этих адресов. На рис. 1 представлен вариант конфигурации шины Avalon-MM.
Реализация кодека 66b/64b на языке VHDL
Введение
В протоколах передачи данных для стабильной работы используются кодеки, выбранные разработчиками с учётом следующих требований:
В протоколах передачи данных для стабильной работы используются кодеки, выбранные разработчиками с учётом следующих требований:
- равномерное распределение 0 и 1 в канале
- простота кодирования/декодирования
- иметь небольшую избыточность
- Ethernet (10,40,100G)
- Common Public Radio Interface
- Fibre Channel (10G, 16G)
- Infiniband (FDR, EDR)
- Thunderbolt
Непрерывная интеграция при разработке RTL-модулей
Введение
Создание цифровых устройств, как правило, представляет из себя итеративный процесс. Требования к устройству частично могут измениться уже на этапе его разработки. Также часто приходится модифицировать RTL-код после получения отчетов от инструментов синтеза и имплементации. По этой причине желательно предпринять определенные шаги для облегчения поддержки кода и внесения возможных изменений. Иными словами, нужно настроить процесс непрерывной интеграции. В этой статье на примере Github Actions и разработанного нами ранее сумматора с AXI-Stream интерфейсами мы поговорим о том, как может выглядеть процесс непрерывной интеграции при создании цифровых устройств.
GitHub Flow
Для начала кратко рассмотрим, каким образом обычно ведется современная разработка RTL-модулей. Так как сейчас цифровое устройство представляет из себя код на одном из языков описания аппаратуры, для его сопровождения необходимо пользоваться системой контроля версий. На текущий момент наиболее популярной системой является Git. Есть несколько подходов ее использования, но мы остановимся, наверное, на самом простом, который называется GitHub Flow. Давайте рассмотрим, что он из себя представляет.
Создание цифровых устройств, как правило, представляет из себя итеративный процесс. Требования к устройству частично могут измениться уже на этапе его разработки. Также часто приходится модифицировать RTL-код после получения отчетов от инструментов синтеза и имплементации. По этой причине желательно предпринять определенные шаги для облегчения поддержки кода и внесения возможных изменений. Иными словами, нужно настроить процесс непрерывной интеграции. В этой статье на примере Github Actions и разработанного нами ранее сумматора с AXI-Stream интерфейсами мы поговорим о том, как может выглядеть процесс непрерывной интеграции при создании цифровых устройств.
GitHub Flow
Для начала кратко рассмотрим, каким образом обычно ведется современная разработка RTL-модулей. Так как сейчас цифровое устройство представляет из себя код на одном из языков описания аппаратуры, для его сопровождения необходимо пользоваться системой контроля версий. На текущий момент наиболее популярной системой является Git. Есть несколько подходов ее использования, но мы остановимся, наверное, на самом простом, который называется GitHub Flow. Давайте рассмотрим, что он из себя представляет.
Внутренняя память ПЛИС, которой всегда не хватает
Введение
Для начала хотелось бы выделить два основных свойства внутренней памяти ПЛИС:
В этой статье мы рассмотрим какая внутренняя память есть в ПЛИС фирмы Intel/Altera и возможные варианты оптимизации её использования.
Общая информация
В ПЛИС фирмы Intel/Altera в основном используются следующие типа встроенной памяти:
Для начала хотелось бы выделить два основных свойства внутренней памяти ПЛИС:
- удобство использования (+)
- ограниченное количество (-)
В этой статье мы рассмотрим какая внутренняя память есть в ПЛИС фирмы Intel/Altera и возможные варианты оптимизации её использования.
Общая информация
В ПЛИС фирмы Intel/Altera в основном используются следующие типа встроенной памяти:
- M9K, в таких как Stratix IV, Arria II, Cyclone IV, Cyclone III
- M20K, в таких как Stratix 10, Stratix V, Arria 10, Arria V
Симуляция высокоскоростных приёмопередатчиков с динамической реконфигурацией для ПЛИС Intel серии IV. Подготовка
Введение
Для начала хотелось бы сказать, что наверное каждый "ПЛИСовод" использовал высокоскоростные приёмопередатчики. В семействе ПЛИС Intel/Altera серии IV IP ядро с этим функционалом называется ALTGX.
Основная задача этого IP ядра - преобразование параллельной шины на низкой частоте в последовательную шину на высокой.
Динамическая реконфигурация позволяет менять различные параметры приёмопередатчиков "на лету", то есть не меняя прошивку ПЛИС.
Основными из них являются:
Для начала хотелось бы сказать, что наверное каждый "ПЛИСовод" использовал высокоскоростные приёмопередатчики. В семействе ПЛИС Intel/Altera серии IV IP ядро с этим функционалом называется ALTGX.
Основная задача этого IP ядра - преобразование параллельной шины на низкой частоте в последовательную шину на высокой.
Динамическая реконфигурация позволяет менять различные параметры приёмопередатчиков "на лету", то есть не меняя прошивку ПЛИС.
Основными из них являются:
- скоростные характеристики, то есть на какой скорости будут принимать и передавать данные
- включать/выключать встроенные кодеки (в ПЛИС серии IV - кодек 8b/10b)
- менять аналоговые параметры, такие как TX VOD, TX Preemphasis, RX Offset Cancelation, RX Adaptive Equalizer.
Симуляция высокоскоростных приёмопередатчиков с динамической реконфигурацией для ПЛИС Intel серии IV. Практика
Введение
В прошлой статье мы описали и подготовили всё, что необходимо для сборки TestBench.
Пора приступать от теории к практике. Начнём.
Создание пользовательской логики для IP ядер ALTGX_Reconfig и ALTPLL_Reconfig
Для перестройки скоростных характеристик нам необходимо:
В прошлой статье мы описали и подготовили всё, что необходимо для сборки TestBench.
Пора приступать от теории к практике. Начнём.
Создание пользовательской логики для IP ядер ALTGX_Reconfig и ALTPLL_Reconfig
Для перестройки скоростных характеристик нам необходимо:
- перестроить TX PLL
- перестроить RX и TX Channel
- сбросить RX и TX Channel
- проверить сигнал pll_locked, сигнализирующий то, что TX PLL функционирует в обычном режиме
- проверить сигнал rx_freqlocked, сигнализирующий о том, что RX функционирует в обычном режиме
Симуляция высокоскоростных приёмопередатчиков с динамической реконфигурацией для ПЛИС Intel серии V
Введение
Этой статьей мы продолжает серию статей, цель которых поделиться опытом создания проектов в среде симуляции для тестирования динамической реконфигурации высокоскоростных интерфейсов (приёмопередатчиков) различных поколений ПЛИС фирмы Intel/Altera. В предыдущей статье мы описали IV поколение, теперь очередь "обуздать" V поколение.
Хочется немного повториться... Для того, чтобы освежить информацию в памяти.
Высокоскоростные приёмопередатчики - это пара RX и TX, встроенные в ПЛИС, которые позволяют преобразовать параллельную шину данных на низкой частоте в последовательную на высокой при передаче данных и из последовательной в параллельную при получении данных.
В ПЛИС Intel серии V для использование приёмопередатчиков необходимо использовать IP ядро Transceiver Native Phy.
Динамическая реконфигурация позволяет менять различные параметры приёмопередатчиков "на лету", то есть не меняя прошивку ПЛИС.
Общая схема проекта, который мы будем создавать, следующая:
Этой статьей мы продолжает серию статей, цель которых поделиться опытом создания проектов в среде симуляции для тестирования динамической реконфигурации высокоскоростных интерфейсов (приёмопередатчиков) различных поколений ПЛИС фирмы Intel/Altera. В предыдущей статье мы описали IV поколение, теперь очередь "обуздать" V поколение.
Хочется немного повториться... Для того, чтобы освежить информацию в памяти.
Высокоскоростные приёмопередатчики - это пара RX и TX, встроенные в ПЛИС, которые позволяют преобразовать параллельную шину данных на низкой частоте в последовательную на высокой при передаче данных и из последовательной в параллельную при получении данных.
В ПЛИС Intel серии V для использование приёмопередатчиков необходимо использовать IP ядро Transceiver Native Phy.
Динамическая реконфигурация позволяет менять различные параметры приёмопередатчиков "на лету", то есть не меняя прошивку ПЛИС.
Общая схема проекта, который мы будем создавать, следующая:
Симуляция высокоскоростных приёмопередатчиков с динамической реконфигурацией для ПЛИС Intel серии 10
Введение
В этой статье мы подошли к самому "свежему" поколению ПЛИС фирмы Intel, а именно 10 поколение. И теперь мы будем создавать проект в среде симуляции для Arria 10.
Напомню, что высокоскоростные приёмопередатчики - это пара RX и TX, встроенные в ПЛИС, которые позволяют преобразовать параллельную шину данных на низкой частоте в последовательную на высокой при передаче данных и из последовательной в параллельную при получении данных. Они необходимы для реализации различных протоколов передачи данных. А динамическая реконфигурация в данном случае необходима для "автосогласования" скорости работы интерфейсов, например 1 / 2,5 /10 Gb Ethernet.
В ПЛИС Arria 10 схема проекта, который мы будем создавать, следующая:
В этой статье мы подошли к самому "свежему" поколению ПЛИС фирмы Intel, а именно 10 поколение. И теперь мы будем создавать проект в среде симуляции для Arria 10.
Напомню, что высокоскоростные приёмопередатчики - это пара RX и TX, встроенные в ПЛИС, которые позволяют преобразовать параллельную шину данных на низкой частоте в последовательную на высокой при передаче данных и из последовательной в параллельную при получении данных. Они необходимы для реализации различных протоколов передачи данных. А динамическая реконфигурация в данном случае необходима для "автосогласования" скорости работы интерфейсов, например 1 / 2,5 /10 Gb Ethernet.
В ПЛИС Arria 10 схема проекта, который мы будем создавать, следующая:
