Поиск

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

Всем привет! При сборке проекта всплыл набор предупреждений вида (подформатировал, ибо в оригинале совсем нечитабельно): Суть недовольства САПР в следующем: инстанс корки PCIe содержит внутри блочную память, на входы блоков которой приходит сигнал из недр другой корки - сигнал empty прокинут (через логику) из FIFO, при этом флоп, с которого выходит этот empty, имеет тип FDPE, что в переводе на русский означает, что этот флоп типа "D Flip-Flop with Clock Enable and Asynchronous Preset", и это сильно не нравится синтезатору, о чём он сообщает. Формально он прав - нехорошо, когда асинхронный сброс (пресет) используется - вдруг глитч на сигнале сброса... со всеми вытекающими. Но смотрю, откуда приходит сигнал сброса (пресета), а он приходит с другого флопа, который имеет тип FDRE (D Flip-Flop with Clock Enable and Synchronous Reset), т.е. никаких глитчей быть не может - флоп строго синхронен общему клоку данного домена. Вопрос: а чего он тогда ругается-то? Или у него просто не хватает глубины анализа? И второй вопрос: как быть? Оставить, как есть? Вроде оно безопасно, но неприятный варнинг портит настроение. Или всё же есть способ забороть корректно? P.S. Корка FIFO по умолчанию имеет настройку параметра Reset Type как Asynchronous. Попытался изменить на синхронный тип, появились два раздельных входа ресета (для обоих тактовых доменов - FIFO сконфигурировано с независимыми клоками), но картина не поменялась. Внутри корки флоп сигнала empty по-прежнему имеет тип FDPE, и варнинг, естественно, не уходит. Так понял, что тип сигнала сброса не влияет на реализацию отдельных логических частей, а влияет только на поведение корки в смысле внешнего ресета.