[demidrol 0]

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

 

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

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

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

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

 

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

[Aleх 0]

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

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

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

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

Изменено четверг в 17:40 пользователем Aleх

[demidrol 0]

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

[dvladim 0]

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

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

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

[MickeyMouse 0]

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

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

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

 

[Shivers 0]

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

[zxw227 0]

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

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

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

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

[lexx 0]

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

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