Доброго времени суток. Разбираюсь с реализацией LDPC(7154, 8176) кодера на ПЛИС. В стандарте GSFC-STD-9100 на 16 страницей приведена схема кодера, для вычисления кодовой последовательности необходимо 511 тактов, что не очень долго. Вычислять все значения одновременно ресурсов не хватит. Кто нибудь разбирался с таким кодированием, что можете посоветовать?

Я бы начинал с мат модель. Матлаб или С/С++ вам в помощь
Попытался найти исходные данные, в идеале и "ответ/результат" на эти входные данные.
Проверил работоспособность.
А уже потом начал описывать для ПЛИС исходя из полученной математики

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

например
Морелос-Сарагоса Р. - Искусство помехоустойчивого кодирования (Мир связи) - 2006
[Robert_H._Morelos-Zaragoza]_The_Art_of_Error_Correction_Coding

книга от создателя LDPC кодов
Галлагер Р. Теория информации и наджная связь (1974)

Мат. модель есть, как и данные, проблема именно в реализации, очень долго в ПЛИС считаю, и по ресурсу ограничен

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

Раз Денис ответил, то кажется, он знает реализацию.

да она тут очевидна. Если очень быстро, то работать с вектором 7154 бита, за 511+n тактов будут рассчитаны все проверочные биты. Но ресурса уйдет вагон и маленькая тележка (2*14*511 регистров + 14 ть 511 входовых XOR деревьев). Если нужно экономить ресурс, то очевиден первый шаг : уменьшать количество FSRL ядер. В итоге схема будет как в приложении, ядро займет 2*511 регистров + одно 511 входовое XOR дерево). Но и расчет будет занимать по времени 14*511 + n тактов. Второй шаг экономии ресурсов, это уменьшение рабочей разрядности 511/73/7, но и времени будет занимать 14*(511/3577/37303)+n такта. Будет долго, но можно вычислять по M проверочных битов за такт, тогда время сократиться в M раз, но ценой наличия дополнительных XOR деревьев.

ЗЫ. При проектировании не рекомендую реализовывать архитектуры с мультиплексорами. Т.к. расход лютов, в этом случае, больше, чем на реализацию более широких XOR деревьев. Лучше проектировать на основе замкнутых сдвиговых регистров (см. реализацию регистра - аккумулятора проверочных бит в приложении). Будет минимальный ресурс

ЗЗЫ. Ну а так, если есть эталонные результаты, работы на день-два где то. Сразу вывалить статически конфигурируемый кодер, потом уже по месту подобрать оптимальные параметры ресурс/тактовая.

ЗЗЗЫ. До кучи, еще можно было бы порыть тему реализации кодера, через проверочную матрицу и ее декомпозицию на 4 ре подматрицы. Количество единиц там намного меньше, может получиться более компактный кодер.

спасибо за советы, попробую различные варианты. После реализации напишу, что получилось.

Если бы можно было совсем без мультиплексоров

Немного времени появилось, скидал идеалку в лоб, работающую словами по 7 бит и кодирующую на лету(т.е. не требуется ждать завершения кодирования). По простоте управления и системной интеграции это самый оптимальный ИМХО вариант. Кодер потребует 2*511 битовых аккумуляторов с 7 ми входовыми XOR деревьями (~2*3*511 4-х входовых лютов) + 511 FSRL регистр. ИМХО в 5К уложится, при тактовой 200-220 на плис класса сыклон 3 семерка. Скорострельность будет порядка 1,2 гигабита в секунду.

PS. Если есть эталонные наборы, можете поделиться для использования в качестве референсного? Давно не опенсорсил.

И логичный шаг замены мультиплексора pmask[j][k][midx*pDAT_W +: pDAT_W] на загружаемый регистр сдвига pmask_b_srl[j][k][0 +: pDAT_W]

Теперь само RTL кодирование, по поведенческой модели, займет часа 3.

ЗЫ. в оценке ресурса, я забыл про 2FSRL регистра, ошибся на 511 триггеров

и чуть позже Вы выложите RTL кодирование

не учел еще AND цепи, но с тактовой не промахнулся Достаточно компактно получилось (см. соседнюю тему)