[Flood 12]

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

 

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

 

Известно, что Qualcomm отлаживает свои процессоры и модемы (в т.ч. пишет под них софт, когда чипов еще нет) на собственных FPGA-эмуляторах. Такая машина-эмулятор, по слухам, содержит от 2-х до 8-и блейдов по 15 виртексов максимальной емкости на каждом + активный бекплейн еще с несколькими огромными FPGA. Серия этих машин называется Rumi.

Интересно, какой софт занимается распиливанием нетлистов между таким количеством ПЛИСов и какая получается скорость работы (по-идее, модемные части SoC'а должны работать на реальных скоростях).

[lexx 0]

Обычно руками разделяется. А вообще: каждый из блоков на своей fpga, проц. и контроллер ddr на своих. Общение через шину, но поскольку выровнять пины невозможно то данные идут через через выскочастотный "one by wire". Частоты при этом не реальные а пониженные. Мне кажется у них все аналогично.

[RobFPGA 27]

Приветствую!

 

Интересно, какой софт занимается распиливанием нетлистов между таким количеством ПЛИСов и какая получается скорость работы (по-идее, модемные части SoC'а должны работать на реальных скоростях).

Тот же Synplify вроде позволяет в полуавтоматическом режиме разбивать ASIC проект для синтеза и эмуляции на HAPS платформе.

 

Успехов! Rob.

[yes 5]

off: вы будете таки смеяться, но после того как я повыступал в этой теме,

пришел заказчик, который требует прототипирования чипа на FPGA

 

заказчик отечественный и есть сомнения, что доведет до выпуска чипов, но тем не менее...

 

 

[x736C 0]

У меня была такая история. Разрабатывал несложный канал связи на ПЛИС. Можно предположить, что похожая в самом принципе проблема может возникнуть при разработке заказной ИС. Возникла из-за моей неопытности, но тем не менее.

Суть была такой. 2 видеопотока UDP ethernet объединялись с несколькими UART, добавлялась служебная информация, все это кодировалось и перед передачей на модулятор скремблировалось, т.к. в этой системе скремблер был необходим.

Моделирование показало, что система работает нормально. А далее так. На стенде уже на платах, когда проверял UART, все работало хорошо. Когда проверял ethernet — все отлично. А в сумме не проверил.

И уже на испытаниях, когда все было убрано в недра аппарата и пошли все потоки в своем аутентичном виде, связь стала падать. Оказалось, что разваливается скремблер.

Тут вы, наверное, скажете, что надо было замоделировать все входящие потоки. Но это было бы очень долго даже для относительно простого дизайна, т.к. скремблер вещь вероятностная. Если даже связь падает раз в 5 минут, то моделировать достаточно долго. И желательно иметь потоки данных, какие будут на целевой системе. Но это все, конечно, вполне просто проверяется и отлаживается на ПЛИС, чего я не сделал. Имея подобный опыт, могу предположить, какие вилы вылезают при разработке связных устройств Qualcomm или Broadcom. Или процессоров Intel.

[Koluchiy 0]

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

100500 раз видел людей, у которых не было время на отработку девайса на макете :cranky: .

 

Сразу лепили девайс, который они хотели видеть релизным :).

Вбухивали бабло в корпус, набивали ногой функционал в этот корпус, и т.д..

 

При этом, в итоге получали огромный гемор при отладке этого, иногда возвращались в итоге к разработке макета, и всегда теряли больше времени=денег, чем можно было изначально вложить в разработку макета :).

 

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

1) Разработать вместе с заказчиком ТЗ, которое не подвергнется корректировке в процессе разработки и опытной эксплуатации

2) Реализовать его без предварительного экспериментирования

3) Не наделать при этом ошибок, потребующих корректировки.

 

Но я таких в суровой реальности не встречал. А вот любителей поэкономить времени на необходимых этапах процесса - да сколько угодно.

Проблема собственно асиков в том, что в них переделки наиболее дорогие.

[lexx 0]

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

...

Но я таких в суровой реальности не встречал. А вот любителей поэкономить времени на необходимых этапах процесса - да сколько угодно.

Проблема собственно асиков в том, что в них переделки наиболее дорогие.

 

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

 

Для ASIC, не уверен что для всех, есть время для ECO. Но одного раза хватает для того чтобы понять на будущее, что это еще те трудности и всеми силами не влезать в это (хотя без этого никогда не обходится).

[Shivers 0]

ECO штука не волшебная, и не часто ей пользуются. Потому что:

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

2. Резервные пластины хранятся не вечно - 2-3 месяца, после чего фабрика снимает с себя ответственность за выпуск годных. За это время надо найти ошибку и исправить, отослав на завод новые слои металлов.

3. Возможности ECO ограничены - неизвестно, хватит или не хватит резервной логики для исправления ошибки.

4. Многие Российские дизайн-центры не умеют и/или никогда не делали ECO. Тут в первую очередь сказывается пункт 1 выше.

В общем, ECO - явление в РФ редкое, и собрать ПЛИС-макет уж куда дешевле, проще и быстрее!

[krux 8]

ECO требует перевыпуска части комплекта масок.

да, не всего комплекта, но всё же. от 1/4 до 1/2.

а выпуск комплекта масок - это самая дорогая операция при запуске производства ASIC. обработка пластин как правило существенно дешевле.

[lexx 0]

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

Кого-то это может спасти, если баг нашел в результате длительного тестирования на ПЛИС.

 

[starley 0]

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

Единственное исключение - это использование в СБИС только готовых топологических блоков.

Впрочем, российские реалии таковы, что ОКР на СБИС частенько заканчивается полностью или частично неработающей СБИС, а, иногда, ее и изначально применять особо не планируют. При таком подходе на ПЛИС, конечно, можно экономить. Главное, чтобы по бумагам все хорошо было.

[Dr.Alex 0]

российские реалии таковы, что ОКР на СБИС частенько заканчивается полностью или частично неработающей СБИС, а, иногда, ее и изначально применять особо не планируют.

 

Пруфы воспоследуют?

[Golikov 0]

Пруфов не будет, ОКРы всем закрывать надо:)

 

ПЛИС не применима для тестов времянки или скорости, потому что реально другая технология и другие расклады, ЛУТы потом никто транзисторами не будет собирать. Алгоритмы работы проверяются очень даже. Частота потом может быть эквивалентно пересчитана. Не все же микрухи просто интерфейсы гонять, есть же и СоКи всякие полезные :)

[Shivers 0]

ПЛИС не применима для тестов времянки или скорости, потому что реально другая технология и другие расклады, ..

Ну почему же. Если ПЛИС сделана по технологии на 2-4 поколения младше чем будет в ASIC, то скорости как правило хватает. К примеру, делаете Вы микросхему для 65нм, а ПЛИС сделан по 28 или 16нм.

Некоторые вещи в ПЛИС не промоделируешь, но можно найти замену; тот же PHY, к примеру: если у Вас микросхема будет с PCI-E на борту, то SerDes приходится делать для двух имплементаций - отдельно для ПЛИС и отдельно для ASIC. Кое что, действительно, вообще нельзя никак проверить в ПЛИС - какой нибудь навороченный кэш или регистровый файл с 12-ти портами. И бывает, редко, что логики настолько много, что действительно на full-speed ее нельзя проверить, и приходится снижать скорость. Но обычно все же удается гонять тесты на полной скорости, без проблем. Потому что ПЛИС уже чуть ли не по 10нм делают, а отечественные фирмы по прежнему редко когда ниже 100нм технологи используют - слишком дорого.

 

 

[Golikov 0]

Ну так не всегда проблема что скорости мало, иногда проблема что ее много:) О том и речь что построив что-то на ПЛИС нельзя померить времянки и сказать у меня также будет. Половина времянок ускоряется из-за ЛУТов вместо обычной логики, другая замедляется по тем же причинам %)

Поэтому в общем составить представление о времянках или скорости работы нельзя.

 

Но суть промоделить можно, для того и нужно