Введение

Модель показывает генерацию кода HDL для блока декодера Витерби с фиксированной точкой, используемого при сверточном декодировании с мягким решением. Дополнительные сведения о поддержке HDL для декодера Витерби см. в разделе Создание кода HDL блочной страницы документации.

Чтобы открыть модель, выполните следующие команды.

modelname = 'commviterbihdl';
open_system(modelname);

В этой модели подсистема декодера Витерби верхнего уровня содержит блок декодера Витерби. Чтобы открыть эту подсистему, выполните следующие команды:

systemname = [modelname '/Viterbi Decoder Subsystem'];
open_system(systemname);

Алгоритм декодирования Витерби

Существует три основных компонента алгоритма декодирования Витерби. Они представляют собой вычисления метрики ветви (BMC), add-compare-select (ACS) и декодирование отслеживания. Следующая диаграмма иллюстрирует три единицы в алгоритме декодирования Витерби:

Метод перенормировки

Декодер Витерби предотвращает переполнение метрик состояния в компоненте ACS, вычитая минимальное значение метрик состояния на каждом временном шаге, как показано на следующем рисунке:

Получение минимального значения всех элементов метрики состояния в одном такте приводит к плохой тактовой частоте для схемы. Рабочие характеристики схемы могут быть улучшены путем добавления регистров трубопроводов. Однако простое вычитание минимального значения, задержанного конвейерными регистрами, из метрик состояния может все же привести к переполнению. Аппаратная архитектура изменяет метод перенормировки и позволяет избежать переполнения метрики состояния в три этапа. Сначала архитектура вычисляет значения для пороговых параметров и параметров шага на основе решетчатой структуры и количества битов мягкого решения. Во-вторых, минимальное значение задержки сравнивается с порогом. Наконец, если минимальное значение больше или равно пороговому значению, реализация вычитает значение шага из метрики состояния; в противном случае регулировка не выполняется. Следующий рисунок иллюстрирует модифицированный метод перенормировки:

Расчет длины метрического слова оптимального состояния

Аппаратная реализация вычисляет оптимальную длину слова метрики состояния и сравнивает ее со значением, заданным для блока. Аппаратная архитектура использует оптимальное значение, если оно меньше указанного. Отображается сообщение для отображения значения во время генерации кода HDL. Если вычисленное значение больше указанного значения, выводится сообщение об ошибке и отображается оптимальное значение.

Применение рассчитанной оптимальной длины слова метрики состояния в аппаратной реализации может значительно сократить аппаратный ресурс, если указанное значение слишком велико. Например, если установить 16 битов в качестве длины слова метрики состояния, но для достижения одинаковых числовых результатов требуется только 9 битов, применение вычисленной оптимальной длины слова метрики состояния в аппаратной архитектуре экономит приблизительно 40 процентов ресурсов регистра. Рассчитанная оптимальная длина слова метрики состояния для некоторых типичных шпалер отображается в следующей таблице:

Проверка и генерация кода для модели Витерби с фиксированной точкой

Эта модель декодирует 1/2 скорости DVB, длину ограничения 7, (171 133) сверточный код с 3 битами мягкого решения. Декодер работает в непрерывном режиме с глубиной отслеживания 32. Длина слова метрики состояния устанавливается равной 16 битам. Для проверки параметров блока декодера Витерби можно выполнить следующие команды:

При выполнении checkhdl создаются сообщения, которые сообщают:

Для генерации HDL для подсистемы, содержащей блок декодера Витерби, выполните следующие команды: workingdir = tempname; makehdl (имя системы, «TargetDirectory», workingdir);

Имя файла VHDL ® верхнего уровня соответствует имени блока в модели. Компонент Viterbi_Decoder, созданный в Viterbi_Decoder.vhd, содержит три компонента: BranchMetric, ACS и Traceback. Компоненты ACS и Traceback создают экземпляры компонентов ACSUnit и TracebackUnit несколько раз соответственно. Определения типов данных включены в Viterbi_Decoder_Subsystem_pkg.vhd файлов пакетов.

Чтобы создать средство тестирования для подсистемы, содержащей блок декодера Витерби, выполните следующую команду: makehdltb (systemname, 'TargetDirectory', workingdir);

Оптимизация блока отслеживания обратной связи

Они представляют собой два метода оптимизации блока отслеживания: конвейеризация отслеживания на основе регистров или использование архитектуры отслеживания на основе ОЗУ.

Блок декодера Витерби декодирует каждый бит путем обратной трассировки по глубине отслеживания, определенной для блока. Поскольку блок реализует полную трассировку для каждого бита решения, регистры используются для хранения индекса минимального состояния и решения о ветви в блоке декодирования трассировки. Этот блок может быть конвейерным для улучшения рабочих характеристик генерируемой схемы. Регистры трубопроводов можно добавить в блок отслеживания, указав количество этапов отслеживания на регистр трубопровода. Это можно сделать, установив параметр реализации TracebackPerPerPipeline для декодера Витерби в диалоговом окне свойств блока HDL. Щелкните правой кнопкой мыши блок декодера Витерби, чтобы перейти в меню Свойства блока HDL.

Установка значения свойства равным 4 приводит к вставке регистра трубопровода для каждых четырех единиц отслеживания в модели, как показано на следующем рисунке.

Параметр реализации TracebackPerPerPipeline предоставляет способ балансировки производительности канала в соответствии с требованиями системы. Меньшее значение параметра указывает на необходимость добавления большего количества регистров для увеличения скорости цепи отслеживания. Увеличение числа приводит к меньшему использованию регистров наряду с уменьшением скорости цепи. В нашем эксперименте с 1/2 скорости, длиной ограничения 7, (171 133) сверточным кодом, регулировка параметра TracebackPerPerPipeline от 4 до 8 уменьшает использование регистра трубопровода пополам, с изменением скорости цепи от 173MHz до 94 МГц.

Вместо использования регистров можно использовать RAM для сохранения информации о выживших ветвях. Это можно сделать, установив для свойства HDL Architecture блока декодера Витерби значение RAM-based Traceback.

Существует два основных различия между архитектурами traceback на основе регистров и RAM.

Во-первых, реализация на основе регистров объединяет операции отслеживания и декодирования в один этап и использует наилучшее состояние, найденное из минимальной операции, в качестве начального состояния декодирования. Реализация на основе ОЗУ отслеживает обратно через один набор данных, чтобы найти начальное состояние для декодирования предыдущего набора данных.

Во-вторых, реализация на основе регистров декодирует один бит после полного трекбэка; в то время как реализация на основе ОЗУ отслеживает назад через М выборок, декодирует предыдущие М битов в обратном порядке и освобождает один бит в порядке при каждом такте.

Из-за различий в двух алгоритмах отслеживания, реализация на основе ОЗУ дает разные числовые результаты, чем отслеживание на основе регистров. Для достижения такой же частоты битовых ошибок (BER), как и для реализации на основе регистров, рекомендуется более длинная глубина отслеживания, например, в 10 раз превышающая длину ограничения.

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

Наш эксперимент со скоростью 1/2, длина ограничения 7, (171, 133) сверточный код показывает, что блок отслеживания на основе ОЗУ использует на 90% меньше регистров, чем блок отслеживания на основе регистров (с конвейерированием каждые 4 этапа), используя аналогичные ограничения часов в синтезе. Две реализации обеспечивают компромисс между регистром и ОЗУ, который может быть адаптирован к индивидуальной конструкции.

Выбранные привязки