demidrol 0 Posted March 14 · Report post Сижу и ломаю голову, как правильно было бы проводить синтез системы на кристалле: просто core-логику или ее же с прицепленными падами. Пока вижу такие особенности дизайна с падами 1. надо явным образом выписывать false paths для "медленных" сигналов (типа включить-выключить pull-up на двунаправленном паде) 2. можно забить на спецификацию input и output задержек (выставить их в 0) -- пады-то уже на месте. 3. можно точно так же не морочиться с set_drive/set_load по той же причине. 4. из минусов -- труднее протаскивать скан-цепочку (поскольку "пустые" пады для выходов тестовых векторов синтезатор, конечно же, прицепит куда-то -- или на 0, или на 1. И их придется отцеплять) В общем, хотелось бы послушать ваше мнение по этому вопросу. Share this post Link to post Share on other sites
Aleх 0 Posted March 14 (edited) · Report post С падами, конечно. Логика здесь следующая. Есть ТЗ, в нем указана спецификация интерфейса - тайминги, нагрузки, наклоны фронта. Все это аккуратно перекладывается в sdc (set-input-delay, set-load, set-transition и т.д.). Разумеется, эти констрейнты должны накладываться на выводы микросхемы, а не коре. А значит, пады должны быть обязательно. Уберете пады - не сможете правильно обконстрейнить интерфейс - не попадете в ТЗ. К тому же, систему моделирования у верификаторов тоже надо сразу делать в расчете на топ уровень с падами. Добавлять потом уровень иерархии бывает сложно, лучше сразу все делать правильно. Для верификации вместо падов используют либо модели из библиотеки, либо самодельные поведенческие модели. Но для синтеза лучше иметь инстансами вызовы реальных библиотечных падов, которые выбираются исходя из ТЗ. Вписывают их ртльщики. Хотя для SoC часто все сложнее - бьют дизайн на блоки, делают их отдельно, но в конечном счете все равно синтезируют топ-уровень с падами. Edited March 14 by Aleх Share this post Link to post Share on other sites
demidrol 0 Posted March 14 · Report post Благодарю! У меня просто получилась смешная ситуация, когда заказчики не выдали требований на внешние сигналы. Share this post Link to post Share on other sites
dvladim 0 Posted March 14 · Report post 2 часа назад, Aleх сказал: Есть ТЗ, в нем указана спецификация интерфейса - тайминги, нагрузки, наклоны фронта. Все это аккуратно перекладывается в sdc (set-input-delay, set-load, set-transition и т.д.). Разумеется, эти констрейнты должны накладываться на выводы микросхемы, а не коре. А значит, пады должны быть обязательно. Уберете пады - не сможете правильно обконстрейнить интерфейс - не попадете в ТЗ. Слушайте, ну констрейнты на корпус вы же учитываете в set_input_delay? Что мешает там же учесть и задержи на падах? Share this post Link to post Share on other sites
MickeyMouse 0 Posted March 15 · Report post Соглашусь с комментариями, лучше с падами. Вы и тайминги сразу закроете на весь дизайн и анализ потребления проведете. Я обычно функциональные пады добавляю на уровне rtl, а силовые уже на бэкэнде. Но вам все-равно нужно указывать констрейны описывающие внешние задержки и нагрузки(по крайней мере для синхронных портов чипа). Ну представьте что у вас имеется путь данных "внешний флоп - пад - внутренний флоп" а вы его не законстрейнили... Share this post Link to post Share on other sites
Shivers 0 Posted March 15 · Report post @dvladim Да все можно сделать, если хочется. Вопрос в том, как меньше шишек набить. Можно с падами синтезить, можно без падов. Но с падами результат обьективно лучше, а работы - меньше. Разумеется, если речь идет о верхнем уровне. Если дизайн бить на части, то внутри ведь падов нет. Точнее, не должно быть. Такая же точно ситуация - есть стандарт, где написано что пады дожны размещаться только в топе, а сам топ должен содержать одни иерархические блоки без стандарт селлов. Стандарт придуман для упрощения работы тулов, в частности - автоматической вставки JTAG TAP контроллера средствами синопсис, к примеру. Но если очень хочется, то можно этого стандарта не придерживаться. Просто, шишек больше набьете. А так, все можно ) Share this post Link to post Share on other sites
zxw227 0 Posted March 15 · Report post Маршрут проектирования СНК существенно сокращается и упрощается по сравнению с маршрутом полностью заказных микросхем. Методология проектирования СНК приближается к методологии разработки систем на печатных платах. Основной этап проектирования – это системный. Именно на этом этапе определяются все основные характеристики разрабатываемого микроэлектронного устройства. Этапы функционального проектирования и верификации объединяются и упрощаются. Моделирование схемы на транзисторном и вентильном уровнях вообще может не проводиться. Используются только модели высокого уровня. Возможно и исключение этапа макетирования СНК, если все используемые СФ-блоки аттестованы и адекватно описаны на языках высокого уровня (VHDL, VHDL-AMS и др.). Физическое проектирование также существенно упрощается, т.к. число используемых СФ-блоков и сигнальных связей между ними сравнительно невелико. По существу СНК являются полузаказными микросхемами и основные затраты приходятся на создание системы проектирования и распространения СФ-блоков. Основная выгода состоит в том, что каждый СФ-блок используется во многих изделиях. Кроме этого, в несколько раз сокращается время разработки конечных продуктов. Методология проектирования систем на кристалле предписывает выполнение проекта по двум направлениям. Направление “сверху – вниз” включает: cоставление общей спецификации на СНК; разработку системной модели; подготовку требуемой номенклатуры СФ-блоков; функциональное моделирование СНК; физическое проектирование; верификацию модели. Направление “снизу вверх” включает: подготовку спецификаций на требуемые СФ-блоки; отбор готовых блоков; приобретение или разработку недостающих блоков; разработку и верификацию моделей высокого уровня для используемых СФ-блоков. Share this post Link to post Share on other sites
lexx 0 Posted March 16 · Report post Если сможете написать полные констрейны на логику, то думаю лучше разделить топ и саб. Синтез, ECO удобней, да и синопсис судя по всему так рекомендует (см. выше). Если же логика небольшая, то думаю проще с падами. Для большой логики синтез не оптимален, приходиться делить на блоки. Share this post Link to post Share on other sites
topor_topor 0 Posted March 18 · Report post Если микросхема чисто цифровая и делается в цифровых тулзах то пады ставятся в RTL в топе цифры. Правда часто пады имеют аналоговые сигналы которые надо подключать аналоговым способом (как минимум запретить вставление буферов итп.). Если миксид сигнал, то часто цифра есть внутренним блоком аналогового топа. Тут пады тоже аналогово подключаются аналоговым дизайнером а цифра делается отдельно без них. Если есть честный LIB падов то лучше с ними - задержки входов \ выходов учтутся автоматом... если конечно обконстрейнено всё правильно в SDC (и если вообще сигналы через пады надо констрейнить). Если честных LIB нет то не принципиально. Задержки через пады можно и в SDC описать... Можно как угодно :) Для DFT с падами или без падов вообще без разницы. ------------- "Возможно и исключение этапа макетирования СНК, если все используемые СФ-блоки аттестованы и адекватно описаны на языках высокого уровня (VHDL, VHDL-AMS и др.)" Это из библии какой-то? :) Не знаю что такое "СНК" и "СФ" и чем способ "снизу" от способа "сверху отличается", но менять фло сообразно разуму и текущему моменту очень даже стоит :) Share this post Link to post Share on other sites
Aleх 0 Posted March 19 · Report post DFT в части баундари скан очень даже зависит от наличия падов. Тул из либы вычисляет функции портов пада, и окружает их соотв. тестовыми структурами. Конечно, можно и в слепую написать баундари спецификацию, но лучше все же иметь тайминг либы на пады, и генерить баундари структуры на автомате. На внутренний скан пады конечно же никак не влияют. Share this post Link to post Share on other sites
topor_topor 0 Posted March 19 · Report post 11 minutes ago, Aleх said: Тул из либы вычисляет функции портов пада, и окружает их соотв. тестовыми структурами. Ка-кто давно я JTAG boundary scan вставлял тулзой.... Но насколько помню, ей достаточно видеть ТОП модуль на верилоге (RTL или нетлист) без падов. Она тупо читает на верилоге что вход\выход, что указано как клок\ресет и вставляет нужные ячейки вокруг ТОПа. -------------------------- Насчёт вкинуть ТОП с падами в DFT, для вставления boundary scan вокруг падов вместо портов ТОПа не знаю... Я всё-таки думаю что boundary scan оборачивается вокруг ТОП модуля а не падов... Share this post Link to post Share on other sites
Aleх 0 Posted March 20 (edited) · Report post Возможно, это зависит от вендора тула. У меня опыт синопсиса и кеденса. Синопсис требует пады, и делает проверку того, что вставил (может отругаться, к примеру, что на tdo стоит тип пада просто выход, а не тристейт, может на отсутствие пуллапа отругаться). У кеденса как обычно все либеральней, практически без проверки и с кучей багов, но и там спецификация требует наличия падов. А вот с ментором не работал. Впрочем, допускаю, что и без падов можно както баундари скан вставить, но не представляю как. Никогда так не делал. Edited March 20 by Aleх Share this post Link to post Share on other sites
topor_topor 0 Posted March 20 · Report post 17 hours ago, Aleх said: Возможно, это зависит от вендора тула. Cadence Encounter Test.С учетом того что в миксид сигнал чипах цифра внутри аналога и без падов, тулза просто обязана ставить боундари скан без падов... А кстати зачем боудари скан вам понадобился? Для теста самого чипа внутри он вроде как и не нужен.... Share this post Link to post Share on other sites
Aleх 0 Posted March 22 · Report post Бандари скан в основном нужен для теста паек на PCB, ну и для отладки. В микросхемах эту штуку очень часто делают, годов с 80х. Share this post Link to post Share on other sites
topor_topor 0 Posted March 23 · Report post Кто ни будь использовал JTAG боундари скан при генерации ATPG чтобы стимулировать входы и читать выходы цифры? Share this post Link to post Share on other sites
