[SergeyF 0]

Берусь предположить, что число тактов равно 2t, где t число исправляемых ошибок, если использовался модифицированный, безинверсный БМА (RiBM)

Не совсем. Я его разложил по тактам для уменьшения числа умножителей, поэтому 48 тактов для t=8. 2t=16, сначала первый этап решения (нахождение локаторов) 32 такта, потом второй этап - нахождение значений ошибок 16 тактов.

[des00 25]

...для t=8. 2t=16, сначала первый этап решения (нахождение локаторов) 32 такта, потом второй этап - нахождение значений ошибок 16 тактов.

хммм, что бы за 2t операций найти локатор, нужно t умножителей. полином значений это результат перемножения полинома локаторов и синдромов. Зачем нужно 16 тактов ? вы делаете это на отдельном умножителе ?

 

[SergeyF 0]

хммм, что бы за 2t операций найти локатор, нужно t умножителей. полином значений это результат перемножения полинома локаторов и синдромов. Зачем нужно 16 тактов ? вы делаете это на отдельном умножителе ?

Я делал по статье

Dilip V. Sarwate, Naresh R. Shanbhag "High-Speed Architectures for Reed–Solomon Decoders" IEEE TRANSACTIONS ON VLSI, VOL. 9, NO. 5, OCTOBER 2001

и другим, на которую в этой работе ссылаются.

 

Использовал базовый iBM. В нем сначала считаются локаторы lambda за 2t итераций, а потом ошибки omega за t итераций. На итерациях расчета локаторов (2t итераций) рассчитывается lamba(r + 1) = gamma® *lambda®-delta®*beta® для каждого локатора lambda. Что требует двух умножителей.

 

Так как мне не нужно было спешить, я разложил итерацию на два такта для использования одного умножителя в модуле, который в той статье называется PE. Теперь думаю, почему 48, а не 40 - будет время, подниму проект. Получилось быстрее последовательного Евклида, но медленнее любой из приведенных в статье реализаций БМ. Но зато и по объему что-то среднее между Евклидом и их реализациями БМ. :)

 

[des00 25]

Использовал базовый iBM. В нем сначала считаются локаторы lambda за 2t итераций, а потом ошибки omega за t итераций. На итерациях расчета локаторов (2t итераций) рассчитывается lamba(r + 1) = gamma® *lambda®-delta®*beta® для каждого локатора lambda. Что требует двух умножителей.

такое ощущение что мы говорим о разных попугаях. как я понял вы сделали ribm. Который требует 2t итераций. но на шаге Step.1 riBM.1 видно что рассчитываются сразу все компоненты полинома локаторов. (i = 0,1.....t) расчет каждого локатора состоит из двух умножений и одного сложения. итого только тут уже требуется t умножителей если в дуплексе работать, а не два. Потом нужны еще умножители для delta, не смотря на то что анализируется только delta[0], я вижу что нужно считать все компоненты delta (i = 0,1,....t). Или я чего то в статье упустил?

Именно поэтому я реализовал SiBM, который требует t итераций.

[SergeyF 0]

Нет, я сделал iBM, как он там приведен в самом начале на стр. 643.

[des00 25]

Нет, я сделал iBM, как он там приведен в самом начале на стр. 643.

тогда тем более, смотрим Step Ibm.1 требуется t умножений для дельта, шаг Step Ibm.2 2*t умножений на локатор и так для t локаторов. По моим расчетам двумя умножителями, на все, за 2*t тактов не обойтись. Я что то упускаю ?

[SergeyF 0]

тогда тем более, смотрим Step Ibm.1 требуется t умножений для дельта, шаг Step Ibm.2 2*t умножений на локатор и так для t локаторов. По моим расчетам двумя умножителями, на все, за 2*t тактов не обойтись. Я что то упускаю ?

Конечно, умножителей там во всем решателе БМ больше. В таблице 1 внизу приведено. Я сделал все почти как в fig.1-fig.3, но ввел дополнительный регистр на выходе дерева сложений перед модулем Control (fig.2) и сделал модуль PE (fig.3) на одном умножителе и большем количестве мультиплексоров, чтобы работал за два такта. За счет этого, если посмотреть таблицу 1 на странице 650, у меня получилось 2t+2 умножителей и больше мультиплексоров, чем в iBM(Blahut), меньший критический путь, но 6t тактов на решение. Я не говорю, что сделал лучше - просто нашел некоторую устраивавшую меня точку по объему, частоте и времени решения.

[des00 25]

Конечно, умножителей там во всем решателе БМ больше.

а я уж думал что у меня лыжи не едут :beer:

 

[barabek 0]

Кстати, внесу свою копеечку, заодно покритикуйте. Написал для РС функции умножителя, генератора члена поля заданной степени и функцию генератора полинома для енкодера.

GF_functions.v

[des00 25]

Кстати, внесу свою копеечку, заодно покритикуйте.

какой смысл использовать SV и делать все на макросах ?

 

ЗЫ. расширил свой бчх декодер, rs декодером. скоро выложу полную сборку ;)

 

[barabek 0]

какой смысл использовать SV и делать все на макросах ?

 

Сейчас не помню почему :). То ли из-за модельсима, то ли еще из-за чего-то так вышло. Но решил так. Кривоватенько, согласен.

 

 

 

[Muscat 0]

Раз уж тема превратилась в обсуждение Рида-Соломона, то спрошу здесь же

 

1) То, что исправимых ошибок не было, мы определяем на стадии вычисления синдромов. Полинома локаторов и значения ошибок вычисляем в KES. В классическом БМА, тот что из Блейхута, если у нас deg(delta(x))=L, т.е. степень регистра сдвига соответствует длине L, то комбинация исправима, если нет то ошибок было больше t. Но в модифицированном БМА никакой константы L, с которой надо бы сравнивать нет. Как быть? Как определить, что принятая комбинация неисправима?

 

2) При вычислении синдромов по принятой комбинации R[r0,r2,r3...r254] мы вычисляем

S(1)=r0+r1*(a1)+r2*(a1)^2+r3*(a1)^3....r254*(a1)^254

 

S(16)=r0+r1*(a16)+r2*(a16)^2+r3*(a16)^3....r254*(a16)^254

 

Т.е. в параллели у нас есть 16 блоков, в котором за 255 тактов (или за меньшее при соответствующей оптимизации) вычисляется сумма комонентов синдрома. Мы поочередно подаем внутрь каждого блока принятый кодовый символ и в каждом блоке умножаем на соответствующую степень соответствующего числа.

 

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

(a1) (a1)^2 (a1)^254

....

(a16)..... (a16)^254

 

Как вы решили эту проблему? Где храните эти значения?

- На памяти, но тогда каждый такт надо будет доставать 16 значений по 8 бит, т.е. потребуется память с шириной 128 бит. В принципе не так много, но пока думаю есть ли другие варианты. Тут же вопрос, что перед началом работы декодера будет некая процедура инициации, которая вычислит соответствующие значения и заполнит память, чтобы потом доставать оттуда данные. Либо хранить их во флэше.

- Вариант который я не представляю как осуществить, но просто как мысль. Члены поля Галуа мы генерим с помощью регистра сдвига. Можно ли зная требуемую последовательность (a2...a4....a8...a16...) синтезировать такой регистр сдвига, который выдавал бы ее? Тогда нам потребуется всего ничего триггеров и двоичных сумматоров. Но я не представляю как это сделать математически :-)

[des00 25]

Раз уж тема превратилась в обсуждение Рида-Соломона, то спрошу здесь же

ждите немного, я почти закончил %)

 

[Muscat 0]

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

[des00 25]

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

 

1. в модифицированных никак, только проверка количества корней и степени полинома.

2. нигде, хранить этого не нужно. почему? смотрите выложенный мой кодер бчх