Выпуск #5/2003
В.Кравченко, Д.Радченко.
САПР компании Synopsys. Основные средства и возможности
САПР компании Synopsys. Основные средства и возможности
Просмотры: 7133
Компания Synopsys (www.synopsys.com) – мировой лидер среди производителей САПР СБИС. Продукты Synopsys обеспечивают разработку сложнейших СБИС и систем на кристалле (SoC). Компания также поставляет IP-блоки и предоставляет услуги по разработке СБИС, что позволяет заказчикам упростить процесс проектирования и сократить время выхода своей продукции на рынок. САПР компании Synopsys предназначена для работы с любыми КМОП-технологиями, вплоть до глубокосубмикронных (до 0,13 мкм и ниже) на всех этапах маршрута проектирования.
Маршрут проектирования (см. рис.) Synopsys включает системный уровень (разработка и отладка системы на функциональном уровне и уровне транзакций, отработка ТЗ системы как для аппаратной, так и для программной ее частей, совместная верификация ПО и аппаратуры), уровень регистровых передач RTL (разработка синтезируемого описания аппаратной части СБИС), вентильный уровень (разработка логического проекта СБИС) и топологический уровень (разработка топологического проекта). Synopsys поставляет свыше 50 различных инструментов разработки и верификации СБИС. Остановимся на самых основных.
На системном уровне разработка происходит в среде CoCentric System Studio. Этот уровень включает два подуровня – функциональный и уровень транзакций. На функциональном уровне (уровне алгоритмов) создается и верифицируется математическая модель системы в целом. На уровне транзакций можно моделировать архитектуру системы. Причем для разработки моделей используется ставший фактически промышленным стандартом язык SystemN. Очень важно, что уже на системном уровне CoCentric System Studio позволяет совместно моделировать аппаратную и программную части системы, определять их оптимальное соотношение. Верификация встраиваемого ПО в среде CoCentric System Studio может происходить совместно с верификацией системной модели аппаратной части.
Кроме SystemC, на системном уровне можно использовать модели на языках С/С++, Verilog, VHDL, Matlab, а также задействовать уже готовые IP-блоки. Для моделирования Verilog- и VHDL-кодов предназначены симуляторы VCS и Scirocco, соответственно. В частности, это позволяет, разработав системную модель сложного устройства, довести отдельный его блок до вентильного и даже до топологического уровня и верифицировать системную модель, используя уже готовый блок. В этом случае может выясниться, например, что какие-либо параметры, заложенные в блок на системном уровне, не реализуются, и тогда можно изменить саму систему.
Для перехода с системного уровня к непосредственному проектированию СБИС необходимо описание проекта на уровне регистровых передач (RTL). Переход от системной модели к RTL возможен двумя путями. Традиционный подход – это вручную писать соответствующий код на языках Verilog/VHDL. Описывать RTL-модели позволяет и SystemC, причем для этого не надо заново переписывать код – достаточно лишь дополнить существующее описание определенными конструкциями. Другой подход, предоставляемый CoCentric System Studio, – это генерация так называемой поведенческой модели на SystemC (синтезабельный код SystemC). При этом формируется некая модель в виде "черного ящика", у которой определены интерфейсы, временные характеристики, выполняемые функции, однако внутренняя структура не детализирована. Особенностью Synopsys является то, что из такой модели можно синтезировать логическое описание проекта. Иными словами, система сама синтезирует внутреннюю микроархитектуру СБИС. Для этого предназначен CoCentric SystemC Compiler, который формирует список цепей (netlist) в базисе внутренней библиотеки элементов Synopsys (библиотека GTECH).
Технология логического синтеза на основе поведенческой RTL-модели позволяет быстро получить ответ на вопрос, реализуема ли в принципе та или иная система и какие аппаратные ресурсы СБИС (число вентилей, площадь кристалла, энергопотребление, частотные характеристики и т.д.) для этого нужны. Причем синтезируемые CoCentric SystemC Compiler структуры если и превышают по числу вентилей разработанные вручную, то в среднем не более чем на 10%.
Отметим, что процесс разработки и верификации системных моделей существенно упрощают и ускоряют различные библиотеки системного и RTL-уровней. Основные из них – это Design Ware и Reference Design Kit (RDK). Библиотека Design Ware не имеет аналогов на рынке средств САПР благодаря уникальному набору функциональных параметризируемых блоков (от арифметических устройств до микропроцессорных ядер). RDK представляет собой набор системных моделей множества стандартов и протоколов – в области проводной и беспроводной связи, шинных интерфейсов и т.д. Он удобен, например, при разработке коммуникационного процессора для системы GSM, а модели всего стека GSM-протоколов для верификации модели этой СБИС можно взять из RDK.
За RTL следует вентильный уровень. Для работы на нем предназначено семейство продуктов Design Compiler. Эти продукты занимают на рынке долю около 80%, и фактически Design Compiler стал промышленным стандартом. Он представлен в двух версиях: стандартной Design Compiler Expert и расширенной – Design Compiler Ultra.
С Design Compiler стыкуются различные дополнительные инструменты. Например, DFT-Compiler формирует аппаратные средства контролепригодности синтезируемой структуры (JTAG, BIST, SCAN и т.п.), Power Compiler позволяет оптимизировать схему с точки зрения энергопотребления и т.д. Отметим, что готовые блоки и библиотечные элементы не транслируются повторно, а в Design Compiler передаются указатели на них.
Design Compiler оптимален для технологии до 0,25–0,18 мкм. На технологиях следующего уровня, с разрешением менее 0,18 мкм, начинают проявляться более тонкие физические эффекты. Для работы на этих глубокосубмикроных уровнях предназначен Physical Compiler . В отличие от Design Compiler, этот инструмент использует библиотеки топологического уровня и синтезирует не только список цепей, но и реальное размещение элементов на кристалле. Получив размещение, можно с точностью 5–10% оценить длину связей между элементами и по значениям их емкостей и сопротивлений определить времена задержек распространения сигналов в цепях.
Очень важно, что выходной формат Design Compiler и Physical Compiler стандартны: netlist – на языках Verilog или VHDL, описание размещения элементов – в универсальных форматах pdef, def, LEF, которые понятны продуктам других компаний. Таким образом, Physical Compiler можно использовать в маршрутах проектирования, например, компании Cadence.
Для работы с ПЛИС предназначен стыкуемый с Design Compiler инструмент FPGA Compiler II Add-On, который включает библиотеки около 80 производителей (Altera, Xilinx, Actel, Atmel, Motorola, Intel, Lattice и т.д.). Компания Synopsys позиционирует ПЛИС как средство аппаратной верификации. Именно поэтому разработку и ПЛИС, и заказной СБИС можно проводить в единой среде Design Compiler.
По завершении логического синтеза необходимо провести верификацию проекта. Для анализа временных статических характеристик предназначен пакет Prime Time. Это также весьма распространенный на рынке продукт. Он позволяет получить адекватное представление о поведении схемы, проанализировать его в наилучшем и наихудших случаях, обнаружить скрытые ошибки. У этого продукта есть расширение – Prime Time SI, предназначенное для анализа топологии. Оно позволяет отслеживать взаимовлияние проводников.
Для синтеза топологии служит инструмент Astro. Он предназначен для размещения, трассировки и оптимизации топологии. При размещении и трассировке учитывается влияние взаимных помех между отдельными проводниками и фрагментами схемы (например, можно запретить вести длинные связи в одном слое, размещать рядом мощные буферные элементы и т.д. ). Astro позволяет учитывать влияние физических эффектов, проявляющихся при технологическом разрешении меньше 0,18 мкм. Предусмотрена и защита от так называемого антенного эффекта, возникающего на стадии производства, когда остаточный заряд формирующегося проводника способен повредить уже подсоединенный к нему вентиль. Для борьбы с подобными явлениями предусмотрены определенные меры, например разбиение длинного проводника на несколько коротких в разных слоях, введение защитного диода и т.д. Astro позволяет определить те места, где антенный эффект может проявиться.
На выходе Astro получается готовая топология кристалла в формате gds2. Однако ее надо проверить, прежде всего – на паразитные RC-параметры. Для экстракции RC-параметров из уже готовой топологии предназначен инструмент Star RCXT. Полученные с его помощью RC-характеристики реальной топологии можно проанализировать с помощью того же Astro или Prime Time SI.
Кроме анализа временных параметров проверяются соблюдения правил проектирования (DRC) и правильности электрической схемы (ERC), т.е. правильность соединений, наличие не соединенных входов/выходов и т.п. Третья составляющая проверки топологии – восстановление из нее списка цепей и сравнение с исходным netlist (LVS). Все эти проверки реализует инструмент Hercules.
Отметим, что средства, предназначенные для работы на топологическом уровне, – Astro, Hercules, Star RCXT и т.д. – вошли в состав системы Synopsys после слияния этой компании с фирмой Avant! От нее же к Synopsys перешла и база данных MilkyWay, позволяющая работать с описанием проекта одновременно нескольким инженерам. Причем все изменения вносятся только в одну рабочую версию (разумеется, предусмотрено сохранение предыдущих версий), что исключает ситуацию, когда по ошибке в работе оказываются несколько копий проекта. В MilkyWay проекты хранятся во внутреннем закрытом представлении, что исключает возможность какого-либо непредусмотренного вмешательства в проект. Поскольку эта база данных – продукт компании Avant!, она совместима только с ее инструментами. Поэтому специалисты Synopsys работают над совместимостью с MilkyWay других инструментов платформы Synopsys (исключая системный уровень).
Разумеется, мы затронули лишь отдельные, наиболее значимые продукты Synopsys. Однако видно, что в этой среде проектирования можно решать сколь угодно сложные задачи, пример чему – разработка SPARC-совместимых процессоров семейства "МЦСТ-R" в компании "Московский центр СПАРК технологий". Подробно маршрут проектирования этих процессоров на основе САПР Synopsys описан в статье: Бабаян Б., Ким А., Сахнин Ю. Отечественные микропроцессоры серии "МЦСТ-R". – ЭЛЕКТРОНИКА: НТБ, 2003, №3. Именно в среде Synopsys создавалось синтезабельное ядро уникального сигнального процессора NM6403 компании "Модуль" – единственный отечественный IP-блок, который нашел покупателя на внешнем рынке. Подробнее о возможностях САПР Synopsys мы расскажем в последующих публикациях.
На системном уровне разработка происходит в среде CoCentric System Studio. Этот уровень включает два подуровня – функциональный и уровень транзакций. На функциональном уровне (уровне алгоритмов) создается и верифицируется математическая модель системы в целом. На уровне транзакций можно моделировать архитектуру системы. Причем для разработки моделей используется ставший фактически промышленным стандартом язык SystemN. Очень важно, что уже на системном уровне CoCentric System Studio позволяет совместно моделировать аппаратную и программную части системы, определять их оптимальное соотношение. Верификация встраиваемого ПО в среде CoCentric System Studio может происходить совместно с верификацией системной модели аппаратной части.
Кроме SystemC, на системном уровне можно использовать модели на языках С/С++, Verilog, VHDL, Matlab, а также задействовать уже готовые IP-блоки. Для моделирования Verilog- и VHDL-кодов предназначены симуляторы VCS и Scirocco, соответственно. В частности, это позволяет, разработав системную модель сложного устройства, довести отдельный его блок до вентильного и даже до топологического уровня и верифицировать системную модель, используя уже готовый блок. В этом случае может выясниться, например, что какие-либо параметры, заложенные в блок на системном уровне, не реализуются, и тогда можно изменить саму систему.
Для перехода с системного уровня к непосредственному проектированию СБИС необходимо описание проекта на уровне регистровых передач (RTL). Переход от системной модели к RTL возможен двумя путями. Традиционный подход – это вручную писать соответствующий код на языках Verilog/VHDL. Описывать RTL-модели позволяет и SystemC, причем для этого не надо заново переписывать код – достаточно лишь дополнить существующее описание определенными конструкциями. Другой подход, предоставляемый CoCentric System Studio, – это генерация так называемой поведенческой модели на SystemC (синтезабельный код SystemC). При этом формируется некая модель в виде "черного ящика", у которой определены интерфейсы, временные характеристики, выполняемые функции, однако внутренняя структура не детализирована. Особенностью Synopsys является то, что из такой модели можно синтезировать логическое описание проекта. Иными словами, система сама синтезирует внутреннюю микроархитектуру СБИС. Для этого предназначен CoCentric SystemC Compiler, который формирует список цепей (netlist) в базисе внутренней библиотеки элементов Synopsys (библиотека GTECH).
Технология логического синтеза на основе поведенческой RTL-модели позволяет быстро получить ответ на вопрос, реализуема ли в принципе та или иная система и какие аппаратные ресурсы СБИС (число вентилей, площадь кристалла, энергопотребление, частотные характеристики и т.д.) для этого нужны. Причем синтезируемые CoCentric SystemC Compiler структуры если и превышают по числу вентилей разработанные вручную, то в среднем не более чем на 10%.
Отметим, что процесс разработки и верификации системных моделей существенно упрощают и ускоряют различные библиотеки системного и RTL-уровней. Основные из них – это Design Ware и Reference Design Kit (RDK). Библиотека Design Ware не имеет аналогов на рынке средств САПР благодаря уникальному набору функциональных параметризируемых блоков (от арифметических устройств до микропроцессорных ядер). RDK представляет собой набор системных моделей множества стандартов и протоколов – в области проводной и беспроводной связи, шинных интерфейсов и т.д. Он удобен, например, при разработке коммуникационного процессора для системы GSM, а модели всего стека GSM-протоколов для верификации модели этой СБИС можно взять из RDK.
За RTL следует вентильный уровень. Для работы на нем предназначено семейство продуктов Design Compiler. Эти продукты занимают на рынке долю около 80%, и фактически Design Compiler стал промышленным стандартом. Он представлен в двух версиях: стандартной Design Compiler Expert и расширенной – Design Compiler Ultra.
С Design Compiler стыкуются различные дополнительные инструменты. Например, DFT-Compiler формирует аппаратные средства контролепригодности синтезируемой структуры (JTAG, BIST, SCAN и т.п.), Power Compiler позволяет оптимизировать схему с точки зрения энергопотребления и т.д. Отметим, что готовые блоки и библиотечные элементы не транслируются повторно, а в Design Compiler передаются указатели на них.
Design Compiler оптимален для технологии до 0,25–0,18 мкм. На технологиях следующего уровня, с разрешением менее 0,18 мкм, начинают проявляться более тонкие физические эффекты. Для работы на этих глубокосубмикроных уровнях предназначен Physical Compiler . В отличие от Design Compiler, этот инструмент использует библиотеки топологического уровня и синтезирует не только список цепей, но и реальное размещение элементов на кристалле. Получив размещение, можно с точностью 5–10% оценить длину связей между элементами и по значениям их емкостей и сопротивлений определить времена задержек распространения сигналов в цепях.
Очень важно, что выходной формат Design Compiler и Physical Compiler стандартны: netlist – на языках Verilog или VHDL, описание размещения элементов – в универсальных форматах pdef, def, LEF, которые понятны продуктам других компаний. Таким образом, Physical Compiler можно использовать в маршрутах проектирования, например, компании Cadence.
Для работы с ПЛИС предназначен стыкуемый с Design Compiler инструмент FPGA Compiler II Add-On, который включает библиотеки около 80 производителей (Altera, Xilinx, Actel, Atmel, Motorola, Intel, Lattice и т.д.). Компания Synopsys позиционирует ПЛИС как средство аппаратной верификации. Именно поэтому разработку и ПЛИС, и заказной СБИС можно проводить в единой среде Design Compiler.
По завершении логического синтеза необходимо провести верификацию проекта. Для анализа временных статических характеристик предназначен пакет Prime Time. Это также весьма распространенный на рынке продукт. Он позволяет получить адекватное представление о поведении схемы, проанализировать его в наилучшем и наихудших случаях, обнаружить скрытые ошибки. У этого продукта есть расширение – Prime Time SI, предназначенное для анализа топологии. Оно позволяет отслеживать взаимовлияние проводников.
Для синтеза топологии служит инструмент Astro. Он предназначен для размещения, трассировки и оптимизации топологии. При размещении и трассировке учитывается влияние взаимных помех между отдельными проводниками и фрагментами схемы (например, можно запретить вести длинные связи в одном слое, размещать рядом мощные буферные элементы и т.д. ). Astro позволяет учитывать влияние физических эффектов, проявляющихся при технологическом разрешении меньше 0,18 мкм. Предусмотрена и защита от так называемого антенного эффекта, возникающего на стадии производства, когда остаточный заряд формирующегося проводника способен повредить уже подсоединенный к нему вентиль. Для борьбы с подобными явлениями предусмотрены определенные меры, например разбиение длинного проводника на несколько коротких в разных слоях, введение защитного диода и т.д. Astro позволяет определить те места, где антенный эффект может проявиться.
На выходе Astro получается готовая топология кристалла в формате gds2. Однако ее надо проверить, прежде всего – на паразитные RC-параметры. Для экстракции RC-параметров из уже готовой топологии предназначен инструмент Star RCXT. Полученные с его помощью RC-характеристики реальной топологии можно проанализировать с помощью того же Astro или Prime Time SI.
Кроме анализа временных параметров проверяются соблюдения правил проектирования (DRC) и правильности электрической схемы (ERC), т.е. правильность соединений, наличие не соединенных входов/выходов и т.п. Третья составляющая проверки топологии – восстановление из нее списка цепей и сравнение с исходным netlist (LVS). Все эти проверки реализует инструмент Hercules.
Отметим, что средства, предназначенные для работы на топологическом уровне, – Astro, Hercules, Star RCXT и т.д. – вошли в состав системы Synopsys после слияния этой компании с фирмой Avant! От нее же к Synopsys перешла и база данных MilkyWay, позволяющая работать с описанием проекта одновременно нескольким инженерам. Причем все изменения вносятся только в одну рабочую версию (разумеется, предусмотрено сохранение предыдущих версий), что исключает ситуацию, когда по ошибке в работе оказываются несколько копий проекта. В MilkyWay проекты хранятся во внутреннем закрытом представлении, что исключает возможность какого-либо непредусмотренного вмешательства в проект. Поскольку эта база данных – продукт компании Avant!, она совместима только с ее инструментами. Поэтому специалисты Synopsys работают над совместимостью с MilkyWay других инструментов платформы Synopsys (исключая системный уровень).
Разумеется, мы затронули лишь отдельные, наиболее значимые продукты Synopsys. Однако видно, что в этой среде проектирования можно решать сколь угодно сложные задачи, пример чему – разработка SPARC-совместимых процессоров семейства "МЦСТ-R" в компании "Московский центр СПАРК технологий". Подробно маршрут проектирования этих процессоров на основе САПР Synopsys описан в статье: Бабаян Б., Ким А., Сахнин Ю. Отечественные микропроцессоры серии "МЦСТ-R". – ЭЛЕКТРОНИКА: НТБ, 2003, №3. Именно в среде Synopsys создавалось синтезабельное ядро уникального сигнального процессора NM6403 компании "Модуль" – единственный отечественный IP-блок, который нашел покупателя на внешнем рынке. Подробнее о возможностях САПР Synopsys мы расскажем в последующих публикациях.
Отзывы читателей