[dxp 32]

Всем привет!

 

Вот есть такой инструмент в 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, для каких проектов (всегда, никогда, только для больших и т.д.), на каких уровнях иерархии (только топ или какие-то внутренние куски иерархии) и вообще интересны мнения и оценки имеющих реальный опыт работы с этим.

[RobFPGA 27]

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

 

Увы - при работе с графикой  всегда есть свои плюсы и минусы. И оценка чего больше у каждого  сугубо индивидуальна. Проблемами красоты схем в 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.

 

 

[fguy 4]

 del

Изменено 28 декабря, 2018 пользователем fguy

[fguy 4]

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

 

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

 

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

 

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

 

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

Изменено 28 декабря, 2018 пользователем fguy

[Flip-fl0p 4]

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

[RobFPGA 27]

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

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  и отлавливая глюки при генерации из BD в rtl. Правда это давно уже было.

Удачи! Rob.

 

 

[fguy 4]

2 hours ago, RobFPGA said:

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

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

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

[dxp 32]

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

 

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

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

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

[RobFPGA 27]

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

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.

[Flip-fl0p 4]

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 постепенно уходит в прошлое...

[dmitry-tomsk 0]

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. При этом целый час вивадо заново всё имплементирует. Даже на пару десятков плат уже проблема ждать для обновления прошивок.

[RobFPGA 27]

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

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.

  

[Flip-fl0p 4]

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 минут на серверной машине имплементировать пару несложных ядер - это уж больно долго.

[andrew_b 14]

6 минут назад, Flip-fl0p сказал:

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

https://habr.com/post/353094/

[dmitry-tomsk 0]

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 файл, вивадо всю прошивку считает испорченной и заново запускает и синтез и имплементацию, а надо то только битстрим переделать.