То, что я написал, не имеет отношение к БЧХ и справедливо для любого кода.
Вообще, способность кода к обнаружению ошибок не имеет отношения к методу декодирования - это свойство кода, а не декодера.
В принципе, код может обнаружить любую ошибку, не совпадающую с кодовым словом.
Понятно, что некоторые ошибки веса d в принципе не могут быть обнаружены, если совпадают с кодовым словом.
Если поделить количество кодовых слов веса d на общее количество векторов веса d, то легко посчитать,
с какой вероятностью можно НЕ обнаружить ошибку веса d.
Количество кодовых слов мин. веса для большинства коротких БЧХ известно точно.
Для длинных кодов БЧХ известно, что их весовой спектр приближается к биномиальному распределению с ростом длины.
Иногда можно пользоваться грубой оценкой необнаружения ошибки в виде 1/(2^r).

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

Гарантированно мы не можем сказать ничего.
Есть след. варианты.
1) На расстоянии D (D<9) от принятого вектора есть кодовое слово. Тогда произошло либо D ошибок либо, как минимум, d-D.
2) Ближайший кодовый вектор находится на расстоянии D (D>8). Тогда произошло не менее D ошибок.
Это все, что можно сказать.
В вашем конкретном случае 10 ошибок могли лечь как кодовое слово, тогда вы увидете кодовое слово на расстоянии 6 от принятого вектора.
Это значит, что ошибок было либо 6, либо как минимум 16-6.

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

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

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

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

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

To des00

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

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

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

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

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

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

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

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


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

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

собрал в квартусе. на выходе константа
проблема видимо в synplify

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

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

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

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

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


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


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