Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Syn0psys BSD & SCAN
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Разработка цифровых, аналоговых, аналого-цифровых ИС
Nix_86
День добрый!

Собираюсь имплементировать проект. Применяю тулы 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
+1 Пришлось снижать тестовое покрытие (dont_touch на Tap и BS), поскольку после сканов check_bsd уже не проходит.
Если кто знает лучший рецепт, мне тоже будет любопытно услышать.

2. можно. Они ведь через hookup цепляются. Тул сам пробьет иерархию к ним, добавив новые порты и провода
Еще можно принудительно указать иерархию, куда располагать Тар и BS
Nix_86
Цитата(Shivers @ Mar 24 2017, 19:11) *
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
А Вы пробовали так делать?
Цитата из мануала говорит что
1) должны быть пады для всех портов
2) на каждый порт должен быть ровно один пад.
Про иерархию в этой цитате нет ни слова. Сигнальные пады не хукапятся, тул сам их ищет.

Очень сильная сторона DC по сравнению с тем же генусом, что DC может верилог для TAP+BSD выписать, а заодно топ-уровень со вставкой выше обозначенного. Чтобы это было красиво и корректно, надо чтобы пады были наверху, и чтобы в топе не было никакой логики. Другими словами, топ левел - verilog netlist. Я только с таким представлением и работаю. Но когда то делал эксперименты и с утопленными падами в иерархии, и вроде работало. Просто это очень криво, утапливать пады. Плохой стиль.
Nix_86
Цитата(Shivers @ Mar 24 2017, 20:41) *
А Вы пробовали так делать?

Нет, не пробовал. Пока нахожусь на завершающем этапе разработки RTL и неспешно продумываю детали синтеза, DFT, BSD.

Цитата(Shivers @ Mar 24 2017, 20:41) *
Про иерархию в этой цитате нет ни слова.

Когда пишут "top-level design", а не просто "design", волей-неволей представляется дизайн на конкретном уровене иерархии, в данном случае "верхнем".

Цитата(Shivers @ Mar 24 2017, 20:41) *
Я только с таким представлением и работаю.

Думаю придётся и мне вытащить это в TOP, чтобы
Цитата(Shivers @ Mar 24 2017, 20:41) *
это было красиво и корректно

Цитата(Shivers @ Mar 24 2017, 20:41) *
Просто это очень криво, утапливать пады. Плохой стиль.

Не спорю. На определенном этапе разработки при описании сущности модуля иногда удобно видеть пады, связанные с этой сущностью в этом же модуле. Не всегда этот модуль оказывается рядом с "топом", а пады при этом могут быть "продвинутыми", с большой кучей режимных входов (подтяжки к vdd, gnd, отключаемые глитч-фильтры, триггеры Шмитта и т.д.). Для управления всем этим приходится тащить шины наверх, перегружая промежуточные уровни иерархии вязанками проводов.
Shivers
По поводу стиля верхнего уровня, кажется в мануалах DC что то сказано про это - есть какой то даже стандарт IEEE, согласно которому верхний уровень это wrapper, содержащий пады, PHY и верхний уровень проекта (core).

Пока дизайн не готов, можете потренироваться на кошечках: где то в папке установки DC есть (раньше точно был) тьюториал с VHDL моделью риск-процессора, на которой предлагается освоить design vision. Дизайн содержит пару ошибок, но если их допилить, написать верхний уровень и вставить пады, то можно тренироваться дальше - вставлять DFT и т.д.

p.s. чтобы проще было протаскивать сигналы, переходите на SV, там есть т.н. интерфейсы. Правда, это ни разу не наглядно, на мой взгляд. И, если не ошибаюсь, раньше модуль лицензии DC для работы с SV стоил отдельных денег.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.