сделал отдельную тему для проекта с началом здесь

сообщения из кросс тем переместил.


продолжаем пиарить красоту SV. итак

новый релиз проекта БЧХ :
1. переписана работа с математикой в полях галуа. Теперь ква собирает декодер много быстрее, почти не задумываясь и не требует кучу памяти %)
2. переписан статически конфигурируемый БЧХ кодер/декодер, удалены лишние модули, ясность выше код чище
3. добавлен статический конфигурируемый RS кодер/декодер, стиль унифицирован с БЧХ кодером. Внимание : в сорцах есть реализация BM алгоритма, требующая на декодирование всего check тактов (!!! именно тактов а не шагов).
4. модифицированы random constraints тестбенчи, ясность выше, код чище.
5. Все как и прежде, не требует каких либо генераторов, скриптов и т.д. Вычисляется и синтезируется по месту. Расчет генераторного полинома БЧХ по прежнему не сделан %(

Динамически конфигурируемые кодеры/декодеры выкладывать не буду, это уж как нить сами

UPD. Естественно осталась возможность использовать несколько инстансов кодеров с разными параметрами в одном проекте %)

Таки нашел время добить reformulated IBM алгоритм для БЧХ кодов, который приведен в статье Low-Power High-Throughput BCH Error Correction VLSI Design for Multi-Level Cell NAND Flash Memories со случайно(хотя скорее преднамеренно !!!) допущенной ошибкой. В итоге вывел свою реализацию на основе RIBM для РС кодов.

SRIBM позволяет за t тактов (!!!) вычислить полином локаторов + шикарно ложиться на архитектуру плис. В зависимости от используемого кода и требуемой производительности позволяет получить хорошие результаты по ресурсу(!!!). В комплекте 3 РТЛ реализации этого алгоритма + идеалки используемые для вывода алгоритма.

1. Причесал описание, для БЧХ добавил полиномов, кое что поправил в тестбенче
2. Добавил статически конфигурируемый декодер РС со стираниями, по алгоритму ribm, правда реализации только самая быстрая и самая медленная.
3. Различные алгоритмы декодирования РС со стираниями в идеалках (BM, IBM, rIBM, RIBM)

ЗЫ. точнее не самая быстрая, можно посчитать также за check тактов, если полином локаторов стираний, рассчитать заранее используя блок rs_eras_syndrome_count_poly для вычисления синдрома и полинома локаторов стираний

Не нашел. Функция generate_pol_coeficients таже.

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

Я думал что добавили функцию расчета полиномов. Проблема в том, что нужно считать больше 511. Ну да ладно.
Кстати, нашел еще одну реализацию БМ, можно ли при этом уменьшить обьем на 40%?

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


надо глянуть на досуге



хмм, смотрю алгоритм на странице 773, судя по алгоритму должно быть 2*t умножителей GF(2^m), смотрю выложенный код

те же t2 умножителей %) (t2+1) это константа,

а если еще учесть что у них в алгоритме, а в выложенном коде я немного смущен %)

Для кода БЧХ GF(2^11) исправляющего 8 ошибок, какую тактовую частоту может обеспечить ваш декодер?

полином дайте проверю. Из того что делал, декодер с t = 23 в поле GF(2^8), свободно, не особо напрягаясь, работает на 200МГц на третьем сыклоне. Для GF(2^11) проверить надо, но думаю что 150 на том же чипе даст точно.

у меня дает 135 на третьем циклоне, а надо 155. Какими способами можно увеличить частоту?

полином дайте, проверю сколько получиться.

Вот для примера кодер {8191, 8152, 3/7} работа в поле GF(2^13), чип EP3C25...C8, используется TQ, все по дефолту, порты виртуальные

результаты LE/REG/Fmax

bch_enc 45/44/402.09MHz
bch_dec в режиме ribm_t_by_t 823/447/180.6MHz

и это при математике в поле GF(2^13), 5-6 слоев логики. При этом TQ показывает пару возможных оптимизаций для разгона, но если учесть что на декодирование уходит 22 такта, а пакет длинной 8191 такт, то можно сделать BM по мультициклу и задрать тактовую/битовую потока под 250-300 МГц %)


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

полином 2053(x^11+x^2+1), код (2040, 1952) поле GF(2^11) 8 ошибок чип EP3C25...C8

а где генераторный полином? примитивный полином мне не нужен %)

без генераторного полинома, bch_enc не собрать, а результаты по декодеру LE/REG/Fmax

bch_dec в режиме ribm_t_by_t 1127/790/213,04MHz

4 слоя логики. Если учесть что для этого результата решение BM занимает 129 тактов, а пакет весит 2040, то можно посадить BM для работы на половинном клоке, поставить мультицикл и выжать 250-300 МГц. Но и в базе 200 мегабит в секунду обрабатывает не особо напрягаясь %)

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

Всем кто решиться использовать этот декодер при низких Eb/N0, надо помнить что в этом декодере, перебор ченя и коррекция ошибок происходят одновременно. Поэтому в случае отказа от декодирования, который определиться в конце ченя, декодер размножает ошибки. Что бы это побороть, нужно немного модифицировать ченя, выплюнуть сырые данные в фифошку/память вместе с коррекцией ошибок ну и потом считать с коррекцией или без %) но это не сложно и делается минут за 10-20 %)

Да, интересный у вас результаты получились. Меня интересует именно декодер. Вроде для него генераторный полином я не использовал, но посмотрю. Точно сейчас посмотреть не могу, но приблизительно sibm/5000 LE/700-800 Reg/135 Fmin Mhz (требуется 155), но результат за 16 тактов. На решение не более 32 тактов, иначе не успею. Интересно какие при таком условии будет характеристики вашего декодера. Можете объяснить как посадить BM для работы на половинном клоке и что значит поставить мультицикл и выжать 250-300 МГц, вообще как-то не очень понятно что вы имеете ввиду. Если можно, объясните поподробнее.

bch_dec(ribm_1t) BM выполняется за t+1 = 9 тактов, 3209/732/170.85MHz, судя по TQ упирается в разводку, если сделать register dublication + кое что подпилить в BM думаю что выйдет на 200МГц.
bch_dec(ribm_2t) BM выполняется за 2*t+1 = 17 тактов, 2472/776/184.95MHz, тут сложнее, надо бороть "лишний" мультиплексор в BM


Хмм, вам лучше почитать мои публикации о TQ, временных ограничениях, одноцикловых цепях и мультицикловых. Если на пальцах, то подаете на clockena меандр и говорите временному анализатору что задержки считать не для периода T, а для периода 2*T. Естественно что производительность именно этого блока упадет, но если ее достаточно для выполнения задачи, то.... %)

Кстати, вы же тестируетесь с каким то кодером. Генераторный полином можно получить, подав "дельта импульс". последовательность со всеми нулевыми битами, кроме одного %)

Вы имеете ввиду подать на вход кодера дельта импульс? Еще было бы интересно посмотреть результаты для sibm алгоритма, чтобы сравнить.

да. нашел стандарт 975.1 там указаны функции циклотомических классов для получение генераторных полиномов GF(2^11), на досуге получу полином %)


а смысл? он гарантировано проиграет, для этого достаточно посмотреть как рассчитывается delta %)

bch_dec(ibm_2t) выполняется за 2t+1 = 17 тактов, 2816/957/145.69MHz
bch_dec(ibm_4t) выполняется за 4t+1 = 33 такта, 2212/959/188.08MHz
bch_dec(ibm_2t_by_t) выполняется за 2t + 2(t+1)^2+1 = 179 такта, 1805/1057/238.04MHz. Но этот в свое время конвейризировался по самое нехочу

Для этого кода (2040,1952) t= 8 G1(x) = x11 + x2 + 1, G3(x) = x11 + x5 + x3 + x2 + 1, G5(x) = x11 + x6 + x5 + x + 1, G7(x) = x11 + x7 + x3 + x2 + 1, G9(x) = x11 + x8 + x5 + x2 + 1, G11(x) = x11 + x8 + x6 + x5 + x4 + x + 1, G13(x) = x11 + x10 + x3 + x2 + 1, G15(x) = x11 + x10 + x9 + x8 + x3 + x + 1.
g(x)=G1(x)*G3(x)*G5(x)*G7(x)*G9(x)*G11(x)*G13(x)*G15(x)

спасибо !!!

А так не проще: Если надо просто построить код, то набрать в матлабе строчку:

>> [genpoly,errorcorr] = BCHGENPOLY(2047,2047 - 11*8)

проще, но в матлабе что у меня на машине написано



у вас какая версия матлаба ?

Для генерации длинных кодов я использовал следующий файл.

о, это то что нужно. спасибо %)

R2010a. Ограничение на степень двойки при генерации БЧХ - не более 16.
Так что до длин 65535 все должно работать.
Сейчас на рутрекере есть более поздняя версия матлаба.Может быть там еще лучше.

понятно, надо будет глянуть, я держу старую версию, т.к. ИМХО она быстрее в режиме косимуляции работает %)

Почему вы решили сделать процедуру Ченя и исправление ошибок одновременно?

мне нужна была минимальная задержка, при этом на размножение ошибок можно было закрыть глаза.

Есть версия декодера лишенная этого недостатка выкладывать ее не вижу смысла. Любой разработчик сделает эту задачу максимум за пару часов (надо всего то, разбить ченя на 2 модуля с передачей подтверждений между ними). А кто не сможет волен обратиться за кастомизацией, о цене договоримся %))))))))))

Также есть версии декодера с динамически изменяемым {n, check}, но смысла выкладывать не вижу. Выложенные сорцы заточены под простую реализацию динамического изменения, кому надо тот сделает %)

Правильно ли я понял, что для плис оптимизация поиска Ченя не актуальна?
Clock enable применен для энергосбережения?
Если в какой-то момент декодер мне не нужен, то я должен отключить clock enable. Перед включением сбросить ресетом(для инициализации) и подать clock enable?

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

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

я вам сразу про это сказал %)

Да я помню. Хотел посмотреть ради интереса что изменится. Действительно вы были правы.

А {n,check} - в Вашей версии любые можно поставить на ходу или заранее определенный набор (набор определяется до синтеза) ? Модифицировал Ваш код для декодирования 12 кодов, каждый со своим {n,check}, длина до 16384. Декодер занимает около 5000 LE. С ростом количества кодов растет и декодер, примерно линейно. В основном это умножители в галуа на константы. Если бы были умножители числа на число, то от количества кодов декодер бы не так сильно рос. Только вот не знаю на сколько такое решение реально. Просто в моей задаче скорость не нужна (50 мгц за глаза), а вот количество кодов надо 36...
В Вашей версии динамически изменяемых {n,check} умножители в галуа также на константы или умножители динамического числа на динамическое число?

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

Для работы мне нужны были с динамическим укорочением и с предопределенном набором check.

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

Для динамического декодера нужно делать немного по другому :
1. genstart == 0, это позволит очень просто считать синдромы по максимальному check (не нужна коррекция позиций синдромов) цена : дополнительный умножитель при расчете значений ошибок
2. везде считать на максимальный check
3. уйти с RIBM на rIBM алгоритм (не нужна коррекция позиций готового полинома локаторов). цена : несколько больший ресурс при последовательном вычислении.
4. ченя делать в обратном порядке в отдельном проходе (не нужна начальная коррекция при укорочении кода).

ну собственно все, в итоге ресурс декодера у вас будет чуть больше, чем статического декодера кода с максимальным check


рад что вы разобрались в вопросе %)


И еще про динамическую конфигурацию. Если кол-во генераторных полиномов больше 4-х, то выгоднее поставить кодер с умножителями на число, иначе мультиплексор + 4 кодера %) (для полей GF(2^8)

Если есть желание, можем скооперироваться и сделать ваш, полностью перестраиваемый декодер. Но с условием, сорцы открываем ?

Зачем нужна behavioral model? Чем это лучше симуляции синтезируемого кода? Ведь в разработку добавляется дополнительный этап сравнения двух моделей?

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

Доброго времени суток!прочитал представленные исходники!и никак не могу разобраться, как все-таки поступать, в процедуре Ченя, с укороченными кодами?у меня получаются позиции ошибок но соответственно со смещением на длину укорочения кода!пытался задерживать FIFO на эту задержку но получается расхождение!может кто нибудь подскажет как правильно быть? заранее спасибо!

Вопрос разрешился!))))

Делаю параллельный БЧХ. При этом он получается в несколько раз больше Рид-Соломона при той же пропускной способности. Так должно быть и почему?

Я так понимаю все зависит от параметров ваших кодов.

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

Приведу пример 2 декодера BCH(2040,1930) по 8 бит занимают 20% в EP2AGX45DF29C4. При этом блок Berlekamp–Massey только один. 2 РС декодера RS(255,239) по 8 бит занимает примерно 500 ячеек, т.е. значительно меньше.

если имелось в виду по 8 бит за 1 такт, то чему удивляться то? ручками распишите получаемую логику на уровне функций и это станет очевидно.

ЗЫ. если вам нужна производительсность бчх 8 бит за 1 такт (что, если брать например сыклон 3, соответствует ~200 мегабайт в секунду), то как вариант поставить 8 декодеров, с одним блоком BM.

Очередное обновление :
1. Добавил все БЧХ полиномы, которые использовал и проверял
2. Добавил возможность изменять rootspace в кодере/декодере RS без стираний (по просьбе форумчан)

Жаль, что нет кнопочки "Спасибо!"

1. Добавил возможность изменять rootspace в кодере/декодере RS со стираниями (для общности)

Есть вопрос по парралельному декодеру. Если длина кодового слова не кратна ширине декодера, то в последнее слове передаются не значащие биты. Поэтому синдром считается не правильно. Как быть?

вырезать из расчета незначащие биты %)