[RobFPGA 27]

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

2 minutes ago, dxp said:

... Но Vivado там же (т.е. в директории src) генерит этот "мусор" (synth, sim). Вот ка бы это уносилось куда-нить в build, которая является целиком и полностью продуктом генерации, и там этому "мусору" (как также являющимся продуктом генерации) самое место. А src содержала бы только исходники, которые правятся руками.

Но какая  разница  если с .gitignore  все одно в репе все чисто будет? 

А  если хочется  идеальной чистоты  то в новых версиях Vv в  самом  BD  может быть поле  указывающее  на папку где  будет генерироваться рабочие файлы. Но не факт что  в старых версиях это поле тоже  есть.

"design": {
    "design_info": {
      "boundary_crc": "0x4A55E2C8E251BAA3",
      "device": "xcvu9p-fsgd2104-2-e",
      "gen_directory": "../../../../proj_name.gen/sources_1/bd/bd_name",
      "tool_version": "2020.2",
     .... 

   

Удачи! Rob.

[fguy 4]

5 часов назад, dxp сказал:

Для того, чтобы схематика не слетала, там надо ещё директорию ui (в ней файлик с кодированными именем и расширением .ui) тащить вместе с файлом .bd.

Еще нужна папка ip c файлами xci, в которых прописаны параметры используемых в бд ядер - по крайней мере в 2021.1 ее оставляют в папке srcs и в файле *.bd на них ссылаются.

[RobFPGA 27]

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

2 hours ago, fguy said:

Еще нужна папка ip c файлами xci,

Вот как раз это вроде как необязательно в  Vv2020.  То есть только  .bd  вроде  достаточно чтобы  при  generate_target all ...  воссоздать папку  ip со всеми корками используемыми  на этой BD.  Но это не проверялось на всем разнообразии возможных BD. 

 

Удачи! Rob. 

[dxp 32]

4 часа назад, fguy сказал:

Еще нужна папка ip c файлами xci, в которых прописаны параметры используемых в бд ядер - по крайней мере в 2021.1 ее оставляют в папке srcs и в файле *.bd на них ссылаются.

При добавлении файла bd в проект, оно само создаёт IP (xci файлы). Vivado 2018.2.

[fguy 4]

1 час назад, RobFPGA сказал:

Вот как раз это вроде как необязательно в  Vv2020.

Попробовал на 2021.1 исключить всю папку ip из bd - сломался миг ддр3, вернул только подпапку с миг-ом в ip (там xci и пара prj) - бд открылась нормально - параметры у ядер на месте, проверка бд проходит без ошибок, запуск генерации "продукта" с поядерным синтезом то же выполнилась. Итого в новом формате папка ip с xci и доп файлами все же нужна, либо проверяйте сами каким еще ядрам такая чистка может навредить - xilinx решил по простому оставить все.

1 минуту назад, dxp сказал:

При добавлении файла bd в проект, оно само создаёт IP (xci файлы). Vivado 2018.2.

В старых версиях они так же нужны, но так же не для всех ядер и при выполнении для бд команды "reset output product" вивада оставляет только xci, а нагенеренный мусор удаляет - в новом формате проекта его держат в папке *.gen.

[dxp 32]

Что-то геморная штука эти bd, как я посмотрю. А в чём цымес, так сказать? Экономия на вводе? Так в хорошем программерском текстовом редакторе оно и поудобнее будет и, побыстрее. И всё равно ведь потом враппер текстовый подключать, а там этот архаичный Verilog с множеством портов (вместо удобных SV интерфейсов), тоже писанины прилично и, главное, поле для ошибок немалое (пропустишь сигнал или не туда подключишь).

 

Наглядность? Тоже сомнительно, особенно если учесть, что при любом телодвижении норовит перерисовать схему.

 

Ну, и проприетарное решение, переносимости ноль.

 

И в завершение проблемы с повторяемостью при переносе в другой проект и сохранением в системах контроля версий.

 

За что боремся?

[fguy 4]

4 минуты назад, dxp сказал:

За что боремся?

В первую очередь есно за наглядность и структурированность большого проекта. На vhdl видел обе крайности - все-в-одном и "бесконечное" дерево - оба представляют собой сомнительное удовольствие для написания ручками, а про наглядность можно и не упоминать - ее тут просто нет. БД это по факту красивая надстройка над проектом типа "бесконечное" дерево, только ползать по нему самому не надо. Редактор бд все еще желает лучшего, но он намного удобнее и функциональнее "списка" с микроблэйзом в ISE. Валидация бд то же полезна, но к сожалению не всегда видит косяки и цепляется там где не должна. Для облегчения сохранения в гитах в последних вивадах сделан огромный шаг - надеюсь не последний. Про непереносимость - даже классический vhdl не всегда легко перенесется с хilinx на альтеру, да и между поколениями плис можно легко что-нибудь словить. Недавно разбирал проект от известной фирмы для их новых чипов - проект универсальный под обе оболочки - виваду и альтеру, но программер такое ощущение вылез из пещеры с ISE и пытался использовать виваду как привык - в бд были такие финты наделаны, что я был в шоке - то что можно было сделать штатными ядрами зачем то делалось на ртл без всякой надобности.

С враппером в виваде все достаточно просто - язык на выбор - vhdl или verilog, а если имена пинов не полениться и присвоить одни и те же в бд и констрэйнах, то и писать его не надо - разок сгенерить - дальше само автоматом.

[RobFPGA 27]

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

31 minutes ago, dxp said:

Что-то геморная штука эти bd, как я посмотрю.

Да  уж проблем хватает. 
На сколько помню изначально  это был стартап оболочки для быстрой разработки проектов "наброской" готовых кубиков на BD. И автоматической  генерации кода внутри BD со сквозным распространением параметров и их валидацией.  Но такая концепция требует много проверок и взаимосвязей  при  усложнении дизайна и иерархии. Отсюда IMHO и ограничения на тип сигналов на портах и такие тормоза  при работе с BD.

Ну а проблемы со сложностью  коннекта  к блокам BD можно обойти макросами и некоторой само-организаций (для V/SV). У меня давно уже многие стандартные  шины  к BD конектятся так 

module my_name ( 
  `AXI4L_PORT_SLAVE(s_ctrl, 20, 32),
   ...
);

  `AXI4L_WIRE_BUS(m_tcp0_ctrl  16, 32, s_ctrl_aclk, s_ctrl_aresetn);
  `AXI4L_WIRE_BUS(m_tcp1_ctrl, 16, 32, s_ctrl_aclk, s_ctrl_aresetn);
   ...
  `AXI4_WIRE_BUS(m_0_axi, 40, 256, 4, 0, axi_aclk, axi_aresetn);
  ...
    
  usr_sys_bd i_usr_sys_bd (
    .S00_aclk     (s_ctrl_aclk   ),
    .S00_arstn    (s_ctrl_aresetn),
    //
    `AXI4L_PORT_CONNECT_NOCR(S00,         s_ctrl),
    `AXI4L_PORT_CONNECT_IF_NOCR(M01, if_dma_ctrl), 
    `AXI4L_PORT_CONNECT_IF_NOCR(M02, if_prc_ctrl),  
    `AXI4L_PORT_CONNECT_NOCR(M03,    m_tcp0_ctrl),  
    `AXI4L_PORT_CONNECT_NOCR(M04,    m_tcp1_ctrl),  
    `AXI4L_PORT_CONNECT_NOCR(M06,    m_phy0_ctrl),  
    `AXI4L_PORT_CONNECT_NOCR(M07,    m_phy1_ctrl),  
    //
    .S00_AXI_aclk (axi_aclk   ),
    .S00_AXI_arstn(axi_sresetn),
    //
    `AXI4_PORT_CONNECT_NOCR(S00_AXI,  s_axi,   0),
    `AXI4_PORT_CONNECT_NOCR(M00_AXI,  m_0_axi, 0),
    `AXI4_PORT_CONNECT_NOCR(M01_AXI,  m_1_axi, 0) 
  );

          

Удачи! Rob. 

[dxp 32]

3 минуты назад, fguy сказал:

В первую очередь есно за наглядность и структурированность большого проекта.

Вы top на bd оформляете?

 

Я как помню, вроде как основное преимущество bd озвучивали то, что можно быстро скидать модуль из готовых отлаженных блоков, и уже его враппер подключать к проекту. Но как-то мне не показалось, что на bd получается быстрее, чем текстом, если использовать не портянки портов, а упаковывать это всё в SV интерфейсы.

 

Есть случаи, когда без bd просто в принципе не обойтись? Ну, скажем, на SoC'ах PS или это тоже можно без bd сделать?

[RobFPGA 27]

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

15 minutes ago, dxp said:

Вы top на bd оформляете?

У меня  top всегда  RTL .  А BD использую по мере необходимости как модули в иерархии.  Но многие  делают BD как топ, особенно если есть готовый board_file  шаблон.  

15 minutes ago, dxp said:

Есть случаи, когда без bd просто в принципе не обойтись? Ну, скажем, на SoC'ах PS или это тоже можно без bd сделать?

Тенденция  однако печальная.  Некоторые  IP корки  присутствуют только для использования на BD (IP integration only). Часто  связанно это с наличием в этих  корках  скриптов которые генерят BD динамически во время этапа validation.  Некоторые  чисто RTL корки (как например AXI interconnect RTL v1.7 в 2020.2 )  уже  помечены как  Discontinued. 

 

Удачи! Rob.

[dxp 32]

1 минуту назад, RobFPGA сказал:

Тенденция  однако печальная.  Некоторые  IP корки  присутствуют только для использования на BD (IP integration only). Часто  связанно это с наличием в этих  корках  скриптов которые генерят BD динамически во время этапа validation.  Некоторые  чисто RTL корки (как например AXI interconnect RTL v1.7 в 2020.2 )  уже  помечены как  Discontinued. 

Ну, тогда, видимо, единственным корректным способом переноса остаётся экспорт/импорт tcl, и его же в реп и класть. 

[fguy 4]

3 минуты назад, dxp сказал:

Вы top на bd оформляете?

Это как бы самый правильный вариант - топ является враппером для бд, который связан с пинами плис через констрэйны - можно конечно топ и ручками писать если иначе никак, например, свести в кучу врапперы одной или нескольких бд и ряда других ядер или ртл. Сейчас вроде как сделали вложенные бд (DXP), но мне пока хватает и объединения блоков (hier) - средний проект это порядка 200 ip (включая фикции типа слайсов) и разом все на экран это уже перебор. Опять же многие вещи делаются автоматом во враппере бд - например, буфера для тристэйт пинов ядра SPI будут сгенерены вивадой - вам только названия сигналов согласовать с констрэйнами останется.

8 минут назад, dxp сказал:

 

Есть случаи, когда без bd просто в принципе не обойтись? Ну, скажем, на SoC'ах PS или это тоже можно без bd сделать?

Конечно можно, но все придется писать ручками - имхо садомазо будет еще то. Ну и я не знаю как будет (и будет ли) работать автоматический экспорт драйверов в сдк для ядер с AXI-интерфейсами для управления с процессора, да и сам конфиг процессора то же - возможно это только в бд работает.

12 минут назад, RobFPGA сказал:

Некоторые  IP корки  присутствуют только для использования на BD (IP integration only).

К сожалению есть и другие крайности - например, если захотите использовать нативный интерфейс вместо акси в ядре ддр, то эта фишка доступна только в ртл, а размещение ядра ддр4 там может привести к появлению на jtag второго микроблэйза из этого ядра, который вам совсем не сдался и его придется учитывать при сборе прошивки. Чем дальше в лес, тем толще глюки...

В последних вивадах заметил еще одну тенденцию - ядра для видео-обработки написаны на хлс и являются конфигурируемыми, что пока не доступно простым смертным.

[RobFPGA 27]

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

33 minutes ago, fguy said:

К сожалению есть и другие крайности - ...

Этого и следовало ожидать  -  автоматизация BD тянет за собой необходимость описания огромного числа интерфейсов,  опций и режимов конфигурации  и что более печально  валидации всех возможных  комбинаций которые пользователь может захотеть задать.  

Поэтом  и развивается в основном мейнстрим конфигурации IP ядер.  Ну  а желающие  могу прикрутить на BD свое IP с любым нативным интерфейсом, и "портами" легкого поведения  

Хорошо хоть то что в Vv есть гибкость в выборе как создавать себе  "трудности".  

 

Удачи. Rob.

[fguy 4]

59 минут назад, RobFPGA сказал:

Поэтом  и развивается в основном мейнстрим конфигурации IP ядер. 

Эта фишка была еще в ISE, а вивада принесла наглядность для больших проектов вместе с ростом плис. Знакомые кто работал с плис еще лет 20-25 назад вообще сидели в схематике - рисовали схему соединений элементов плис ручками - 100% заполняемость была обычной нормой. На горизонте уже очередная революция - версаль - разница его с предыдущими ZynqUS+ гораздо больше прогресса между первыми цинками и второй серией. Блок из 400 процов потребует принятия новых подходов к проектированию и программированию. Видимо xilinx пришел к выводу что универсальная матрица логики плис не всегда позволяет эффективно решать задачи, да и рост реальных частот обработки в них далек от желаемого, а ip с SSR слишком уж большие. В версалях обещают на фир-ах в блоке процов 600 МГц и в реальных проектах это частота будет сохраняться, т.к. блок процов не зависит от содержимого плисовой части. Хочешь-не-хочешь, а идти в ногу со временем приходится.

[dxp 32]

9 часов назад, fguy сказал:

Блок из 400 процов потребует принятия новых подходов к проектированию и программированию. Видимо xilinx пришел к выводу что универсальная матрица логики плис не всегда позволяет эффективно решать задачи, да и рост реальных частот обработки в них далек от желаемого, а ip с SSR слишком уж большие. В версалях обещают на фир-ах в блоке процов 600 МГц и в реальных проектах это частота будет сохраняться, т.к. блок процов не зависит от содержимого плисовой части. Хочешь-не-хочешь, а идти в ногу со временем приходится.

Версали разные бывают. В Prime и Premium этого нет. В серии AI - да. Но там главная фишка уже лежит просто в другой плоскости: векторные вычисления. Это просто ортогональная тема плисоводству, и там без соответствующего бэкграунда делать нечего. Но мощь, да, лютая.