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

Syn0psys BSD & SCAN

День добрый!

Собираюсь имплементировать проект. Применяю тулы 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?

Спасибо!

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


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

2. можно. Они ведь через hookup цепляются. Тул сам пробьет иерархию к ним, добавив новые порты и провода
Еще можно принудительно указать иерархию, куда располагать Тар и BS

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Shivers @ Mar 24 2017, 19:11) <{POST_SNAPBACK}>
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 из первого поста.

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


Ссылка на сообщение
Поделиться на другие сайты
А Вы пробовали так делать?
Цитата из мануала говорит что
1) должны быть пады для всех портов
2) на каждый порт должен быть ровно один пад.
Про иерархию в этой цитате нет ни слова. Сигнальные пады не хукапятся, тул сам их ищет.

Очень сильная сторона DC по сравнению с тем же генусом, что DC может верилог для TAP+BSD выписать, а заодно топ-уровень со вставкой выше обозначенного. Чтобы это было красиво и корректно, надо чтобы пады были наверху, и чтобы в топе не было никакой логики. Другими словами, топ левел - verilog netlist. Я только с таким представлением и работаю. Но когда то делал эксперименты и с утопленными падами в иерархии, и вроде работало. Просто это очень криво, утапливать пады. Плохой стиль.

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Shivers @ Mar 24 2017, 20:41) <{POST_SNAPBACK}>
А Вы пробовали так делать?

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

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

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

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

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

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
По поводу стиля верхнего уровня, кажется в мануалах DC что то сказано про это - есть какой то даже стандарт IEEE, согласно которому верхний уровень это wrapper, содержащий пады, PHY и верхний уровень проекта (core).

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

p.s. чтобы проще было протаскивать сигналы, переходите на SV, там есть т.н. интерфейсы. Правда, это ни разу не наглядно, на мой взгляд. И, если не ошибаюсь, раньше модуль лицензии DC для работы с SV стоил отдельных денег.

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


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

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

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

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

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

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

Войти

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

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