Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов Опции

[des00]

Добрый день!

Наконец то появилось время подтянуть себя в вопросах реализации кодов с вероятностным декодированием. Первая задача реализация DVB-RCS/WiMAX CTC кодера на ПЛИС, часть проекта будет выложен в опенсорс. Решил создать отдельную тему для обсуждения вопросов по реализации

После штудирования литературы и примеров сорцов в сети возникла часть вопросов, на которые не хватает ума/настойчивости найти ответы:
1. Для DVB-RCS оговорены выкалывания под скорости кодирования 1/3, 2/5, 1/2, 2/3, 3/4, 4/5, 6/7. Почему не определены скорости 5/6 (удивляет "дырка" между скоростями 4/5 и 6/7) и 7/8? При этому матрица выкалывания под эти скорости возможна.
2. Полиномы RCS для Wimax и DVB одинаковые, но перемежители разные. Это сделано по политическим причинам или это результат "улучшения" характеристик декодера в процессе разработки стандарта?
3. В сверточных бинарных кодах, свойство tail-bitting используется при декодировании: В одной доке нашел что дополняют принятую последовательность вначале и в конце, затем декодируют по витерби и выкусывают нужное. В примере матлаба вообще составляют два фрейма, декодируют один за другим, потом из двух декодированных собирают один результат. Никакого намека на похожие операции в доках на турбокоды не нашел. Почему в алгоритмах SOVA/MAP/... для турбокодов это не делается?
4. По tail-bitting нашел в доках только то, что особым образом инициализируются рекурсия прямой и обратной метрики на первой итерации, а на всех остальных значения между итерациями сохраняются. Но
в сорцах от CML цикл по итерациям выглядит так :

Код

for it = 1:max_iterations
    inx1 = X + inner_extr;
    [outx1, outz1]=DuobinaryCRSCDecode( inx1, inz1, poly, decoder_type);
    
    llrx1 = outx1 - inner_extr;
    inx2(1:3*N) = llrx1( code_interleaver_GF4);
    [outx2, outz2, out_info]=DuobinaryCRSCDecode( inx2, inz2, poly, decoder_type);
    detected_data(code_interleaver.info_intl) = (out_info>0)+0;
    errors(it)= sum( sum(abs(detected_data - data)));
    if (errors(it) == 0)
        break;
    else
        inner_extr(code_interleaver_GF4) = outx2 - inx2;
    end
end

Т.е. видно что последовательные вызовы функции DuobinaryCRSCDecode между собой не обмениваются этой информацией. А в самих функциях

Код

    // initialization  for CRSC code
    for (i =0; i< max_states; i++)
    {
        alpha[i][0] = 0;
        beta[i][len] = 0;
    }

Т.е. не используется даже свойство одинакового начального состояния. Более того, в алгоритмах с оконным расчетом обратной рекурсии тоже забивают на свойство tail-bitting. Так насколько это важно и почему во всех доках настойчиво пишут кодировать данные 2 раза для определения состояния инициализации?
5. В алгоритмах, наследованных от Log-MAP метрика ветки считается как сумма корреляций метрик приемных битов с выходными битами решетки : gamma(Sk-1, S) = Lapri + (ys0*xs0 + ys1*xs1 + yp0*xp0 + yp1*xp1). При этом предполагается что y - надежность принятого символа , x = -1/1 выходной(переданный) бит. В сорцах от CML это место выглядит так :

Код

    int m_input = 2;  // 2 input bits,
    int max_states = 8; // total state numbers
    int M_input = 1<<m_input;
    int i, j, max_trellis = M_input * max_states;
.......
        for (j = 0; j< max_trellis; j++)
        {
            temp_input = j%M_input;
            temp_output = trellis_out[j];
            gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ];   //llr for systematic symbol
            gamma[j] += ( temp_output ==0)? 0: inz[ (temp_output -1)+ i*llr_height ];  //llr for parity symbol
        }

Насколько я понимаю Си gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ] - берет надежности символов кроме нулевого. Диапазон изменения temp_input = 0..3 или в битах 00/01/10/11. Вот этот момент мне совсем не понятен.

Пока всё Прошу помощи тех кто в теме.

[des00]

Созрел следующий вопрос: метрики состояний проходят через процедуру нормализации. А как поступают с Lextrinsic и выходными LLR битов ? Судя по результатам моделирования, при сходимости декодера, Lextrinsic, а за ним и LLR выходных символов/битов имеют тенденцию к росту от итерации к итерации. Но, как я понимаю, нормализовать их нельзя, а логичнее использовать ограничение на определенном уровне. Правда упоминание об этом в статьях я не нашел, так ли это ?

[andyp]

Видел, что экстринсики скалили между итерациями (но не между полуитерациями) на что-то типа 0.8 - 0.9. Там же после первой итерации все равно их статистическая независимость нарушается и начинается сплошная магия.

[des00]

Видел, что экстринсики скалили между итерациями (но не между полуитерациями) на что-то типа 0.8 - 0.9. Там же после первой итерации все равно их статистическая независимость нарушается и начинается сплошная магия.

да, где то в доке находил коэффициент 0.75, но это только для max-log-MAP алгоритма, для компенсации неидеальности аппроксимации логарифма суммы экспонент.

[andyp]

да, где то в доке находил коэффициент 0.75, но это только для max-log-MAP алгоритма, для компенсации неидеальности аппроксимации логарифма суммы экспонент.

Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

[des00]

Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

хмм, надо еще будет эту тему прошерстить.

В приложении матлабовский примитивный, без какой либо оптимизации, декодер dvb-rsc, часть функций сделана близко к железу, позволяет покрутить/посмотреть что и как считается, что куда идет, как себя ведут метрики и прочее Содержит комментарии как что и куда. Перехожу к работе над HDL идеалкой.

Прикрепленные файлы

 ctc.zip ( 12.61 килобайт ) Кол-во скачиваний: 39

 

[andyp]

Перехожу к работе над HDL идеалкой.

Поздравляю с завершением этапа

[des00]

Поздравляю с завершением этапа

Похоже где то я ошибся Сделал идеалку на RTL, осознал откуда растут ноги у количества эффективных бит у метрик пар/ветвей/состояний/extinsic. Но? начал гонять и заметил расхождение в характеристиках декодера, по сравнению с используемым мной "референсным" документом. Документ в приложении, характеристики на странице 3 (466 страница документа). Набрел на него когда искал точки привязки BER для декодера(в других найденных документах приводился FER в качестве характеристик).

Первая мысль что используемый для моделирования в RTL генератор шума не верен. Отложил в сторону RTL. Взял матлабовский вариант без квантования, ограничений, честный Log Map и т.д. Тоже не бьются кривые с документом. Особенно если учесть тот факт, что в документе якобы рассмотрен Max Log Map без каких либо улучшений. Проверяю на QPSK, пакет длинной 64 пары, кодирование 1/3, 10 итераций. Пример расхождения характеристик : EbN0 = 2.5дб, в статье BER 5е-5, RTL код BER 4е-4, матлаб 2е-4.

Может кто нибудь поделиться ссылками на эталонные результаты или характеристиками своих декодеров? Интересует кривая для пакета 64 пары, кодирование 1/3, 8 итераций. Диапазон EbNo 0.5:0.5:4.

Прикрепленные файлы

 Design_and_Implementation_of_Low_Power_Turbo_Encoder_for_DVB_RCS_Software_Radio.pdf ( 436.62 килобайт ) Кол-во скачиваний: 84

 

[des00]

Похоже где то я ошибся

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).

У тебя решетка циклическая, следовательно состояния решетки в начале и конце должны быть одинаковыми. Начинать нужно с альф. Доходишь до конца, используешь последние полученные альфы для инициализации (N+1)ых бет и идешь назад по решетке. Затем сохраняешь полученные 0ые беты для использования как 0ые альфы на следующей итерации.

Понял, проверю. Цикличность отдельно альф от бет я сделал основываясь на разделе в стандарте (в приложении). С бет начинал потому что планирую в железе делать sliding window с двумя движками для бет и одним для альф. Уж больно не хочется два раза массив данных перебирать.

Когда искал в чем косяк созрел такой вопрос. Насколько правомочно формирование метрик отсчета L1,L2 для дебитов по правилу:
L00 = 0, L01 = L2, L10 = L1, L11 = L1+L2. По идее это результат вычитания из метрик L01/L10/L11 метрики L00. Но тогда должно быть так :
исходные метрики L00 = -L1-L2, L01 = -L1 + L2, L10 = L1 - L2, L11 = L1+L2 и после вычитания получается L00 = 0, L01 = 2*L2, L10 = 2*L1, L11 = 2*(L1+L2).

Казалось бы постоянный множитель LLR алгоритму не принципиален, но ведь этот множитель задает распределение надежностей. Например пусть L1/L2 = 4, тогда честные метрики будут : L00 = -8, L01 = 0, L10 = 0, L11 = 8. "Расстояния" между метриками L01/L10/L11 и метрикой L00 будет 0/8/8/16. Тогда как по упрощенному правилу метрики будут L00 = 0, L01 = 4, L10 = 4, L11 = 8 и расстояния 0/4/4/8. Как более правильно? Или этом пренебрегают в виду того, что exp(-4) = 0.0183 и exp(-8) = 3.3546e-04?

Эскизы прикрепленных изображений

 

[Mogwaika]

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).

Код запускаете напрямую или компилируете в mex или exe?
У меня для декодера компиляция дала прирост почти на порядок.

[des00]

Код запускаете напрямую или компилируете в mex или exe?
У меня для декодера компиляция дала прирост почти на порядок.

Судя по всему напрямую, рылся в хелпе как скомпилировать в mex (в симулинке такое делать умею), а тут так и не разобрался.

[Grizzzly]

Судя по всему напрямую, рылся в хелпе как скомпилировать в mex (в симулинке такое делать умею), а тут так и не разобрался.

Посмотрите примеры по codegen.

По своему опыту скажу следующее: если в матлабовском коде используются в основном встроенные функции, которые хорошо векторизованы, то от генерации сишного кода будет даже проигрыш прмерно в 1.5-2 раза, если же присутствует множество вложенных циклов, условия, то будет выигрыш (у меня получалось от 1.5 до 20 раз для различных программ, Win7, 64 bit).

Сообщение отредактировал Grizzzly - Feb 4 2015, 17:08

[Mogwaika]

Посмотрите примеры по codegen.

По своему опыту скажу следующее: если в матлабовском коде используются в основном встроенные функции, которые хорошо векторизованы, то от генерации сишного кода будет даже проигрыш прмерно в 1.5-2 раза, если же присутствует множество вложенных циклов, условия, то будет выигрыш (у меня получалось от 1.5 до 20 раз для различных программ, Win7, 64 bit).

У меня даже декодер, оптимизированный под матричные операции для ускорения простого кода ускорился значительно.
Плюсом желательно использовать parfor, чтобы полностью загрузить процессор.
Далее можно скомпилировать exe с помощью mcc для запуска сразу на нескольких машинах с установленным mcr.

[Serg76]

У меня даже декодер, оптимизированный под матричные операции для ускорения простого кода ускорился значительно.
Плюсом желательно использовать parfor, чтобы полностью загрузить процессор.
Далее можно скомпилировать exe с помощью mcc для запуска сразу на нескольких машинах с установленным mcr.

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

Посмотрите примеры по codegen.

По своему опыту скажу следующее: если в матлабовском коде используются в основном встроенные функции, которые хорошо векторизованы, то от генерации сишного кода будет даже проигрыш прмерно в 1.5-2 раза, если же присутствует множество вложенных циклов, условия, то будет выигрыш (у меня получалось от 1.5 до 20 раз для различных программ, Win7, 64 bit).

Какая максимальная скорость достигнута в Вашей реализации?

[Grizzzly]

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

Турбо-декодер делал давно, для него не генерировал код. Описал полученные результаты на различных алгоритмах только в качестве примера по генерации mex-файлов. Из последнего: сейчас мне понадобилась собственная реализация алгоритма Витерби. В первом случае мне нужно только значение наилучшей метрики (оптимальные пути не ищутся, только вычисляются метрики), выигрыш получился минимум в 10 раз, на некоторых длинах блоков и при определенном числе состояний решетки в 15-20 раз. Для случая, когда декодер выдает оптимальный путь, выигрыш составил 1.5 раза (подозреваю, что как-то можно оптимизировать процесс копирования выживших путей). Процессор Intel Core 2 Duo, 3 GHz. Компилятор использовался VS 2010, наверное, от будь от Intel, результаты получились бы лучшими. Matlab 2014a 64 bit. Мне real-time не нужен, генерировал только для сокращения времени моделирвания.
Не подскажете, где можно прочитать по настройкам оптимизации?

Сообщение отредактировал Grizzzly - Feb 5 2015, 08:45

[Serg76]

Турбо-декодер делал давно, для него не генерировал код. Описал полученные результаты на различных алгоритмах только в качестве примера по генерации mex-файлов. Из последнего: сейчас мне понадобилась собственная реализация алгоритма Витерби. В первом случае мне нужно только значение наилучшей метрики (оптимальные пути не ищутся, только вычисляются метрики), выигрыш получился минимум в 10 раз, на некоторых длинах блоков и при определенном числе состояний решетки в 15-20 раз. Для случая, когда декодер выдает оптимальный путь, выигрыш составил 1.5 раза (подозреваю, что как-то можно оптимизировать процесс копирования выживших путей). Процессор Intel Core 2 Duo, 3 GHz. Компилятор использовался VS 2010, наверное, от будь от Intel, результаты получились бы лучшими. Matlab 2014a 64 bit. Мне real-time не нужен, генерировал только для сокращения времени моделирвания.
Не подскажете, где можно прочитать по настройкам оптимизации?

Ок, спасибо. Если немного отойти от темы, то выигрыш 1.5 раза - это сколько в битах и для какой относительной скорости кодирования и длины кодового ограничения? Кстати, алгоритм Витерби, точнее его вариант с генерацией мягкого выхода - SOVA, можно смело применять и для RCS кода, правда неизвестно еще будет ли выигрыш по скорости в сравнении с MAX-LOG-MAP, но по эффективности, конечно, хуже. По поводу Intel: прирост должен быть как на уровне компилятора, так и при использовании их примитивов - IPP, а по поводу настроек оптимизации имеется ввиду компилятор?

~300кб/с (свёрточный турбо на 4х битном регистре, rate 1/2, 10 итераций max-log-map, qpsk + awgn, Xeon E5-2620v2 2.10GHz, mcr 2014a 64bit)

Спасибо, 4-х битный - это на 16 состояний как в RCS2?