[x736C 0]

но "как на реальной железке" - даже не верится.

Если не надо эмулировать систему на уровне логических ячеек, то почему нет.

Виртуалки же вполне шустро крутят одну операционку с прикладными задачами из под другой.

Только это актуально для отладки софта, а не железа, о котором шла речь в этой теме.

[bogaev_roman 0]

получается что сапр такой как каденс со всеми пакетами для проектирования сбис стоящий 200 млн не способен в "адекватные" сроки "спроектировать" более сложную сбис нежели 555 таймер) в адекватные сроки

какое-то противоречие...

 

Знаю например что ангстрем не использует плис в своем маршруте но с другой стороны ангстрем процы не делает...

А о каком устройстве вообще идет речь - порядок логических вентилей, какие интерфейсы, скорости? В простых случаях, кстати, создание с нуля прототипа вообще не требуется - иногда достаточно отладочную борду (минимальные сроки и деньги).

но у Синопсиса были так называемые "платформ симуляторы" предназначенные для отладки софта

в RTL код процессор вставляется как некий предкомпиленный объект (написаный на С, а не на Верилоге) и тогда производительность симуляции становится сравнимой с рантаймом

Про такое я слышал, но говорили, что стоимость ну очень высока.

[Flood 12]

по поводу разработки софта для АЗИК процессора - гораздо разумнее использовать симуляторы, не знаю как у Каденса, но у Синопсиса были так называемые "платформ симуляторы" предназначенные для отладки софта

 

У Cadence, конечно, такое есть. Называется Cadence Palladium. Насколько знаю, цены там космические, но производительность, а также время компиляции проектов не сравнимы с обыкновенным прототипированием на ПЛИС. В результате применения таких платформ софт и драйверы для разного рода сложных чипов (SoC, GPU и т.п.) появляются раньше выхода первых чипов с фабрики.

В сети можно найти интересные презентации о применении Palladium в Nvidia и подобных конторах.

[yes 5]

У Cadence, конечно, такое есть. Называется Cadence Palladium. Насколько знаю, цены там космические, но производительность, а также время компиляции проектов не сравнимы с обыкновенным прототипированием на ПЛИС. В результате применения таких платформ софт и драйверы для разного рода сложных чипов (SoC, GPU и т.п.) появляются раньше выхода первых чипов с фабрики.

В сети можно найти интересные презентации о применении Palladium в Nvidia и подобных конторах.

 

Palladium это аппаратный ускоритель - та же ПЛИС, но за привязку к ней GUI и вообще, то что уже инженеры постарались, добавляет немало денег (вроде можно не покупать, а арендовать)

у Синопсиса аналог HAPS

 

а то чисто программный симулятор, но работает часто быстрее чем аппаратный, потому что модель более абстрактная

 

[favalligi 0]

Здравствуйте!

 

Подскажите пожалуйста кто действительно знает зачем нужны ПЛИС в процессе разработки СБИС?

Как я понимаю это нужно тем у кого нет достаточного пакета CADENCE, - кабибра, вируоза, енкоунтер и кто проектирует низкочастотную "логику"

Вопрос, - нафига ?, технология ведь все равно разная и в части высокочастотных интерфейсов такая отладка ничего не даст

Выскажу свое мнение по этому поводу с колокольни функционального верификатора.

Допустим вы разрабатываете высокоскоростной контроллер предположим PCIE 3.0 со своими приемопередатчиками и цифровой частью, которым рулит допустим MIPS-подобный процессор.

Первая не тривиальная задача для такого проекта при симуляции RTL описания, не говоря уже о нетлисте, даже при налиичи дорогостоящих гридов прогоны регрессий могут занимать по 2-3 дня. Синтез такого проекта в ПЛИС тоже занятие не быстрое, но в сравнение намного быстрей.

Во вторых вы правильно писали что ПЛИС для таких проектов стоят солидных денег, но опять же запуск партии на заводе того же TSMC стоит на порядки дороже, а цену ошибки я думаю оценить можно. Плюс к этому не забывайте что для симуляции вам помимо лицензии на САПР нужна еще лицензия на BFM(миниммум) либо комплексный тестсьют который все сделает за вас(тут ценник уже космический и не сравним с ПЛИС).

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

Так что обычно стараються проверить все и в симуляции, параллельно гоняя в ПЛИС какие-то нагрузочные тесты.

Изменено 18 января, 2017 пользователем favalli

[Poluektovich 0]

Для ранней отладки софта вендоры предлагают виртуальные платформы, которые состоят из быстрой ISS-модели процессора и TLM-моделей периферии.

Виртуальные можно использовать и с аппратными ускорителями, программа будет испольяться на ISS, а высокоскоростная периферия помещается в аппаратный ускоритель. А все вместе называют гибридной платформой.

[yes 5]

Звучит фантастически, хотя вероятно именно так и работают симуляторы всяких Nios2/Microblaze, но "как на реальной железке" - даже не верится.

 

известный "фри" симулятор qemu достигает где-то трети-половины (зависит от крутости хоста) для 500МГц АРМа

но он не "цикл-акурате", то есть сопрягать его с rtl-кодом не просто

 

предполагаю, что платные модели процессора имеют похожую производительность, а точная времянка требуется только от axi шины, но так как ни разу вживую такого не видел - то не уверен в этом утверждении - самому интересно

 

[radigast 0]

Вставлю свои пять копеек в эту тему.

 

Есть следующие основные подходы к моделированию аппаратуры до выпуска тестового чипа:

• высокоуровневая TLM/ISS модель
• собственно RTL
• ПЛИС
• ускорители/эмуляторы

 

RTL является непосредственном источником для дальнейшего проектирования ИС (если вы не используете HLS, который, на мой взгляд, пока применим только для отдельных подблоков, преимущественно аппаратных акселераторов какой-либо сложной математики). Поэтому хочешь - не хочешь, а RTL перед отправкой на финальный синтез моделировать придется. Также как потом придется моделировать и полученные нетлисты. Причем, даже при условии, что все уже было проверено в ПЛИС (как уже упоминалось, прототип в ПЛИС и RTL под синтез в ИС это не одно и тоже и, как минимум, придется перепроверять подключение макро памятей и физики)

 

Что касается дополнительного использования трёх оставшихся способов моделирования, то тут очень все зависит от типа устройства, ресурсов и времени, которые выделены на этот проект.

 

TLM/ISS на этапе проработки архитектуры хороши: можно поисследовать утилизацию архитектуры на реальных задачах, прикинуть разбиение алгоритма на HW/SW. Но реальные цифры по производительности на ней не получишь, реальный драйвер тоже не отладишь. Все-таки в RTL слишком много особенностей реализации, которые сложно учесть на этом этапе проектирования, а они бывает существенно сказываются на результатах работы ПО.

Потактовые модели ядер для данного уровня бывают, но это уже оптимизированные модели, сделанные для готового и апробированного RTL, который продается как IP. И тут речь уже идет скорее не о разработке таких моделей, а об экстракции из RTL и дальнейшей оптимизации (свободные тулы для этого — verilator, слышал о такой конторе как Carbon, которые профессионально этим занимаются).

 

С другой стороны моделирование RTL является слишком медленным для реальных задач, без которого не будет обратной связи по производительности, удобству программирования, и останется риск пропуска архитектурных и «хитрых» ошибок. В этом контексте ПЛИС идеально подходят для прототипирования:

• вычислительных ядер
• акселераторов
• сложной, но стандартной периферии, типа ethernet со встроенным алгоритмами обработки пакетов, и.т.п

Моделирование RTL, при этом, все равно никуда не уходит. Ставить непроверенный RTL в ПЛИС и тратить сутки на пересинтез и дебаг мелких багов, которые можно отловить за минуты/часы моделирования RTL — удовольствие ниже среднего.

 

 

При этом ПЛИС почти неприменимы для прототипирования периферии с собственной физикой.

Серьезные сложности возникают при попытке прототипировать целиком проекты больших СнК.

Для последней задачи как раз можно пользоваться эмуляторами. К слову в эмуляторах типа Palladium уже ставят не ПЛИС, а специализированные ASICи.

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

 

Жирные западные компании, как правило, имеют целые здания забитые серверами, число которых стремится к бесконечности и счетное число эмуляторов. В таких условиях запустить тысячи симуляций RTL может оказаться более быстрым способом проверки, чем использование эмулятора. Так, что с эмуляторами тоже не все так однозначно — все определяется теми возможностями, которые есть у компании. Опять же, для больших проектов возни с ПЛИС и эмуляторами может быть очень много.

[Koluchiy 0]

Чтобы сделать асик, прежде всего надо понять, какой нужен асик. Лучше всего для этого - сделать прототип на фпга и дать юзерам поиграться.

 

В большинстве случаев требования к асику изменятся.

[yes 5]

Лучше всего для этого - сделать прототип на фпга и дать юзерам поиграться.

 

прототип на FPGA это какой-нибудь Стратикс или старший Виртекс (и может не один), с источниками по 20А, размером 50х50 и местом под радиатор и т.п.

а прототипируемый АЗИК - это 10х10 с 0.5Вт потребления...

юзеры сильно удивятся с прототипа :)

 

[krux 8]

на дипчипе мелькали статейки про системы эмуляции, например http://www.deepchip.com/items/dac15-02.html

смысл эмуляторов - в возможности "видеть" каждый reg или wire на каждом такте, и значительное ускорение времени симуляции.

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

 

и это, не забываем, что при серии менее 10тыс штук экономически выгоднее ПЛИС чем ASIC.

[Koluchiy 0]

прототип на FPGA это какой-нибудь Стратикс или старший Виртекс (и может не один), с источниками по 20А, размером 50х50 и местом под радиатор и т.п.

а прототипируемый АЗИК - это 10х10 с 0.5Вт потребления...

юзеры сильно удивятся с прототипа :)

Под юзерами подразумевались, конечно же, не школьники с улицы, а разработчики и тестеры оборудования, куда планируется впихнуть этот асик.

[yes 5]

Под юзерами подразумевались, конечно же, не школьники с улицы, а разработчики и тестеры оборудования, куда планируется впихнуть этот асик.

 

по-моему

99% АЗИКов разрабатывается для каких-то носимых устройств. и это не процессоры/драйверы LCD и т.п. (что покрывается гигантами индустрии), а какие-то baseband-ы для обработки радиосвязи и т.п. - то есть имеет смысл проверка работоспособности в реальных условиях работы.

 

естественно, можно найти вариант прототипа на ПЛИС: делаются устройства, в которых реализуется только часть функциональности - ну типа там пара каналов, а в реальном АЗИКе их должны быть сотни, или делается стенд, который, например, можно возить на машине, а эмулируется карманное устройство и т.п.

для каких-то популярных систем (например, тех же GNSS) выпускаются симуляторы, которые могут изобразить эфирный сигнал всей системы в разных условиях "для платы на столе", но и стоят такие симуляторы $M

 

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

 

то есть, такая ситуация, что ПЛИС позволяет заменить все (или хотя бы большую часть) этапов разработки АЗИКа я не знаю. но я совершенно не утверждаю, что ПЛИС нужно запретить, при большом запасе времени и гибком дедлайне прототипировать на ПЛИС весьма интересно и полезно.

 

есть одно "но" скорее менеджерское, чем инженерное:

мне часто приходилось сталкиваться (особенно у отечественных заказчиков) с недоверием к алгоритмам - то есть они хотят на этапе "проверки реализуемости" получить какую-то железку с лампочками, а не софтверные модели и результаты симуляции - тут без ПЛИС не обойтись :)

 

 

[backend 0]

есть одно "но" скорее менеджерское, чем инженерное:

мне часто приходилось сталкиваться (особенно у отечественных заказчиков) с недоверием к алгоритмам - то есть они хотят на этапе "проверки реализуемости" получить какую-то железку с лампочками, а не софтверные модели и результаты симуляции - тут без ПЛИС не обойтись :)

Точно подмечено.

[lexx 0]

Я бы тоже не доверял дизайну без тестирования на FPGA.

Как уже было сказно выше:

1. Позволяет начать разработку/отладку софта/прошивки гораздо раньше

2. Интеграция на верхнем уровне и её прогонка/тестирование

3. Прогонка синтеза (по опыту был вариант, который приводил к ошибке, при этом симуляция проходила без проблем, линт ошибок не выявил)

4. Только функциональное тестирование занимает несколько недель, 24/7 (симуляция займет вечность)

5. Возможность прогонки тестов с различными задержками по шинам (еще месяц или больше)

 

P.S. есть специфические особенности FPGA, невозможно сделать полностью идентичный дизайн.

P.P.S. все очень зависит от размера проекта, но FPGA даже для маленьких предпочтителен.

P.P.P.S. нельзя сказать, что с FPGA лучше, чем без него, он скорее как молотилка данных (но иногда именно это и нужно), однако следует сочетать UVM like поблочно, FPGA, как глобальный и общая симуляция на топ уровне.

 

Зачем нетлист-то симулировать ? Я понимаю, что есть специфичные тесты для этого, но функциональное тестирование мне совсем непонятно. Если без задержек, то это просто бесполезно, поскольку аналогичен исходному коду. С задержками скорее пост-проверка на фукционирование, но это более опять же специфичный тест с post-layout, а не тестирование само по себе.