Перейти к содержанию
    

Вопросы по итеративному декодированию

Прошу прощения я кажется запутался, я правильно понимаю ваш вопрос, вы хотите получить адреса данных после перемежения для бет в обратном порядке?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Прошу прощения я кажется запутался, я правильно понимаю ваш вопрос, вы хотите получить адреса данных после перемежения для бет в обратном порядке?

 

В приложенной статье утверждается, что аналогичная схема может быть использована для генерации индексов интерливера как в прямом так и в инверсном порядке. Правда, там интерливер WiMax, но он должен быть очень похож на интерливер для DVB

cheng_hung2008.pdf

Изменено пользователем andyp

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

да, именно так.

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

покурю внимательно

самое занятное что они правы, внимательно позырил на формулу и все встало на круги своя. Замена сложения на вычитание P0 в аккумуляторе и изменение адреса инициализации с 0 на P0*(N-1) % N дает искомый результат. Жаль только то, что под каждую длину нужен свой уникальный адрес инициализации ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

самое занятное что они правы, внимательно позырил на формулу и все встало на круги своя. Замена сложения на вычитание P0 в аккумуляторе и изменение адреса инициализации с 0 на P0*(N-1) % N дает искомый результат. Жаль только то, что под каждую длину нужен свой уникальный адрес инициализации ;)

 

Это не самая большая проблема. Проблема - обеспечить, чтобы параллельно работающие SISO модули не сталкивались при доступе к памяти экстринсиков. Вот статья про это на примере wimax. Может, будет интересно.

 

martina2008.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Проблема - обеспечить, чтобы параллельно работающие SISO модули не сталкивались при доступе к памяти экстринсиков. Вот статья про это на примере wimax. Может, будет интересно.

статья немного путаная но занятная, но по кросс линкам ведет к статье A HIGH-SPEED MAP ARCHITECTURE WITH OPTIMIZED MEMORY SIZE AND POWER CONSUMPTION вот там яснее написано :)

 

Попутно возник вопрос, почему все бьются за повышение параллелизма одной полуитерации. Положим есть 10 параллельно работающих движков, это требует наличия 10 ти портовых регистровых файлов. Ведь можно же уйти в глубину : те же 10 движков поставить последовательно в конвейер и развязать их двухпортовыми блочками памяти(при этом память под Lext можно заменить на память Lext + Ls). Да, задержка обработки вырастет, но пиковая производительность останется на том же уровне. Правда количество итераций произвольно менять будет сложнее.

A_HIGH_SPEED_MAP_ARCHITECTURE_WITH_OPTIMIZED_MEMORY_SIZE_AND_POWER_CONSUMPTION.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попутно возник вопрос, почему все бьются за повышение параллелизма одной полуитерации. Положим есть 10 параллельно работающих движков, это требует наличия 10 ти портовых регистровых файлов. Ведь можно же уйти в глубину : те же 10 движков поставить последовательно в конвейер и развязать их двухпортовыми блочками памяти(при этом память под Lext можно заменить на память Lext + Ls). Да, задержка обработки вырастет, но пиковая производительность останется на том же уровне. Правда количество итераций произвольно менять будет сложнее.

 

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

 

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

 

Больше информации о том, как устроен декодер у Martinа, можно почерпнуть из прицепленной статьи. Предыдущая была только про интерливер.

 

Что касается граничных альф и бет для окна, они используют значения, полученные на предыдущей итерации.

martina2008_1.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что касается граничных альф и бет для окна, они используют значения, полученные на предыдущей итерации.

Вот как раз по этому вопросу мне не до конца понятно.

Реализовал модель декодера который работает по окну == размеру пакета. За один проход считает альфа и бета: читает метрики и экстинсики для двух пар, до середины пакета набирает состояния в память, после середины начинает вычислять выходные экстринсики для двух пар одновременно и пишет в память экстринсиков. Адреса записи не пересекаются, чтение с записью разведено латентностью обработки. Все должно более менее красиво лечь в ПЛИС, правда в качестве блочков памяти нужно будет из двухпортовок сделать память 2 порта на запись и 2 на чтение (как прикрутить однопортовку еще не задумывался). Сама решетка инициализируется на концах и вычисления идут по эталонной модели с первой итерации.

 

В многооконных декодерах, судя по одной из статей

The algorithm is as following. First of all, the received data for each constituent codes are divided into several contiguous non-overlapping sub-blocks; so called windows. Then, each window is decoded separately in parallel using the BCJR algorithm. In other words, each window is a vector decoder. However, the initial values for alpha and beta variables come from previous iteration of adjacent windows. Since all the windows are being processed at the same time, in the next iteration the initial values are ready to load. Therefore, there is no extra processing needed for the initialization of state probabilities at each iteration. The size of windows is a very important parameter that will be discussed later. Fig. 3 shows the structure of the decoder.

делают так : если я понял правильно, окна не перекрываются и решетки окон инициализируются в 0. Но ведь свойство решеток в том, что они сходятся спустя несколько длин кодовых ограничений? Т.е. если размер окна у нас 32, то первые 16 состояний уйдут "в молоко". Получается первая итерация "на выброс". Но ведь это может дать неправильные экстринсики и усложнить сходимость декодера. На это забивают и тупо увеличивают количество итераций ? Типа "на что не пойдешь ради производительности" ? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем andyp

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну да, на оверлап забивают, чтобы поднять производительность.

Злодеи :)

как прикрутить однопортовку еще не задумывался

Совсем однопортовка не получиться, а вот простая двухпортовка (один порт записи, другой чтения) в режиме интерливинга по младшему биту адреса вполне работает. Идеалку выложил в ПЛИСовую тему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Базовый синтезируемый декодер в ПЛИСовой теме. К сожалению все уперлось в расчет рекурсии за 1 такт : 4 сложения и 3 MAX* :( На моем среднем чипе для 8ми итераций, битовая кодированная скорость ~=2*100/(8*2) = 12.5 мегабит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Базовый синтезируемый декодер в ПЛИСовой теме. К сожалению все уперлось в расчет рекурсии за 1 такт : 4 сложения и 3 MAX*

 

Код не смотрел, но вброшу - Конвейер не спасет отца русской демократии?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Код не смотрел, но вброшу - Конвейер не спасет отца русской демократии?

Нет. Сейчас скорость декодирования в полуитерации 1 пара/такт и частота ~100 МГц, если расконвейризировать (поставить регистры на критическом пути), то получиться частота ~200МГц, но и скорость декодирования 0.5пары/такт. В итоге размен шило, на мыло, при более сложном управлении. Как вариант, можно сделать на частоте ~200МГц, с мультиплексированием вычислительных модулей, при скорости декодирования 0.5 пары за такт, даст экономию ресурса процентов 40.

 

Есть такой вопрос по теории кодирования. На форуме уже была тема с обсуждением этого вопроса, но ЕМНИП закончилась ничем. Предисловие вопроса:

рассмотрим кривую декодирования с такими точками:

# EbNo = 0.5: ber = 3.553110e-002. fer = 1.911794e-001
# EbNo = 1.0: ber = 2.800132e-003. fer = 1.811356e-001
# EbNo = 1.5: ber = 3.224499e-005. fer = 1.677701e-001
# EbNo = 2.0: ber = 0.000000e+000. fer = 1.540700e-001
# EbNo = 2.5: ber = 0.000000e+000. fer = 1.401851e-001
# EbNo = 3.0: ber = 0.000000e+000. fer = 1.269456e-001
# EbNo = 3.5: ber = 0.000000e+000. fer = 1.135156e-001
# EbNo = 4.0: ber = 0.000000e+000. fer = 1.005704e-001
# EbNo = 5.0: ber = 0.000000e+000. fer = 7.646611e-002
# EbNo = 6.0: ber = 0.000000e+000. fer = 5.522185e-002
# EbNo = 7.0: ber = 0.000000e+000. fer = 3.731609e-002
# EbNo = 8.0: ber = 0.000000e+000. fer = 2.336034e-002
# EbNo = 9.0: ber = 0.000000e+000. fer = 1.335576e-002

это QPSK размер пакета 212 пар, скорость 1/3. ber - бер после декодирования, fer - бер до декодирования. Если "не вооруженным взглядом" сравнить измеренный fer с эталонным графиком не кодированного QPSK с характерной точкой 1e-6 при EbNo = 10.5дб, то кажется что что-то не так. Но если вооружиться и пересчитать через EsNo = EbNo + 10log10(bps) + 10log10(coderate) то все встанет на свои места.

 

Теперь собственно сам вопрос : использование EbNo для сравнения систем кодирования/декодирования более менее понятно, нужна общая точка для сравнения характеристик декодеров, но для реальных систем связи более актуален EsNo. Почему он в теории кодирования, в применении к реальным системам связи, совсем не встречается? Более актуален ИМХО потому что этот параметр нагляден. Например: система с не кодированным QPSK может работать с 1е-6 при SNR ~= IEVM == 13.5дб, добавляем кодирование и можем работать при том же бер ну положим с SNR = 6дб(но на меньшей скорости). Наглядно и понятно что к чему, без сложных перерасчетов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Теперь собственно сам вопрос : использование EbNo для сравнения систем кодирования/декодирования более менее понятно, нужна общая точка для сравнения характеристик декодеров, но для реальных систем связи более актуален EsNo. Почему он в теории кодирования, в применении к реальным системам связи, совсем не встречается? Более актуален ИМХО потому что этот параметр нагляден. Например: система с не кодированным QPSK может работать с 1е-6 при SNR ~= IEVM == 13.5дб, добавляем кодирование и можем работать при том же бер ну положим с SNR = 6дб(но на меньшей скорости). Наглядно и понятно что к чему, без сложных перерасчетов.

 

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

 

На практике это оказывается не всегда удобным и народ часто перескакивает на Es/N0, когда именно Es/N0 неизменен и интересует именно выигрыш от применения той или иной схемы в данной конкретной системе связи.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Например: система с не кодированным QPSK может работать с 1е-6 при SNR ~= IEVM == 13.5дб, добавляем кодирование и можем работать при том же бер ну положим с SNR = 6дб(но на меньшей скорости). Наглядно и понятно что к чему, без сложных перерасчетов.

 

Например два графика BER от Es/N0 для BPSK и QPSK, вроде кажется, что BPSK лучше, на самом деле одинаково, да ещё и на полосе экономим в два раза в случае QPSK. SNR - самозапутывание, Eb/N0 - сразу всё ясно. ИМХО

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...