Alex_AZ

Оригинальный JTAG-кабель от Gowin. PL USB Cable v4.0 Среда Gowin FPGA Designer 1.9.8

При программировании SRAM или Embedded Flash чипа GW1N-1S получаю ошибку "VLD Down!". Есть ли у кого-нибудь информация, что бы это могло значить и как с этим бороться? При этом статус и ID code читаются нормально. Т.е. JTAG-цепочка вроде бы работает. Значение кода статуса - 0x00018020. Из документации нашел, что VLD - это 12-й бит регистра статуса. Его значение как-то связано с Embedded flash. При нормальном протекании процесса программирования этот бит должен быть в 1. Более детальной информации не нашел.

В продолжение истории. Получили чипы с Data Code 1948. Из 12 установленных без проблем завелись все 12.

1. Пробовали, не помогает 2. Самое старое, что пока нашли 1.9.6 Beta. На сегодняшний день проверили следующие варианты ПО: - Gowin 1.9.6 Beta с программатором Programmer 2; - Gowin 1.9.7.01 Beta - Gowin 1.9.8 - Gowin 1.9.8.05 - Gowin 1.9.8.06 3. Пробуем. Обращение на форуме только для возможного ускорения поиска проблемы.

По нарастанию напряжений питания - а на какое время нарастания следует ориентироваться? Тут момент такой - на тех же самых платах чипы из другой, "исправной" партии завелись все. На чипах из "неисправной" партии - 10 из 10 не завелись. Не похоже, что где-то на грани работаем. Там чип маленький, проект в принципе простой. Но для очистки совести сделал новый - оставил по одному пину вход и выход. Соединил их между собой. Пытаюсь прошить eeprom - не стартует с теми же симптомами.

Эти выводы в корпусе FN32 наружу не выведены К тому же, на этой же печатной плате чип из другой партии стартует нормально

Добрый день! При прошивке embedded flash микросхемы GW1N-1S возникает проблема: ПЛИС не стартует при включении питания. Прошивка embedded flash проходит успешно включая верификацию, но есть сообщение об ошибке "Error: Finished, NOT wakes up". Работаем с микросхемой GW1N-LV1SFN32C6/I5, Data Code 1919, Lot number AS01185 Пробовали 2 версии ПО Gowin FPGA Designer версий 1.9.8 и 1.9.8.05 В качестве программатора используем поставляемый производителем ПЛИС Gowin FPGA Download Cable Настройки bitstream установлены как показано на рисунках (configuration.jpg, configuration2.jpg) Пробовали менять эти настройки, но результат прежний - плата не стартует. При этом, если прошивать по JTAG напрямую SRAM, то микросхема функционирует правильно. Что примечательно, такие же микросхемы GW1N-LV1SFN32C6/I5 с Date Code 1940 и Lot code AS01221 прошиваются без проблем при приведенных выше настройках проекта и программатора. Известны ли какие-нибудь проблемы с микросхемами GW1N-LV1SFN32C6/I5, Data Code 1919, Lot number AS01185? Возможно были какие-либо известные проблемы с какими-то конкретными партиями микросхем?

Добрый день! Залить удалось, работает. Временные диаграммы сделали в соответствии с документом UG290 версии 2.4.1E, раздел 6.4. Алгоритм программирования взяли из TN652-1.3E, используем ветку с проверкой IDCODE У нас еще была проблема, что ошибочно SI завели на ножку DIN, которая в режиме SSPI работает как CLKHOLD_N. На всякий случай уточню несколько моментов: 1. После того как поднимается CS SSPI, нужно сгенерировать не менее 2х импульсов тактового сигнала CLK. 2. После подачи команды записи 0x3B CS не поднимается до окончания передачи прошивки. 3. Нигде не описанный явно момент: заливать в чип нужно файл .bin, не .fs У нас основная проблема была в том, что нашли несколько версий документа UG290 и в разных версиях процесс программирования описан по-разному. Непонятно было какой из вариантов актуальный. TN652-1.3E_Gowin FPGA Products Slave SPI Configuration Manual.pdf UG290-2.4.1E_Gowin FPGA Products Programming and Configuration Guide.pdf

В свое время при реализации LDPC для DVB-T2 на FPGA мне сильно помогла вот эта статья. Не факт, что в Вашем случае применимо, но есть вероятность, что поможет) FPGA Implementation of LDPC Decoder in DVB.pdf

Добрый день. Безуспешно пытаемся загрузить прошивку в ПЛИС GW1-LV9PG256 в режиме SSPI. По JTAG процесс загрузки проходит нормально. Как мы пытаемся прошить по SSPI (в соответствии с документом TN652 Gowin FPGA Products Slave SPI Configuration Manual): 1. M[2:0] = 'b001, CLKHOLD_N = 1 2. Импульс (1 -> 0 -> 1) RECONFIG_N длительностью 400ns, дожидаемся READY = 1 3. ID-код не опрашиваем 4. Отправляется команда 0x15, 0x00, 0x00, 0x00 (4 байта). Если верить документации, после нее нужно выдержать паузу 4ms. Пробовали как с этой задержкой, так и без нее. 5. Отправляется команда 0x3B (1 байт). 6. Отправляются данные из файла прошивки (пробовали и .bin, и .fs) 7. Отправляется команда 0x3A, 0x00, 0x00, 0x00 После выполнения этой последовательности действий не видим перехода DONE в 1. Можете ли подсказать, что мы делаем не так? Еще пара вопросов. 1. В документе TN652-1.3E Gowin FPGA Products Slave SPI Configuration Manual есть такая фраза Правильно ли понимаю, что после того как передача каких-либо данных закончилась при сигнале CS = 1 нужно на вход SCLK подать минимум 2 тактовых импульса? 2. Допускает ли команда 0x3B запись более одного байта? 3. Какой все-таки файл нужно заливать по SPI .fs или .bin?

Добрый день! Появилась парочка вопросов. 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 в проекте не используется или источником тактового сигнала являются не указанные входы?

Всем привет! Пробую запустить 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, то как вы это обходили? Ситуация выглядит так, что штатный драйвер не рассчитан на такого рода обмен. Ну, или что более вероятно, я чего-то не понимаю)

Добрый день! Экспериментирую с 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? Кажется, что что-то подобное быть должно, но в документации не нашел.

Забыл сразу написать, но может кому-то пригодится. Все заработало нормально после замены кабеля USB. Причем сбоил тот, который шел в комплекте с платой :-) Со штатным драйвером скорость bulk out удалось получить на уровне 10МБ/с, bulk in - 8..9 МБ/с. Думается, что скорость можно еще увеличить, если переписать драйвер под собственное применение без проверок на ошибки.

USB3320C

С ходу получилось около 8Мбайт/с. Но за скоростью пока не гонюсь, хочу получить стабильную работу. После этого можно будет и пооптимизировать.

Добрый день! Только начинаю осваивать 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

Zig, благодарю за участие, особенно в выходной. Согласен, уточнение важное, не отметил сразу. Пока речь идет именно о CBR. Все реализовано так, просто в целях отладки пока сделал вычисление времени задержки (в количестве тактов SCR) при добавлении к выходному пакету. - PCR accuracy входного потока - 40нс. Выходной получается 500-600нс. - 27МГц на моей плате отличаются от номинала (если верить поверенному частотомеру) герц на 20. Вроде не должно быть критично на интервале 1 пакета при битрейте выходного потока 50МБит/с и входного 24.9Мбит/с. - Пакет не задерживается дольше, чем на время одного выходного пакета при выходном битрейте 50Мбит/с. Вместо этого просто задавал константой (исходя из скорости оригинального входного потока, взятого из файла) скорость чтения из большого буфера. Но уменьшить PCR accuracy ниже величин 500-600нс не получается. Согласен, но это судя по результатам, пока проблема меньшего масштаба. Уже добился результатов, когда восстановленное значение скорости потока и заданное константой дают равный результат для PCR accuracy. Во всяком случае, выяснил, что понимаю алгоритм коррекции PCR правильно. Возможно стоит поискать проблемы и неточности в его реализации.

Спасибо за ответ. Абсолютно согласен. Я похоже непонятно и не совсем корректно нарисовал схему, не хотел загромождать. Вычисление приращения и нового значения PCR происходит в момент, когда мультиплексор отправляет пакет, содержащий PCR, модулятору. Мультиплексор же и подменяет старое значение PCR новым вычисленным. В целом, насколько понял, примененный алгоритм ситуацию улучшает, но вносимый джиттер в PCR расходится с описанным в разных статьях (если нужно, могу выложить, но не раньше понедельника), где говорится о 40нс прироста PCR accuracy. Может ли это быть как-то связанным с преобразованием размера пакета при передаче модулятором из 188 байт в 204 после кодера Рида-Соломона? Модулятор, на первый взгляд, дает постоянную задержку данных в нем, что требуется стандартом ISO/IEC 13818. Пока даже не знаю что еще проверить.

Занимаюсь разработкой 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 или сможет подсказать, где возможно наличие подводных камней.

Возможно, при работе в Half-Duplex режиме не отслеживаются коллизии. В ядре MAC-контроллера из ISE были сигналы tx_collision и tx_retransmit для отслеживания подобных ситуаций. При возникновении коллизии нужно было повторно отправить поврежденный пакет.

В свое время для общего развития писал на FPGA проект USB Device (работал в режимах LS, FS) без применения USB PHY и Microblaze/Nios. Работали 1 контрольный и несколько bulk интерфейсов. В качестве точки для старта брал проект университета Джона Хопкинса http://www.xess.com/projects/fpga-usb-v2-project/ . Этот проект кривоват конечно, но позволяет разобраться, что и как должно приниматься и передаваться. А дальше дело техники - убрать чисто студенческие ляпы и нормально структурировать проект.

Сам удивился, но современные синтезаторы умеют деление целых чисел синтезировать. Случилось столкнуться с таким описанием. Судя по схеме в RTL-viewer'e, просто раскрывают цикл сдвигов и вычитаний, но логики при этом используется оооочень много. Соответственно и максимальная частота работы схемы сильно падает.

Ок, продублирую. Несколько дней назад писал на указанный адрес. Пока ответа не было.

А подробнее по задачам на ПЛИС. Задачи у Вас вполне жизненные и, хотя я уже не начинающий, поучаствовать было бы интересно.