Anton1990

Всем здрасте. А вообще хоть как то вопрос поставок собирается решаться. Или отрасль на свалку?

А зачем всё это качать? Микросхем всё равно нету.

Клещи тут ни причем. Просто я не знаю какие вопросы и как их правильно задавать. Опвта маловато. Нужно всё переварить. Спасибо.

Матницу я бы привел, да боюсь пАпасть под раздачу. Но она похоже циклическая. По крайней мере входное сообщение из 2016 точек я нарезаю по 84 точки (т.е. получаем 24 строки). Каждую из этих строчек сдвигаю циклически в соответствии с матрицей. Получается удобно обрабатывать по столбцам. Ну как то так. Стандарт неизвестен. Подозреваю что это что то не стандартное.

А что значит какой код? Ldpc? Матрица известна. Каких то особенностей кода нам не известно. Алгоритм декодирования самодельный итеративный (вычисление llr и их суммирование и т.д.). Я так понимаю, что основная проблема у меня из-за самопальности алгоритма декодирования. Отсюда и сложность его реализации. Есть мнение его реализовать на компьютере в реалтайме. На какую скорость выйду пока непонятно.

Спасибо, конечно, но почти ничего не понял. Возможно я в силу своей тупости не корректно задаю вопрос. У меня сообщение 2016 бит при 5 битах softполучаем 10080 битовый регистр, а таких в проекте получается много, да еще умножаем на количество итераций. Всё это програмируется легко, но для плис неподъемно. Попытался сообщение записать в память по 84 бита ( а точнее soft 5 бит) в строке памяти. Ну и мо мере надобности автоматом извлекать нужные данные. Стало чуть легче (теперь ведь работает с 84×5=420 битным регистром), но автомат чтения и записи крайне сложный и непонятный. Интуитивно хочется поставить двухпортовую память и микроблейзер. Демодулятор пишет в память, а проц декодирует. В этом случае программа декодера становится похожа на программу на с#, а значмт более понятна. Ну мне так кажется. Вот у меня и вопрос. А какую архитектуру выбрать? Или вся слодность у меня из за неправильного алгоритма декодирования?

Всем привет. Интересует подход к созданию soft декодера LDPC. Собственно сам алгоритм разработан (проверен на программной реализации), но его реализация на плис какая-то сложная. Если делать на регистрах, то все легко и понятно, но для плис неподъемна. Делать на памяти можно, но крайне геморойно разрабатывать автоматы чтения и записи в память. Есть подозрение что нужно делать на каком либо процессоре (например,микроблайзер), но то же много вопросов. А отсюда вопрос а как кто делает? И как правильно? Если это важно, то длина блока 2016. Заранее спасибо за ответы.

Всем привет. Сделал проект двумерного турбокода на плис. У меня схема примерно такова: Принятый блок записываю по строкам в блочную память. Для исправления по строкам читаю каждую строку, корректирую, записываю в последующую память. Для исправления по строкам считываю каждую строку, формирую первый столбец, корректирую, записываю в память, снова считываю все строки, формирую второй столбец, корректирую, записываю, и так по всем столбцам. Повторяю все по количеству итераций. Схема полностью рабочая и отлаженная. Но возникла потребность в трехмерных кодах. И тут оказалось что весь предыдущий код практически не применим именно из-за необходимости иначе считывать строки, столбцы и глубину. Вопрос: а как собственно правильно (целесообразно, разумно) строить проект турбо декодера, что бы была повторяемость для разных вариантов и размерностей? По ощущениям напрашивается система на Zynq. А вы делаете как? Заранее спасибо за ответы.

Всем добрый день. Вероятно многие меня пошлют изучать документацию и возможно будут правы. Но... Есть проект на плис kintex ultrascale в котором реализованы: контроллер PCIe + демодулятор + декодер. Модули PCIe и демодулятора неизменны, а вот модуль декодера требуется менять. Вопрос можно но ли как-то решить вопрос с частичной перезагрузкой плис. Типа плата определилась в компьютере, демодулятор работает, а требуемый декодер я сам перезагружаю по мере необходимости. Я так понимаю этот вопрос должен решаться частичной реконфигурацией. Но что это такое и как это реализовать использовать не пойму. Если кто решал подобные задачи разъясните пожалуйста. Заранее спасибо за ответы.

Всем добрый день. Есть проект на vhdl по vivado 2016.4 работающий на частоте clk = 150 Мгц. Clk берется с clk-визарда соответственно констрейн прописан.. В проекте генерируется сигнал "ce" на котором работает большая часть проекта. CE "прореживает" частоту в 2000 раз. Вопрос: как грамотно описать для такой схемы констрейн? Насколько я понимаю виваде незачем пыжится развести всю схему на частоту clk=150 МГц. И можно ли такой констрейн прописать прямо в тексте vhdl модуля? Заранее большое спасибо за ответы.

Всем привет. Дошли руки до реализации LDPC в железе, но сразу же возникли трудности. Как хранить матрицу восстановления в ПЛИС при условии, что она довольно большая (7056 х 1008)? В ней около 30000 едениц, остальное нули (разумеется). Если всю хранить, то это 7056 * 1008 = 7112448 регистров. Как то криво, на мой взгляд. Если хранить только адреса едениц, то ресурсов значительно меньше требуется, но много проверок выходит. Кто сталкивался с подобным подскажите каким путем идти. Заранее спасибо за ответы.

Это точно не DVB-S2 Здесь я полностью согласен. Пока есть программная реализация и то не моя. И да есть демодулированный поток. И все. Больше инфы никакой.

А можно тыкнуть носом в стандарты или хотя бы направление где искать? Точных данных о сигнале расказывать не буду (надеюсь причины понятны), но приведу такой пример. Сигнал порезан на слоты каждый из которых обрабатывается отдельно. Длина слота 2000 бит. Формат принятого слота 1500 бит информации и 500 проверочных бит. Но достоверно известно, что на выходе декодера должно быть 1600 бит информации. Путем анализа установлено, что он формируется из 1200 бит принятой информации, потом вставка из 20 бит информации (т.е. эти 20 бит не принимались и они отсутствуют во входном потоке), потом 40 бит принятой информации, потом 80 бит информации, которой нет во входном потоке, и потом оставшиеся биты принятой информации. Соответственно не понятно откуда взялись два блока информации по 20 и 80 бит, которых нет в входном потоке.

При последующей обработке сигнала Сигнал реальный, система не известна, ну по крайней мере не у кого спросить. В сигнале выброшены быты двумя блоками. Первый блок N - выброшены, потом кусочек сигнала, потом снова K-бит выброшены.

При таком объеме неизвестных (ошибочных бит) код как то не очень справляется. Сигнал реальный, модели никакой нет. Тут хотелось бы понять саму идею. Зачем это делается и какой подход к декодированию нужно применять? Здесь Вы, наверное, наиболее близки к истине. Но вопрос в том является ли это типовым случаем? И если "да", то какой подход применяется для декодирования таких сигналов?

Есть сигнал закодированный кодеком LDPC. Но такое впечатление, что часть информации (примерно 1%) на передатчике после кодирования просто выброшена. Соответственно на приемной стороне сначала необходимо восстановить выброшеную инфу и уж потом декодировать LDPC. Кто нибудь с таким сталкивался? Заранее спасибо за ответы.

Всем добрый день. Есть ФНЧ с коэфф. K, i 0...63. Т.е. фильтр с 64 отводами, коэфф. известны. Как по известным коэффициентам посчитать задержку оказываемую фильтром на фазу сигнала. Частота дискретизации f=100 МГц. Заранее спасибо за ответы.

Первый процесс вырождается в data_ready <= not DATA_PIN1; А второй процесс вырождается в data_ready <= not data_ready; В итоге имеем: data_ready <= not (not DATA_PIN1); По мне, так какой то бред... Прошу прощения.

Пока не проверил на работе, но вроде не мой случай. В вивадо через системный монитор по jtag температура считывается правильно, а значит все подключения правильны, а вот самостоятельно прочитать температуру по ethernet не получается.

Всем здрасте. Собственно пытаюсь с помощью системного монитора прочитать температуру кристалла. Сконфигурировал IP. Через интерфейс drp из нулевого регистра читаю данные. Но там постоянно висит ноль. Но ведь по jtag в Vivado температура читается правильно. Что я возможно делаю не так? Может у кого есть простой пример чтения только температуры. Кристалл Kintex Ultrascale. Заранее спасибо за ответы.

И что можно предпринять? К сожалению большого опыта анализа нетлиста нет.

Всем привет. После добавления ILA в проект на этапе генерации битового файла вылетает с ошибкой. [DRC 23-20] Rule violation (RTSTAT-2) Partially routed net - 1 net(s) are partially routed. The problem bus(es) and/or net(s) are DVBS2Demod_SVN_inst/DVBS2Demod_inst/Deskr_svn_new_inst/DhC_inst/BufQ_reg[13]_BUFG. [Vivado 12-1345] Error(s) found during DRC. Bitgen not run. Если ILA убрать, то проект компилируется успешно. В чем проблема с ILA так и не смог разобраться. Замечу, что ILA стоит не в модулях, отмеченых в ошибке. При установленной ILA на эмплементации выскакивают критические варнинги, которых без ILA не бывает. [Route 35-54] Net: DVBS2Demod_SVN_inst/DVBS2Demod_inst/Deskr_svn_new_inst/DhC_inst/BufQ_reg[13]_BUFG is not completely routed. [Route 35-54] Net: DVBS2Demod_SVN_inst/DVBS2Demod_inst/Deskr_svn_new_inst/DhC_inst/BufQ_reg[13]_BUFG is not completely routed. [Route 35-8] Design has 3 unrouted pins, that are still reachable. [Route 35-1] Design is not completely routed. There is 1 net that is not completely routed. [Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timing violations. Может кто сталкивался с таким? Какие предположения? Заранее спасибо за ответ. Все дела происходят в Vivado 2016.4

Так все верно. Это список соединений между примитивами и он одинаков для обоих версий вивады. И файл констрейнов один и тотже. Иными словами исходник проектов для обоих версий вивадо абсолютно один и тот же, а результат разводки на установках по умолчанию совершенно разный. А как взять результаты трансляции именно этого модуля из вивады2016 и всунуть в виваду2018 ?

К слову сказать в проекте есть модуль который изначально был ngc файлом под виртекс4 проект был в ise. Потом перешли на ультраскале и виваду соответственно. прошлось ngs переделать в кривой vhdl (офигительного размера ~ 20 Мбайт). Так вот в вивадо16.4 все работало как надо, а вот в вивадо18.2 не работает. По впечатлениям что то не разводиться как раз в этом модуле, но его не посмотреть не переделать. Да и в любом случае vhdl файл это некий алгоритм и каким бы кривым он не был работать должен одинаково при компиляции в любой версии среды разработки. А в данном конкретном случае даже число задействованных bufg в разы отличается (4 шт. в vivado16.4 и 17 шт. в вивадо 18.2). Так что я склонен списывать на глюки вивадо.

Сделал проект в Vivado 2018.2 Проект совершенно не работает. Тот же самый проект развел в Vivado 2016.4 и он заработал. Вопрос: в чем дело? Это глюк новой вивады или что то не то с настройками?