[smoke_111 0]

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

[andyp 9]

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

 

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

cheng_hung2008.pdf

Изменено 6 февраля, 2015 пользователем andyp

[des00 25]

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

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

 

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

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

[des00 25]

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

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

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

[andyp 9]

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

 

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

 

martina2008.pdf

[des00 25]

Проблема - обеспечить, чтобы параллельно работающие 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

[andyp 9]

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

 

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

 

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

 

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

 

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

martina2008_1.pdf

[des00 25]

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

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

Реализовал модель декодера который работает по окну == размеру пакета. За один проход считает альфа и бета: читает метрики и экстинсики для двух пар, до середины пакета набирает состояния в память, после середины начинает вычислять выходные экстринсики для двух пар одновременно и пишет в память экстринсиков. Адреса записи не пересекаются, чтение с записью разведено латентностью обработки. Все должно более менее красиво лечь в ПЛИС, правда в качестве блочков памяти нужно будет из двухпортовок сделать память 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 9]

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

Изменено 9 февраля, 2015 пользователем andyp

[des00 25]

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

Злодеи :)

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

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

[des00 25]

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

[andyp 9]

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

 

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

[des00 25]

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

Нет. Сейчас скорость декодирования в полуитерации 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дб(но на меньшей скорости). Наглядно и понятно что к чему, без сложных перерасчетов.

[andyp 9]

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

 

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

 

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

 

 

[petrov 6]

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

 

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