реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Syn0psys BSD & SCAN
Nix_86
сообщение Mar 24 2017, 15:47
Сообщение #1


Частый гость
**

Группа: Свой
Сообщений: 83
Регистрация: 7-04-11
Пользователь №: 64 200



День добрый!

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

Спасибо!
Go to the top of the page
 
+Quote Post
Shivers
сообщение Mar 24 2017, 16:11
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 591
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950



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

2. можно. Они ведь через hookup цепляются. Тул сам пробьет иерархию к ним, добавив новые порты и провода
Еще можно принудительно указать иерархию, куда располагать Тар и BS
Go to the top of the page
 
+Quote Post
Nix_86
сообщение Mar 24 2017, 17:08
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 83
Регистрация: 7-04-11
Пользователь №: 64 200



Цитата(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 из первого поста.
Go to the top of the page
 
+Quote Post
Shivers
сообщение Mar 24 2017, 17:41
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 591
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950



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

Очень сильная сторона DC по сравнению с тем же генусом, что DC может верилог для TAP+BSD выписать, а заодно топ-уровень со вставкой выше обозначенного. Чтобы это было красиво и корректно, надо чтобы пады были наверху, и чтобы в топе не было никакой логики. Другими словами, топ левел - verilog netlist. Я только с таким представлением и работаю. Но когда то делал эксперименты и с утопленными падами в иерархии, и вроде работало. Просто это очень криво, утапливать пады. Плохой стиль.
Go to the top of the page
 
+Quote Post
Nix_86
сообщение Mar 25 2017, 08:25
Сообщение #5


Частый гость
**

Группа: Свой
Сообщений: 83
Регистрация: 7-04-11
Пользователь №: 64 200



Цитата(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, отключаемые глитч-фильтры, триггеры Шмитта и т.д.). Для управления всем этим приходится тащить шины наверх, перегружая промежуточные уровни иерархии вязанками проводов.
Go to the top of the page
 
+Quote Post
Shivers
сообщение Mar 25 2017, 10:33
Сообщение #6


Знающий
****

Группа: Свой
Сообщений: 591
Регистрация: 11-02-08
Из: Msk
Пользователь №: 34 950



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

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

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

Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 20th September 2017 - 20:09
Рейтинг@Mail.ru


Страница сгенерированна за 0.02975 секунд с 7
ELECTRONIX ©2004-2016