scorp 0 24 марта, 2017 Опубликовано 24 марта, 2017 · Жалоба День добрый! Собираюсь имплементировать проект. Применяю тулы syn0psys. Возникла пара вопросов. 1. В какой очередности правильно выполнить DFT и BSD insertion? - если DFT ==> BSD, то сгенерированная BSD-логика будет несканируемой, что неизбежно снизит тестовое покрытие; - если BSD ==> DFT, то скан-цепи охватят всю логику, включая BSR + TAP, однако участие BSR ячеек в ATPG-тесте свалит его. Думаю в этом случае можно запретить логике BSR и(или) TAP участвовать в создании скан-цепей (dont_touch), но опять же ценой снижения тестового покрытия. Интересуют общепринятые подходы. Syn0psys предлагает user guides на каждый тул по отдельности, но информации об очередности их применения и нюансах не нашёл. 2. Пады в дизайне собраны в отдельном модуле (не в TOP). Можно ли рассказать BSD Compiler о том, где они есть? Или же они обязательно должны быть в TOP? Спасибо! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 24 марта, 2017 Опубликовано 24 марта, 2017 · Жалоба +1 Пришлось снижать тестовое покрытие (dont_touch на Tap и BS), поскольку после сканов check_bsd уже не проходит. Если кто знает лучший рецепт, мне тоже будет любопытно услышать. 2. можно. Они ведь через hookup цепляются. Тул сам пробьет иерархию к ним, добавив новые порты и провода Еще можно принудительно указать иерархию, куда располагать Тар и BS Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scorp 0 24 марта, 2017 Опубликовано 24 марта, 2017 · Жалоба 2. можно. Они ведь через hookup цепляются. Тул сам пробьет иерархию к ним, добавив новые порты и провода Еще можно принудительно указать иерархию, куда располагать Тар и BS Спасибо. В данном случае речь не только о JTAG-падах, но и об остальных функциональных. Можно ли через hookup рассказать о них BSD compiler'у, чтобы он их нашёл и правильно соединил с BS-ячейками? Если да, то как? В user guide на BSD Compiler в разделе Design Requirements есть пункт: 2. The top-level design must have I/O pad cells for all functional ports. The pad cells must be linked to the core design pins. There must be a one-to-one correspondence to top-level ports and core pins В связи с этим и возник вопрос №2 из первого поста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 24 марта, 2017 Опубликовано 24 марта, 2017 · Жалоба А Вы пробовали так делать? Цитата из мануала говорит что 1) должны быть пады для всех портов 2) на каждый порт должен быть ровно один пад. Про иерархию в этой цитате нет ни слова. Сигнальные пады не хукапятся, тул сам их ищет. Очень сильная сторона DC по сравнению с тем же генусом, что DC может верилог для TAP+BSD выписать, а заодно топ-уровень со вставкой выше обозначенного. Чтобы это было красиво и корректно, надо чтобы пады были наверху, и чтобы в топе не было никакой логики. Другими словами, топ левел - verilog netlist. Я только с таким представлением и работаю. Но когда то делал эксперименты и с утопленными падами в иерархии, и вроде работало. Просто это очень криво, утапливать пады. Плохой стиль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scorp 0 25 марта, 2017 Опубликовано 25 марта, 2017 · Жалоба А Вы пробовали так делать? Нет, не пробовал. Пока нахожусь на завершающем этапе разработки RTL и неспешно продумываю детали синтеза, DFT, BSD. Про иерархию в этой цитате нет ни слова. Когда пишут "top-level design", а не просто "design", волей-неволей представляется дизайн на конкретном уровене иерархии, в данном случае "верхнем". Я только с таким представлением и работаю. Думаю придётся и мне вытащить это в TOP, чтобы это было красиво и корректно Просто это очень криво, утапливать пады. Плохой стиль. Не спорю. На определенном этапе разработки при описании сущности модуля иногда удобно видеть пады, связанные с этой сущностью в этом же модуле. Не всегда этот модуль оказывается рядом с "топом", а пады при этом могут быть "продвинутыми", с большой кучей режимных входов (подтяжки к vdd, gnd, отключаемые глитч-фильтры, триггеры Шмитта и т.д.). Для управления всем этим приходится тащить шины наверх, перегружая промежуточные уровни иерархии вязанками проводов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 25 марта, 2017 Опубликовано 25 марта, 2017 · Жалоба По поводу стиля верхнего уровня, кажется в мануалах DC что то сказано про это - есть какой то даже стандарт IEEE, согласно которому верхний уровень это wrapper, содержащий пады, PHY и верхний уровень проекта (core). Пока дизайн не готов, можете потренироваться на кошечках: где то в папке установки DC есть (раньше точно был) тьюториал с VHDL моделью риск-процессора, на которой предлагается освоить design vision. Дизайн содержит пару ошибок, но если их допилить, написать верхний уровень и вставить пады, то можно тренироваться дальше - вставлять DFT и т.д. p.s. чтобы проще было протаскивать сигналы, переходите на SV, там есть т.н. интерфейсы. Правда, это ни разу не наглядно, на мой взгляд. И, если не ошибаюсь, раньше модуль лицензии DC для работы с SV стоил отдельных денег. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться