Vengin

Интересно. Но это всё применимо только для linux kernel. А для bare-metal тогда как? Кажется, что должна быть более низкоуровневая и универсальная возможность. Но в целом это всё предполагает, что переключение в принципе возможно. А вот как узнать наверняка ...

C тонкостями FSBL практически не знаком и предполагал, что он больше отвечает за нюансы загрузки. Бегло просмотрел сейчас раздел "Boot and Configuration" в ug585-Zynq-7000-TRM - как-то не особо помогло. В исходникак FSBL тоже не совсем понятно, что смотреть. Да, есть вызов функции ps7_init(). Есть ещё кстати макросы SlcrLock()/SlcrUnlock(). Но даже в какую сторону копать не совсем понятно. Допустим, в FSBL (в post_config?) переключили интерфейс, а что дальше? В моём понимании FSBL ведь выполняется 1 раз? Как это поможет "динамически" и многократно переключать интерфейсы PS_MIO? Продублировал вопрос на форуме Xilinx, глядишь там помогут. Просто сейчас стоит задача понять, возможно ли это в принципе (динамически переключать PS_MIO интерфейсы), или нужно переделывать плату. Да, кстати, там в плане схематики ещё есть нюанс. Дело в том, что этот shared MIO[40-45] интерфейс выводится через коннектор на другую плату. Если прводить оба интерфейса по отдельности, может не хватить места в коннектере.

А при чём тут FSBL, и исходники чего смотреть?

Ну, если это можно делать программно, то это естественно проще чем переразводить плату. Да и вообще мне и самому интересено, насколько в этом плане гибока подсистема PS цинка.

Об этом надо спрашивать человека занимавшегося схематикой. Видимо предполагалось, что всё надо "впихнуть" в MIO.

Здравствуйте. Есть кастомная плата с xc7z030fbg676-1. Из-за ограниченного количества PS MIO на пины MIO40-45 на схематике заведено 2 интерфеса (SDIO и SPI) через внешний mux/demux: Вопрос, можно ли обоими интерфейсами пользоваться "статически" или "динамически"? "Статически" - это на одну прошивку один интерфейс. "Динамически" - это в рамках одной прошивки менять тип PS MIO интерфейса на лету. Насколько я понимаю конфигурация PS MIO выполняется за счёт настройки SLCR Registers (как в генерируемом файле ps_init.tcl). А можно ли эти регистры менять прямо из программы процессора? Смотрел ug585-Zynq-7000-TRM, но явного подвтерждения/опровержения пока найти не удалось.

После попытки установки Universal Scan вооще перестал работать JTAG cable. Когда кабель ещё работал, при поптыке программировани FPGA в Vivado выглядело так. В "Hardware Manager" выбираем "Open Target", коннектимся и видим: open_hw connect_hw_server INFO: [Labtools 27-2285] Connecting to hw_server url TCP:localhost:3121 INFO: [Labtools 27-2222] Launching hw_server... INFO: [Labtools 27-2221] Launch Output: ****** Xilinx hw_server v2017.4.1 **** Build date : Jan 30 2018-15:49:02 ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved. open_hw_target INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/210249A84A2D set_property PROGRAM.FILE {C:/work/syna/Dev/xil_prj/dgcb3045/dgcb_xc7z030_tst04/dgcb_xc7z030_tst04.runs/impl_1/top_dgcb_xc7z030.bit} [get_hw_devices xc7z030_2] current_hw_device [get_hw_devices xc7z030_2] refresh_hw_device -update_hw_probes false [lindex [get_hw_devices xc7z030_2] 0] INFO: [Labtools 27-1435] Device xc7z030 (JTAG device index = 2) is not programmed (DONE status = 0). Теперь это выглядит так: open_hw update_compile_order -fileset sources_1 connect_hw_server INFO: [Labtools 27-2285] Connecting to hw_server url TCP:localhost:3121 INFO: [Labtools 27-2222] Launching hw_server... INFO: [Labtools 27-2221] Launch Output: ****** Xilinx hw_server v2017.4 **** Build date : Dec 15 2017-21:08:27 ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved. Процесс как будто обрывается, до команды 'open_hw_target' не доходит. В SDK тоже ничего: В XSCT консоли команда 'connect' как будто отрабатывает, а 'targets' ничего не выдаёт. В ISE Impact то же выглядит будто кабель не подключен: Welcome to iMPACT iMPACT Version: 14.7 // *** BATCH CMD : setMode -bs // *** BATCH CMD : setMode -bs // *** BATCH CMD : setMode -bs // *** BATCH CMD : setMode -bs GUI --- Auto connect to cable... // *** BATCH CMD : setCable -port auto INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.4 INFO:iMPACT - Digilent Plugin: no JTAG device was found. AutoDetecting cable. Please wait. *** WARNING ***: When port is set to auto detect mode, cable speed is set to default 6 MHz regardless of explicit arguments supplied for setting the baud rates PROGRESS_START - Starting Operation. Connecting to cable (Usb Port - USB21). Checking cable driver. Source driver files not found. The Platform Cable USB is not detected. Please connect a cable.If a cable is connected, please disconnect and reconnect to the usb port, follow the instructions in the 'Found New Hardware Wizard', then retry the Cable Setup operation. Cable connection failed. Connecting to cable (Parallel Port - LPT1). Checking cable driver. Your driver installation is not complete. Please re-run your application or run install_drivers.exe from the ISE installation area as an Administrator to complete the driver installation. Service using windrvr6.sys : SYSTEM\CurrentControlSet\Services\WinDriver6. ImagePath = \SystemRoot\system32\drivers\windrvr6.sys. Start = 3. ErrorControl = 1. Type=1. Cable connection failed. Connecting to cable (Parallel Port - LPT2). Checking cable driver. Your driver installation is not complete. Please re-run your application or run install_drivers.exe from the ISE installation area as an Administrator to complete the driver installation. Service using windrvr6.sys : SYSTEM\CurrentControlSet\Services\WinDriver6. ImagePath = \SystemRoot\system32\drivers\windrvr6.sys. Start = 3. ErrorControl = 1. Type=1. Cable connection failed. Connecting to cable (Parallel Port - LPT3). Checking cable driver. Your driver installation is not complete. Please re-run your application or run install_drivers.exe from the ISE installation area as an Administrator to complete the driver installation. Service using windrvr6.sys : SYSTEM\CurrentControlSet\Services\WinDriver6. ImagePath = \SystemRoot\system32\drivers\windrvr6.sys. Start = 3. ErrorControl = 1. Type=1. Cable connection failed. Connecting to cable (Parallel Port - LPT4). Checking cable driver. Your driver installation is not complete. Please re-run your application or run install_drivers.exe from the ISE installation area as an Administrator to complete the driver installation. Service using windrvr6.sys : SYSTEM\CurrentControlSet\Services\WinDriver6. ImagePath = \SystemRoot\system32\drivers\windrvr6.sys. Start = 3. ErrorControl = 1. Type=1. Cable connection failed. PROGRESS_END - End Operation. Elapsed time = 2 sec. Cable autodetection failed. WARNING:iMPACT:923 - Can not find cable, check cable setup ! Попытался: 1. Удалить Universal Scan. 2. Переустановить драйвера кабеля (в Vivado и в ISE). 3. Откатиться на Recovery Point до установки Universal Scan. Пока эффект нулевой. Кроме как переустановки ОС даже не знаю, что ещё попробовать. Осталось только убедиться, что кабель ещё действительно работает (но так как это удалённо, пока нет возможности). Может сталкивался кто с подобным поведением?

SDK и самодельные проги это конечно здорово и интересно, но как-то нету беджето-времени под это. В моём случае Win10-64bit, пока нет возможности проверить, если вдруг получится, отпишусь.

А можно пример/ссылку? Не совсем понимаю, о каком софте идёт речь. Вроде когда давно работал с тем же Universal Scan и для простейшего диагностирования/управления хватало возможностей программы. Очень надеюсь, что удастся сбрасывать Zynq используюя сигнал PS_POR_B. Да и банально пощупать состояние пина светодиода (т.к. физически увидеть это я не могу).

Здравствуйте. Есть кастомная плата, в JTAG цепочке Coolrunner CPLD (XC2C64A-7QFG48I) и Zynq-7000 (xc7z030fbg676-1): Для программирования испльзуется JTAG-HS2 Programming Cable: Поскольку работать с платой приходится удалённо, и есть определённые проблемы, хотелось для дебага продиагностировть/подёргать пины каким-нибудь JTAG Analyzer софтом. Попробовал пару попавшихся софтин (в триал режиме), и ни одна с этим типом кабеля не заработала. Может подскажет кто JTAG софт для данного HS2 кабеля? Может где поискать какие специфические библиотеки для данного кабеля или ещё чего?

Точно, недоглядел. Спасибо!

Vivado после синтеза/имплемента показывает окошко с опциями типа: Открыть синтезированный/имлементированный дизайн Показать репорты Что-то ещё (точно не помню)… И checkbox: «Запомнить выбранную опцию и больше не показывать это окно» Допустим выбрали опцию «Показать репорты» и запомнили этот выбор (галочку в checkbox). Больше окошко напоминание не показывается. Потом, появилась необходимость изменить на другую опцию (скажем «Открыть синтезированный дизайн»). Т.к. окно больше не показывается, то в нём этого сделать не можем. А где ещё эту настройку поменять? Перерыл GUI менюшки самого Vivado – вроде не нашлось таких опций. Может знает кто, в каких недрах (конфигурационный файл, реестр или ещё где) эти настройки хранятся, чтобы хи можно было бы изменить? Или может есть какие Tcl команды для чтения/изменения этих настроек.

В настройках синтеза пропишите mode -out_of_context

Если примменительно к симуляции в Modelsim, то можно передавать VHDL packages в Verilog/SystemVerilog (с некоторыми ограничениями и конвертацией типов). Называется это всё "Sharing User-Defined Types". Необходимый VHDL package нужно компилить с флагом -mixedsvvh. Пример из user manual:

Понятное дело, что при желании можно соорудить скрипты, которые всё будут причёсывать. Но меня интересовало, можно ли в Vivado изначально убрать это "тасование" (думал может какой простой настрокой можно сделать), чем городить огород. Опять таки для "ревизионности" это было бы полезно. Но судя по всему это невозможно.

Конкретно для одного случая, мне так было бы проще добавлять исходные файлы (и в дальнейшем с ними работать). Т.к. был уже готовый список в тектсовом формате и в нужном порядке.

Ладно, надо сделать перерыв, пока понятнее не становится. Но по крайней мере есть надежда, что раз кому-то это понятно, значит не всё потеряно . Ещё раз, спасибо за разъяснения.

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

За точку отсчёта в обоих случаях берётся фронт rd_en (T=585ns). Как это получается, что если FIFO сконфигурировано без выходного регристра, то rd_en защёлкивается при T=585ns (и выход появлятеся через 1 такт на T=595ns), а если сконфигурировано с выходным регистром, то абсолютно тот же rd_en защёлкивается на такт позже T=595ns? Как-то могут одни и те же одинаковые входные сигналы тактироваться в FIFO по разному?

Ну вот, как только кажется, что появилась ясность, и всё начало становиться на свои места, появляются новые затыки. Вот диаграмма чтения Common Clock FIFO 32x1024 Standard, без выходных регистров (т.е. выходная задержка 1 такт): Задержка между rd_en и dout как и ожидается =1 такт. Переконфигурировал FIFO и добавил выходной регистр (Output Registers = Embedded Registers). Ожидается, что задержка выходных данных увеличится на 1 такт, и будет составлять 2 такта (о чём и говорится в Summary на корку "Read latency = 2"). Однако в симуляции поджидает неприятный сюрприз: Как видим значение на выходе dout появляется через 2 такта + 100ps, т.е. 3 такта для синхронной логики. Как же так?

Действительно логично... Благодарю за "разжевывание".

Хм, действительно во 2-ом случае запись в момент T=16300ns, хотя я был уверен что на такт раньше, при T=16100. Пойду разбираться. Но при всё при этом, мне не понятно, почему при чтении из FIFO выходные данные не имеют эту задержку 100ps: Тут значение 0x1B появляется в момент 20300ns. Это для FIFO без выходных регистров. Ведь сама BRAM память синхронна и её выход должен быть с задержкой хотя бы в 1 такт (как это и указано в параметрах).

Я описал лишь один случай, но это применимо абсолютно ко всем выходным статусным сигналам FIFO (в том числе full и empty - они точно также задержаны на 100ps). Так что проблема не исчезает, если просто "закрыть на глаза". Тем более, что описываемый случай касается синхронного FIFO. И ни о каких передачах в другой домен речи не идёт. И ещё я упоминал, что стоит задача читать как можно раньше, чуть позже не вариант.

И всё-таки мне совершенно непонятно как работать с ядром. Вот для примера остановлюсь только на одном случае. Это диаграмма записи из первого сообщения, сгенерированного Vivado тестбенча с "искусственной" задержкой входных сигналов (wr_en, din) "after 50 ns": Насколько я понимаю, задержка между wr_en и data_count будет 1 такт. Т.е. синхронная логика "видит" значение сигнала wr_en на такте клока T=16300ns, а новое значение data_count=0x1 на следующем клоке T=16500ns. А теперь возьмём это ядро, и из Vivado тестбенча с "искусственными" задержками вставим в "реальный" проект. Входные сигналы wr_en, din и прочие контролируются синхронной логикой, и в функциональной симуляции не имеют никаких "искусственных" задержек "after XX ns". Тем не менее, т.к. ядро по прежнему выходные сигналы задерживает на 100ps получается что latency увеличивается. Т.е. получается, что (с точки зрения синхронной логики) задержка между wr_en и data_count будет 2 такта! Т.е. синхронная логика "видит" значение сигнала wr_en на такте клока T=16100ns, а новое значение data_count=0x1 по преженму клоке T=16500ns, т.е. через 2 такта. Обясните пожалуйста, где я не прав, или как это всё понимать.

Звучит логично, надо будет принять на вооружение. Правда не совсем понятно, как, скажем, поступать для Common Clock FIFO с общим сигналом data_count. Ведь в данном случае нет отедльных rd_data_count и wr_data_count для каждого клокового домена, т.к. клок общий. Искусственно создавать такие идентичные сигналы с "прицелом на асинхронное FIFO"? Согласен, для симуляции не важно, на сколько сигнал задержан. Если изменения произошли после фронта клока - то и защёлкиваться они будут на следующем клоке. Т.к. визуально эти 100ps заметить крайне сложно (поначалу я их просто не видел), это и приводит к ощущению, что данные защёлкиваются не на том клоке. Мне например по прежнему не понятно, почему для функциональной модели для задержки сигнала на 1 такт xilinx где-то использует эти 100ps (а где-то вроде полноценный такт).