Вообщем то вопрос таков

По какому алгоритму вы рекомендуете делать декодер Рида-Соломона?
В Блейхуте (1) написано, что Берлекемпа-Месси подходит как для аппаратной, так и для программной реализации и он быстрее Евклида.
Морелос-Сарагоса (2) говорит, что алгоритм Евклида лучше подходит для аппаратной реализации из-за структурной однородности.

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

Какой алгоритм лучше подойдет?
Я подозреваю, что BMA, так как на современных ПЛИС можно реализовать сколь угодно замороченный и разветлвенный алгоритм, так что имеет смысл брать самый быстрый.

ПЛИС миллионник
РС - вариации в поле GF(256)
-------
1) "Теория и практика кодов, контролирующих ошибки" Р.Блейхут "МИР", Москва, 1986
2) "Искусство помехоустойчивого кодирования. Методы, алгоритмы, применение" Р.Морелос-Сарагоса Техносфера Москва 2006

Если много тактов можно потратить на декодирование и нужно поменьше объем - то итеративный Евклида, если быстрее - то вариации БМ без инверсий. Стоит посмотреть вот эти статьи:
1. D.V.Sarwate, N.R.Shanbhag. High-Speed Architectures for Reed-Solomon Decoders. IEEE Transcations on VLSI Systems, Vol. 9, No. 5, October 2001, pp. 641-655.
2. H. Lee. High-Speed VLSI Architecture for Parallel Reed-Solomon Decoder. IEEE Transactions on VLSI Systems, Vol. 11, No. 2, April 2003, pp. 288-294.
В [1] рассмотрены разные варианты реализации БМ, в [2] - Евклида.

В (1) и (2) разобраны и Евклид и БМА к слову :-)
Могли бы вы пояснить про БМА с инверсиями и без? Я ориентируюсь на алгоритм из Блейхута.

Присоеденяюсь к предыдущему и советую (1). Кстати там, в таблице 1 и приводится сравнение известных способов БМ и евклида. Так вот приведенные там методы riBM и RiBM в сравнении с Евклидом по некоторым (интересным мне) оказались лучше. Но уступают по количеству умножителей (а они занимают довольно значительное место ). Если остановитесь на БМ то лучше этой статьи пожалуй нет. Во всяком случае не нашел (я имею ввиду описание реализации, а не теорию).

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

По инверсии. В классическом БМ необходимо деление. Его заменяют на умножение на инверсию. Это и является самым мерзким местов при классическим БМ при аппаратной реализации. А методы без инверсии избавлены от этого.

Я тоже советую делать решатель по [1]. Сам делал схожим образом, но модифицировав классический iBM как мне было удобно (он также неплохо с точки зрения теории раскрыт в статье I. S. Reed, M. T. Shih, T. K. Truong, “VLSI design of inverse-free Berlekamp–Massey algorithm,” Proc. Inst. Elect. Eng., pt. E, vol. 138, pp. 295–298, Sept. 1991.). В два раза больше тактов, но удалось разбить критический путь, так как невязка у меня рассчитывается в первом такте итерации в блоке DC, а в расчете локаторов используется на втором такте в блоке PE. В результате выше по частоте, чем iBM и можно обойтись одним умножителем в PE, так как на первом такте можно умножить гамму на лямбда. А 48 тактов для кода (255,239,8) меня устроило.

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

Деление (через инверсию и умножение) - это медленно и много места. Вычисление обратного в поле Галуа - одна из самых плохо минимизируемых функций, которые я видел . Например, в алгоритме Форни, так же, как сделано в [2], реализовал инверсию на блочной памяти таблицей 256x8.

Всем спасибо за советы! Буду делать BMA.

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

Кстати, алгоритм Судана кто нибудь разбирал? Имеет смысл влезать?
http://citeseerx.ist.psu.edu/viewdoc/downl...p1&type=pdf

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

тоже в планах сделать собственного рида соломона, как мне надо. но я буду сразу в хдл делать, без симулинка

А что так?

почему без симулинка? или зачем свой делать ? %)

Почему без моделирования,хотя можете не отвечать,действительно можно и так.

Я Витерби делал по следующему пути. Сначала в Матлабе реализовал алгоритм функционально соответствующий тому, что будет в железе. Потом ручками написал VHDL код, потом сравнивал работу железки и алгоритма - результаты одинаковые, остался доволен.
Думаю, что моделирование необходимо для оценки функциональных параметров. В случае Витерби в Матлабе алгоритм был покручен с разным ограничением на глубину декодирования, на максимальную метрику, на варианты поиска минимума и т.д. Крутить такое в HDL было бы не очень удобно.

Сейчас хочу попробовать делать модель в Симулинке, с прямой трансляцией в HDL код.

А не могли бы Вы скинуть мне Вашу версию модели в Симулинке алгоритма Берлекемпа-Месси? Как раз занимаюсь этим вопросом, но он что-то у меня не идет(