Pavel_I

До него руки еще не дошли )) Все будет в процессе развития проекта.

Всем спасибо, разобрался. DMA в итоге запустился. Его регистры все-таки читаются как надо через функции XIic_WriteReg/XIic_ReadReg. С I2C блоком отдельная история, уже не столь интересная. Думал, что регистры AXI IP блока должны быть доступны через Memory Browser. Но как раз там только младший байт отображается. Как обычно "сам дурак" )) Надо было глубже вникать прежде, чем просить помощи.

Вот схема проекта. Все главным образом подключалось через Connection Automation Сам код выглядит, например, вот так XIic_WriteReg(XPAR_IIC_0_BASEADDR, 0x128, 0x12345678); u32 reg = XIic_ReadReg(XPAR_IIC_0_BASEADDR, 0x128); Здесь 0x128 - смещение до 32-битного регистра. Читается только 0x00000078

Начинаю осваивать работу с Zync SoC и столкнулся с необьяснимой проблемой. Создал систему с процессорным ядром и DDR памятью, добавил I2C IP блок на шине AXI. Коммуникация с внешним I2C устройством работает. Т.е. запускается отладка проекта из Vitis, возможно посылать данные по I2C шине и получат правильный ответ. Далее решено добавить AXI DMA блок, чтобы получать данные от внешнего устройства и записывать их в память. DMA не получилось запустить, как ожидалось. Стал исследовать в чем дело, правильно ли записываются конфигурационные регистры DMA. И обнаружил, что при чтении из 32-х разрядных регистров читается только младший байт, а остальное нули. Т.е., например, имееются два регистра для задания адреса в памяти, куда DMA должен складывать данные. Пишешь туда 32-х разрядные числа, а когда читашь их обратно сохраняетя только младший байт, как записано. Остальные байты нулевые. Тогда меня заинтересовало, а как же работает I2C блок? Оказалось, что практически все конфигурационные регистры используют только младшие восемь бит. Имеется несколько 32-х разрядных регистров для параметров тайминга, но их тоже невозможно записать, а потом прочитать полность. Но они в моем случае и не задействованы. Решил я посмотреть, что же происходит в синтезированной схеме. И там действительно во входной шине данных и выходной шине часть линий занулено (фрагмент схемы прилагается). Т.е. конфигурационные регистры IP блока в принципе не могут быть записаны и прочитаны, как 32-х значащие числа. В заключении я создал свой блок с AXI-Lite шиной. Из моего блока регистры пишутся и читаются полностью. Анализ синтезированной схемы схемы DMA блока тоже показывает, что часть разрядов шин данных также зануляется. Оптимизация что ли какая? Кто-то может подсказать почему так происходит и куда копать?

Система Win 7/64 Согласно документации система должна сообщить о новом устройстве. Этого не происходит. И в девайс менеджере новых устройств не появляется. Linux пробовал. Там тоже никакой реакции. Обе материнки на Intel H81 Express. У одной слот PCI-E x1, у другой mini-PCI-E (использовал переходник). Spread spectrum опции в биосе нет. К сожалению, под рукой пока нет других компьютеров. Нынче ноутбуки у всех в округе. Плата тактирутся с материнки. Судя по LOCK светодиоду генератора клоков, клок с материнки приходит. Пробовал шить по-разному и перегружать. Работать упорно не хочет. Еще такой момент. Слот PCI-E x1, а плата может x2. Вот не знаю, может ли она автоматом переключится на нужную скорость? Это уже в прошивку надо править. Пока не дошел до этого. Пока склоняюсь, что проблема все-таки на железном уровне.

Компьютер никак не реагирует на вставленную плату. Пробовал на двух разных. Сами слоты PCI-E компьютеров проверял сетевой карточкой. С ними все в порядке. Светодиоды на плате, например Data Link up, не демонстрируют какую-либо активность. Битстрим для FPGA заливал в загрузочную флеш.

Добрый день! По акции была приобретена данная плата что-бы поиграться с PCI-Express. Начал с демонстрационных проектов, которые не заработали. Засомневался в работоспособности SERDES и электрических соединений на пути к PCI-е разъему. В моем варианте ПЛИС четыре SERDES устройства. Тогда с помощью SERDESEyeDemo проекта решил проверить их работоспособность. В оригинале SERDESEyeDemo использует DCU0 CH1. И в такой конфигурации все работает, как и должно быть. Т.е. передатчик передает, приемник принимает, как с Internal Loopback так и c External Loopback. Дальше в проекте стал менял SERDES. Во-первых, выяснилась такая особенность. У каждого SERDES имеется Receive CDR Loss of Lock, который, насколько понимаю, показывает есть ли синхронизация с примаемым потоком. Так вот в оригинальном SERDESEyeDemo (DCU0 CH1) все работает объяснимо – есть поток на входе – есть синронизация, нет потока – нет синхроницации. Для остальных трех SERDES, что есть поток, что нету, показывает, что есть синронизация. Смотрю это в Reveal Analyzer SERDES Debug, а также на отладочном светодиоде. Для двух SERDES из DCU1 могу использовать только Internal Loopback. И они в принципе работают. SERDES CH0 из DCU0, который ответственен за PCI-Express с Internal Loopback тоже принимает, но когда делаешь External Loopback принимать совсем не хочет. Хотя передатчик передает (смотрю осциллографом), и детектор сигнала на входе показывает, что он есть. Вообщем, происходят странные вещи, с которыми непонятно, что делать. Остается два предположения. Либо делаю что-то не так. Либо ПЛИС имеет дефект в SERDES юнитах, во что верится с трудом. Может кто сталкивался с подобным? Или может что-то еще посоветовать. В принципе, могу предоставить прошивки для ПЛИС. Возможно кто-то еще располагает аналогичной платой и сможет посмотреть, как она себя ведет. Также, если у кого-то заработали-не заработали демо проекты для PCI-e, то было бы также интересным узнать про это.

К этой плате еще бы Connectivity IP Suite раздобыть, вообще бы замечательно было.

А платформа/компилятор какие? Смотрю у MinGW вот нет таких макросов в sys/time.h time.h

Опишу, как я понимаю процесс. Имеется передатчик с фильтром и канал. В сумме они дают некий фильтр, который характеризуется импульсной характеристикой. Еще есть согласованный фильтр. Символ на выходе всего этого в отсчетный момент для каждого состояния в алгоритме Витерби может быть расчитан с использованием кросс-коррелиций. Дальше может быть посчитана метрика, как квадрат евклидова расстояния между этим "восстановленным" отсчетом и принятым символом с выхода согласованного фильтра. Как я вижу, по объему вычислений это тоже самое, как соотношение (15) из статьи.

Пытаюсь осмыслить работу MLSE приемника. В зарубежных статьях для расчета метрики алгоритма Витерби приводятся соотношения вида (15) из приаттаченой статьи. Физический смысл соотношения не очень понятен (или, скорее, не очень нагляден) и возникает вопрос - почему бы в качестве метрики не использовать евклидово расстояние между принятым символом (с выхода согласованного фильтра) и символом, полученным на основе импульсной характеристики канала? Unification_of_MLSE_receivers_and_extension_to_time_varying_channels.pdf

Думаю таковых нет потому, как платы еще не начали рассылать. Интересная статейка

Альтернативы по сравнимой цене для "пощупать" все равно нету. Пришлют когда-нибудь :-)

Было бы интересно узнать, чем дело кончится. Чем послали? Обычная почта, EMS, UPS? По моим наблюдениям обычную почту "трясут" гораздо меньше. Как-то послали мне здоровый RF генератор весом 25 кг через EMS. Но все думаю - попал. Нашел даже заранее в интернете "своего" брокера при EMS, который за фиксированную сумму брался это дело протолкнуть. Но в итоге все и так обошлось. До сих пор удивляюсь. PS: Собственно вот, может кому пригодится: http://customsprocedure.ru/ems

Действительно есть шанс, что таможня может завернуть. Еще посылку могут потерять, украсть, повредить. Плата может сломаться или оказаться дефектной. Поэтому, если страшно, то единственная возможность свести риск к нулю - купить у местных барыг за дорого. В случае посредника декларируешь сам. За последнее время покупал разные вещи, которые потенциально могли завернуть. Включая осциллограф RIGOL за 800$. Все доехало. Вот еще одна поучительная история http://habrahabr.ru/post/205038/