Этот пример показывает поддержку генерации HDL-кода блока Viterbi Decoder. Это показывает, как проверять, сгенерировать, и проверить HDL-код, который вы генерируете из модели Viterbi Decoder фиксированной точки. Этот пример также обсуждает настройки, которые можно использовать, чтобы изменить HDL-код, который вы генерируете.
В порядке запустить этот пример, у вас должна быть лицензия HDL Coder™.
Модель показывает генерацию HDL-кода для блока Viterbi Decoder фиксированной точки, используемого в мягком решении сверточное декодирование. Чтобы узнать больше о поддержке HDL Декодера Витерби, обратитесь к документации.
Чтобы открыть модель, запустите следующие команды:
modelname = 'commviterbihdl';
open_system(modelname);
В этой модели Подсистема Декодера Витерби подсистемы верхнего уровня содержит блок Viterbi Decoder. Чтобы открыть эту подсистему, запустите следующие команды:
systemname = [modelname '/Viterbi Decoder Subsystem'];
open_system(systemname);
Существует три основных компонента к Viterbi, декодирующему алгоритм. Они - метрическое вычисление ответвления (BMC), "добавьте, сравнивают выбор" (ACS) и декодирование traceback. Следующая схема иллюстрирует эти три модуля в Viterbi, декодирующем алгоритм:
Декодер Витерби предотвращает переполнение метрик состояния в компоненте ACS путем вычитания минимального значения метрик состояния на каждом временном шаге, как показано в следующей фигуре:
Получение минимального значения всех метрических элементов состояния за один такт приводит к плохой частоте часов для схемы. Производительность схемы может улучшаться путем добавления конвейерных регистров. Однако просто вычитание минимального значения, задержанного конвейерными регистрами от метрик состояния, может все еще вести, чтобы переполниться. Аппаратная архитектура изменяет метод перенормализации и избегает метрического переполнения состояния на трех шагах. Во-первых, архитектура вычисляет значения для порога и параметров шага, на основе структуры решетки и количества мягких битов решения. Во-вторых, задержанное минимальное значение сравнивается с порогом. Наконец, если минимальное значение больше, чем или равно пороговому значению, реализация вычитает значение шага из метрики состояния; в противном случае никакая корректировка не выполняется. Следующая фигура иллюстрирует измененный метод перенормализации:
Аппаратная реализация вычисляет оптимальный размер слова метрики состояния и сравнивает его со значением, которое вы задаете для блока. Аппаратная архитектура использует оптимальное значение, если это меньше, чем то, вы задаете. Сообщение отображено, чтобы показать значение во время генерации HDL-кода. Если расчетное значение больше, чем значение, вы задаете, о сообщении об ошибке сообщают, и оптимальное значение отображено.
Применение расчетного оптимального метрического размера слова состояния в аппаратной реализации может значительно уменьшать аппаратный ресурс, если значение, которое вы задаете, является слишком большим. Например, если вы устанавливаете 16 битов как метрический размер слова состояния, но только 9 битов требуются, чтобы достигать тех же числовых результатов, применение расчетного оптимального метрического размера слова состояния в аппаратной архитектуре сохраняет приблизительно 40 процентов ресурсов регистра. Расчетный оптимальный метрический размер слова состояния для некоторых типичных решеток отображен в следующей таблице:
Эта модель декодирует уровень DVB 1/2, продолжительность ограничения 7, (171,133) сверточный код с мягким решением на 3 бита. Декодер запускается в непрерывном режиме с traceback глубиной 32. Метрический размер слова состояния установлен в 16 битов. Чтобы подтвердить установки параметров блока Viterbi Decoder, можно запустить следующие команды:
workingdir = tempname;
checkhdl (systemname, 'TargetDirectory', workingdir);
Выполнение checkhdl генерирует сообщения, которые сообщают:
значение по умолчанию TracebackStagesPerPipeline. Больше информации об этом параметре может быть найдено в разделе Pipelining основанным на регистре traceback модулем,
метрический размер слова состояния, используемый в HDL-коде по сравнению с набором того на маске блока,
общая задержка, введенная конвейером, указывает относительно исходного блока Viterbi.
Чтобы сгенерировать HDL для подсистемы, содержащей блок Viterbi Decoder, запустите следующие команды: workingdir = tempname; makehdl (systemname, 'TargetDirectory', workingdir);
Верхний уровень имя файла VHDL® совпадает с именем блока в модели. Компонент Viterbi_Decoder, сгенерированный в Viterbi_Decoder.vhd, содержит три компонента: BranchMetric, ACS и Traceback. Компоненты ACS и Traceback инстанцируют компонентов ACSUnit и TracebackUnit многократно соответственно. Определения типов включены в файл пакета Viterbi_Decoder_Subsystem_pkg.vhd.
Чтобы сгенерировать испытательный стенд для подсистемы, содержащей блок Viterbi Decoder, запустите следующую команду: makehdltb (systemname, 'TargetDirectory', workingdir);
Они - два метода, чтобы оптимизировать traceback модуль: конвейеризация основанного на регистре traceback или использование основанной на RAM traceback архитектуры.
Конвейеризация основанного на регистре traceback модуля
Блок Viterbi Decoder декодирует каждый бит путем прослеживания через traceback глубину, которую вы задаете для блока. Поскольку блок реализует полный traceback для каждого бита решения, регистры используются, чтобы сохранить минимальный индекс состояния и выбор при разветвлении в Traceback Декодирование модуля. Этот модуль может быть конвейерным в порядке улучшать производительность сгенерированной схемы. Конвейерно обработайте регистры, может быть добавлен к traceback модулю путем определения количества этапов traceback на конвейерный регистр. Это может быть сделано путем установки параметра реализации TracebackStagesPerPipeline для Декодера Витерби в диалоговом окне свойств блока HDL. Щелкните правой кнопкой мыши по блоку Viterbi Decoder, чтобы перейти к меню HDL Block Properties.
Установка значения свойства к 4 результатам во вставке конвейера указывает для каждых четырех traceback модулей в модели, как проиллюстрировано в следующей фигуре:
Параметр реализации TracebackStagesPerPipeline предоставляет вам способ сбалансировать производительность схемы на основе системных требований. Меньшее значение параметров указывает на требование, чтобы добавить больше регистров, чтобы увеличить скорость traceback схемы. Увеличение номера приводит к более низкому использованию регистров наряду с уменьшением в скорости схемы. В нашем эксперименте с уровнем 1/2, продолжительность ограничения 7, (171,133) сверточный код, настраивая параметр TracebackStagesPerPipeline от 4 до 8 уменьшает конвейерное использование регистра в половине со скоростью схемы, изменяющейся с 173 МГц до 94 МГц.
Основанный на RAM traceback
Вместо того, чтобы использовать регистры, можно принять решение использовать RAM, чтобы сохранить информацию ответвления оставшегося в живых. Это может быть сделано путем установки свойства HDL Architecture блока Viterbi Decoder к основанному на RAM Traceback.
Существует два существенных различия между основанным на регистре и основанной на RAM traceback архитектурой.
Во-первых, основанная на регистре реализация комбинирует traceback, и декодируйте операции в один шаг, и использует лучшее состояние, найденное от минимальной операции как начальное состояние декодирования. Основанная на RAM реализация прослеживает через один набор данных, чтобы найти, что начальное состояние декодирует предыдущий набор данных.
Во-вторых, основанная на регистре реализация декодирует один бит после полного трекбека; в то время как основанная на RAM реализация прослеживает посредством выборок M, декодирует предыдущие биты M в обратном порядке и выпускает один бит по порядку в каждом такте.
Из-за различий в двух traceback алгоритмах, основанная на RAM реализация приводит к различным числовым результатам, чем основанный на регистре traceback. Более долгая traceback глубина, например, 10 раз продолжительности ограничения, рекомендуется в основанном на RAM traceback достигнуть подобной частоты ошибок по битам (BER) как основанной на регистре реализации.
Размер RAM, требуемого для реализации, зависит от решетки и traceback глубины. Следующая таблица обобщает Использование оперативной памяти для некоторых типичных структур решетки.
Наш эксперимент с уровнем 1/2, продолжительность ограничения 7, (171, 133) сверточный код показывает, что основанный на RAM traceback модуль использует на 90% меньше регистров, чем основанный на регистре traceback модуль (с конвейеризацией каждых 4 этапов)), использование подобных ограничений часов в синтезе. Эти две реализации обеспечивают компромисс RAM регистра, который может быть адаптирован в соответствии с отдельным проектом.
Кларк, G. C. Младший и J. Затвор Каин., кодирование с коррекцией ошибок для цифровой связи, Нью-Йорка, нажатия пленума, 1981.
Г. Феиджин и П. Г. Гулэк, "Архитектурные компромиссы для управления памятью последовательности оставшегося в живых в Декодерах Витерби", Транзакции IEEE на Коммуникациях, издании 41, № 3, стр 425-429, март 1993.