Перейти к содержанию
    

Anton1990

Участник
  • Постов

    184
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Anton1990

  • Звание
    Частый гость
    Частый гость

Посетители профиля

2 300 просмотров профиля
  1. Всем здрасте. А вообще хоть как то вопрос поставок собирается решаться. Или отрасль на свалку?
  2. А зачем всё это качать? Микросхем всё равно нету.
  3. Клещи тут ни причем. Просто я не знаю какие вопросы и как их правильно задавать. Опвта маловато. Нужно всё переварить. Спасибо.
  4. Матницу я бы привел, да боюсь пАпасть под раздачу. Но она похоже циклическая. По крайней мере входное сообщение из 2016 точек я нарезаю по 84 точки (т.е. получаем 24 строки). Каждую из этих строчек сдвигаю циклически в соответствии с матрицей. Получается удобно обрабатывать по столбцам. Ну как то так. Стандарт неизвестен. Подозреваю что это что то не стандартное.
  5. А что значит какой код? Ldpc? Матрица известна. Каких то особенностей кода нам не известно. Алгоритм декодирования самодельный итеративный (вычисление llr и их суммирование и т.д.). Я так понимаю, что основная проблема у меня из-за самопальности алгоритма декодирования. Отсюда и сложность его реализации. Есть мнение его реализовать на компьютере в реалтайме. На какую скорость выйду пока непонятно.
  6. Спасибо, конечно, но почти ничего не понял. Возможно я в силу своей тупости не корректно задаю вопрос. У меня сообщение 2016 бит при 5 битах softполучаем 10080 битовый регистр, а таких в проекте получается много, да еще умножаем на количество итераций. Всё это програмируется легко, но для плис неподъемно. Попытался сообщение записать в память по 84 бита ( а точнее soft 5 бит) в строке памяти. Ну и мо мере надобности автоматом извлекать нужные данные. Стало чуть легче (теперь ведь работает с 84×5=420 битным регистром), но автомат чтения и записи крайне сложный и непонятный. Интуитивно хочется поставить двухпортовую память и микроблейзер. Демодулятор пишет в память, а проц декодирует. В этом случае программа декодера становится похожа на программу на с#, а значмт более понятна. Ну мне так кажется. Вот у меня и вопрос. А какую архитектуру выбрать? Или вся слодность у меня из за неправильного алгоритма декодирования?
  7. Всем привет. Интересует подход к созданию soft декодера LDPC. Собственно сам алгоритм разработан (проверен на программной реализации), но его реализация на плис какая-то сложная. Если делать на регистрах, то все легко и понятно, но для плис неподъемна. Делать на памяти можно, но крайне геморойно разрабатывать автоматы чтения и записи в память. Есть подозрение что нужно делать на каком либо процессоре (например,микроблайзер), но то же много вопросов. А отсюда вопрос а как кто делает? И как правильно? Если это важно, то длина блока 2016. Заранее спасибо за ответы.
  8. Всем привет. Сделал проект двумерного турбокода на плис. У меня схема примерно такова: Принятый блок записываю по строкам в блочную память. Для исправления по строкам читаю каждую строку, корректирую, записываю в последующую память. Для исправления по строкам считываю каждую строку, формирую первый столбец, корректирую, записываю в память, снова считываю все строки, формирую второй столбец, корректирую, записываю, и так по всем столбцам. Повторяю все по количеству итераций. Схема полностью рабочая и отлаженная. Но возникла потребность в трехмерных кодах. И тут оказалось что весь предыдущий код практически не применим именно из-за необходимости иначе считывать строки, столбцы и глубину. Вопрос: а как собственно правильно (целесообразно, разумно) строить проект турбо декодера, что бы была повторяемость для разных вариантов и размерностей? По ощущениям напрашивается система на Zynq. А вы делаете как? Заранее спасибо за ответы.
  9. Всем добрый день. Вероятно многие меня пошлют изучать документацию и возможно будут правы. Но... Есть проект на плис kintex ultrascale в котором реализованы: контроллер PCIe + демодулятор + декодер. Модули PCIe и демодулятора неизменны, а вот модуль декодера требуется менять. Вопрос можно но ли как-то решить вопрос с частичной перезагрузкой плис. Типа плата определилась в компьютере, демодулятор работает, а требуемый декодер я сам перезагружаю по мере необходимости. Я так понимаю этот вопрос должен решаться частичной реконфигурацией. Но что это такое и как это реализовать использовать не пойму. Если кто решал подобные задачи разъясните пожалуйста. Заранее спасибо за ответы.
  10. Всем добрый день. Есть проект на vhdl по vivado 2016.4 работающий на частоте clk = 150 Мгц. Clk берется с clk-визарда соответственно констрейн прописан.. В проекте генерируется сигнал "ce" на котором работает большая часть проекта. CE "прореживает" частоту в 2000 раз. Вопрос: как грамотно описать для такой схемы констрейн? Насколько я понимаю виваде незачем пыжится развести всю схему на частоту clk=150 МГц. И можно ли такой констрейн прописать прямо в тексте vhdl модуля? Заранее большое спасибо за ответы.
  11. Всем привет. Дошли руки до реализации LDPC в железе, но сразу же возникли трудности. Как хранить матрицу восстановления в ПЛИС при условии, что она довольно большая (7056 х 1008)? В ней около 30000 едениц, остальное нули (разумеется). Если всю хранить, то это 7056 * 1008 = 7112448 регистров. Как то криво, на мой взгляд. Если хранить только адреса едениц, то ресурсов значительно меньше требуется, но много проверок выходит. Кто сталкивался с подобным подскажите каким путем идти. Заранее спасибо за ответы.
  12. Это точно не DVB-S2 Здесь я полностью согласен. Пока есть программная реализация и то не моя. И да есть демодулированный поток. И все. Больше инфы никакой.
  13. А можно тыкнуть носом в стандарты или хотя бы направление где искать? Точных данных о сигнале расказывать не буду (надеюсь причины понятны), но приведу такой пример. Сигнал порезан на слоты каждый из которых обрабатывается отдельно. Длина слота 2000 бит. Формат принятого слота 1500 бит информации и 500 проверочных бит. Но достоверно известно, что на выходе декодера должно быть 1600 бит информации. Путем анализа установлено, что он формируется из 1200 бит принятой информации, потом вставка из 20 бит информации (т.е. эти 20 бит не принимались и они отсутствуют во входном потоке), потом 40 бит принятой информации, потом 80 бит информации, которой нет во входном потоке, и потом оставшиеся биты принятой информации. Соответственно не понятно откуда взялись два блока информации по 20 и 80 бит, которых нет в входном потоке.
  14. При последующей обработке сигнала Сигнал реальный, система не известна, ну по крайней мере не у кого спросить. В сигнале выброшены быты двумя блоками. Первый блок N - выброшены, потом кусочек сигнала, потом снова K-бит выброшены.
  15. При таком объеме неизвестных (ошибочных бит) код как то не очень справляется. Сигнал реальный, модели никакой нет. Тут хотелось бы понять саму идею. Зачем это делается и какой подход к декодированию нужно применять? Здесь Вы, наверное, наиболее близки к истине. Но вопрос в том является ли это типовым случаем? И если "да", то какой подход применяется для декодирования таких сигналов?
×
×
  • Создать...