Введение

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

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

modelname = 'hdlcoder_commviterbi';
open_system(modelname);

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

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

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

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

Метод ренормализации

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

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

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

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

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

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

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

Выполнение checkhdl генерирует сообщения, которые сообщают:

Чтобы сгенерировать 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);

Оптимизация модуля трассировки

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

Блок Viterbi Decoder декодирует каждый бит, отслеживая назад через глубину отслеживания, которую вы задаете для блока. Поскольку блок реализует полный обратный вызов для каждого бита принятия решения, регистры используются для хранения минимального индекса состояния и решения ветви в модуле Traceback Decoding. Этот модуль может быть конвейеризован в порядок для улучшения эффективности сгенерированной схемы. Регистры трубопроводов могут быть добавлены к модулю отслеживания, путем определения количества этапов отслеживания для каждого регистра трубопровода. Это может быть сделано путем установки параметра реализации TracebackStagesPerPipeline для декодера Viterbi в диалоговом окне свойств блоков. Щелкните правой кнопкой мыши блок Viterbi Decoder, чтобы перейти в меню HDL Block Properties.

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

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

Вместо использования регистров можно выбрать использование ОЗУ для сохранения информации о ветви выжившего. Это можно сделать путем установки свойства HDL Architecture блока Viterbi Decoder в Traceback на основе оперативной памяти.

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

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

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

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

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

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

Выбранные ссылки