[scorp 0]

Вопрос ко всем разработчикам проектов на FPGA, кому приходилось переводить проект на ASIC. С какими проблемами столкнулись и что пришлось исправить/доработать?

Не случайно размещаю тему в этом разделе. Речь идёт не о применении встроенных мегафункций ПЛИС, требованиях к быстродействию или площади кристалла, а именно о походах к созданию поведенческого описания в части тактирования, сброса т.д.

[des00 25]

вам сюда http://electronix.ru/forum/index.php?showforum=111

[FatRobot 0]

Если у вас в массе своей синхронный проект и приемлемое разбиение проекта на модули, то внимание нужно уделить следуюшим аспектам:

 

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

 

- Встроенные блоки памяти придется сгенерировать или синтезировать. Нужно оценить, что в кажом случае нужно: SRAM, RF, Synthesized FF. Геометрию, скорость и т.п. Примерно та же задача для ROM.

 

- Выбрать IO pads из стандартной/доступной библиотеки. Придется покупать/проектировать те, которых в библиотеке нет.

 

- Единообразный синхронный или асинхронный Reset должен доходить до всех FF

 

- Для модулей в интерфейс нужно добавить порты, отноясщиеся к bist и mbist

 

- Сделать и отладить по-возможности полную верификационную оснастку.

 

- Во могих случаях при внесении изменений в RTL с сохранением функциональности очень помогает LEC

 

- Придется поменять схемы тактирования и геренрации производных от тактовых частот под использование clock gating или вообще отказаться от производных (только FF EN в RTL). Либо покупать/проектировать блоки тактирования, аналогичные по функциям тем, что в плис. Здесь будет много интересных открытий, если в исходном описании широко использовалась практика тактирования обоими фронтами.

 

- Внимательно проверить SDC

 

Ничего сверхординарного. Там RTL, и здесь RTL. В итоге, если все эти шаги аккуратно сделаны, и на последующих этапах проектирования (которых тоже не мало) не произошло чудес, то должен получиться работоспособный кристалл

- слишком большой по площади

- слишком большой по потреблению.

 

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

 

Успехов.

[scorp 0]

Fat Robot, спасибо Вам за развёрнутый и подробный ответ! Передо мной стоит задача перевода чужого проекта, отработанного на ПЛИС, в ASIC. В ходе работы наткнулся на проблемы с отсутствием сброса многих триггеров, которые привели к неработоспособности дизайна уже на этапе моделирования нетлиста в базисе библиотеки. В этой связи стало интересно, есть ли кроме отсутствия сброса ещё какие-то моменты, типичные для ПЛИСоводов и неприемлемые для ASIC.

[topor_topor 0]

Fat Robot, спасибо Вам за развёрнутый и подробный ответ! Передо мной стоит задача перевода чужого проекта, отработанного на ПЛИС, в ASIC. В ходе работы наткнулся на проблемы с отсутствием сброса многих триггеров, которые привели к неработоспособности дизайна уже на этапе моделирования нетлиста в базисе библиотеки. В этой связи стало интересно, есть ли кроме отсутствия сброса ещё какие-то моменты, типичные для ПЛИСоводов и неприемлемые для ASIC.

Если симуляция падает из-за отсутствия ресета это не значит что RTL неправильный и тем более не будет работать. Тут кстати перевод в ASIC нипричём - както-же в ПЛИС это работало.

Ну и по поводу перевода в ASIC - незабудьте встроить тестовые структуры для производства.

 

 

- Встроенные блоки памяти придется сгенерировать или синтезировать. Нужно оценить, что в кажом случае нужно: SRAM, RF, Synthesized FF. Геометрию, скорость и т.п. Примерно та же задача для ROM.

- Единообразный синхронный или асинхронный Reset должен доходить до всех FF

- Придется поменять схемы тактирования и геренрации производных от тактовых частот под использование clock gating или вообще отказаться от производных (только FF EN в RTL). Либо покупать/проектировать блоки тактирования, аналогичные по функциям тем, что в плис. Здесь будет много интересных открытий, если в исходном описании широко использовалась практика тактирования обоими фронтами.

- Встроенные блоки памяти прийдётся либо заменить тригерами либо купить как IP (это аналоговая схема)... ну и встроить схему их тестирования при производстве...

- К Reset никаких вопросов. Может и не быть на тригере ресета, если начальное состояние пофик. Этот вопрос к особенностям ASIС никак не относится

- Незнаю чё там за блоки тактирования в ПЛИС, тут всё как с другими IP.

Тактирование по обеих фроттах - никаких поблем.... как и много других трюков с клоками.

Чтото переделывать под использование clock gating врядли надо....

[FatRobot 0]

Тут, как в анекдоте: "Теоретически мы с тобой миллионеры, а на практике ..."

 

Наверное, это ключевой момент дискуссии:

- Незнаю чё там ...

[scorp 0]

Тут кстати перевод в ASIC нипричём - както-же в ПЛИС это работало.

 

Не соглашусь. Простой пример – в ПЛИС начальное состояние триггера, в которое он устанавливается при подаче напряжения питания м/с может быть предопределено. Если функционал проекта завязан на это конкретное начальное состояние, то зашитая ПЛИС будет работать в приборе как положено. В ASIC начальное состояние несброшенного триггера не детерминировано. Типичная ситуация: многие ПЛИС-разработчики передают для миграции в ASIC проект без полноценных функциональных тестов, подкрепляя это тем, что "проект выверен и отработан на ПЛИС в составе приборе". В этом случае недетерминированное начальное состояние триггеров в кремнии приведёт к неработоспособности м/с в соответствии с задуманными алгоритмами.

 

Ну и по поводу перевода в ASIC - незабудьте встроить тестовые структуры для производства.

 

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

 

Тактирование по обеих фроттах - никаких поблем....

 

Были и такие проблемы, когда переводили проект в ASIC 0.35 мкм. Не хватало быстродействия - виоляции по путям от rising edge до falling edge. Впоследствии выяснилось, что решения о защёлкивании по rise или по fall разработчиком описания принимались неосознанно и никакого влияния на функционал не оказывало. Проект был отправлен на переработку. Вывод: быстродействие современных зарубежных ПЛИС "прощает" эти ляпы в данном случае.

 

 

 

... ну и встроить схему их тестирования при производстве...

Вывести интерфейс к блокам памяти для их тестирования снаружи? Или встроить логику для их тестирования внутри по заданным алгоритмам?

[topor_topor 0]

Не соглашусь. Простой пример – в ПЛИС начальное состояние триггера, в которое он устанавливается при подаче напряжения питания м/с может быть предопределено. Если функционал проекта завязан на это конкретное начальное состояние, то зашитая ПЛИС будет работать в приборе как положено. В ASIC начальное состояние несброшенного триггера не детерминировано. Типичная ситуация: многие ПЛИС-разработчики передают для миграции в ASIC проект без полноценных функциональных тестов, подкрепляя это тем, что "проект выверен и отработан на ПЛИС в составе приборе". В этом случае недетерминированное начальное состояние триггеров в кремнии приведёт к неработоспособности м/с в соответствии с задуманными алгоритмами.

 

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

 

Были и такие проблемы, когда переводили проект в ASIC 0.35 мкм. Не хватало быстродействия - виоляции по путям от rising edge до falling edge. Впоследствии выяснилось, что решения о защёлкивании по rise или по fall разработчиком описания принимались неосознанно и никакого влияния на функционал не оказывало. Проект был отправлен на переработку. Вывод: быстродействие современных зарубежных ПЛИС "прощает" эти ляпы в данном случае.

 

Вывести интерфейс к блокам памяти для их тестирования снаружи? Или встроить логику для их тестирования внутри по заданным алгоритмам?

1) Согласен - есть в ПЛИС возможность задавать начальное состояние с прошивки....

Плохо и странно если авторы ПЛИС решили это использовать, а переводчику в ASIC не сказали....

А может быть что им просто ресет не нужен, т.к. часть схемы самоустанавливается в процессе.

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

Интересно, такие розработчики SDC передают, или у них проект както сам компилился и прошивался?

3) "Были и такие проблемы, когда переводили проект в ASIC 0.35 мкм. Не хватало быстродействия" - иногда может нехватить даже если всё по одному еджу.

Понижайте Fmax или переходите на 0.18 :)

Да - при дизайне надо учитывать быстродействие и это вопрос к розработчику RTL.

Да - чтобы получить ASIC подешевле, а парибыль побольше - простым перебросом RTL с ПЛИС не отделаешся...как собственно и наоборот

4) Как тестировать внутренние блоки памяти - нет однрозначного ответа. Оба варианта возможны.

Вопрос в цене времени тестирования и дополнительно потраченной площади кристала.

Маленькую память проще снаружи, а для большой - встраивают BIST

 

ЗЫ

"защёлкивании по rise или по fall разработчиком описания принимались неосознанно"

а я смотрю технология "дизайн не приходя в сознание" становится всё популярнее :)

[Golikov 0]

Все популярнее становиться описывать что хочешь чтобы схема делала, а не саму схему. Не надо с этим бороться, вентили все дешевле, время все дороже... это не относиться к теме АСИКов, там есть смысл экономить.

 

а что такое SDC?

[Maverick_ 15]

а что такое SDC?

у альтеры SDC - у ксайлинкса UCF

PS симплифай, cadence тоже поддерживают формат SDC

[topor_topor 0]

а что такое SDC?

https://www.synopsys.com/Community/Interope...s/TapinSDC.aspx

[FatRobot 0]

Есть три кита timing closure при проектировании для ПЛИС (все в графической оболочке):

- поле "clock frequency"

- ползунок "speed - area"

- кнопка RUN

 

SDC для лохов и скучно

 

Интересно, такие розработчики SDC передают, или у них проект както сам компилился и прошивался?

а я смотрю технология "дизайн не приходя в сознание" становится всё популярнее :)

 

 

[Maverick_ 15]

Есть три кита timing closure для ПЛИС (все в графической оболочке):

- поле "clock frequency"

- ползунок "speed - area"

- кнопка RUN

 

SDC для лохов и скучно

а можно поподробнее пояснить про три кита?

[topor_topor 0]

Есть три кита timing closure при проектировании для ПЛИС (все в графической оболочке):

- поле "clock frequency"

- ползунок "speed - area"

- кнопка RUN

 

SDC для лохов и скучно

+ "а у меня на столе работало" - это четвёртый кит вместо верификации (UVM для лохов и ваще тоска зелёная)

[scorp 0]

Интересно, такие розработчики SDC передают, или у них проект както сам компилился и прошивался?

к сожалению, никаких SDC, значение тактовой частоты и клоковый пин, указанные в ТЗ – всё что есть :) Самое интересное начинается когда случайно обнаруживаются внутренние generated-клоки, полученные делением основного клока, о которых никто из ПЛИСоводов, с кем я работал, обычно не считает нужным предупредить. В связи с этим вопрос - есть ли тул, позволяющий выявить и законстрэйнить эти штуки сразу на этапе согласования исходных данных без лишней головной боли и разъяснений автору RTL, что это необходимо?

 

Понижайте Fmax или переходите на 0.18 :)

Fmax диктует заказчик, проектные нормы - руководство. Так и работаем )

 

ЗЫ

"защёлкивании по rise или по fall разработчиком описания принимались неосознанно"

а я смотрю технология "дизайн не приходя в сознание" становится всё популярнее :)

в точку ;)