[Tausinov 0]

Добрый день!

Есть у кого-нибудь опыт чего-нибудь подобного? В случае положительного ответа, распишу в подробностях, с какой проблемой столкнулся.

[wolfman 0]

У нас есть. Рекофигурация используется для работы с различнми протоколами.

[Tausinov 0]

5 minutes ago, wolfman said:

Рекофигурация используется для работы с различнми протоколами.

Здорово, хотелось бы перенять опыт, если получится.

Суть такая: есть плата с ПЛИСиной, которая посредством PCIe цепляется к хосту и есть соответственно корка AXI Bridge для этого самого PCIe, используемая в режиме PR over PCIe. Соответственно есть желание иметь, как минимум, две рабочие конфигурации: 1) Статический дизайн, включающий само ядро PCIe, и минимальную логику поверх + реконфигурируемый модуль, прошивка этой части шьется на флэшку, откуда успешно грузится по SPI за время достаточное, чтобы PCIe линк успел подняться; 2) В этот самый реконфигурируемый модуль подгружать всю основную обработку, включая JESD для работы с АЦП и DDR.

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

Что сейчас является камнем преткновения? В основном реконфигурируемом модуле используются ядра JESD и соответствующий клок, который нужно завести на их вход. Имплементация родительской прошивки проходит, сама прошивка успешно генерится, а вот унаследованная от нее, содержащая основной реконфигурируемый модуль разводится, но при генерации прошивки выдает ошибку. Ругается как раз на этот самый клок, говорит, что логический порт не имеет указанного пользователем места... Хотя в констрейнтах это само собой присутствует и не мешает генерации первичной прошивки. Ячейки с трансиверами стопроцентов находятся в нужном pblock'е, констрейнты указаны. В логе единственный момент, связанный с данными портами, это как раз ошибка при генерации прошивки. Честно говоря, пока больше идей, что с этим делать нет. Если есть какие-то мысли, что попробовать или проверить, буду признателен.

[negiin 0]

в базовой конфигурации нужно сделать буферы на всех входных портах, даже если они не используются в ней. Чтобы регистры  сохранились, нужно использовать директиву синтеза noprune.

с клоком так же, нужно тактировать регистр noprune этим клоком

[RobFPGA 27]

Приветствую!

6 hours ago, Tausinov said:

...  Ругается как раз на этот самый клок, говорит, что логический порт не имеет указанного пользователем места...

Хотелось  бы  уточнить  тип FPGA.  US+  ?. 
И что значит  "не имеет места"?  Может лучше сам лог показать. Ну и чуть подробнее что за клок (ref для трансиверов, sync для JESD, ...).  

 

Удачи! Rob.

[warrior-2001 0]

День добрый!

Судя по описанию проблемы первый же совет должен решить вопрос.

6 часов назад, negiin сказал:

в базовой конфигурации нужно сделать буферы на всех входных портах, даже если они не используются в ней. Чтобы регистры  сохранились, нужно использовать директиву синтеза noprune.

с клоком так же, нужно тактировать регистр noprune этим клоком

 

[Tausinov 0]

10 hours ago, negiin said:

в базовой конфигурации нужно сделать буферы на всех входных портах, даже если они не используются в ней. Чтобы регистры  сохранились, нужно использовать директиву синтеза noprune.

с клоком так же, нужно тактировать регистр noprune этим клоком

Да, этот момент уже понял и применил еще до того, как вопрос задать. Клок подаю на IBUFDS_GTE3 с атрибутом (* dont_touch="true" *), в схематике разводки базовой конфигурации видно, что буфер присутствует. Так же пробовал подавать его на заглушку в виде PHY уровня JESD, корку, добавленную, чтобы "сделать буфер" для входов трансиверов.

10 hours ago, RobFPGA said:

Приветствую!

Хотелось  бы  уточнить  тип FPGA.  US+  ?. 
И что значит  "не имеет места"?  Может лучше сам лог показать. Ну и чуть подробнее что за клок (ref для трансиверов, sync для JESD, ...).  

 

Удачи! Rob.

Без плюса, просто US, но, судя по документации, возможность использования трансиверов в RM появилась как раз в US-семействе.

[DRC UCIO-1] Unconstrained Logical Port: 4 out of 17 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined.  To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.  Problem ports: lmx_ref_clk_n_i[1:0], and lmx_ref_clk_p_i[1:0].

Это был вольный перевод) С употреблением терминологии есть, конечно, определенные сложности...

Да, опора для трансиверов и он же через BUFG_GT на ядра JESD в качестве основного

 

 

 

 

[RobFPGA 27]

Приветствую.

27 minutes ago, Tausinov said:

Без плюса, просто US, но, судя по документации, возможность использования трансиверов в RM появилась как раз в US-семействе.

У меня практики PR для просто US еще не было. 
Но на сколько помню читал что PR для US и US+ отличаются и для US есть некоторые отличия.  

Кстати в доке по PR есть такая фраза 

Quote

During the Partial Reconfiguration flow, RMs are carved out using update_design -black_box. During this command any embedded IO buffers, and the associated constraints, such as PACKAGE_PIN and IOSTANDARD, are removed. When the black box RP is filled in with a new RM, these IOB constraints need to be reapplied to the design.

Хорошо бы убедится  что когда  разводится  RM часть все назначения пинов сохраняются (или применяются повторно).

 

Удачи! Rob.   

[Tausinov 0]

3 minutes ago, RobFPGA said:

У меня практики PR для просто US еще не было. 
Но на сколько помню читал что PR для US и US+ отличаются и для US есть некоторые отличия. 

Про US+ в этом плане ничего сказать не могу, не заострял внимания за отсутствием актуальности пока.

5 minutes ago, RobFPGA said:

Хорошо бы убедится  что когда  разводится  RM часть все назначения пинов сохраняются (или применяются повторно).

Насколько я понял, для перегружаемого RM нужно иметь отдельный файлик с констрейнтами, где обязательно должны присутствовать все моменты, связанные с внешними пинами. Так сейчас и делаю.

Пины все-все прямо не проверял, но как будто бы с этим все в порядке было. Сейчас сократил дизайн до минимума, по сути оставив только буфер для клока. Если смотреть назначение пинов, то в сборке основной конфигурации пин не является fixed, а package pin оказывает совершненно другим и не совпадает с констрейнтом заданным.

 

[RobFPGA 27]

Приветствую!

4 hours ago, warrior-2001 said:

в базовой конфигурации нужно сделать буферы на всех входных портах

IMHO это не обязательно, тем более это не всегда возможно так могут быть конфликты с типом буферов внутри RM (или с буферами внутри IP корок внутри RM). 
На  топе  можно просто указать для портов чтобы Vv не вставлял автоматом  IO буфера если эти порты не используются в static регионе. 

(* io_buffer_type = "none" *) input|output  wire port_name,

Но естественно тогда эти буфера надо будет вставлять в RM модуле уже  ручками.

 

Удачи! Rob. 
  
P.S.   Для US+ это работает но вот для US пока не проверялось. 

[Tausinov 0]

8 minutes ago, RobFPGA said:

Но естественно тогда эти буфера надо будет вставлять в RM модуле уже  ручками.

С буферами, вроде, разобрался. Если в топовом уровне не ставить их в явном виде, то вcтавки в RM достаточно, можно не добавлять. Основная проблема с этим как будто бы не связана

(* io_buffer_type = "none" *)

Хотя так  в какой-то степени нагляднее для тех, кто видит проект впервые.