Jump to content

    

Vengin

Свой
  • Content Count

    116
  • Joined

  • Last visited

Everything posted by Vengin


  1. Здравствуйте. Есть кастомная плата с xc7z030fbg676-1. Из-за ограниченного количества PS MIO на пины MIO40-45 на схематике заведено 2 интерфеса (SDIO и SPI) через внешний mux/demux: Вопрос, можно ли обоими интерфейсами пользоваться "статически" или "динамически"? "Статически" - это на одну прошивку один интерфейс. "Динамически" - это в рамках одной прошивки менять тип PS MIO интерфейса на лету. Насколько я понимаю конфигурация PS MIO выполняется за счёт настройки SLCR Registers (как в генерируемом файле ps_init.tcl). А можно ли эти регистры менять прямо из программы процессора? Смотрел ug585-Zynq-7000-TRM, но явного подвтерждения/опровержения пока найти не удалось.
  2. Там однако десятки-сотни программ - копать не перекопать. В примерах виденных ранее вроде не встречалось.
  3. Интересно. Но это всё применимо только для linux kernel. А для bare-metal тогда как? Кажется, что должна быть более низкоуровневая и универсальная возможность. Но в целом это всё предполагает, что переключение в принципе возможно. А вот как узнать наверняка ...
  4. 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] интерфейс выводится через коннектор на другую плату. Если прводить оба интерфейса по отдельности, может не хватить места в коннектере.
  5. А при чём тут FSBL, и исходники чего смотреть?
  6. Ну, если это можно делать программно, то это естественно проще чем переразводить плату. Да и вообще мне и самому интересено, насколько в этом плане гибока подсистема PS цинка.
  7. Об этом надо спрашивать человека занимавшегося схематикой. Видимо предполагалось, что всё надо "впихнуть" в MIO.
  8. Здравствуйте. Есть кастомная плата, в JTAG цепочке Coolrunner CPLD (XC2C64A-7QFG48I) и Zynq-7000 (xc7z030fbg676-1): Для программирования испльзуется JTAG-HS2 Programming Cable: Поскольку работать с платой приходится удалённо, и есть определённые проблемы, хотелось для дебага продиагностировть/подёргать пины каким-нибудь JTAG Analyzer софтом. Попробовал пару попавшихся софтин (в триал режиме), и ни одна с этим типом кабеля не заработала. Может подскажет кто JTAG софт для данного HS2 кабеля? Может где поискать какие специфические библиотеки для данного кабеля или ещё чего?
  9. После попытки установки 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. Пока эффект нулевой. Кроме как переустановки ОС даже не знаю, что ещё попробовать. Осталось только убедиться, что кабель ещё действительно работает (но так как это удалённо, пока нет возможности). Может сталкивался кто с подобным поведением?
  10. SDK и самодельные проги это конечно здорово и интересно, но как-то нету беджето-времени под это. В моём случае Win10-64bit, пока нет возможности проверить, если вдруг получится, отпишусь.
  11. А можно пример/ссылку? Не совсем понимаю, о каком софте идёт речь. Вроде когда давно работал с тем же Universal Scan и для простейшего диагностирования/управления хватало возможностей программы. Очень надеюсь, что удастся сбрасывать Zynq используюя сигнал PS_POR_B. Да и банально пощупать состояние пина светодиода (т.к. физически увидеть это я не могу).
  12. Vivado после синтеза/имплемента показывает окошко с опциями типа: Открыть синтезированный/имлементированный дизайн Показать репорты Что-то ещё (точно не помню)… И checkbox: «Запомнить выбранную опцию и больше не показывать это окно» Допустим выбрали опцию «Показать репорты» и запомнили этот выбор (галочку в checkbox). Больше окошко напоминание не показывается. Потом, появилась необходимость изменить на другую опцию (скажем «Открыть синтезированный дизайн»). Т.к. окно больше не показывается, то в нём этого сделать не можем. А где ещё эту настройку поменять? Перерыл GUI менюшки самого Vivado – вроде не нашлось таких опций. Может знает кто, в каких недрах (конфигурационный файл, реестр или ещё где) эти настройки хранятся, чтобы хи можно было бы изменить? Или может есть какие Tcl команды для чтения/изменения этих настроек.
  13. Если примменительно к симуляции в Modelsim, то можно передавать VHDL packages в Verilog/SystemVerilog (с некоторыми ограничениями и конвертацией типов). Называется это всё "Sharing User-Defined Types". Необходимый VHDL package нужно компилить с флагом -mixedsvvh. Пример из user manual:
  14. В Vivado в файле проекта *.xpr добавляемые файлы исходников выглядят прибизительно так: <File Path="$PPRDIR/file1.vhd"> <FileInfo> <Attr Name="UsedIn" Val="synthesis"/> <Attr Name="UsedIn" Val="simulation"/> </FileInfo> </File> <File Path="$PPRDIR/file2.vhd"> <FileInfo> <Attr Name="UsedIn" Val="synthesis"/> <Attr Name="UsedIn" Val="simulation"/> </FileInfo> </File> Только вот Vivado по своей инициативе меняет последовательность файлов (переставляет местами и тасует как заблагорассудиться). Это неудобно при корректировке *.xpr файла вручную (как в текстовый файл), сравнения изменений, ведения истории и т.п. Может можно как-то запретить эти вольности в *.xpr файле и "застолбить" последовательность файлов?
  15. Понятное дело, что при желании можно соорудить скрипты, которые всё будут причёсывать. Но меня интересовало, можно ли в Vivado изначально убрать это "тасование" (думал может какой простой настрокой можно сделать), чем городить огород. Опять таки для "ревизионности" это было бы полезно. Но судя по всему это невозможно.
  16. Конкретно для одного случая, мне так было бы проще добавлять исходные файлы (и в дальнейшем с ними работать). Т.к. был уже готовый список в тектсовом формате и в нужном порядке.
  17. Симулирую FIFO корку Vivado и что-то никак не удаётся получить ожидаемого поведения. Не совпадают результаты симуляции с тем, что описано в даташите (в частости latency выходных сигналов), и с тем, что ожидаешь увидеть. Когда много лет назад приходилось работать с FIFO ядром в ISE, не припомню таких трудностей. Совсем запутался, надеюсь коллективный разум поможет. Итак вводные: Vivado v2017.4 (64-bit), корка fifo_generator_v13_2_1. Генерим простейшее FIFO: Native (без AXI), Common Clock Block-RAM, 8x16, Standard Read Mode (т.е. не First Word Fall Through), без выходных регистров: Как видим, ожидаемая задержка чтения (данных) должна быть 1 такт. А задержка остальных выходных сигналов указывается в даташите (“Ch. 3: Designing with the Core” -> Latency -> Non-Built-in FIFOs: Common Clock and Standard Read Mode Implementations) : Т.е. вроде все остальные выходные сигналы в домене чтения (кроме prog_empty) должны иметь задержу 0 тактов. Хотя лично для меня это звучит странно, т.к. в моём понимании это сигналы «синхронные» (т.е. выходят с неких внутренних регистров ядра), и должны быть задержаны хотя бы на 1 такт. И эти догадки подтверждаются синтезом корки (на схематике выходные «статусные» выходят с регистров. В моём понимании это задержка минимум в 1 такт (или больше, в зависимости от общего количества регистров в каскаде). Уже это вызывает вопросы. Xilinx в даташите на FIFO описывает, как определяется Latency: Тут стоит сказать, что ИМХО такое изображение диаграмм (т.е. не как в function simulation, («синхронное, такт-в-такт»), а как в timing simulation (более «реалистичное» с учётом таких задержек, как setup/hold)) не только не помогает понять логику работы для функциональной симуляции, но скорее больше мешает, ухудшает восприятие и приводит к потенциальным ошибкам. По мне так эта диаграмма больше похожа на latency=1, а не 0. Так вот генерим в Vivado тестбенч для нашего простенького FIFO (правым кликом на IP-Core –> “Open IP Example Design…”). В сгенеренном Vivado тестбенче «имитируются» вышеупомянутые timing задержки, т.е на VHDL используются конструкции вида “… after XX ns”. Таким способом «задержаны» синхронный сброс (srst), входные сигналы записи/чтения (wr_en/rd_en) и входные данные записи (din). В данном случае период клока симуляции 200ns, задержки after = 50ns. И что же мы имеем в симуляции. Вот так выглядит запись в FIFO: А так чтение из FIFO: Сначала я долго не мог понять, что за 0.1ns на выходных сигналах (диаграмма чтения, 3-ий курсор, сигналы empty/data_count обновляются при T=16300.1ns). Покопавшись в даташите и инете, вроде пришёл к выводу, что так явно «имитируются» delta delay симуляции (и/или задержки синхронных сигналов в железе). В даташите (Ch. 4: Design Flow Steps -> Simulation -> Behavioral Model): И на форуме Xilinx: тыц (100 ps delay for Block Memory Generator 6.3) и тыц (BRAM output delay). Т.е. вроде эти 100ps должны быть «более наглядными» (если сравнивать с delta delay, которая в симуляции стремится к нулю), показывая, что «in hardware, it should never assume that synchronous data is available instantaneously with the active clock edge». Переварив всё это, я прихожу к выводу, что: На диаграмме записи задержка сигналов статуса чтения (empty, data_count) по отношению к wr_en вроде как 0 тактов (соответствует значениям в таблице 3-14). Хотя (как уже писалось раньше), эти сигналы вроде как выходят с регистров, и должны иметь задержку минимум 1 такт. На диаграмме чтения задержка сигнала данных (dout) по отношению к сигналу rd_en мне непонятна (получается ещё меньше, чем 0 тактов, т.к. нет 100ps, а исходя из вышеупомянутых параметров FIFO latency=1). При этом если сконфигурировать FIFO с выходным регистром (Embedded или Fabric в поле Output Register), то ожидаемая задержка latency=2 такта, а на диаграмме выход dout «свдигается» на всё те же 100ps (т.е. выравнивается со «статусными» выходными сигналами, что вроде как по описанию Xilinx соответствует задержке 0 тактов, а не 2). Но больше всего мне непонятно, как такие выходные сигналы (с задержкой на 100ps) «стыковать» с остальной частью логики, которая описана естественно без такого рода задержек, как просто «функциональная» схема или «синхронный» дизайн на логическом уровне. Т.е. елсли в проекте стыковать это FIFO ядро, на уровне функциональной симуляции, его входные управляющие сигналы (wr_en, wr_data) не будут иметь «имитируемую» задержку 'after XX ns'. Т.е к примеру диаграмма записи будет выглядеть так: Получается, что с точки зрения остальной «функциональной логики», выходные статусные сигналы empty и data_count будут иметь latency=2. Т.е. любой синхронный процесс «защёлкнет» значение empty/data_count после двух клоков от сигнала wr_en (в момент T=16500ns), т.к. после одного клока (T=16300ns) сигнал ещё не обновился из-за этих 100ps. В то же время у асинхронных процессов эти 100ps будут вызывать glitch-и, и тоже приводить к ошибкам. В конечном итоге, основые вопросы такие. Как работать в «функциональной» симуляции с таким ядром? И почему выходные задержки latency не соответствуют значениям указанным в datasheet? Понимаю, что решение должно быть, но мне оно пока не ясно. Извиняюсь, что так много букв получилось, но не знаю как всё это описать покороче. И это лишь простейший вариант конфигурации FIFO. А что уж будет, если надо использовать скажем разные клоковые домены, в режиме First-Word-Fall-Through, разные Aspect Ratios и т.п.
  18. Ладно, надо сделать перерыв, пока понятнее не становится. Но по крайней мере есть надежда, что раз кому-то это понятно, значит не всё потеряно . Ещё раз, спасибо за разъяснения.
  19. Нет я не прикалываюсь, я недоумеваю. Да, периодически при симуляции начинаешь ломать голову, когда же этот момент синхронизации происходит. И после долгих мучений вроде приходишь к некому консенсусу. Но в данном случае я решительно не понимаю, как абсолютно одинаковые входные данные могут трактоваться по разному. Это у меня в голове пока не укладывается... И как может добавление одного регистра увеличивать задержку на 2 такта?
  20. За точку отсчёта в обоих случаях берётся фронт rd_en (T=585ns). Как это получается, что если FIFO сконфигурировано без выходного регристра, то rd_en защёлкивается при T=585ns (и выход появлятеся через 1 такт на T=595ns), а если сконфигурировано с выходным регистром, то абсолютно тот же rd_en защёлкивается на такт позже T=595ns? Как-то могут одни и те же одинаковые входные сигналы тактироваться в FIFO по разному?
  21. Ну вот, как только кажется, что появилась ясность, и всё начало становиться на свои места, появляются новые затыки. Вот диаграмма чтения 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 такта для синхронной логики. Как же так?
  22. Действительно логично... Благодарю за "разжевывание".
  23. Хм, действительно во 2-ом случае запись в момент T=16300ns, хотя я был уверен что на такт раньше, при T=16100. Пойду разбираться. Но при всё при этом, мне не понятно, почему при чтении из FIFO выходные данные не имеют эту задержку 100ps: Тут значение 0x1B появляется в момент 20300ns. Это для FIFO без выходных регистров. Ведь сама BRAM память синхронна и её выход должен быть с задержкой хотя бы в 1 такт (как это и указано в параметрах).