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

синтез цифровой схемы: c падами или без?

Сижу и ломаю голову, как правильно было бы проводить синтез системы на кристалле: просто core-логику или ее же с прицепленными падами. Пока вижу такие особенности дизайна с падами

 

1. надо явным образом выписывать false paths для "медленных" сигналов (типа включить-выключить pull-up на двунаправленном паде)

2. можно забить на спецификацию input и output задержек (выставить их в 0) -- пады-то уже на месте.

3. можно точно так же не морочиться с set_drive/set_load по той же причине.

4. из минусов -- труднее протаскивать скан-цепочку (поскольку "пустые" пады для выходов тестовых векторов синтезатор, конечно же, прицепит куда-то -- или на 0, или на 1. И их придется отцеплять)

 

В общем, хотелось бы послушать ваше мнение по этому вопросу.

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


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

С падами, конечно.

Логика здесь следующая. Есть ТЗ, в нем указана спецификация интерфейса - тайминги, нагрузки, наклоны фронта. Все это аккуратно перекладывается в sdc (set-input-delay, set-load, set-transition и т.д.). Разумеется, эти констрейнты должны накладываться на выводы микросхемы, а не коре. А значит, пады должны быть обязательно. Уберете пады - не сможете правильно обконстрейнить интерфейс - не попадете в ТЗ.

К тому же, систему моделирования у верификаторов тоже надо сразу делать в расчете на топ уровень с падами. Добавлять потом уровень иерархии бывает сложно, лучше сразу все делать правильно. Для верификации вместо падов используют либо модели из библиотеки, либо самодельные поведенческие модели. Но для синтеза лучше иметь инстансами вызовы реальных библиотечных падов, которые выбираются исходя из ТЗ. Вписывают их ртльщики.

Хотя для SoC часто все сложнее - бьют дизайн на блоки, делают их отдельно, но в конечном счете все равно синтезируют топ-уровень с падами.

Изменено пользователем Aleх

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


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

Благодарю! У меня просто получилась смешная ситуация, когда заказчики не выдали требований на внешние сигналы.

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


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

2 часа назад, Aleх сказал:

Есть ТЗ, в нем указана спецификация интерфейса - тайминги, нагрузки, наклоны фронта. Все это аккуратно перекладывается в sdc (set-input-delay, set-load, set-transition и т.д.). Разумеется, эти констрейнты должны накладываться на выводы микросхемы, а не коре. А значит, пады должны быть обязательно. Уберете пады - не сможете правильно обконстрейнить интерфейс - не попадете в ТЗ.

Слушайте, ну констрейнты на корпус вы же учитываете в set_input_delay? Что мешает там же учесть и задержи на падах?

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


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

Соглашусь с комментариями, лучше с падами.

Вы и тайминги сразу закроете на весь дизайн и анализ потребления проведете. Я обычно функциональные пады добавляю на уровне rtl, а силовые уже на бэкэнде.

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

 

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


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

@dvladim Да все можно сделать, если хочется. Вопрос в том, как меньше шишек набить. Можно с падами синтезить, можно без падов. Но с падами результат обьективно лучше, а работы - меньше. Разумеется, если речь идет о верхнем уровне. Если дизайн бить на части, то внутри ведь падов нет. Точнее, не должно быть. Такая же точно ситуация - есть стандарт, где написано что пады дожны размещаться только в топе, а сам топ должен содержать одни иерархические блоки без стандарт селлов. Стандарт придуман для упрощения работы тулов, в частности - автоматической вставки JTAG TAP контроллера средствами синопсис, к примеру. Но если очень хочется, то можно этого стандарта не придерживаться. Просто, шишек больше набьете. А так, все можно )

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


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

Маршрут проектирования СНК существенно сокращается и упрощается по сравнению с маршрутом полностью заказных микросхем. Методология проектирования СНК приближается к методологии разработки систем на печатных платах. Основной этап проектирования – это системный. Именно на этом этапе определяются все основные характеристики разрабатываемого микроэлектронного устройства. Этапы функционального проектирования и верификации объединяются и упрощаются. Моделирование схемы на транзисторном и вентильном уровнях вообще может не проводиться. Используются только модели высокого уровня. Возможно и исключение этапа макетирования СНК, если все используемые СФ-блоки аттестованы и адекватно описаны на языках высокого уровня (VHDL, VHDL-AMS и др.). Физическое проектирование также существенно упрощается, т.к. число используемых СФ-блоков и сигнальных связей между ними сравнительно невелико. По существу СНК являются полузаказными микросхемами и основные затраты приходятся на создание системы проектирования и распространения СФ-блоков. Основная выгода состоит в том, что каждый

СФ-блок используется во многих изделиях. Кроме этого, в несколько раз сокращается время разработки конечных продуктов. Методология проектирования систем на кристалле предписывает выполнение проекта по двум направлениям.

  • Направление “сверху – вниз” включает:
  • cоставление общей спецификации на СНК;
  • разработку системной модели;
  • подготовку требуемой номенклатуры СФ-блоков;
  • функциональное моделирование СНК;
  • физическое проектирование;
  • верификацию модели.
  • Направление “снизу вверх” включает:
  • подготовку спецификаций на требуемые СФ-блоки;
  • отбор готовых блоков;
  • приобретение или разработку недостающих блоков;
  • разработку и верификацию моделей высокого уровня для используемых СФ-блоков.

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


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

Если сможете написать полные констрейны на логику, то думаю лучше разделить топ и саб. Синтез, ECO удобней, да и синопсис судя по всему так рекомендует (см. выше). Если же логика небольшая, то думаю проще с падами.

Для большой логики синтез не оптимален, приходиться делить на блоки.

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


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

Если микросхема чисто цифровая и делается в цифровых тулзах то пады ставятся в RTL в топе цифры. Правда часто пады имеют аналоговые сигналы которые надо  подключать аналоговым способом (как минимум запретить вставление буферов итп.). 

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

Если есть честный LIB падов то лучше с ними - задержки входов \ выходов учтутся автоматом... если конечно обконстрейнено всё правильно  в SDC (и если вообще сигналы через пады надо констрейнить).

Если честных LIB  нет то не принципиально. Задержки через пады можно и в SDC описать...

Можно как угодно :)

Для DFT с падами или без падов вообще без разницы.

-------------

"Возможно и исключение этапа макетирования СНК, если все используемые СФ-блоки аттестованы и адекватно описаны на языках высокого уровня (VHDL, VHDL-AMS и др.)"

Это из библии какой-то? :) Не знаю что такое "СНК" и "СФ" и чем способ "снизу" от способа "сверху отличается", но менять фло сообразно разуму и текущему моменту очень даже стоит :)

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


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

DFT в части баундари скан очень даже зависит от наличия падов. Тул из либы вычисляет функции портов пада, и окружает их соотв. тестовыми структурами. Конечно, можно и в слепую написать баундари спецификацию, но лучше все же иметь тайминг либы на пады, и генерить баундари структуры на автомате. На внутренний скан пады конечно же никак не влияют.

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


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

11 minutes ago, Aleх said:

Тул из либы вычисляет функции портов пада, и окружает их соотв. тестовыми структурами. 

Ка-кто давно я JTAG boundary scan вставлял тулзой....

Но насколько помню, ей достаточно видеть ТОП модуль на верилоге (RTL или нетлист) без падов.

Она тупо читает на верилоге что вход\выход, что указано как клок\ресет и вставляет нужные ячейки вокруг ТОПа.

--------------------------

Насчёт вкинуть ТОП с падами в DFT, для вставления boundary scan вокруг падов вместо портов ТОПа не знаю...

Я всё-таки думаю что boundary scan оборачивается вокруг ТОП модуля а не падов...

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


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

Возможно, это зависит от вендора тула. У меня опыт синопсиса и кеденса. Синопсис требует пады, и делает проверку того, что вставил (может отругаться, к примеру, что на tdo стоит тип пада просто выход, а не тристейт, может на отсутствие пуллапа отругаться). У кеденса как обычно все либеральней,  практически без проверки и с кучей багов, но и там спецификация требует наличия падов. А вот с ментором не работал. Впрочем, допускаю, что и без падов можно както баундари скан вставить, но не представляю как. Никогда так не делал.

Изменено пользователем Aleх

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


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

17 hours ago, Aleх said:

Возможно, это зависит от вендора тула. 

Cadence Encounter Test.С учетом того что в миксид сигнал чипах цифра внутри аналога и без падов, тулза просто обязана ставить боундари скан без падов...

А кстати зачем боудари скан вам понадобился?

Для теста самого чипа внутри он вроде как и не нужен....

 

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


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

Бандари скан в основном нужен для теста паек на PCB, ну и для отладки. В микросхемах эту штуку очень часто делают, годов с 80х.

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


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

Кто ни будь использовал JTAG боундари скан при генерации ATPG чтобы стимулировать входы и читать выходы цифры?

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


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

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...