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

Умножение в поле Галуа

Да, поиск Ченя действительно найдет ошибок не больше, чем степень полинома, так что этот метод не подходит.

 

В алгоритме Форни осуществляется деление одного члена поля на другой. Деление на ноль не определено, соответственно я отслеживал эту ситуацию, как свидетельствующую о том, что произошла неисправимая ошибка. Я попробовал сравнить этот метод с классическим БМА

 

Классический БМА,описанный в Блейхуте, стр 215, в котором исправимость комбинации определяется выражением deg(delta(x))=L, где delta(x) - собственной высчитанный полином локатора ошибок. L - длина регистра, внутренняя переменная алгоритма. То есть степень полинома не должна превышать L

 

Получилось так,что эти ситуации не пересекаются. То есть проблема деления на ноль возникает тогда, когда БМА посчитал комбинацию исправимой, и не возникала, когда БМА считал, что эту ошибку исправлять не следует.

 

Короче вопрос

Как вы в своих моделях Рида-Соломона отслеживаете неисправимые ошибки?

 

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


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

Короче вопрос

Как вы в своих моделях Рида-Соломона отслеживаете неисправимые ошибки?

Еще раз повторюсь auk_rs_mem_atl.vhd (основной блок RS от альтеры)

 

  if ((bms_done='1' and numerr_ctrl(1)='1' and pull_numerr_fifo='0') or
      (bms_done='1' and numerr_ctrl(0)='1' and pull_numerr_fifo='1')) then
    numerrhold_q(1) <= numerr_bms;
  elsif pull_numerr_fifo='1' and numerr_ctrl(2)='0' then
    numerrhold_q(1) <= (others => '0');
  end if;
  if ((bms_done='1' and numerr_ctrl(2)='1' and pull_numerr_fifo='0') or
      (bms_done='1' and numerr_ctrl(1)='1' and pull_numerr_fifo='1')) then
    numerrhold_q(2) <= numerr_bms;
  elsif pull_numerr_fifo='1' and numerr_ctrl(2)='0' then
    numerrhold_q(2) <= numerrhold_q(1);
  end if;
....
counter_b : Process (clk, reset)
BEGIN
  if reset='1' then
    numroots <= (others => '0');
  elsif Rising_edge(clk) then
    --if ena_chn_int='1' then
      if toggle_cnt_del(1)='1' and polyzero='1' then
        numroots <= (others => '0');
      elsif toggle_cnt_del(1)='1' and polyzero='0' then
        numroots(1) <= '1';
        numroots(wide downto 2) <= (others => '0');
      elsif polyzero='0' and chn_status/=idle then
        numroots <= unsigned(numroots) + natural(1);
      end if;
    --end if;
  end if;
END PROCESS counter_b;
.........
decfail_gen_proc_d: process(numroots, numerrhold_q(2), chn_status, chn_end_point, polyzero)
begin

  if chn_end_point='1' and chn_status/=idle then
    if polyzero='0' then
      if (unsigned(numroots)+natural(1)) = unsigned(numerrhold_q(2)) then
        decfail_gen_d <= '0';
      else
        decfail_gen_d <= '1';
      end if;
    else
      if unsigned(numroots) = unsigned(numerrhold_q(2)) then
        decfail_gen_d <= '0';
      else
        decfail_gen_d <= '1';
      end if;
    end if;
  else
    decfail_gen_d <= '0';
  end if;
end process decfail_gen_proc_d;

 

Зы. результаты моделирования чуть позже

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


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

Короче вопрос

Как вы в своих моделях Рида-Соломона отслеживаете неисправимые ошибки?

 

Никак. Чтобы обнаруживать ошибки и/или исправлять нужна избыточность, она уже потрачена на исправление ошибок, то что при превышении определённого количества ошибок блок декодируется неправильно абсолютно нормальная ситуация.

 

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


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

Так а что делать то с делением на ноль? У меня одного что ли такая ситуация возникает?

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


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

Так а что делать то с делением на ноль? У меня одного что ли такая ситуация возникает?

 

x/0=0 хоть это и не верно математически

 

 

 

 

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


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

Блейхут, стр 30

"Каждый ненулевый элемент <поля> имеет обратный и следовательно, деление всегда определено, за исключением деления на ноль"

 

Мне по прежнему кажется, что "делить на ноль=умножить на ноль" это какая то опасная штука и нужно как нибудь обойтись без этого.

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


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

Мне по прежнему кажется, что "делить на ноль=умножить на ноль" это какая то опасная штука и нужно как нибудь обойтись без этого.

я вколотил в таблицу инверсий число 1 и не парюсь %)

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


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

>>я вколотил в таблицу инверсий число 1 и не парюсь %)

 

Что это значит? Таблица инверсий состоит из 255 обычных членов поля Галуа и еще возможно из 256ого нуля, если вы разрешили деление на ноль

 

Я доковырял свою модель, помоделировал модель кодека при передаче через АБГШ, сравнивал с эталонными кривыми из BERTool из матлаба - совпадает до десятой дБ. Вносил ошибки вручную, все ошибки кратности меньшей t исправлялись без проблем. Пробовал для кодека (15,9) и для (255,239).

Поскольку рассматривать строки из 255 чисел вряд ли кто захочет,привожу данные для простенького кодера (15,9), полином 1+X+X^4, число исправляемых ошибок 3

 

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

 

Элементы поля Галуа я обозначал следующим образом

a^0 -> 1

a^1 -> 2

a^2 -> 3

0 -> 16 (Все нули)

 

Исходная последовательность была закодирована, а затем внесено 4 символьные ошибки (позиции 1,2,9,12)

эталон [6 10 15 12 16 10 12 10 15 9 2 10 2 13 5]

принято [5 16 15 12 16 10 12 10 11 9 2 16 2 13 5]

 

Полином локаторов ошибок высчитанный классическим БМА по Блейхуту

[1 4 10 7 16 16 16 16 16]

Как видим, он имеет степень 3, то есть максимальное слагаемое полинома (x^4)*(a^8),все остальное нуль

При этом вычисленное L, как ни странно, так же равно 3. Хотя по Блейхуту, такого быть не должно.

 

Едем дальше

 

По модифицированному RiBM было насчитано

delta_loc =[14 2 8 5]

omega_loc =[9 4 11]

 

Полином локаторов тот же, что и высчитанный в БМА, с точностью до множителя a^13 (=14)

 

И вот эти 2 полинома поступают на совмещенную процедуру поиска Ченя-Форни, где Ченя находит 1(!) ошибку на позиции 5 со значением a^3

err_num = 5 0 0

err_val = 4 16 16

err_amount = 1

 

И она исправляется

 

Итого получаем

эталон [6 10 15 12 16 10 12 10 15 9 2 10 2 13 5]

принято [5 16 15 12 16 10 12 10 11 9 2 16 2 13 5]

исправлено [5 16 15 12 4 10 12 10 11 9 2 16 2 13 5]

 

То есть мы бережно сохранили 4 внесенных ошибки и добавили еще одну свою на 5 позицию.

 

1) почему для полинома степени 3 Ченя нашел 1 корень? Означает ли это, что не любой полином с коэффициентами поля Галуа имеет число корней равно степени полинома? Или это означает, что я криво реализовал поиск Ченя? Если число ошибок было меньше t, то Ченя находит число корней равное степени полинома. Если так, то прав barabek, который именно так и отслеживает неисправимые комбинации и не всякий полином степени n с коэффициентами из расширенного поля Галуа может быть представлен как (x-A1)(x-A2)..(x-An)

 

2) Как вы отслеживаете подобные ситуации? Прав ли Petrov, что их отследить невозможно? Отслеживать по значению равенства нулю производной в Форни не подходит. В RiBM никакого коэффициента L нет. Как это сделано в "фабричных" декодерах? То есть единственная возможность, это несовпадение степени полинома и количество корней найденных Ченя? Как реализовать аппаратно подобную процедуру? Устраивать перебор всех коэффициентов локатора ошибок, пока не найдем максимальный, неравный нулю?

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


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

>>я вколотил в таблицу инверсий число 1 и не парюсь %)

 

Что это значит? Таблица инверсий состоит из 255 обычных членов поля Галуа и еще возможно из 256ого нуля, если вы разрешили деление на ноль

Да в общем-то без разницы, что вставлять в таблицу на 0-ю позицию, т.к. одновременно равняться 0 и полином лямбда и производная полинома лямбда не могут (мне так кажется ). Соответственно какая разница, чему будет равен результат вычисления по Форни, если полином локатора ошибок на данной позиции отличен от нуля.

 

1) и не всякий полином степени n с коэффициентами из расширенного поля Галуа может быть представлен как (x-A1)(x-A2)..(x-An)

 

Ага, ведь есть же неприводимые полиномы. Как более наглядный пример возьмем уравнение над вещественным полем x^2+x+1=0. Для этого полинома нет вещественных корней (мнимые -это другое поле)

 

 

2) Как вы отслеживаете подобные ситуации? Прав ли Petrov, что их отследить невозможно? Отслеживать по значению равенства нулю производной в Форни не подходит. В RiBM никакого коэффициента L нет. Как это сделано в "фабричных" декодерах? То есть единственная возможность, это несовпадение степени полинома и количество корней найденных Ченя? Как реализовать аппаратно подобную процедуру? Устраивать перебор всех коэффициентов локатора ошибок, пока не найдем максимальный, неравный нулю?

 

Имеется ввиду, что если ошибка больше t, то возможны три варианта - 1)определяем что кратность больше t и делаем заключение о недостоверности, (кол-во корней != степени лямбда) 2) ошибочно "исправляем" 3) неправильный принятый пакет выдаем за достоверный. Возможность варианта 3 очевидна. Допустим возникло столько ошибок, что полином "перепрыгнул" через кодовое расстояние и занял другое допустимое значение. Ну а вариант 2 следует из варианта 3, только чуть-чуть "недопрыгнул".

 

 

 

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


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

У меня свой код практически закончен, меня этот конкретный вопрос сейчас интересует ;-)

если вам интересно можете сравнить ;)

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


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

Я верилог не знаю, так что сравнить пока не могу :-)

 

Сейчас пока начала с VHDLописания кодера

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


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

Я верилог не знаю, так что сравнить пока не могу :-)

а зря :)

 

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


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

Читайте теорию кодов Рида-Соломона,тогда 3/4 вопросов отпадут :)

1. При работе без стираний (явного указания декодеру позиции ошибки) количество обнаруживаемых и исправляемых символов составляет (чмсло проверочных символов)/

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

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


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

<i>Поэтому имеет смысл ставить после подсчета локатора решающее устройство у которого идет проверка степени полинома локатора, при нулевой и превышающей ((чмсло проверочных символов)/2-1) дальнейший декодер не запускается- в первом случае блок принят без ошибок и дальнейшее декодирование не имеет смысла,во втором ошибок слишком много. </i>

Неа

 

4 варианта

1) Блок принят совсем без ошибок

2) Можем обнаружить и исправить ошибку

3) Можем только обнаружить ошибку

4) Необнаруживаемая ошибка

 

Наличие ошибки фиксируется тем, что полином синдрома неравен нулю,т.е. если ошибок не было (1) или, что для нас равносильно, кодовое слово "перескочило" в другое разрешенное слово, то считать полином локатора и значений уже не надо.

 

2 случай характеризуется как раз тем, что поиск Ченя нашел ровно столько ошибок, какова степень полинома локатора.

3 случай как отслеживается, когда Ченя нашел корней больше-меньше, чем степень полинома. Здесь мы точно знаем, что ошибка была, но исправлять не нужно. Я покрутил модельку в М-Лабе, если не делать этой проверки, то кодер "найдя" ошибочные корни в поиске Ченя, начинает эти символы исправлять, добавляя свое.

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


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

Если сравнивать степень полинома с числом найденных корней,то это эквивалентно порогу в (число проверочных символов)/2, что в свою очередь приводит, в зависимости от параметров кода, к вероятности ложного срабатывания вплодь до 10^(-4), что является во многих случаях недопустимо большой величиной,поэтому и рекомендуется ставить порог на декодирование ниже реально допустимого для кода. Отстут на 1 снижает вероятность ложного срабатывания примерно на 10^6

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


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

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

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

Гость
Ответить в этой теме...

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

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

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

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

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

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