Jump to content

    

Alex_AZ

Свой
  • Content Count

    59
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Alex_AZ

  • Rank
    Участник

Информация

  • Город
    Array

Recent Profile Visitors

3253 profile views
  1. Добрый день! Появилась парочка вопросов. 1. Правильно ли понимаю, что GW1N-LV9 в корпусе UG256 невозможно загрузить по SSPI, т.к. в этом корпусе не выведены наружу ноги MODE[2:0]? Откуда вопрос: корпус PG256 (BGA) большой, имеет шаг выводов 1.0мм и у него есть MODE[2:0]. Корпус UG256 меньше, с шагом выводов 0.8мм и было бы удобнее использовать его. Но непонятно как загрузить ПЛИС внешним процессором, т.к. согласно документации ноги MODE[2:0] наружу не выведены и режим конфигурации SSPI недоступен. 2. Что делать со входами L/RPll, если pll в проекте не используется или источником тактового сигнала являются не указанные входы?
  2. Всем привет! Пробую запустить USB на Zynq-7000 baremetal. За основу взял пример xusbps_intr_example.c из поставки Vivado/Vitis. Разрабатываемое устройство - USB Device с контрольными конечными точками 0x00 и 0x80, и по одной Bulk конечной точке IN и OUT. Сценарий работы: хост передает данные на устройство по Bulk OUT, устройство их обрабатывает и возвращает хосту через Bulk IN. Собственно, все работает более-менее хорошо до тех пор, пока не нужно "придержать" передачу данных с хоста. Т.е. приходит блок данных на обработку и пока приложение на Zynq занимается обработкой, я не хочу принимать новые данные с хоста. Вроде бы интерфейс USB позволяет реализовать такой сценарий ответами NAK/NYET. Судя по ug585-Zynq-7000-TRM, конечная точка Bulk OUT на запросы транзакций отвечает NAK, если она не primed. Т.е. перед транзакцией мы готовим дескрипторы транзакций dTD, затем делаем конечную точку primed. Когда отработают USB и DMA, данные окажутся в указанной области памяти, дескрипторы dTD снова становятся активными, а конечная точка должна стать не-primed. Пробую реализовать. Передаю c хоста блок данных по размеру входного буфера. USB и DMA отрабатывают, но конечная точка остается primed. Статус конечной точки проверяю, читая регистр XUSBPS_EPRDY_OFFSET. Т.е. если верить ug585, в primed конечную точку хост может продолжить передавать данные, в ситуации, когда их некуда девать. Если кто-нибудь работал с USB на Zynq-7000 baremetal, то как вы это обходили? Ситуация выглядит так, что штатный драйвер не рассчитан на такого рода обмен. Ну, или что более вероятно, я чего-то не понимаю)
  3. Добрый день! Экспериментирую с Ethernet на отладочной плате MYIR Z-turn board. На ней чип физического уровня Ethernet присоединен к MIO Zynq'a, т.е. к его PS-части (блок Gigabit Ethernet Controller(GEM)). Хочу без каких-либо изменений или анализа передавать пакеты Ethernet в PL. Как основу брал пример от Xilinx "Zynq-7000 AP SoC - Performance - Ethernet Packet Inspection - Bare Metal - Redirecting Packets to PL Tech Tip". Все заработало, но DMA там настроено на прием только 1 пакета. Поправил, сделал сброс бита Ownership дескриптора (1 - с буфером, описываемым данным дескриптором работает software, 0 - с буфером работает блок GEM). Принимаются теперь все пакеты, но требуется вмешательство процессора по очистке этого бита. Т.к. задачи обработки на стороне процессора не стоит, то и отвлекать его на сброс флага не хотелось бы. Отсюда вопрос - есть ли механизм автоматической переинициализации дескрипторов DMA блока GEM? Кажется, что что-то подобное быть должно, но в документации не нашел.
  4. Забыл сразу написать, но может кому-то пригодится. Все заработало нормально после замены кабеля USB. Причем сбоил тот, который шел в комплекте с платой :-) Со штатным драйвером скорость bulk out удалось получить на уровне 10МБ/с, bulk in - 8..9 МБ/с. Думается, что скорость можно еще увеличить, если переписать драйвер под собственное применение без проверок на ошибки.
  5. С ходу получилось около 8Мбайт/с. Но за скоростью пока не гонюсь, хочу получить стабильную работу. После этого можно будет и пооптимизировать.
  6. Добрый день! Только начинаю осваивать Zynq. Пытаюсь запустить USB Device на плате MYIR Z-turn board (xc7z020, usb phy USB3320) в baremetal. Сгенерировал BSP, в качестве основы для проекта использовал поставляемую библиотеку xusbps и пример работы с ней xusbps_intr_example.c. На этом этапе вроде все нормально. Затем в этом примере подправил дескрипторы под стандартные от Cypress и пытаюсь работать с устройством из Cypress Control Center. Передача по BulkOut (из ПК в Zynq) работает нормально. С передачей BulkIn возникли вопросы, которые решить пока не получилось. Вкратце, что я пытаюсь делать: после инициализации и ренумерации USB посылаю по BulkOut посылку, которая служит сигналом для начала передачи из Zynq в ПК по BulkIn. Со стороны ПК из Cypress Control Center начинаю инициировать чтение единичных пакетов по BulkIn. До какого-то момента такие передачи проходят, затем возникает исключение - отсутствие ответа на BulkIn-запрос от ПК. Количество успешно переданных пакетов до возникновения ошибки случайно. Вопрос - что я делаю не так? Как правильно работать с библиотекой xusbps? На первый взгляд все что в ней написано - правильно и соответствует документации Zynq TRM(ug585). После того как попали в ошибочное состояние соответствующий дескриптор dTD находится в активном состоянии (т.е. выполнена запись в регистр XUSBPS_EPRIME_OFFSET и мы "отдали" железу этот дескриптор), но передача не проходит. Есть подозрение, что это может быть связано с неправильной работой с кэшем. В приложении - код с которым работаю. По сравнению с оригиналом изменил настройки enpoint1 в main, основной цикл в main и обработчик Ep1EventHandler. Мои настройки Endpoint1 DeviceConfig.EpCfg[1].Out.Type = XUSBPS_EP_TYPE_BULK; DeviceConfig.EpCfg[1].Out.NumBufs = 2;//16; DeviceConfig.EpCfg[1].Out.BufSize = 64;//512; DeviceConfig.EpCfg[1].Out.MaxPacketSize = 512; DeviceConfig.EpCfg[1].In.Type = XUSBPS_EP_TYPE_BULK; DeviceConfig.EpCfg[1].In.NumBufs = 1;//16; DeviceConfig.EpCfg[1].In.MaxPacketSize = 64;//512; Новый основной цикл XUsbPs_EpIn *Ep1In; Ep1In = &UsbInstancePtr->DeviceConfig.Ep[1].In; while (NumReceivedFrames < 1) //There was no errors { if (flagRcv == 1) // Ep1 BulkIn operations are enabled { //XUsbPs_dTDInvalidateCache(Ep1In->dTDHead); if (!XUsbPs_dTDIsActive(Ep1In->dTDHead)) { memset(sendBuf1,cnt,64); Status = XUsbPs_EpBufferSend(UsbInstancePtr, 1, sendBuf1, 64); cnt++; } } } xusbps_intr_example.c
  7. Zig, благодарю за участие, особенно в выходной. Согласен, уточнение важное, не отметил сразу. Пока речь идет именно о CBR. Все реализовано так, просто в целях отладки пока сделал вычисление времени задержки (в количестве тактов SCR) при добавлении к выходному пакету. - PCR accuracy входного потока - 40нс. Выходной получается 500-600нс. - 27МГц на моей плате отличаются от номинала (если верить поверенному частотомеру) герц на 20. Вроде не должно быть критично на интервале 1 пакета при битрейте выходного потока 50МБит/с и входного 24.9Мбит/с. - Пакет не задерживается дольше, чем на время одного выходного пакета при выходном битрейте 50Мбит/с. Вместо этого просто задавал константой (исходя из скорости оригинального входного потока, взятого из файла) скорость чтения из большого буфера. Но уменьшить PCR accuracy ниже величин 500-600нс не получается. Согласен, но это судя по результатам, пока проблема меньшего масштаба. Уже добился результатов, когда восстановленное значение скорости потока и заданное константой дают равный результат для PCR accuracy. Во всяком случае, выяснил, что понимаю алгоритм коррекции PCR правильно. Возможно стоит поискать проблемы и неточности в его реализации.
  8. Спасибо за ответ. Абсолютно согласен. Я похоже непонятно и не совсем корректно нарисовал схему, не хотел загромождать. Вычисление приращения и нового значения PCR происходит в момент, когда мультиплексор отправляет пакет, содержащий PCR, модулятору. Мультиплексор же и подменяет старое значение PCR новым вычисленным. В целом, насколько понял, примененный алгоритм ситуацию улучшает, но вносимый джиттер в PCR расходится с описанным в разных статьях (если нужно, могу выложить, но не раньше понедельника), где говорится о 40нс прироста PCR accuracy. Может ли это быть как-то связанным с преобразованием размера пакета при передаче модулятором из 188 байт в 204 после кодера Рида-Соломона? Модулятор, на первый взгляд, дает постоянную задержку данных в нем, что требуется стандартом ISO/IEC 13818. Пока даже не знаю что еще проверить.
  9. Занимаюсь разработкой DVB-C модулятора. В целом все работает, возникают только вопросы к алгоритму коррекции (перештамповке) PCR. Проблема проистекает из того, что скорость входного потока в общем случае не равна скорости потока, генерируемого модулятором. Для компенсации этой разности скоростей в поток добавляются нуль-пакеты. Такое изменение структуры потока влечет за собой необходимость коррекции меток времени, так как временные интервалы между пакетами с временными метками в общем случае изменяются. Механизм перештамповки PCR использую такой как описан, например здесь: https://electronix.ru/forum/index.php?showtopic=93519 Такой же механизм (добавление к PCR времени задержки пакета в цепях модулятора) описан и во множестве других статей. Схема в общем виде моей реализации приведена в приложении. Смущает то, что выходное значение PCR-accuracy сильно увеличивается по сравнению со входным, если верить анализатору Dektec. А именно, при входном PCR accuracy = 40нс, на выходе получаю PCR-accuracy иногда достигающее величины 500-600нс. Источник потока - программа Astra. Может кто-то сталкивался с проблемами приведенного алгоритма перештамповки PCR или сможет подсказать, где возможно наличие подводных камней.
  10. Возможно, при работе в Half-Duplex режиме не отслеживаются коллизии. В ядре MAC-контроллера из ISE были сигналы tx_collision и tx_retransmit для отслеживания подобных ситуаций. При возникновении коллизии нужно было повторно отправить поврежденный пакет.
  11. В свое время для общего развития писал на FPGA проект USB Device (работал в режимах LS, FS) без применения USB PHY и Microblaze/Nios. Работали 1 контрольный и несколько bulk интерфейсов. В качестве точки для старта брал проект университета Джона Хопкинса http://www.xess.com/projects/fpga-usb-v2-project/ . Этот проект кривоват конечно, но позволяет разобраться, что и как должно приниматься и передаваться. А дальше дело техники - убрать чисто студенческие ляпы и нормально структурировать проект.
  12. Сам удивился, но современные синтезаторы умеют деление целых чисел синтезировать. Случилось столкнуться с таким описанием. Судя по схеме в RTL-viewer'e, просто раскрывают цикл сдвигов и вычитаний, но логики при этом используется оооочень много. Соответственно и максимальная частота работы схемы сильно падает.
  13. Ок, продублирую. Несколько дней назад писал на указанный адрес. Пока ответа не было.
  14. А подробнее по задачам на ПЛИС. Задачи у Вас вполне жизненные и, хотя я уже не начинающий, поучаствовать было бы интересно.