Версия для печати темы

Автор: des00 Jun 19 2011, 09:57

сделал отдельную тему для проекта с http://electronix.ru/forum/index.php?showtopic=75629&view=findpost&p=819949 здесь

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


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

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

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

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

Автор: des00 Jul 15 2011, 06:51

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

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

Автор: des00 Mar 16 2012, 06:34

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

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

Автор: Denisnovel Mar 16 2012, 09:07

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

Автор: des00 Mar 16 2012, 09:24

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

Автор: Denisnovel Mar 16 2012, 09:29

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

Автор: des00 Mar 16 2012, 09:39

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


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



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

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

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

Автор: Gold777 Mar 16 2012, 17:59

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

Автор: des00 Mar 17 2012, 02:30

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

Автор: Gold777 Mar 17 2012, 05:33

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

Автор: des00 Mar 17 2012, 15:10

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

Вот для примера кодер {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 МГц %)


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

Автор: Gold777 Mar 17 2012, 18:07

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

Автор: des00 Mar 18 2012, 14:20

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

Автор: des00 Mar 18 2012, 15:28

без генераторного полинома, 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 %)

Автор: Gold777 Mar 18 2012, 15:59

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

Автор: des00 Mar 19 2012, 03:52

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. Естественно что производительность именно этого блока упадет, но если ее достаточно для выполнения задачи, то.... %)

Автор: des00 Mar 19 2012, 05:30

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

Автор: Gold777 Mar 19 2012, 09:33

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

Автор: des00 Mar 19 2012, 13:27

да. нашел стандарт 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. Но этот в свое время конвейризировался по самое нехочу

Автор: Gold777 Mar 19 2012, 14:30

Для этого кода (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)

Автор: des00 Mar 19 2012, 16:03

спасибо !!!

Автор: SKov Mar 19 2012, 19:26

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

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

Автор: des00 Mar 20 2012, 03:42

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



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

Автор: Denisnovel Mar 20 2012, 04:15

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

Автор: des00 Mar 20 2012, 05:17

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

Автор: SKov Mar 20 2012, 06:20

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

Автор: des00 Mar 20 2012, 06:23

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

Автор: Gold777 Mar 22 2012, 17:01

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

Автор: des00 Mar 23 2012, 05:57

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

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

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

Автор: Denisnovel Mar 25 2012, 13:37

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

Автор: Gold777 Mar 25 2012, 15:13

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

Автор: des00 Mar 25 2012, 16:04

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

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

Автор: Gold777 Mar 25 2012, 16:15

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

Автор: alexPec Mar 25 2012, 19:46

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

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

Автор: des00 Mar 26 2012, 09:54

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

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

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

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


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


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

Автор: des00 Mar 26 2012, 13:29

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

Автор: Denisnovel Mar 26 2012, 15:47

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

Автор: des00 Mar 26 2012, 15:50

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

Автор: lomey Mar 28 2012, 19:50

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

Автор: lomey Mar 29 2012, 16:34

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

Автор: Denisnovel Mar 29 2012, 17:48

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

Автор: Gold777 Mar 29 2012, 20:21

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

Автор: des00 Mar 30 2012, 08:15

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

Автор: Denisnovel Apr 1 2012, 14:26

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

Автор: des00 Apr 1 2012, 15:07

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

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

Автор: des00 Apr 3 2012, 07:57

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

Автор: -Al- Apr 3 2012, 09:11

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

Автор: des00 Apr 4 2012, 15:43

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

Автор: Denisnovel Apr 20 2012, 06:04

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

Автор: des00 Apr 20 2012, 06:55

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

Автор: Denisnovel Apr 20 2012, 07:02

Я сделал так

Где osyndrome_comb[n%dec_width] как раз синдром без учета последних бит.
Но в этом случае критический путь получился очень длинным

Автор: des00 Apr 20 2012, 07:10

ну а как вы хотите по другому? %) за все надо платить. тут либо так, либо искать другие способы задать смещение начала/конца.

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

Автор: Gold777 Apr 23 2012, 16:33

Если нужна производительность 8 бит за такт для кода длиной 2040, получается, что блок синдромов получит результат за 255 тактов. Т.е. за один так для первого синдрома вычисляется (alfa^1,alfa^2,alfa^3,..,alfa^8). Как вы предлагаете поставить 8 декодеров как-то не очень понятно? Если поставить 8 блоков подсчета синдромов параллельно, получается в первый блок идет первый бит, во второй блок 2-й бит и т.д, хотя этот второй бит нужен для подсчета в первом блоке. И еще вопрос как поступать, если нужна производительность 64 бита за такт для этого же кода? Думаю, что за 31-32 такта думаю по частоте не войдет.

Автор: Denisnovel Apr 24 2012, 05:16

Может это поможет на ст 771. Если не секрет, делаете для G.975.1?

Автор: Gold777 Apr 24 2012, 07:44

Получается надо обрабатывать по 8 бит или по 16, тогда возможно по частоте войдет. Да, делаю для G.975.

Автор: des00 Apr 24 2012, 09:43

а если заранее, записать 8 фреймов в память перед декодированием и после декодирования ?

Автор: Denisnovel Apr 24 2012, 10:03

Нужно сохранять синдром и поочереди подавать их в БМ.
Как я понял вы делаетет I.4. Почему выбрали этот алгоритм? Еще более не скромный вопрос: Т8 или Орион?

Автор: Gold777 Apr 24 2012, 13:53

Я делаю I.3. I.4 сделал там вроде все понятно, идет распараллеливание данных на 64 блока т.к каждый бит принадлежит отдельному кодовому слову. Если вы сделали I.3, расскажи как. Еще интересно сколько ваши декодеры заняли ресурсов.
Поймите правильно, но мне бы не хотелось называть организацию в которой работаю.


Собственно так и собрался делать.

Автор: des00 Apr 24 2012, 16:14

оптимальные решения они всегда в одной области находяться.

ЗЫ. Интересно мнение форумчан, как вы смотрите на то, что бы пополнить тему декодерами : витерби, турбо (на основе БЧХ кодов было бы интересно порыть), LDPC (интересно порыть, т.к. в этой теме ничего не понимаю)? И сопутствующий вопрос, как тестировать вероятностные декодеры без матлаба? сгородить в верилоге модулятор/демодулятор + модель awgn ?

Автор: Denisnovel Apr 24 2012, 16:31

I.3 я сделал. Какие есть конкретные вопросы. По ресурсам сложно сказать, так как нужно еще оптимизировать кое-что. Чем не устроил I.4?

Автор: Serg76 Apr 24 2012, 16:35

есть такие практические схемы турбокодов-произведения на основе БЧХ.


я использую собственные программные модели (С++) модулятор/демодулятор + модель awgn.

Автор: des00 Apr 24 2012, 16:44

как раз от вас я о них и слышал %), не поделитесь ссылками?

вы же вроде как делаете как раз все для PC платформы, или вы через DPI портируете это в HDL симуляторы и тестируете HDL корки ?

Автор: Serg76 Apr 24 2012, 16:59

по-моему здесь http://electronix.ru/redirect.php?http://www.google.com.ua/url?sa=t&rct=j&q=aha%20turbo%20bch%20(32%2C21)&source=web&cd=6&sqi=2&ved=0CFAQFjAF&url=http%3A%2F%2Fwirelessman.org%2Ftg1%2Fphy%2Fcontrib%2F802161pc-00_43.pdf&ei=29uWT_DdJ8bwsgbqncz6DQ&usg=AFQjCNEb6Fbv4W1uM5GMThOlKGOri1zc2g&cad=rja


неа, только программное моделирование

Автор: Gold777 Apr 24 2012, 17:02

Интересует реализация внутреннего декодера. Судя по документу, который скинули, у вас следующая схема: 8 блоков вычисления синдромов на входе по 8 бит, один блок решателя ключевого уравнения обрабатывающий данные с 8-ми каналов по очереди, 8 блоков Ченя по 8 бит. Записать 8 блоков данных в память перед декодированием и после декодирования (Вот этот момент особенно интересует). Вы так сделали? И еще по ресурсам было бы интересно хотя бы приблизительные результаты оценить. Можно в личку. I.4 устроил, но надо остальные FEC схемы реализовать.

Автор: des00 Apr 24 2012, 17:03

большое спасибо, начну копать %)

Автор: Denisnovel Jun 25 2012, 11:39

To des00
Хочу сделать, чтобы IBM работал на частоте в два раза меньше. Для этого делаю multicycle как описано у вас в блоге. Причем в проекте несколько разных декодеров. Правильно ли я задал констрейты?

Clock Enable для входа в модуле bch_berlekamp генерится следующем образом.

Автор: des00 Jun 25 2012, 16:00

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

Если по мультициклам, то их накладывают на цепи между регистрами источниками сигнала и приемниками. Где в вашей команде указано что это относиться к регистрами ? )

Автор: Denisnovel Jun 26 2012, 04:25

В моём кнстрейте описывается, что все регистры в модуле bch_berlekamp:berlekamp работают на частоте в два раза меньше. Т.е. источником и приемником является эти регистры. Или я не прав?
Если я захочу сделать частоту в 2 раза меньше, то в PLL я должен выдать синхроную частоту. Как это описать?

Автор: des00 Jun 26 2012, 04:50

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


хммм, сгененрировать PLL и посмотреть на вейвформы ее работы?

Автор: Denisnovel Jun 26 2012, 09:15

А если написать так, то между регистрами модуля БМ будет увеличенный период?

С PLL не поял? Допустим, я сделал синхронную частоту в два раза меньше, подал её на модуль БМ, как синхронизировать данные между этими clock domain?

Автор: des00 Jun 26 2012, 14:40

смотрите что говорит TQ, если он скажет что будет, значит будет. %)

а если сделаете пусть и на одной частоте но с clkena синхронизировать не потребуется ? Повторю еще раз, прочитайте что такое PLL и ее свойства. Сгенерируйте в мегавизарде PLL и посмотрите на вейвформы выходных сигналов. Тогда сразу все поймете %)

Автор: Denisnovel Jun 28 2012, 19:36

По PLL я имею ввиду, что одна ПЛЛ генерирует быстрый и медленный клок, то есть они синхронные, как на картинке выше . Ну да оставим PLL.
У меня работает первый вариант задания контстрейтов , TQ распознает их как мультисайкл. Самый критичный путь в этом случае от clken до регистров модуля БМ.
Еще вопрос. Правильно ли я понимаю, что БЧХ может детектировать ошибки больше t, но меньше 2t, и определять их количество?

Автор: Gold777 Jun 29 2012, 13:23

БЧХ может детектировать 2t ошибок

Автор: SKov Jun 29 2012, 13:35

Количество не может. Только сам факт наличия где-то ошибок кратности от 1 до d-1.

Автор: des00 Jun 29 2012, 13:55

значит TQ вас понял %)


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

Автор: SKov Jun 29 2012, 14:34

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

Автор: Gold777 Jun 29 2012, 17:51

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

Автор: SKov Jun 29 2012, 18:35

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

Автор: des00 Jun 30 2012, 05:43

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

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

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

Автор: SKov Jun 30 2012, 06:07

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

Автор: des00 Jun 30 2012, 06:46

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

Автор: Koluchiy Jul 2 2012, 09:32

To des00

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

Автор: des00 Jul 2 2012, 19:19

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

Автор: Denisnovel Jul 4 2012, 13:04

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

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

Автор: des00 Jul 4 2012, 17:13

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

Автор: nkie Oct 3 2012, 09:54

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

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

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


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

Автор: Костян Oct 19 2012, 08:18

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

Автор: Костян Oct 19 2012, 10:30

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

Автор: des00 Oct 19 2012, 11:09

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

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

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

Автор: Костян Oct 19 2012, 11:55

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

Причем 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

Автор: des00 Oct 19 2012, 15:26

там непосредственное перемножение полиномов.

Шаг 1. берем x+a
Шаг 2. умножаем на (x+a^2). получаем x^2 + x(a + a^2) + (a*a^2).
Шаг 3. умножаем на (x+a^3). получаем x^3 + x^2(a + a^2 + a^3) + x(a*a^2 + a^3*(a+a^2)) + (a*a^2*a^3).
и т.д.

Т.е. gf_mul в этой функции это учет раскрытия скобок с умножением на следующий корень, а gf_add это накопление значения при коэффициенте.


можно переделать идеальный gf_mul на синтезируемый gf_mult_a_by_b, может тогда ему станет лучше. но мне было лень это делать %)

Автор: des00 Oct 30 2012, 06:21

1. Реализована функция расчета генераторного полинома БЧХ. В качестве прототипа использовалась функция из матлаба.

Сравнил с полиномами из таблицы один в один. В симуляторе все прекрасно работает. Но при синтезе ква 9.1 долго думает когда ищет циклотомические классы. Но тем не менее полином в ква 9.1 считается и ресурс энкодера после синтеза такой же что и при использовании таблиц. Из особенностей : т.к. кол-во классов и членов классов априори не известно, а ква не может использовать массивы больше чем 2^28 бит, настройка размерностей массивов в функции генерации полиномов задается в ручную через макросы (файл bch_define.v).


2. Заменил функции gf_add/gf_mul в генерации полинома РС на синтезируемые xor/gf_mult_a_by_b. Тест показал что все работает, ква тоже съел и не подавился. Сделал для проверки синтезируемости на сторонних синтезаторах (в частности Symplify)

Автор: Костян Oct 30 2012, 09:35

стесняюсь спросить, а какая разрядность Вашего Symplify ? 32 или 64 ? У меня лицензия только под 32 позволяет работать. Менял я уже gf_mult на gf_mult_a_by_b. Это для 32 бит ничего не давало. Видимо в разрядности синтезатора собака зарыта.

Автор: des00 Oct 30 2012, 09:40

да у меня пока никакого нету, ставить надо %)

Автор: Gold777 Oct 30 2012, 16:59

При декодировании кода Рида-Соломона (к примеру RS(255,239)) заметил такую особенность: когда ошибок в сигнале нет первый синдром практически всегда получается ненулевым, остальные S2..S16 равны нулю. Решатель ключевого уравнения показывает что кол-во ошибок равно нулю и собственно ничего не исправляется. Все таки непонятно почему первый синдром ненулевой?Ведь по теории такого быть не должно (если ошибок нет значит все синдромы должны быть равны нулю!!!). Интересно, что при внесении ошибок неправильного исправления не наблюдал. У БЧХ такой закономерности не встречал.

Автор: des00 Oct 30 2012, 17:39

ищите ошибку, вот результат прогона 10 блоков такого кода без ошибок

Автор: Gold777 Oct 30 2012, 18:58

Спасибо, буду искать ошибку. Странно, что у БЧХ такого не наблюдалось.

Автор: Gold777 Nov 1 2012, 18:12

Более подробно опишу ранее описанную проблему. При расчете синдромов первый синдром вычисляю подставляя alfa^1 т.е. S1(alfa^1 ), S2(alfa^2), S16(alfa^16) или надо первый синдром считать подставляя alfa^0 т.е. S1(alfa^0)...S16(alfa^15)? Если расчет по второму варианту делать, то если нет ошибок все синдромы равны нулю (Позиции ошибок считаются правильно, а величины). По первому варианту S16(alfa^16) получается ненулевым (при этом позиции ошибок и величины считаются верно). Вот не могу понять, где у меня ошибка и какой вариант при расчете правильный? И еще вопрос все ли 16 синдромов всегда используются при декодировании или можно не все их вычислять(по идее существует 2^128 различных вариантов комбинаций синдромов, а возможных комбинаций ошибок и величин будет меньше)?

Автор: des00 Nov 2 2012, 08:43

Все зависит от того, как именно у вас рассчитан генераторный полином. Если вы брали корни полинома как a^[0:check] то и синдромы нужно считать для корней со степенями [0:check], если a^[1:check+1] то соответственно будет сдвиг.


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

Автор: SKov Nov 2 2012, 09:31

Если у вас 2^128 разных синдромов, то ровно столько различных
ошибок может исправлять код. Там могут быть и ошибки веса много больше Dмин/2.
Исправить все можно, например, полным перебором кодовых слов (если много свободного времени )
Чем больше Dмин, тем дальше код от плотной упаковки и тем больше тяжелых ошибок (больше Dмин/2)
он в принципе может исправлять.
Вообще, не обязательно исправлять совсем все ошибки для хорошего декодера.
Есть , например, такой результат: достаточно исправлять все ошибки,
которые может исправить код, до веса Dвг,тогда вероятность ошибки декодирования не более чем вдвое
превосходит вероятность ошибки при декодировании полным перебором.
Здесь Dвг означает мин. расст. для данного кода, которое получается
из границы Варшамова-Гильберта для данных кодовых параметров.
Другое дело, что ваш конкретный алгоритм исправляет только часть этих ошибок.
Наример, он не исправляет ошибки веса больще Dмин/2.
Но если вы не будете в алгоритме испрользовать часть синдрома,
то часть исправимых алгоритмом ошибок еще больше уменьшится,
т.е. вы не сможете исправлять даже некоторые ошибки веса меньше Dмин/2.

Автор: Gold777 Nov 2 2012, 13:52

Если в рекомендации указан следующий порождающий полином
Правильно ли я понимаю что надо считать с alfa^0?


Можете объяснить, что значит плотная упаковка кода и почему чем больше Dmin, тем больше ошибок можно исправить за пределами исправляющей способности кода?

Автор: SKov Nov 2 2012, 14:41

Любой код можно представить в виде точек в n - мерном пространстве Хемминга.
У каждого кода есть минимальное расстояние. Это значит, что если провести в пространстве Х.
сферу радиуса Dmin/2 вокруг каждого кодового слова, то получившиеся сферы не будут пересекаться.
И наоборот, если провести сферы радиуса хоть на одну единицу больше - то сферы начнут пересекаться.
Рассмотри шары радиуса Dmin/2, т.е. пересечений еще нет.
Вопрос: какая доля всего пространства Хемминга векторов длины n "вычерпана" этими шарами?
Ответ зависит от кода. Для кодов Хэмминга (это те, которые исправляют одну ошибку),
эти шары вычерпывают ровно ВСЕ пространство. Известно, что "почти все" пространство
вычерпывают примитивные коды БЧХ, исправляющие две ошибки. Эти коды относят к классу плотно упакованных.
Чем больше радиус шаров, тем больше пространства остается "в промежутках" между шарами.
Конечно, это не абсолютное правило (вспомним код Голея), но общая тенденция именно такая.
Чем дальше кодовые параметры от границы Хемминга, тем хуже упакован код.
Удобнее рассматривать смежные классы кода, чтобы понять упакованность кода.
В лидерах смежных классов, как известно, находятся те вектора ошибок, которые может
исправить код (при оптимальном декодировании, например полным перебором).
Так вот, у совершенных кодов (например, код Хемминга), все лидеры имеет вес 1, причем это все вектора веса 1.
Для квазисовершеннх кодов в лидерах есть все вектора веса до Dmin/2, и некоторые вектора веса Dmin/2 +1.
Это, например, упомянутые выше квазисовершенные БЧХ коды с Dmin =5.
Чем хуже упаковано шарами Хеммингово пространство, тем больше тяжелых лидеров существует в стандартной
расстановке для данного кода.
Я когда-то делал моделирование для длинных БЧХ кодов (16тыс бит.)
Для кодов с Dmin = 7..13 довольно часто встречались случайные вектора ошибок веса n/2,
которые переводили слово в другую сферу. Т.е. происходила неисправимая ошибка, которая приводила к неправильному декодированию в другое кодовое слово.
Это значит, что шары для этих кодов более-менее плотно заполняли пространство.
А вот для кодов с Dmin >30 даже на сотнях тысяч опытов не удавалось попасть в кодовую сферу.
Т.е. в качестве вектора ошибки генерировался случайный вектор веса n/2, далее выполнялось
декодирование по БМ, но в результате получался отказ от декодирования,
т.е. от полученного вектора на расстоянии Dmin/2 не находилось ни одного кодового слова.
Это означает, что доля пространства, высекаемая кодовыми шарами радиуса Dmin/2 была почти нулевой для больших Dmin.
Так что даже случайно тыкая пальцем в произвольный вектор в пространстве Хемминга,
мы почти с нулевой вероятностью попадали в окрестность хоть какого-нибудь кодового слова.
Это и означает, что данные коды были весьма далеки от плотной упаковки.
А вообще задачи максимально плотно упаковки разных пространств
шарами или другими объектами - это отдельная наука (и не только кодировочная), на эту тему написана куча книжек.
Поищите в и-нете.

Автор: des00 Nov 2 2012, 15:37

Да именно так, при этом нужно модифицировать еще и процедуру Ченя (ввести там корректирующий коэффициент)

2 SKov
Спасибо за разъяснение. Вам бы лекции или блог по кодированию вести, очень интересно.

Автор: SKov Nov 2 2012, 18:14

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

Автор: Serg76 Nov 2 2012, 18:49

Да уж, горькая правда жизни. Но, к сожалению, это касается не только кодирования, но и всей области телекоммуникаций. У нас в свое время курс по кодированию ограничился рассмотрением только кодов Хемминга и БЧХ. Даже сверточное не рассматривали, какие там Turbo и LDPC

Автор: SKov Nov 2 2012, 20:00

К сожалению, катастрофическое состояние в высш. образовании непонятно как лечить.
Ну, поднять зарплаты преподам, чтобы они не разрабатывали ИБП, а занимались наукой.
Предположим, это сделали. А дальше что?
Все мои толковые студенты сейчас быстро попадают на хлебные места в совместные предприятия.
А совместные предприятия - это пылесосы, которые вытягивают через несколько лет
наши лучшие молодые мозги за бугор.
Вот и получается, что нет смысла поднимать вузы, т.к. это в основном пойдет на пользу только
зарубежному производству. Нашей стране нужны дворники , мелкие менеджеры и обслуга для топливного комплекса.
А то, что молодой специалист, разбогатев, потянется обратно на родину -
так могут думать только очень большие политики. Я таких примеров в своем окружении не знаю.
Точнее, знаю пару бывших студентов, которые вернулись, но как раз не разбогатев и не самые креативные.
В общем, все совсем грустно.
Но, мы, кажется, свернули в злостный нетопик.
Предлагаю на этом закончить или в личку.

Автор: Gold777 Nov 3 2012, 11:08

Не очень понятно какой корректирующий коэффициент т.е. наподобие корректирующего коэффициента для укороченного кода при инициализации, только alfa^0 ?

SKov
Спасибо большое спасибо за подробное объяснение.

Автор: des00 Nov 3 2012, 12:32

алгоритм форни считает Yi = -z^m0 *omega(z)/z*lambda'(z), где m0 - степень первого корня. Но для m = 0, там будет 1 и коррекция не нужны. Ошибся немного %)

Автор: Gold777 Nov 6 2012, 09:46

У меня получается правильные величины ошибки (если синдромы считать с alfa^0 как в моем случае) только если omega(x)=alfa0*S2 + (alfa1*S3 +alfa2*S2)x + (alfa0*S4+alfa1*S3+alfa2*S2)x^2+ ....-хотя по теории надо считать
omega(x)=alfa0*S1 + (alfa1*S2 +alfa2*S1)x + (alfa0*S3+alfa1*S2+alfa2*S1)x^2+ ... В чем может быть ошибка или я теорию неправильно понял?

Автор: des00 Nov 8 2012, 16:26

для выяснения проблемы вышлите мне параметры используемого вами кода : {m, n,k, m0, rootspace} и пару закодированных блоков. посмотрю что к чему. Лучше на почту.

Автор: Gold777 Nov 20 2012, 15:06

Деление a/b в алгоритме Форни для декодера Рида-Соломона (255,239) реализовал через умножение используя таблицу инверсных элементов 1/b на блочной памяти (в таблицы номер ячейки значение b, значение ячейки соответственно результат 1\b). Подскажите правильная ли у меня таблица и если нет то где ошибка? Если кто-то реализовал алгоритм Форни для декодера на ПЛИС без использования таблицы инверсий, сколько места занял делитель в поле Галуа?

Автор: des00 Feb 6 2015, 11:33

Продолжаю пиарить красоту SV.

На сей раз использование возможностей SV для простого моделирования алгоритмов на примере сверточного дуобинарного турбокода. Поддерживаются стандарты DVB и Wimax + сделано расширение скоростей кодирования. Кодер синтезируемый, декодер пока только идеалка близкая к железу по организации вычислений и интерфейсам. Тестбенч - так называемый bertest. Поддерживается пока только QPSK. В идеалке можно покрутить разрядности, алгоритмы (семейство MAX Log MAP) посмотреть что и куда идет и как считается.

Автор: des00 Feb 10 2015, 07:28

Запилил идеалку для прямого портирования на RTL уровень. Отличие от идеалки общего вида :
1. Одновременный проход прямой и обратной рекурсии
2. collision-free интерливер для одновременного доступа для метрик прямой и обратной ветви.
3. Компрессия метрик состояний ветвей для уменьшения расхода памяти метрик (прекрасно ложится на плис).
4. Изменена концепция работы с буферами данных для оптимизации ресурса памяти плиса.
5. Код почищен от мусора.

До синтезируемого RTL кода 1,5 шага
ЗЫ. Пока все проверяется на QPSK скорости 1/3 и 1/2. Другие скорости и модуляции пока не проверял.

Автор: des00 Feb 24 2015, 09:02

Синтезируемый, статически конфигурируемый, однопроходный (один проход на полуитерацию) декодер DVB-RSC кода и бертест для него. Синтез в ква 9.1 для сыклона и7 для блока 128 бит : ~6000LE, 15M9K, 106МГц настройки по умолчанию. Тактовая упирается в расчет рекурсии. Нормализация вынесена из нее, все уперлось в ограничения алгоритма.

Автор: des00 Mar 4 2015, 16:27

Последняя версия кодека:
1. Добавлена таблица перемежений Wimax-OFDM, Wimax-OFDMA
2. Переписана работа кодера (таблицы, генератор адресов), архитектура оптимизирована под ПЛИС
3. Сделан рекурсивный процессор с комбинированной модульно-классической арифметикой, ресурс тот же, но тактовая поднялась за счет уменьшения длинны трасс.
4. Убран атрибут синтеза в памяти метрик, приводил к некорректной работе в ПЛИС. Кое где вбиты атрибуты, во избежание имплементации сдвиговых регистров на памяти.
5. Кодек проверен в железе на разных пакетах и разных скоростях кодирования на последовательностях до 1е9 бит.

На этом опенсорсная часть, этого кодека окончена

Автор: x736C Mar 4 2015, 16:57

des00, спасибо большое за труды.

Что планируете реализовать в закрытой части, если не секрет?
Чтобы знать, к чему стремиться

Автор: des00 Mar 5 2015, 05:56

Именно по этому кодеку планов громадье :
1. Динамически конфигурируемый кодек, в том числе с переключением на лету.
2. Эконом версию декодера с меньшим ресурсом.
3. Добавить модуляции до КАМ64.
4. Текущий декодер, на частоте 100 МГц и 8 итерациях дает где-то 12 Мб/с скорость декодирования, есть задумки сделать декодер на ~100 мегабит

Ну и затем BTC, LDPC

Автор: des00 Apr 10 2015, 07:05

Wimax LDPC encoder со статической конфигурацией. Поддерживаемые скорости 1/2, 2/3B, 3/4A, 5/6.
Параметры кодера для сыклона 3 и7:
Кодирование по 4 бита, скорость 5/6, длина 576 : 456 плиток хлопающих на частоте 250МГц (~1 Гбит/с)
Кодирование по 4 бита, скорость 5/6, длина 2304 : 1342 плитки хлопающих на частоте 200МГц (~800Мб/с)
Кодирование по 8 бит, скорость 5/6, длина 2304 : 1145 плитки хлопающих на частоте 210МГц (~1.68Гбит/с)

UPD. Метод проверки - по эталонной модели и матлабу. Код для матлаба в теме про кодирование в Алгоритмах
UPD2. Возможность работать по 4/8 бит определяется целочисленной кратностью expansion factor (zf) 4/8 битам.

Автор: johan Apr 10 2015, 19:39

Спасибо за еще один пример пользы SystemVerilog'a!
Вы намеренно по асинхронному сбросу сбрасываете только val и state? Исходите из каких-то соображений по разводке или из философии, что сбрасывать надо только управляющие сигналы?

Автор: des00 Apr 11 2015, 06:20

Все по заветам http://electronix.ru/redirect.php?http://forums.xilinx.com/xlnx/attachments/xlnx/TIMEANBD/4280/1/wp272%28v101%29%20Get%20smart%20about%20reset-%20Think%20local,%20not%20global%20%28by%20Ken%20Chapman%29.pdf(автора пикоблейза и Xilinx гуру): When creating each section of a design, simply ask, “Does this bit need to be reset”?
Все в системе определяется по сигналу валидности и состоянием конечного автомата, смысла сбрасывать другие сигналы нет. Помимо этого, на некоторых платформах (где триггер может быть только с одним типом сброса), можно потерять в ресурсе или производительности.

Автор: johan Apr 11 2015, 08:53

Благодарю за ответ.
Со временем тоже пришел к аналогичной философии: сбрасывать только то, что надо сбрасывать. Но иногда лень берет своё, и сбрасываю всё.
Недавно копался в интерконнекте Альтеры, и заметил, что они тоже "ленятся", и как-то общих рекомендаций и философии не прослеживается.
Видимо от самих разработчиков этих модулей зависит.

То сбрасывают всё:


А вот тут наоборот, сбрасывают только то, что надо

Автор: des00 Apr 11 2015, 13:21

Скорее от лени и прилежания Обычно после получения необходимой функциональности и закрепления результатов, я провожу ручной рефакторинг кода (удаляю все ненужное, делаю расширенные комментарии, правлю описания сбросов, убираю большинство варнингов синтеза и т.д.). Т.е. рассматриваю код как товарный продукт. Да это "шашечки", но зато всегда могу вернуться к коду и понять как он работает. Ну а кому то нужно "ехать" и они забывают заветы Ф. Брукса о том что написание кода это 15% от всего проекта

Автор: des00 Apr 21 2015, 08:05

1. BERtest + идеальный matlab style декодер.
2. идеальный RTL like декодер (один шаг до RTL реализации для любого разработчика). Содержит параметр pLLR_BY_CYCLE - количество метрик обрабатываемых за 1 такт. Должно быть меньше чем expansion factor.

Автор: des00 May 13 2015, 16:16

Wimax LDPC кодек со статической конфигурацией. Поддерживаемые скорости 1/2, 2/3B, 3/4A, 5/6.

Метод декодирования 2D normalized Min-Sum. Декодер работает с прямыми метриками, ширина интерфейса определяется количеством метрик обрабатываемых за 1 такт. Количество метрик за такт должно быть кратно размеру T матрицы H (24). expansion factor (Zf)

Результаты декодера на плис средние. Сыклон 4, спидгрейт с7, длина 2304, скорость кодирования 5/6, 8 метрик за 1 такт, разрядность метрики 5 бит: 11872LC, 6624Reg, 37 M9K, тактовая 210 МГц. Тормозит генерация адресов памяти, т.к. в ваймаксе есть нечетные сдвиги, что делает невозможным работу с блочком памяти в режиме больше 1 метрики.

Тестбенч бертест, кпск, 2/4/6/8/16 метрик за такт. Время декодирования = 2*((Niter + 0.5)*length/кол-во метрик за такт) + латентность порядка 30 тактов).

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

Автор: des00 May 27 2015, 14:53

1. Отучил кодер от ограничений на размер интерфейса 2^N кратный pT pZF, теперь любое числое кратное pТ pZF.
2. Оптимизировал управление конвейером в декодере, выиграл немного тактов.
3. Сделал декодер с разделенным входным буфером и более сложным управлением. В зависимости от размера блока памяти потребуется больше, но зато можно совместить последнюю полуитерацию декодирования с загрузкой рабочей памяти новыми данными.

Этот релиз последний.

Автор: des00 Aug 31 2015, 11:34

маппер и мягкий демапер для модуляций BPSK, QPSK, 8PSK, QAM16, QAM32, QAM64, QAM128, QAM256, QAM1024.

Созвездия:
BPSK - повернуто на 45 грудусов
QPSK, QAM16-QAM256 - из доки от AHA.
8PSK - повернуто на 22.5 градуса.

Метрики квадратных КАМов, BPSK, 8PSK - конфигурируемой разрядности, остальные нечетные КАМы - фиксированные 4 бита. Метрики = логарифм отношения надежностей битов символа, при условии sigma^2 = 0.5

Результаты на арию 5 С5: демапер 623/791 ALM/Reg, частота за 300 МГц

Тестбенч простой, просто проверяет только жесткое решение.

ЗЫ. Разыскивается созвездие КАМ512. Можно свое нарисовать, но несколько часов терять не охота

Автор: des00 Sep 1 2015, 14:40

Как то совсем забыл про матлаб. В итоге весь ряд модуляций (правда матлабовские 32 и 128 отличаются от ахашных).
Немного поэкспериментировал с ква, странно но generate for дал более хороший результат, чем процедурный for + перевел таблицы кам128 и 512 на использование разбиения таблиц блоками 8х8, вместо 16х16. Это дало суммарную экономию ~250 плиток. Итоговый результат на полный демаппер 852 ALM, 1076 регистров, частота упала до 280МГц (еще один слой регистров добавлять лень, да и целевая у меня 250).

Автор: des00 Apr 4 2016, 13:44

LDPC Кодер (7154, 8176) для стандарта GSFC-STD-9100. При работе с 7ми битными словами параметры кодера для Aria V : 3610ALM/~275МГц, производительность > 1,5Гигабит в сек.

Автор: des00 Jun 14 2016, 10:05

Кодер работал неправильно, вот что значит читать стандарты по диагонали Архив прибил.

NASA GSFC LDPC codec 7154/8176 (GSFC-STD-9100).

В аттаче : RTL кодер, декодер идеалка и самая медленная версия RTL декодера, работающая по 4 нода за такт и с не буферизированным выходом. Ресурсы для Арии 5 : ALM/REG/M10K 565/1218/24. Оцененная частота для С5 261.44 MHz. Более быстрые декодеры уже сами

Автор: des00 Jun 22 2016, 09:57

Немного почистил код, оптимизировал сигналы готовности vnode/cnode движков, проверил режим работы с большим количеством метрик за такт.

Набираю информацию по F-LDPC кодам(GRA коды). Может у кого есть хорошая подборка?

Автор: des00 Jun 29 2016, 07:19

Делаю подходы к TPC : кодер Хэмминга. Совершенный, расширенный, в систематической форме.

Автор: des00 Jun 4 2018, 10:47

Появилось окно. Стало скучно. Таки добил старый TODO. БЧХ со стираниями, работает на лету, 250 мегабит на ария 5.

Автор: Denisnovel Jun 4 2018, 19:53

Где можно почитать про декодер со стираниями? Можно ли их использовать для итеративного декодирования?

Автор: dvladim Jun 4 2018, 20:14

Offtop.
Послушайте Денис, Вы не думали завести репозитарий на github например для всяких таких поделок?
Мне кажется это было бы удобнее, если Вашим работам разрешено находиться в открытом доступе.

Автор: x736C Jun 4 2018, 22:57

Р. Морелос-Сарагоса «Искусство помехоустойчивого кодирования. Методы, алгоритмы, применение».
стр.103-105.

В случае с БЧХ-кодами получаются две итерации декодирования.

dvladim, присоединяюсь.

Автор: blackfin Jun 4 2018, 23:24

Автор: andrew_b Jun 5 2018, 04:49

ГитХаб превращается в тыкву. Все оттуда бегут.

Автор: Poluektovich Jun 5 2018, 07:38

Тогда GitLab.

Автор: des00 Jun 9 2018, 05:37

Еще в помощь вот это http://electronix.ru/redirect.php?http://the-art-of-ecc.com/3_Cyclic_BCH/index.html и пример от x736C, который он сделал по моей просьбе, за что отдельное спасибо). Про итеративное декодирование, будет время, сделаю турбокодер на основе приложенной статьи.


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

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

Автор: dxp Jun 12 2018, 07:31

Куда бегут? Какие есть достойные ресурсы?

Автор: andrew_b Jun 12 2018, 11:06

В течение первых суток после новости о покупке ГитХаба Некрософтом на ГитЛаб смигрировало около 100 000 проектов.
Все они разной степени тормознутости и глючности.

Автор: x736C Jun 12 2018, 14:44

А какие есть объективные и обоснованные опасения?
У меня просто там платный аккаунт. А я не в зуб ногой.

Автор: AVR Jun 22 2018, 11:46

Извините за оффтоп (тема то про FEC), но для миграции с github куда-либо еще в настоящий момент нет ни малейших оснований. Миграция тысяч проектов лично мне не понятна, никаких негативных последствий от покупки компании так и не наступило, и вряд ли наступит вообще.

Автор: Denisnovel Aug 2 2018, 10:45

Какой порядок следования бит? Если у нас синдром задается следующей формулой, то в декодер сначала поступают r[n-1],r[n-2]... или наоборот?
http://electronix.ru/redirect.php?https://postimages.org/

Автор: DuHast Aug 11 2018, 06:24

в декодер сначала поступают r[n-1],r[n-2]...
И если преобразовать приведённую Вами формулу к виду, пригодному для реализации в железе, то будет понятно почему.

Автор: des00 Sep 5 2018, 06:32

Появилось немного времени.

Статически конфигурируемый кодек турбокода, описанного в документе ETSI EN 301 545-2 V1.2.1 (DVB-RCS2). От DVB-RCS отличается решеткой на 16 состояний.
Поддерживаются все описанные в документе 34 размера блока(от 14 до 599 байт) и скорости кодирования(1/3....7/8). Тестбенч - бертест.

Результаты на 5 ой арии для блока на 14байт: кодер/декодер 107/5382ALM, частота 125МГц.

Автор: des00 Sep 10 2018, 05:11

Всем доброго дня, нужна теоретическая помощь. Суть вот в чем.

Снял характеристики всех возможных режимов работы кодека и .... не вижу ощутимой разницы между DVB-RCS2 и DVB-RCS. Хотя она должна быть, т.к. кодовое расстояние решетки на 16 и 8 различно. Да и сами авторы, утверждают

а кое где встречается и

Код проштудировал, явной ошибки в алгоритме Max Log MAP не вижу, разрядности на переполнение проверил. Начал рыть в сети и получил результаты, которые еще больше поставили в тупик. Например, в приложенной статье приводятся коды на решетке 8(рисунок 5) и 16(рисунок 6). Видно что, для одной и тойже модуляции и скорости, код с решеткой 16 проигрывает коду с решеткой 8.

Других явных сравнений не нагуглилось, пошел с другой стороны. Вот народ продает корку www.sworld.com.au/pub/pcd04d4.pdf, смотрю ее характеристики и они в пределах +-0.1дб совпадают со снятыми мной (смотреть графики для MAX Log MAP, К - длина в битах(!!!)).

http://electronix.ru/redirect.php?https://postimages.org/

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

Автор: Fat Robot Sep 10 2018, 08:32

Matlab?
При реализации tc я обнаружил довольно неприятный эффект: можно сделать незначительные ошибки (перемежитель, выкалывание, хвост) , которые приводят к незначительному ухудшению корректирующей способности. Т.е. кодер и декодер tc до определенной степени устойчивы к ошибкам реализации: катастрофы не происходит, все продолжает работать, но хуже, чем заявлено.
Искать и отлаживать такие ошибки очень тяжело.

Автор: des00 Sep 10 2018, 12:05

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

Автор: Fat Robot Sep 10 2018, 13:21

В матлабе есть реализация турбо кодера и декодера. С них можно начать.

Успехов

Автор: des00 Sep 10 2018, 13:35

Хмм, а в каком именно не подскажите? посмотрел 2012 и 2015а, не нашел.

Автор: Fat Robot Sep 10 2018, 16:08

http://electronix.ru/redirect.php?https://www.mathworks.com/help/comm/ref/comm.turbodecoder-system-object.html

Introduced in R2012a

Мне пока не понятно, как задать начальное состояние (circulation state), но я уверен, что вы справитесь.

Кстати, по поводу circulation state: он позволяет сделать многопроходный декодер для constituent conv. code, используя 'закольцованную' решетку. Вы рассматривали такую возможность при реализации?

Автор: des00 Sep 11 2018, 01:57

понял, вы про системный обьект в общем виде, я искал сразу DVB декодер, который дубинарный систематический с закольцеванной решеткой. В стандарте он называется duo-binary circular recursive systematic convolution code, одному символу сооотвествует 4 метрики. Закольцовывание решетки там прописано в стандарте, поэтому кодер там многопроходный. В декодере если убрать закольцовывание состояний между итерациями(стартуя каждый раз с нуля) качество декодера падает, ЕМНИП порядка 0.8дб.

Посмотрю подойдет ли этот объект для реализации такого декодера.

Автор: Fat Robot Sep 11 2018, 07:26

Я говорил про несколько проходов app декодера в одной итерации турбо-декодера.

Автор: des00 Sep 13 2018, 11:26

хммм, не встречал в литературе, проведу экспиремент

Автор: des00 Sep 19 2018, 11:14

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

Вот для DVB-RSC2 блок 188 байт, скорости кодирования 1/3, 1/2, 2/3, 4/5 PSK
http://electronix.ru/redirect.php?http://aff3ct.github.io/comparator.html?left=TURBO_DB%2FAWGN%2FBPSK%2FRSC_DB_RSC_DB%2FBCJR%2FTurbo_DB_N1880_K1504_BCJR_i8_fnc_DVB-RCS2.txt&right=TURBO_DB%2FAWGN%2FBPSK%2FRSC_DB_RSC_DB%2FBCJR%2FTurbo_DB_N3008_K1504_BCJR_i8_fnc_DVB-RCS1.txt

В приложении то что намерил я для блока 188 байт. QPSK

http://electronix.ru/redirect.php?https://postimg.cc/dZtmCySb

расхождение в 0.1дБ. Что-то тут не так.

UPD. У кого виснет скрпит, просто выбрать BER Comparator, там TURBO_DB это будет оно. Есть результаты только для 188 байтового кода

Автор: Grizzzly Sep 28 2018, 07:54

А у кого результаты лучше? Их или ваши? Я кое-какие схемы погонял, сравнил со своими матлабовскими. В aff3ct чуток лучше результат. Но это другая схема, не ваш случай.