Перейти к содержанию

    

Vivado Block Diagram, насколько удобно, необходимо...

Всем привет!

 

Вот есть такой инструмент в Vivado как Block Diagram Editor, что делает в целом понятно - позволяет организовывать межсоединения между блоками/модулями/ядрами в наглядной графической форме. Мне как-то до сих пор подобные инструменты не очень пригождались - помнится, ещё на Active-HDL пробовал топ делать с помощью такой вот схемы (блок диаграммы), поначалу понравилось, но потом энтузиазм поугас - как-то многовато телодвижений лишних (чуть что поправить - эн мелких правок в разных местах), а главное, когда диаграмма становится большой, то уже линии соединений скорее мешают, чем помогают, и проще их (соединения) не таскать шинами/проводниками, а оформлять метками, что уже в значительной степени нивелирует красоту и эффективность схемного представления... А потом я просто научился инстансы модулей оформлять так, что читабельность практически не уступает вот такому схемному с метками.

 

Но вот вижу, что Xilinx в своих примерах и design flow активно использует именно BD. Более того, обнаружил, что некоторые корки просто недоступны в виде отдельного ядра - например, AXI Interconnect инстанцируется только в BD, и отдельным ядром OOC его сделать нельзя, хотя его составные компоненты - Crossbar, Clock Converter, Data Width Converter и прочие, - вполне можно получить виде отдельных ядер и подключить их к проекту как обычно. Кроме того, насколько знаю, тяжёлые ядра типа Microblaze или Zynq подключаются к проекту тоже только через BD.

 

И вот возникает вопрос: насколько это нужный и полезный инструмент в повседневной работе? Попытаюсь изложить в меру своего понимания темы плюсы и минусы BD'шного подхода.

 

Плюсы:

  • Наглядность межсоединений. Хотя при росте схемы она резко падает. Может немного спасти ведение иерархии - чтобы на каждом уровне было вменяемое количество "кубиков" и их связей, но и тут есть засада - при большом проекте возрастает количество уровней иерархии, что затрудняет навигацию и вообще мысленный охват проекта.
  • Возможность лёгкого манипулирования большим количеством портов, группируя их в шины - как, например, сигналы AXI шины.
  • Средства автоматизации - редактор BD автоматически отслеживает неподключенные порты и устанавливает на них значения по умолчанию.

Минусы:

  • Некоторое усложнение проекта - ещё один уровень выше HDL.
  • Не все типы файлов поддерживаются - например, .sv исходники не поддерживаются, только .v, .vhd, т.е. если у меня код на SystemVerilog, то для того, чтобы из модуля родить "кубик" для BD, мне нужно сделать специальный файл-обёртку вокруг исходного модуля.
  • Хуже переносимость. Если HDL сорцы можно напрямую передавать в другой проект на синтез и симуляцию, то с файлом диаграммы уже не так просто - сам этот файл вне среды САПР Vivado никому не нужен, а если сгенерить по нему исходник, то он получается в не очень читабельном и сопровождабельном руками виде.

 

Для меня в первую очередь значимым является способность легко и просто работать с портами. И вот если бы редактор BD умел извлекать из SV интерфейсов сигналы (а лучше бы просто использовал их как есть), то это было бы очень круто! Но идея с файлом-обёрткой на Verilog как-то не очень греет. Для сугубо вериложных файлов BD, наверное, и даёт заметный профит - автоматом подхватывает все сигналы модуля и всё хорошо, но в SV есть замечательная штука - интерфейсы, которые позволяют свести количество портов модуля к минимуму, сделать использование сигналов портов простым и безопасным, а кроме этого ещё и местами нетривиальную логику завернуть внутри интерфейса. И вот тут-то пожалуй главный профит BD нивелируется и превращается балласт (необходимость городить врапперы вокруг модуля и руками мапить сигналы интерфейсов на порты модуля-обёртки).

 

Вопросы внешнего вида (наглядности, лёгкости восприятия и удобства модификации) на HDL вполне решаются стилем форматирования экземпляров модулей, а поддержка интерфейсов позволяет легко получить компактные описания.

 

В общем, пока не понял хорошенько, в чём профит BD, какие у него есть киллер-фичи. Но ведь широко используют, и это, наверное, неспроста. Прошу высказываться по теме - что сказано верно, а что нет, что-то упущено, а что-то наоборот "в точку". Кто пользуется BD, для каких проектов (всегда, никогда, только для больших и т.д.), на каких уровнях иерархии (только топ или какие-то внутренние куски иерархии) и вообще интересны мнения и оценки имеющих реальный опыт работы с этим.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Увы - при работе с графикой  всегда есть свои плюсы и минусы. И оценка чего больше у каждого  сугубо индивидуальна. Проблемами красоты схем в Vivado особенно не заморачиваются -  не до этого пока. Тут конечно Vivado тяжело сравнивать с ActiveHDL или HDLdesigner.

 

В дизайне BD у Xilinx основная киллер-фича это - и так сойдет по быстрому накидать готовых кубиков. Ну и  формирование BD через tcl api - то есть автоматическая "рисовка". Вот именно из за этого некоторые корки и не доступны в RTL. Потому что по сути они есть BD автоматически сгенерированные скриптами в зависимости от заданных параметров самой корки а также текущих параметров других корок на BD (получается динамическая конфигурация). В RTL тоже можно самому сваять аналог таких "солянок" обычными RTLными средствами (то же AXI Interconnect состоит из отдельных вполне RTLных IP). 

 

IMHO при работе с BD в Vivado  нужно выработать определенные шаблоны применения удобные для вас.  Я например никогда не делаю BD как топ. Топ у меня всегда RTL. Так же пока не пытаюсь  активно  тянуть RTL в BD. Скорее наоборот - если нужно по быстрому модуль  со стандартными  кубиками - набросал в BD (или скриптом с параметрами) и вставил в свой RTL. Ну а что бы не  страдать в RTL подключением сотен строк портов (в основном для AXI интерфейсов)  либо использовать шаблоны в редакторе, либо я например сделал свой аналог интерфейсов на макросах :).  Поэтому в RTL подключение AXI у меня выглядит так:

`AXI4_WIRE_BUS(s_vfifo_data, VFIFO_ADDR_WH, VFIFO_DATA_WH, VFIFO_ID_WH, 0, ddr4_200_clk, ddr4_200_arstn);
`AXI4L_WIRE_BUS(m_vfifo_ctrl, AXIL_ADDR_WH, 32, ctrl_aclk, ctrl_arstn);

pcie_sys_bd i_pcie_sys (

`AXI4L_PORT_CONNECT(M00_AXIL, m_vfifo_ctrl),

`AXI4_PORT_CONNECT(S00_AXI,  s_vfifo_data, 0),
..

 

 Фактически наличие tcl API для рисовки есть большой плюс для автоматизации некоторых процессов - но это же и убивает саму суть параметров в RTL. Но это так же позволяет вам дописать отсутствующий функционал  в Vivado самому - например можно автоматом парсить те же sv интерфейсы и создавать из них interface definitions и врапперы для использования в BD. 

 

Удачи! Rob.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 del

Изменено пользователем fguy

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пользуюсь только BD с самого появления вивады (2014). Поначалу были неудобства в необходимости "ручками" раскидывать ресеты - в исе для микроблэйза это делалось автоматом. Далее с усложнением проектов стало понятно что древовидная структура в исе превратится в "дикий ужос" когда число ядер в проекте достигнет хотя бы 30-40. Сейчас в проектах число ядер доходит до 200 (по инфе вивады). Соединить это все в виде легко читаемого текста на VHDL просто не реально, а уж оперативно что то поправить и подавно.

 

Ядро AXI Interconnect это не совсем "ядро" - это сборка из ядер которая формируется динамически из более мелких кубиков в зависимости от настроек конфигурации. Вы можете собрать ее сами, но удовольствие будет еще то. "Ядро" гигабитного эзернета это так же такая же сборка. Изменить их ручками нельзя - зато можно легко скопировать копи-пастом в свой Hierarchy.

 

Если вы хотите использовать в БД свои исходники то оформляйте их как ядра вивады и сможете оперировать ими в БД.

 

Сигналы интерфейсов коннектятся по именам с констрэйнами для физических пинов без всяких доп. оберток в виде топа на VHDL, а так же доступны ядра для установки ручками всяких буферов (BUFG и т.п.). Тристэйты во враппере БД автоматом прогоняются через буфера и становятся обычными inout.

 

Копировать БД между проектами штатными средствами (через буфер копи-пастом или вивадой) возможности к сожалению нет, а ручками делается все просто - копируем папку ваш_проект.srcs\sources_1\bd\ваш_бд в другой проект в это же место и добавляем ссылку на него в файл "имя_проекта.xpr" в корне проекта. Далее открываем измененный проект и через буфер копи-пастом переносим что нужно между БД.

Изменено пользователем fguy

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дурацкая рисовалка. Постоянно после обновления модуля ставит мне инверсию на сброс. Приходится руками ставить правильный активный уровень сброса. Генерация hdl wrapper - за гранью добра и зла - умеет только в std_logic_vector.  Модули, написанные а vhdl2008 вообще запрещает вытаскивать на блок схему. Я пока только начал работать с vivado - но пока у меня сложилось ощущение, что этот софт создан для того чтобы инженеру было неуютно с им работать....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

44 minutes ago, Flip-fl0p said:

Дурацкая рисовалка. Постоянно после обновления модуля ставит мне инверсию на сброс. Приходится руками ставить правильный активный уровень сброса. Генерация hdl wrapper - за гранью добра и зла - умеет только в std_logic_vector.  Модули, написанные а vhdl2008 вообще запрещает вытаскивать на блок схему. Я пока только начал работать с vivado - но пока у меня сложилось ощущение, что этот софт создан для того чтобы инженеру было неуютно с им работать....

Eще раз IMHO - DB в Vivado не затачивалось для разработки схем со сложным миксом пользовательского уникального RTL (меняющегося по 20 раз на день) и корок в формате IP-XACT.  Основная концепция BD в Vivado  -  конструктор из стабильных "кубиков" оформленных как IP-XACT с  использованием стандартных или заранее определенных пользователем интерфейсов. И некая автоматизация конфигурации при этом. Отсюда и бедность инструментов для работы в BD. 

Ну а глюки есть в каждом инструменте. Хорошо что вы не слышали как у меня были "ощущения" матом рисуя схемы в ActiveHDL :yes3: и отлавливая глюки при генерации из BD в rtl. Правда это давно уже было.

Удачи! Rob.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 hours ago, RobFPGA said:

Основная концепция BD в Vivado  -  конструктор из стабильных "кубиков" оформленных как IP-XACT с  использованием стандартных или заранее определенных пользователем интерфейсов.

У меня окромя штатных ядер еще пара десятков своих на хлс-е и немного VHDL-ядер и все это интенсивно правится без особых проблем. Вивада при открытом БД отслеживает изменения ядер в папке репозитория и оповещает об этом с предложением обновиться, при изменениях в интерфейсах для обновленных ядер выдается предупреждение. Так что работать над проектом вполне себе удобно. Крупный проект разбивается на функциональные блоки Hierarchy, что избавляет от огромной портянки с сотней ядер в одном окне.

Косяки конечно же есть как и везде - верификатор видит далеко не все проблемы, при верификации тупо упирается в несоответствие типов данных на входных стримах для IP floating_point - имхо достаточно было бы проверять ширину, жуткие тормоза при конфигурировании IP FFT и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо большое всем за ответы!

 

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

Я например никогда не делаю BD как топ. Топ у меня всегда RTL. Так же пока не пытаюсь  активно  тянуть RTL в BD. Скорее наоборот - если нужно по быстрому модуль  со стандартными  кубиками - набросал в BD (или скриптом с параметрами) и вставил в свой RTL.

А вставляете этот фрагмент, изготовленный с помощью BD, сгенерив RTL код для него или в виде корки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

1 hour ago, dxp said:

...

А вставляете этот фрагмент, изготовленный с помощью BD, сгенерив RTL код для него или в виде корки?

Так код из BD в любом случае генерируется. Когда сделали BD то можно получить для него RTL враппер  через меню  или командой -

make_wrapper -inst_template -files [get_files pcie_sys_bd.bd] -fileset [get_filesets sources_1] 

Получите pcie_sys_bd_wrapper.v (или .vhd в зависимости от текущего значения параметра TARGET_LANGUAGE). Ну а там либо сам враппер вставляете, либо непосредственно rtl инстанс BD из враппера (чтобы меньше лишней иерархии было).  

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, RobFPGA сказал:

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

Так код из BD в любом случае генерируется. Когда сделали BD то можно получить для него RTL враппер  через меню  или командой -

make_wrapper -inst_template -files [get_files pcie_sys_bd.bd] -fileset [get_filesets sources_1] 

Получите pcie_sys_bd_wrapper.v (или .vhd в зависимости от текущего значения параметра TARGET_LANGUAGE). Ну а там либо сам враппер вставляете, либо непосредственно rtl инстанс BD из враппера (чтобы меньше лишней иерархии было).  

Удачи! Rob.

Вот только с vhdl враппер не дружит. Вернее дружит только с типом std_logic_vector. При этом этот гад, даже если есть самописный модуль с другими типами, например std_ulogic_vector, создаст для них тип std_logic_vector и привет ошибки....

Я уж не гвоорю про типы bit_vector, natural... В итоге ты стараешься, создаешь систему типов, чтобы минимизировать число ошибок. Но в конце в итоге плюешь на все и пишешь все с типом std_logic_vector, либо пишешь "прокладку", убивая всю красоту строгой типизации VHDL. Вот прям обидно, что почти весь функционал по генерации HDL - ограничен только этим типом. Пойду изучать verilog, вернее System Verilog... Видно VHDL постепенно уходит в прошлое...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 hours ago, RobFPGA said:

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

Так код из BD в любом случае генерируется. Когда сделали BD то можно получить для него RTL враппер  через меню  или командой -

make_wrapper -inst_template -files [get_files pcie_sys_bd.bd] -fileset [get_filesets sources_1] 

Получите pcie_sys_bd_wrapper.v (или .vhd в зависимости от текущего значения параметра TARGET_LANGUAGE). Ну а там либо сам враппер вставляете, либо непосредственно rtl инстанс BD из враппера (чтобы меньше лишней иерархии было).  

Удачи! Rob.

А не подскажите tcl команду для шифрования прошивок? Платы у заказчиков с разными ключами, нужно как-то один проект сделать с множеством вариантов ключей. Я пока вручную xdc файл с ключом подключаю и запускаю generate bitstream. При этом целый час вивадо заново всё имплементирует. Даже на пару десятков плат уже проблема ждать для обновления прошивок.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

29 minutes ago, dmitry-tomsk said:

А не подскажите tcl команду для шифрования прошивок? Платы у заказчиков с разными ключами, нужно как-то один проект сделать с множеством вариантов ключей. Я пока вручную xdc файл с ключом подключаю и запускаю generate bitstream. При этом целый час вивадо заново всё имплементирует. Даже на пару десятков плат уже проблема ждать для обновления прошивок.

Не подскажу - так как у меня пока такой необходимости не было. Но может быть вам проще сохранить checpoint  .dcp после P&R, и потом работать только с ним? Загружаете  checpoint,  через tcl  меняете параметры BITSTREAM.ENCRYPTION*  и генерируете  новый bit файл.  И не надо каждый раз P&R  новый делать.

 

Вообще - самый огромный плюс в Viado по сравнению с ISE (да и наверное с Qu) в том что можно работать интерактивно на любой стадии P&R проекта. 

То есть загрузил checkpoint-netlist в память и можно делать с ним что хочешь.   Менять любые constraint, патчить netlist, интерактивно делать palce и route  частично или полностью откатывая назад  если что не понравилось. И при этом не надо по новой запускать полный цикл P&R!  Понятное дело это все в ручном режиме. При некоторой сноровке это сильно упрощает жизнь разработчику. 

 

Удачи! Rob.

  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, RobFPGA сказал:

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

Не подскажу - так как у меня пока такой необходимости не было. Но может быть вам проще сохранить checpoint  .dcp после P&R, и потом работать только с ним? Загружаете  checpoint,  через tcl  меняете параметры BITSTREAM.ENCRYPTION*  и генерируете  новый bit файл.  И не надо каждый раз P&R  новый делать.

 

Вообще - самый огромный плюс в Viado по сравнению с ISE (да и наверное с Qu) в том что можно работать интерактивно на любой стадии P&R проекта. 

То есть загрузил checkpoint-netlist в память и можно делать с ним что хочешь.   Менять любые constraint, патчить netlist, интерактивно делать palce и route  частично или полностью откатывая назад  если что не понравилось. И при этом не надо по новой запускать полный цикл P&R!  Понятное дело это все в ручном режиме. При некоторой сноровке это сильно упрощает жизнь разработчику. 

 

Удачи! Rob.

  

А есть где-нибудь обучалка этим вещам ?

Пока у меня от работы в Vivado только дергается глаз. 20 минут на серверной машине имплементировать пару несложных ядер - это уж больно долго.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, RobFPGA said:

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

Не подскажу - так как у меня пока такой необходимости не было. Но может быть вам проще сохранить checpoint  .dcp после P&R, и потом работать только с ним? Загружаете  checpoint,  через tcl  меняете параметры BITSTREAM.ENCRYPTION*  и генерируете  новый bit файл.  И не надо каждый раз P&R  новый делать.

 

Вообще - самый огромный плюс в Viado по сравнению с ISE (да и наверное с Qu) в том что можно работать интерактивно на любой стадии P&R проекта. 

То есть загрузил checkpoint-netlist в память и можно делать с ним что хочешь.   Менять любые constraint, патчить netlist, интерактивно делать palce и route  частично или полностью откатывая назад  если что не понравилось. И при этом не надо по новой запускать полный цикл P&R!  Понятное дело это все в ручном режиме. При некоторой сноровке это сильно упрощает жизнь разработчику. 

 

Удачи! Rob.

  

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация