Zalman_

Сейчас активно изучаю тему декодирования DVB-S2 сигналов и столкнулся с задачей перестановки бит в проверочной части поступаемого фрейма. Известно, что это делается до декодера и известно, что это необходимо из-за особенностей кодера DVB-S2. Информации по этому нашел не много, лишь мнения разных людей, которые с этой темой связаны. Можете ли "тыкнуть" где и что на эту тему можно почитать? Какие варианты реализаций известны или популярны. Интересно как реализуется подобный "перестановщик" + не хочется изобретать велосипед. Заранее спасибо!

Спасибо за ответ! Есть небольшой вопрос по поводу работы Вашего проекта в QuestaSim 10.2c. Установил рекомендованную Вами версию и все работает как часы, спасибо. Есть некоторый нюанс, который я не смог найти в сети. Суть нюанса: 1) В качестве примера возьмем первый модуль (ldpc_dvb_dec_source). 2) После успешной компиляции Questa переходит в этап симуляции, на котором открывается окно sim. В этом окне перечислены инстансы компонентов и если щелкнуть на какой-либо из них, то в другом окне (Objects) появится список всех переменных (reg, wire и т.д.). Подобное я замечал ранее при работе с ModelSim (работал именно с ней). Проще говоря, щелкнув на нужный инстанс я мог посмотреть работу любой объявленной переменной и таким образом отладить работу какого-то внутреннего процесса. 3) У Вас в проекте такая возможность отсутствует. Я вижу только input/output сигналы, но нет ничего, что находится внутри. 4) Заранее скажу, что если в окне Objects кликнуть ПКМ и перейти в пункт Show, то у меня все включено. Соответственно, сам я ничего не ограничивал. Собственно вопрос. Это особенность работы QuestaSim и SystemVerilog или дело в моем малом опыте? UPD: проблема решена. Дело было в функции vopt, которая по дефолту оптимизировала проект, из-за чего отображались лишь входные и выходные порты

Понял, спасибо Есть несколько вопросов по поводу Вашего декодера. Никогда в жизни не писал декодеры и сейчас только вникаю в эту тему, поэтому есть вопрос на основе того, что посмотрел в различных работах (имеющих разную дату опубликования) на эту тему (статьи, диссертации, IP ядра различных компаний). Очень часто вижу параллельную или layered структуру декодеров. Предполагаю, что эти структуры обоснованы "параллелизмом" ПЛИС и поэтому чаще всего применяются. А какую структуру имеет Ваш декодер ? Есть ли его функциональная схема ? Я видел схожие черты Вашего декодера с другими структурами, но не смог установить явного сходства. Также на основе просмотра статей (отчасти беглого) я увидел, что mapping памяти для хранения проверочной матрицы H у всех различных и нет какого-то единого формата. Возможно, я ошибаюсь. Так как Ваш проект можно попробовать в работе в целях изучения, то есть ли какие-то статьи/диссертации/любая другая информация на основе которой Вы писали свой декодер и "размечали" память? Я столкнулся с тем, что есть разные архитектуры и разные методы разметки памяти, поэтому не знаю с чего можно было бы начать (ввиду малого опыта).

Да, проект я взял весь (do/include/rtl/testbench). Ошибочный файл "codec_buffer_nD_alogic" находится по пути rtl/buffer. Заранее скажу, что с QuestaSim я мало работал, поэтому возможно, я делаю что-то не так. Проект пытаюсь запустить таким образом: 1) File -> Change Directory (выбираю FEC-main/do) 2) В консоли ввожу do do_ldpc_dvb.do 3) Получаю следующий лог. Лог QuestaSim выглядит так.

Добрый день! Новичок в LDPC кодах и соответствующих декодерах. Взял Ваш проект (ldpc_dvb) для изучения. Попробовал запустить симуляцию через QuestaSim 10.4c и получил следующую ошибку: # ** Note: (vsim-3812) Design is being optimized... # # ** Error: ../rtl/ldpc_dvb/enc/ldpc_dvb_enc_ibuffer.sv(212): Module 'codec_buffer_nD_alogic' is not defined. # ** Error: ../rtl/buffer/codec_abuffer.sv(192): Module 'codec_buffer_nD_alogic' is not defined. # ** Error: ../rtl/ldpc_dvb/dec/ldpc_dvb_dec_ibuffer.sv(212): Module 'codec_buffer_nD_alogic' is not defined. # ** Error: ../rtl/buffer/codec_abuffer.sv(192): Module 'codec_buffer_nD_alogic' is not defined. # Optimization failed # Error loading design # Error: Error loading design # Pausing macro execution # MACRO ./do_ldpc_dvb.do PAUSED at line 22 Правильно ли я понимаю, что недостающие файлы также нужны для более производительных версий?

Спасибо за помощь!

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

Задача - LDPC декодер внутри FPGA. Первый пришедший в голову вариант - декодер из MATLAB с последующей генерацией HDL. Источник : https://www.mathworks.com/help/wireless-hdl/ref/dvbs2ldpcdecoder.html При попытке сгенерировать код на основе тех параметров, которые они указывают в Algorithms -> Performance, получаю результат по блокам памяти хуже, чем у них (229 у меня, 157,5 у них). Настройка HDL Coder проводилась, однако результат не изменился. Отличия: - в 1 бит в шине входных данных; - семейство, под которое проводится генерация Kintex7 (325). Из того, что нет - Hardware Support Packages. Нет, так как не пускает дальше страницы, где предлагают обновить матлаб (на данный момент версия 2022b). Не уверен, что это сильно влияет, но могу ошибаться. Собственно сам вопрос. В чем на ваш взгляд может быть проблема и что посоветуете в данном случае? Спасибо за помощь!

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

1) От BPSK до QAM-1024, включая APSK 2) Нет, применяются разные синхропоследовательности с разной длиной цикла. Необязательно, может использоваться и другой вариант нумерации. На передающей стороне сигнал формируется так: поступает блок данных пользователя (длина цикла от 1024 до 64000 бит), на него накладывается аддитивный скремблер. Производится помехоустойчивое (ПУ) кодирование (используется Turbo Product Codes (TPC) с разной скоростью кодирования – поэтому и длины циклов разные). К закодированному блоку данных добавляется синхрокомбинация от 8 до 24 бит. Она разная и зависит от ПУ кода. Далее эти данные поступают на модулятор, причем синхрослово может начинаться с любого бита модуляционного слова. И всё это далее подается в канал связи. Ко мне поступает битовый поток от демодулятора. Известно - вид модуляции, длина цикла и вид синхромаркера. Неизвестно – начальная фаза захвата демодулятора. И сигнал не идеальный – с ошибками. В процессе приема могут происходить «повороты» фазы и срывы тактовой от демодулятора. спутниковый канал, ИСЗ 'нителсат'? - Да. На приложенном фото один из вариантов сделайте коррелятор с 'мягким входом' в синхру, т.е. задать допустимое кол-во ошибок в синхрослове и задать кол-во совпадений опоры с принятым - N раз подряд. ТОже самое на выход из синхры. типа гистерезис. работайте по знаку. - Спасибо за совет, обдумаю

1. Планируется система обработки сигналов, структура которых уже давно известна и определена (отмечу, что разрабатываемая система только принимает сигнал и влиять на передающую часть я физически не могу). Данные сигналы входят в список тех сигналов, которые обрабатывает схема AHA 4540. Наиболее неприятный сигнал с точки зрения длительности периода, имеет период 16320. 2. Делаю вручную потому, что система обработки сигналов создается на ПЛИС. 3. Из предыдущих пунктов вытекает то, что необходимо создать либо такую же систему (по качеству работы), либо лучше. По итогу, не хотелось бы создавать велосипед в этой области, поэтому и прошу помощи в этом вопросе от более опытных людей.

AHA 4540 Нужно сделать два выделенных блока

Наверное, меня не так поняли Задача стоит в синхронизации перед декодером Turbo Product Code (TPC). На входе у меня координаты точек после демодулятора.

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

Задача в том, что самому выбрать последовательность для синхронизации я не могу, так как необходимо настроиться на известный сигнал. Со своей стороны я знаю лишь маркер - 11110101000010111000. Синхронизатор построен по такому алгоритму, что в битовом формате среди всего поступающего потока осуществляется поиск этого маркера на протяжении нескольких циклов. Если не нахожу в предполагаемом месте, то сдвигаю на N бит и продолжаю поиск. Если нахожу маркер, то для уверенности в факте синхронизации анализирую еще 3 цикла (в сумме 4) и только после этого данные подаются на турбодекодер. Алгоритм работает медленно, ввиду того, что приходится последовательно анализировать несколько циклов. Можно ли как-то ускорить этот процесс ?