[SKov 0]

Вот интересно, как я понял из учебников по кодированию, сам код БЧХ позволяет обнаружить большее кол-во ошибок, но не все из них. Ограничение d-1 связанно с использованием стандартных методов декодирования, через решение системы уравнений. Интересно чисто теоретически, есть ли методы позволяющие преодолеть эту границу? (ну кроме полного перебора или синдромного декодирования что почти тоже самое).

 

То, что я написал, не имеет отношение к БЧХ и справедливо для любого кода.

Вообще, способность кода к обнаружению ошибок не имеет отношения к методу декодирования - это свойство кода, а не декодера.

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

Понятно, что некоторые ошибки веса d в принципе не могут быть обнаружены, если совпадают с кодовым словом.

Если поделить количество кодовых слов веса d на общее количество векторов веса d, то легко посчитать,

с какой вероятностью можно НЕ обнаружить ошибку веса d.

Количество кодовых слов мин. веса для большинства коротких БЧХ известно точно.

Для длинных кодов БЧХ известно, что их весовой спектр приближается к биномиальному распределению с ростом длины.

Иногда можно пользоваться грубой оценкой необнаружения ошибки в виде 1/(2^r).

[amelyutin9 0]

Возник следующий вопрос. К примеру исправляющая способность кода 8 ошибок. На передающей стороне мы внесли 10 ошибок. Соответственно декодер может обнаружить 16 ошибок. Можем ли мы на этапе декодирования каким-либо образом сказать сколько конкретно ошибок у нас возникло или мы можем только гарантированно сказать что их больше восьми?

[SKov 0]

Возник следующий вопрос. К примеру исправляющая способность кода 8 ошибок. На передающей стороне мы внесли 10 ошибок. Соответственно декодер может обнаружить 16 ошибок. Можем ли мы на этапе декодирования каким-либо образом сказать сколько конкретно ошибок у нас возникло или мы можем только гарантированно сказать что их больше восьми?

Гарантированно мы не можем сказать ничего.

Есть след. варианты.

1) На расстоянии D (D<9) от принятого вектора есть кодовое слово. Тогда произошло либо D ошибок либо, как минимум, d-D.

2) Ближайший кодовый вектор находится на расстоянии D (D>8). Тогда произошло не менее D ошибок.

Это все, что можно сказать.

В вашем конкретном случае 10 ошибок могли лечь как кодовое слово, тогда вы увидете кодовое слово на расстоянии 6 от принятого вектора.

Это значит, что ошибок было либо 6, либо как минимум 16-6.

[des00 27]

То, что я написал, не имеет отношение к БЧХ и справедливо для любого кода.

Спасибо за развернутый ответ, то что вы пишите понятно и сомнению не подлежит. Мой же вопрос заключался в существовании алгоритма декодирования БЧХ кодов, который обладает возможностью исправлять часть ошибок больше D (ведь по теории можно).

 

Т.е. ИМХО классический БЧХ декодер обладает фиксированными, не вероятностными характеристиками (в не в том смысле что вероятность ошибки к нему не применима, а в том смысле что от прогона к прогону на случайном потоке он будет давать одинаковый результат), существует ли метод декодирования (итеративный алгоритм чейза не рассматриваем) позволяющий выйти за эти границы БЧХ ?

 

ЗЫ. могу путать термины теории кодирования, прошу строго не судить %)

 

[SKov 0]

Спасибо за развернутый ответ, то что вы пишите понятно и сомнению не подлежит. Мой же вопрос заключался в существовании алгоритма декодирования БЧХ кодов, который обладает возможностью исправлять часть ошибок больше D (ведь по теории можно).

 

Т.е. ИМХО классический БЧХ декодер обладает фиксированными, не вероятностными характеристиками (в не в том смысле что вероятность ошибки к нему не применима, а в том смысле что от прогона к прогону на случайном потоке он будет давать одинаковый результат), существует ли метод декодирования (итеративный алгоритм чейза не рассматриваем) позволяющий выйти за эти границы БЧХ ?

 

ЗЫ. могу путать термины теории кодирования, прошу строго не судить %)

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

чем гарантирует граница БЧХ. Вроде, иногда можно исправить +2 ошибки. Больше я не видел.

[des00 27]

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

чем гарантирует граница БЧХ. Вроде, иногда можно исправить +2 ошибки. Больше я не видел.

Хммм вроде вопрос касался расширенных кодов БЧХ с добавлением бита четности. Но скорее всего запамятовал %) Спасибо.

[Koluchiy 0]

To des00

 

Денис, не появилось ли нового релиза с расчетом генераторного полинома БЧХ?

[des00 27]

To des00

 

Денис, не появилось ли нового релиза с расчетом генераторного полинома БЧХ?

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

[negiin 0]

Почему размерность порта количества ошибок m?

logic [m-1 : 0] obiterr

Может лучше привязать его к количесту исправляемых ошибок

logic [$clog2(t)-1:0]  obiterr

[des00 27]

Почему размерность порта количества ошибок m?

logic [m-1 : 0] obiterr

Может лучше привязать его к количесту исправляемых ошибок

logic [$clog2(t)-1:0]  obiterr

ваша правда, можно но смысл ? при вариации типов декодеров постоянно отслеживать разрядность этого порта? Экономия копейки, требуется введение нового типа, да и кому нужно переписать не сложно %)

[nkie 0]

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

  rs_enc
  #(
    .n        ( n             ) ,
    .check    ( check         ) ,
    .m        ( m             ) ,
    .irrpol   ( irrpol        ) ,
    .genstart ( used_genstart )
  )
  uut_enc
  (
    .iclk    ( iclk      ) ,
    .iclkena ( iclkena   ) ,
    .ireset  ( ireset    ) ,
    //
    .isop    ( isop      ) ,
    .ieop    ( ieop      ) ,
    .ieof    ( ieof      ) ,
    .ival    ( ival      ) ,
    .idat    ( idat      ) ,
    //
    .osop    ( enc__osop ) ,
    .oval    ( enc__oval ) ,
    .oeop    ( enc__oeop ) ,
    .odat    ( enc__odat )
  );

Взято из файла тест бенча rs_eras_enc_dec_tb.v

Что означает

rs_enc
  #(
    .n        ( n             ) ,
    .check    ( check         ) ,
    .m        ( m             ) ,
    .irrpol   ( irrpol        ) ,
    .genstart ( used_genstart )
  )

Понятно что uut_enc - наследник или копия модуля rs_enc, но за что отвечает здесь #(...)?

 

... но за что отвечает здесь #(...)?

все разобрался, передача параметров...

[Костян 0]

Как оптимизировать рассчет GPOLY ?

Синтезатор (использую synplify) на следующий код делает на 12 страниц RTL, содержащий ПЗУ и логику, тогда как на выходе всего лишь массив констант GPOLY

`include "rsParam.vh"
`include "gfFunctions.vh"

module testEnc (


    output gpoly_t  dataOut    //%Данные выход кодера
    );

    
//-----------------------------------------------------------
//% формирование таблиц 
//-----------------------------------------------------------
gpoly_t GPOLY;

rom_t     ALPHA_TO;
rom_t     INDEX_OF;


    always_comb 
    begin
    
        ALPHA_TO  = generate_gf_alpha_to_power(irrpol);
        INDEX_OF  = generate_gf_index_of_alpha(ALPHA_TO);

        GPOLY     = generate_pol_coeficients (genstart, rootspace, check, generate_gf_index_of_alpha(generate_gf_alpha_to_power(irrpol)),  generate_gf_alpha_to_power(irrpol));
        dataOut = GPOLY;
    end

endmodule

 

 

[Костян 0]

собрал в квартусе. на выходе константа :blink:

проблема видимо в synplify

[des00 27]

собрал в квартусе. на выходе константа :blink:

проблема видимо в synplify

Извините что не ответил сразу, да проблема именно в симплифае. По непонятным причинам он не может рассчитать генераторный полином по этой функции. Причем в режиме VHDL все ок, а вот в Verilog ну никак. Поэтому когда потребовалось запустить декодер под хилых, из моделсима прочитал полином и задал руками %)

 

ЗЫ. под режимом VHDL/Verilog понимается то что эта функция есть на обоих языках.

 

ЗЗЫ. Небольшой анонс : на подходе БЧХ со стираниями, декодер витерби, как обычно все под лицензией free for use :)

[Костян 0]

Извините что не ответил сразу, да проблема именно в симплифае. По непонятным причинам он не может рассчитать генераторный полином по этой функции. Причем в режиме VHDL все ок, а вот в Verilog ну никак. Поэтому когда потребовалось запустить декодер под хилых, из моделсима прочитал полином и задал руками %)

спасибо, так и делал изначально:

    always_comb 
    begin
    
        // ALPHA_TO  = generate_gf_alpha_to_power(irrpol);
        // INDEX_OF  = generate_gf_index_of_alpha(ALPHA_TO);

        // GPOLY     = generate_pol_coeficients (genstart, rootspace, check, generate_gf_index_of_alpha(generate_gf_alpha_to_power(irrpol)),  generate_gf_alpha_to_power(irrpol));        
                            //$display ("GPOLY=%p",GPOLY);
        GPOLY = {1, 12'd1023, 12'd3523, 12'd1566, 12'd4068, 12'd3078, 12'd2862, 12'd2296, 12'd4030, 12'd3332, 12'd2733};

        
    end

Причем ALPHA_TO и INDEX_OF рассчитывается без проблем. С помощью атрибутов пытаюсь заставить работать и расчет GPOLY.

была идея, указал даже явно ROM STYLE как logic , все равно синтезатор наделал ПЗУ-шек. Мне не жалко лишней логике, но в моем случае при m=12 синфлифай жрет всю доступную память ПК и вылетает с ошибкой.

 

 

Есть еще вопрос, то ли пятница, то ли еще что, не могу разобраться, как Вы раскрыли скобки при вычислении GPOLY = (X+a)(X+a^2)(X+a^3) и т.д. в функции generate_pol_coeficients. Поясните, пожалуйста, на пальцах :smile3046:

 

 

P.S тогда как RTL в synplify загружен логикой и ПЗУ, technology view имеет константу. весьма любопытно :). это как он аккуратно по коду идет , боится оптимизировать лишнее.

P.S. нашел причинную функцию. synplify стесняется оптимизировать ПЗУ в функции gf_mul